GPS Recommendation

[CarCode]

Originally Posted by chuckr

I am not a techie - so bear with us

We are OpenCPN on a laptop and tablet with windows 10 -- our gps is a Hamlet blue tooth that is actually solar powered -
all I can say is it works and yes you have to go to 9600

The Hamlet has a very poor satellit sensitivity. If you want a far better blue tooth device get the Qstarz 818XT.
For bluetooth the baudrate doesn't matter, it is handled automatically by the SPP protocol of the bluetooth stack.

Gerhard

[solosail]

Originally Posted by barnakiel

OP has an input not an output challenge. It does not matter what can be done with the gps data once it gets in; the question is how to get the gps data in, in the first place.

kplex.conf tells you nothing about where the device attaches. But I am not going to tell this x times only this one last time.

I am not sure why you need kplex to get data from a gps puck to OpenCPN as a Linux based OpenCpn reads gps from serial or usb tty, without any need for kplex. As I have said before, I am not a Pi virtuoso just wondering why you guys make simple things difficult. Complex platforms make life difficult for the end user. KISS.

Make sure the driver is loaded.
Make sure the usb is recognised.
Check how the gps attaches to your machine.
(all these is done by checking linux machine startup logs)
View the flow on this specific tty.
Then attach this specific tty to OpenCPN config page in the GUI.

Puck status: blinks=locking on, steady=locked on. Depending on your puck, before locking on the signal the puck may provide zero data in the terminal window. Wait till the led is solid.

Use simple methods, and troubleshoot from the source, outwards, one step at a time.

Signing off,
b.

From the manufacturers support page (RASPBERRY PI – GlobalSat BU-353S4 GPS Installation | Instant Support Site) I installed :apt-get install gpsd gpsd-clients python-gps
Then entered the command:gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock

If I look at lsusb I can see the GPS
If i look at : sudo cat /dev/ttyUSB0 I can see the data stream.
If I look at : cgps -s I see the live position!

when I go to the Openplotter USB manager tab I see it (as dev/ttyUSB0) and add it. Then it shows up in the drop down under OpenCPN OPTIONS>CONNECTIONS>serial... dataport however nothing shows up?
In fact I have tried this on a strait OpenCPN install and have the same problem?
Any other ideas?

[barnakiel]

Originally Posted by solosail

(...)

Then entered the command:gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock

If I look at lsusb I can see the GPS
If i look at : sudo cat /dev/ttyUSB0 I can see the data stream.
If I look at : cgps -s I see the live position!

when I go to the Openplotter USB manager tab I see it (as dev/ttyUSB0) and add it.

Then it shows up in the drop down under OpenCPN OPTIONS>CONNECTIONS>serial... dataport however nothing shows up?
In fact I have tried this on a strait OpenCPN install and have the same problem?
Any other ideas?

Provided you

1) can see the port at OpenCPN dropdown menu (connections ...),

then you select it and assign the correct baud rate to it,

you should now get data flow both on the OpenCPN data monitor >

(... show nmea debug window OPTION at the upper part of same screen).

Can you see the data flow in the nmea debug window on OpenCPN?

You should also get a ship icon in the plotter, UNLESS the data debug window in OpenCPN shows garbled data.

BTW

Having played with gpsd I noticed at times the puck received some (instruction ???) from the gpsd module which caused the puck deliver nonsensical output. The only way I could deal with this was to leave it well alone for about 2 days (memory backup chip in the puck).

Google some for gpsd interaction with the puck then. This is one clue.

It is interesting that gpsd is there now that we know there is also kplex in between. This makes for many things that can contribute to your challenge. This is where team work sucks: you can always blame it on the next guy ...

So, I just bump you up as I cannot resolve any gpsd riddles having given up on gpsd at very early stages of my own gps/linux adventures.

BTW The other two clues are:

- make sure the puck is not 'dumbed' by gpsd - plug into a Windows machine, make sure it works ok there, and:

- do play with the baud rate speeds at OpenCPN. Mostly 4800 or 9600 though.

Wishing you luck,
b.

[chuckr]

Originally Posted by CarCode

The Hamlet has a very poor satellit sensitivity. If you want a far better blue tooth device get the Qstarz 818XT.
For bluetooth the baudrate doesn't matter, it is handled automatically by the SPP protocol of the bluetooth stack.

Gerhard

Never had an issue with connectivity - but then again

[CarCode]

Originally Posted by chuckr

Never had an issue with connectivity - but then again

Seeing a recommendation for the Hamlet I once bought it because of its build-in power supply by its solar panel. But because of its poor GPS features I never use it.
As bluetooth device I use the Qstarz which has a cold start time of about 30 seconds and shows normally about 10 sats then, while the Hamlet needs more then 1-2 minutes to show 3-4 sats in same environment.
It is a good idea to set the Baudrate for a bluetooth GPS to a higher rate because some of these devices are able to send with 10 Hz. Up to 115200 is possible.

Gerhard

[barnakiel]

There is also no speed issues when using wifi or ethernet gps data (IP under OpenCPN).

b.

[CarCode]

Originally Posted by barnakiel

There is also no speed issues when using wifi or ethernet gps data (IP under OpenCPN).

b.

Correct, but there are very few GPS WiFi devices available. Most devices without cable have bluetooth.

Gerhard

[bcn]

Which makes complete sense considering power consumption and required bandwidth.

[barnakiel]

Originally Posted by CarCode

Correct, but there are very few GPS WiFi devices available. Most devices without cable have bluetooth.

Gerhard

Well.

Most phones today have gps and wifi, so every phone becomes a wifi gps beacon. Or am I missing anything?

Also, they have BT, so they can be either wifi or BT beacons, as per user's request.

I have experimented with BT devices before I settled on wifi nmea. BT always gave me plenty of issues with pairing and paired devices lost, etc. Esp. on stripped down linux platforms.

b.

[barnakiel]

Originally Posted by bcn

Which makes complete sense considering power consumption and required bandwidth.

If power is an issue then I would stick with a cable.

IP nmea data can be sent via an ethernet cable.

I was shopping for a BT router some time ago only to discover such a thing did not exist. So, from utility and flexibility point, BT is a one trick pony - good if embeded but hard to work with if you develop your own hardware.

b.

[CarCode]

Anybody has its own experience.
One is able to write 4 chars to pair a bluetooth and another one is able to write the 4x 3 chars fields for IP and also other needed things to connect a smartphone to a PC. That is life...

Gerhard

[barnakiel]

Originally Posted by CarCode

Anybody has its own experience.
One is able to write 4 chars to pair a bluetooth and another one is able to write the 4x 3 chars fields for IP and also other needed things to connect a smartphone to a PC. That is life...

Gerhard

Yes. Indeed. All things have many aspects and it is in fact a bonus we have this many options.

BT specs seem better cut for small boat / low power connectivity (like, eg, on our 26' boat that is 99% solar driven).

I wish my nmea data could be sent over BT rater than wifi.

How would you send an available serial nmea data over BT? Is there something like a serial-BT adapter similar to the ones we use for sound / voice and video?

THX

barnakiel

[bcn]

Yes this does exist and is used in industrial environments. Or for feeding differential corrections in professional GPS receiver.

Pay attention that the devices you want to use for this serial connection do provide the SPP (Serial Port Profile) in their BT stack.
Most of modern phones don't have it (anymore).

[CarCode]

Originally Posted by barnakiel

I wish my nmea data could be sent over BT rater than wifi.

How would you send an available serial nmea data over BT? Is there something like a serial-BT adapter similar to the ones we use for sound / voice and video?

I use as source for AIS data the build-in AIS of my VHF radio RO4800.
Because I don't like cables attached to my laptop the serial output of the VHF is send via the FireFly device (attachment).

Gerhard

[CarCode]

For people interested in other GNSS than US-GPS like Glonass or Galileo:
The Galileo operator ESA announced today that 9 atomic clocks of their satellits are broken now. Actually they have 18 sats with 72 atomic clocks (4 for each sat).

Gerhard