multiple gps receivers

[seandepagnier]

I recently set up the openplotter moitessier hat which features a glonass gps receiver among other sensors. This hat works perfectly so far.

I still have my bu353 usb gps, and it is less that a meter away in the boat, but the two fixes are about 9 meters apart.

I can enable both with priority 1 in opencpn, and it switches between the two... but it would be nicer to pick one, and plot both somehow. I could write a hack to turn one into an ais target to get a track. This would be interesting to plot while sailing. Are there any other practical uses? Is there a good way to determine which is more accurate?


1) What about boats with multiple receivers in different locations? Should we handle this in the config?

2) Can/should plugins be able to access secondary gps?

[bdbcat]

Sean...

Leaving aside the questions of how to use two receivers at once, this is troubling...

"I still have my bu353 usb gps, and it is less that a meter away in the boat, but the two fixes are about 9 meters apart."

If both receivers report an accurate fix, how shall we decide which one to select for primary use? Can we get sensible HDOP values from them to help decide?

Dave

[Maelruan]

Access to a secondary GPS:

I find using a secondary GPS with a secondary plotter app to be very useful. One is an external unit via USB and the secondary is an internal card.
It means that 2 tracks are recorded, making a spare should one app crash, as has happened, and very inconvenient times. Saved tracks can be followed to return to a haven at night or thru thick fog. A good track over a narrow poorly marked channel can also be very useful.
Using a secondary GPS/plotter setup with more detailed charts for an area, or even Google Earth if there is a network signal, can greatly complement OpenCPN, especially when exploring estuaries and tidal areas.

However, a particular problem has arisen. OpenCPN will frequently find the signal from the secondary GPS even though that Com port is un-ticked in the Connections menu. While the debug screen shows that data in red and discards it, OpenCPN reports a heading of 180 degs @ 0kts, and sometimes diverts instantaneously to a point many miles away, before recording double the normal speed & returning to normal. This 180 deg business rang a bell: I think I read about it on the forum somewhere but can not now find that reference.
As to using GPS and GLONASS, I'll be further testing a new external GPS unit for which W10 insisted on installing new "u-blox 7" drivers and config app (u-centre) which gives options to select GPS, GLONASS, Galileo, and 3 other systems either separately or combined with any of the others.

[joel383]

My bu353 is very accurate, never more than a few ft difference from the map, or my garmin handheld.


Sent from my iGloo.

[MilesAhead]

Originally Posted by boat_alexandra

I recently set up the openplotter moitessier hat which features a glonass gps receiver among other sensors. This hat works perfectly so far.

I just got my Moitessier HAT and I simply cannot get the GPS to work. To be honest I'm an RPi newbie and there is all sorts of stuff I do not understand. But it seems that it is an issue with GPSD. By the way I'm using an RPi 3B+ and OpenPlotter 1.2.x. I've confirmed that everyhting is working correctly, except for the GPS.

I followed the instructions at https://docs.sailoog.com/openplotter...-ais-reception

If there are more recent instructions I would really appreciate you pointing me to them.

In OP if I assign the MOT to GPSD on the Serial tab, I get absolutely nothing out when I run the kplex diagnostic for GPSD. The screen is just blank.
If I assign the MOT to KPlex, with baud 4800, on the Serial tab, I get messages when I run the kplex diagnostic for MOT, but the GLL and GGA messages do not contain any lat/lot info. The lat/lon related messages are below.

Device Type Interval Data
GP GLL 1.0 ,,,,,080724.085,V,N*
GP GGA 1.0 ,080724.085,,,,,0,0,,,M,,M,,*

The heel, yaw, temp, and pressure sensors are working.

When I run
cat /dev/moitessier.tty
cat /dev/moitessier.spi
I get output, but again the GPS related messages do not contain any lan/lon info.

Any suggestions? Any pointers to configuration changes I need to make on Raspbian?

I think it is more of an issue at the Raspbian level, but, as I wrote earlier, I am far from an expert. I'm using an RPi 3B+ and there is a whole host of info on the internet about getting GPSD to work correctly with GPS USB pucks. And when I look at my /etc/default/gpsd it looks like the daemon isn't even started.
START_DAEMON="false"
USBAUTO="false"
DEVICES=""
GPSD_OPTIONS="-n -b"

But the Moitessier HAT isn't a USB puck, so I'm not sure how to set this correctly. When I try to start GPSD manually I get an error because I'm not specifying the device, but I do not know what device name to use. I can't run lsusb to find the device name because the HAT doesn't use a USB puck.

There are no instructions on either the OP or Moitessier web sites on how to set this up. Frustrating!!

[Tehani]

Originally Posted by bdbcat

Sean...

Leaving aside the questions of how to use two receivers at once, this is troubling...

"I still have my bu353 usb gps, and it is less that a meter away in the boat, but the two fixes are about 9 meters apart."

If both receivers report an accurate fix, how shall we decide which one to select for primary use? Can we get sensible HDOP values from them to help decide?

Dave

It is a good idea.
But it has the disadvantage that the different primary data (N2k, NMEA0183 and Seatalk1) set different resolutions for the HDOP. I think it is not advisable to compare this data to choose the source. (Seatalk delivers a resolution 100 times smaller than N2k and NMEA0183 can use a variable number of decimal digits).
Maybe "Sats in view" would work. It is a integer value.
Jose Luis

[bcn]

Originally Posted by Tehani

It is a good idea.
But it has the disadvantage that the different primary data (N2k, NMEA0183 and Seatalk1) set different resolutions for the HDOP. I think it is not advisable to compare this data to choose the source. (Seatalk delivers a resolution 100 times smaller than N2k and NMEA0183 can use a variable number of decimal digits).
Maybe "Sats in view" would work. It is a integer value.
Jose Luis

GSV, Sat in view does not help with some modern GPS chips: those are using a minimum number of sats for the fix, omitting sats with weak signals or less ideal geometry.
HDOP is an indicator of the quality of the geometry of the sats, but not by itself a guarantee for a good fix. You will not get a good fix with a bad HDOP, but two GPS with a similar HDOP can yield significantly different results.

All this said: If you don't have some antenna problems, an equipment generating noise in the GNSS frequencies, traveling on a channels with trees or deep in a Norwegian fjord, on a boat with a recent GPS reception is almost always a no-brainer.