GPS gviing wrong Date

[Be Free]

Sorry, it took a while to digest and diagram that. Let's see if I got it right.

Your GPS antenna is connected to the GX2000 radio

The GX2000 is connected to the Quark
One or more SeaTalk devices are connected to the Quark
You have an AIS that is not always on connected to the Quark either via SeaTalk or NMEA0183 (does not really matter which way at this point).

The Quark is connected via WiFi to a laptop running OpenCPN

The Quark is connected via USB to a Pi running OpenPlotter.

You are converting the NMEA0183 to SignalK on the Pi.
You are running something on the Pi that plots your position (could be a SignalK plugin, another OpenCPN, something else??)

OpenCPN on the laptop is picking up SignalK from the Pi. Assuming WiFi.


Assuming all that is correct....


Your laptop and the Pi will always get a bad date from the GPS antenna and will always get a good one from the AIS (when it is on).

As I understand it, your laptop OpenCPN is receiving two (three when AIS is on) GPS position messages. That's going to cause problems.

First, identify and prioritize the AIS based GPS in OpenCPN. It is always right and will be coming in fastest. For each message type, OpenCPN will always use the highest priority connection and ignore the lower ones. Check your manual (or use the debug window) to see what messages your AIS is sending.

Your next best source will be SignalK. That is because you are going to fix the date before SignalK sends it out. Alternatively, you could set up a new connection in OpenCPN for UDP 10108 on from the Pi. Either would work. The UDP connection would be slightly faster but it may not be worth setting up another connection for it.

Your lowest message source on OpenCPN should be the raw GPS (via the Quark). Only use this as the last resort. The date will always be wrong.


Now, how to fix the date....

I'm assuming again, but OpenPlotter comes with a SignalK server. This assumes that you are using it.

SignalK has a Node Red Web App. You will need to use this; not a freestanding Node Red install. I don't think it comes pre-installed. You will find it in the SignalK Appstore. After it is installed you can access it through the Webapps page.

After Node Red is installed on the Pi you can import the routine that LeaseOnLife sent you. Pasting it from the clipboard is usually the easiest way to import. When you try to load it you will probably get errors regarding missing nodes. LeaseOnLife already told you how to load the missing nodes.

You are going to pick up the output from the Quark (its going to a serial connection but I don't know how it's going to look on your system) and use it as input to LeaseOnLife's flow.

The flow will output UDP 10108. You can feed that into the Sendpathvalue node (with a little massaging) to generate the SignalK output that is currently going out with the wrong date.


Finally...


The absolutely simplest fix is to connect the AIS to the GX2000 and everything will work perfectly.



You will still see two GPS sources in OpenCPN but the priorities I listed above will still fix them: AIS first, SignalK second.



An AIS should only be using around 3W on average so power should not be an issue.



As far as message rates go, the Pi should be able to handle them. Try it without the GPS antenna and see what happens.

[Be Free]

One more thing...


You could leave the GPS attached to the radio and disconnect the radio from the Quark. You would still need to prioritize the GPS inputs and keep the AIS but it would give you a working radio without needing the AIS to be on.


The only loss would be DSC messages will not be sent to the rest of the network unless the AIS is also picking up DSC (some do).

[LifePart2]

Bill, your assumptions are all correct and your solution is excellent, except for one thing. Everything comes in to the Pi by USB (or wifi) as a single source from the Quark, so OpenCPN cannot prioritize them. Is there some way to get some of the inputs into the Pi by a different route - using GPIO pins, for example? Then I could prioritize some.

I used to have a ShipModul 2 BT that worked great, and had filtering onboard. But it died so that one of the inputs no longer worked. Sadly I threw it out when I got the Quark which I bought as the BT version of ShipModul was no longer available, and on the surface it looked like the Quark did the same as the ShipModul but cheaper. Now I realise that it is missing the filtering.

The Pi also runs OpenCPN and functions as my main chartplotter. The AIS sends its data as NMEA 0183 through bare wires (no USB plug). I can either wire that into the radio (but not the same time as the GPS) or into the Quark. .

The laptop (windows 10) receives NMEA0183 by wifi from the Quark. It does not receive SignalK. I guess it could if I set up an access point on the Pi and use that instead? Does all the data (NMEA and or Signal K) get output to the network by default?

As for the NodeRed, I took a look at the documentation but could not see how to create/input a new node. Where do I paste in that JSON doc that LeaseOnLife kindly gave me? Is there a simple recipe for doing this, or is it going to involve hours of learning to get my head around it all? It is installed on Signal K/OpenPlotter.

I don't need the DSC messages in OpenCPN, so maybe removing that input is a way to go. The radio seems to be quite happy with the GPS information it is receiving but complains if there is no input. Also, when the Pi and Laptop lose GPS input (not infrequently) I see that the radio still shows a live (and changing) GPS position. So something is not right in the transmission of data from the radio to OpenCPN. I just re-did the wire connections so maybe it will be better now. When the laptop but not the Pi loses GPS I disconnect and then reconnect the wifi and that often fixes it. It is all this weird intermittent stuff that it doing my head in.

I do appreciate all your help with this. I really would like to get it all sorted out once and for all. It has consumed way to much of my time already - I want to be sailing, not fixing electronics or adapting to dodgy data.

Maybe the simple solution is to remove the radio to Quark link and just use the AIS input into the PI. I have noticed, however, that when the AIS is first turned on the large amount of data does crowd out the GPS information. It seems to take about 5 or 10 minutes for it to all settle down and give me a steady GPS stream.

Once again, thank you for taking the time to help me with this.

[LifePart2]

Some more info. The more I study this, the more confusing it gets.

I did some testing today. Kept the AIS off, so there was just one GPS receiver, going directly into the VHF and then from there to the Quark. Then watched the radio, laptop and the Pi as we sailed.

The position, SOG and COG on the radio remained solid and accurate (confirmed agains my Navionics on the phone).

Meanwhile I would get random aberrations on the Pi. At one point the boat moved down to 83 deg south and back again. At another time the position showed 25 deg 24.11 min North while, AT THE SAME TIME, the position on the VHF was 25 deg 25.07 North. On several occassions the Pi would show a COG of 478901838687326102374679329 or some other long string of random digits. At the same time both the radio and the laptop showed a COG of 142 deg. And another time it would show a wrong COG of, say, 76 deg.

Then the boat would disappear from the screen completely, and reappear. Or it would bounce back and forth a mile or so north south. Mostly it seems that it is the lattitude that is randomised, but not always. A quick trip to the prime meridian also happens.

All are using the same NMEA data stream, so where is the Pi getting these weird values from? According to the VHF they are NOT coming in on the raw NMEA data.

Obviously there is some logical solution, but how do I figure this out? I did try to record the VDR stream on the laptop, but then OpenCPN spontaneously died on me. It does that on both computers at times.

It is interesting also that the laptop (getting data by wifi) seems to be more stable than the Pi (USB Signal K). But both do weird stuff. So, is the corruption coming from the Quark?

So frustrating.

[Be Free]

Noel,
I have seen your update and will get to it as soon as I have some free time.

[Be Free]

Q: "Is there some way to get some of the inputs into the Pi by a different route - using GPIO pins, for example? Then I could prioritize some."

A: Yes, you can connect the GPS directly to the GPIO pins but it is not a good idea. The GPS is using RS442 and the PI is designed for RS232 signaling. They are close and you might get away with it but is is more likely to cause problems than what you have. Additionally, there really should be an opto-isolator between the two devices to protect the Pi.

If you want to go down this path there are devices that will translate between the similar but electrically different protocols and give you the isolation to protect your Pi. The Quark is already doing something similar so I don't see the advantage.

Q: "Does all the data (NMEA and or Signal K) get output to the network by default?"

A: All of the Signal K data is being created from the NMEA data coming into the Pi. Some of it is passing through the Quark from the radio or AIS, some may be coming off the seatalk bus. I'm not sure what you have there. In any case, the Pi is only seeing NMEA data on the serial (USB) connection.

All of the Signal K data on the Pi is available at port 3000. By default, Openplotter does not transmit the NMEA data but there are several tools built in that could be used. From a practical standpoint this is probably not the best way access the NMEA data over the network.

The Quark is already transmitting all of the NMEA data that the Pi could transmit. Just get it from the Quark. I think Quark uses TCP port 2000 by default.

Q: Regarding the Node Red flow that LeaseOnLife sent.

A: I'm not sure where you are having trouble with this one and I'm not sure at this point that you really need it. The radio is happy with the GPS even though the date is wrong. DSC will not care; the message only has a time field (which is correct). It does not use the date IIRC.

For other devices why not use the AIS?

Now, on to the odd position issues when you only have one GPS source connected.

As I understand it, you do not have any issues with the radio regarding position data as long as you have the GPS connected. All of the issues you are seeing are past the radio on the Pi and the laptop.

On those two devices you see intermittent problems with with location data. Sometimes it affects both, sometimes only one.

The laptop is connected via wifi to the Quark. The Pi is connected via USB to the same device.

Troubleshooting network issues is something I've made a good living at for a long time. That said, it is hard to troubleshoot problems like this remotely so I may be going down a rabbit hole.

My first impression is that this being caused by network corruption.

• USB connections are not well shielded from interference. How long is the cable between the Quark and the Pi. Do you see any potential areas of concern?
• From a command prompt on the laptop: (assuming Windows and Quart still set to default address)
  • ping 192.168.1.100 -n 100 This will send 100 short messages to the Quark which will send them right back to the laptop. When it finishes it will report packets sent, received, lost, approximate round trip times in milliseconds, minimum, maximum, and average.
  • ping 192.168.1.100 -l 82 -n 100 This will send 100 messages corresponding to the longest NMEA message you are likely sending. Report back the same information as the previous test.
• In OpenCPN on the laptop:
  • Create a TCP connection to the Quark. IP address is 192.168.1.100 and port is 2000 by default. Require a checksum.
  • Open NMEA debug window and report any errors.

[LifePart2]

Solved, I think!

There were several steps I had to do to get it working and stable, and they are different for the two pi's

Raspberry Pi 3B with OpenPlotter 2

I am still using this as it has the license for the Bahamas Explorer charts which cannot be ported across to the new Pi.

1) As per https://www.cruisersforum.com/forums...-222987-3.html I added CMA=384M to the /boot/cmdline.txt

2) I removed all the official US vector charts are they seem to be worse and less useful than the basic CM93, and also they don't cover the bahamas anyway.

3) I deleted all my old tracks.

4) I turned OpenGL OFF

5)On the connections I removed the Signal K connection and then added a straight USB serial connection to the COM port receiving the Quark USB input. The reason for this is that the Signal K node Red installation does not have the serialport node, and I can't install it on this version of NodeRed, and I can't update it without breaking the Signal K installation. Without the Signal K Filter there seems to be no advantage in using it over the basic USB connection.

Since this is now straighforward NMEA input, I then did input filtering on this in the Connections tab. First I opened up the NMEA Debug panel so I could see what sentences are arriving. I then ACCEPTED all of them except AIVDO, STALK, and any malformed ones ( I have things like $$$GPRMC showing up). This worked much better than REJECTING the bad ones.

Now it seems to run solidly without freezing and without jumping around.

Of course that does not fix the date issue on the GPS RMC sentences, but that is not a huge problem.

Raspberry Pi 4B 8Gb with OpenPlotter 3 and B&G Halo 20+ radar

I had huge problems trying to get this new installation to work with the radar. Eventually I just got a copy of an installation on a friend's boat that is working. I did have to use a cross-over cable to connect the Ethernit switch to the RPI.

On this the Signal K and Node Red are more upto date, and Signal K filter is an option in the menu. So here I have stayed with Signal K and am using the Filter to keep only the good sentences. I will also install the SerialPort node into NodeRed and then use that to run with LeaseOnLife's nice litter script. Not done that yet, but am optimistic.

As with the RPI3 I have removed the US charts, so at this point have only the CM93 charts which I have been using for 5+ years with no issues.

OpenGL is ON with none of the sub-options selected.

I also plan to move the installation onto a fast USB flash drive instead of the SD Card.

Windows 10 Laptop

The jumping around and freezing have been a problem on this too, so I did the same as for the RPI3. Connection to the Quark is by wifi with the same sentence filtering. US charts are gone. Tracks are deleted.

OpenGL is ON with the three sub-options except Show FRP selected.

I am optimistic that this will make things more stable.

So, thank you all for adding your thoughts and suggestions. Much apreciated.

[LeaseOnLife]

nice progress!
since you are having so much fun with it, I cleaned up that node-red flow a bit, it is very much the same but I cleaned out some non-used sh.t.

Copy below string into an empty node-red flow (tab).


I do not know how well nod-red deals with a possible disconnect/reconnect on USB/serial.

Just to give you more work or thoughts the latest gpsd is said to also correct for the date. You could have a gpsd daemon running that scans all USB-serial devices for gps input, corrects the date and then feed gpsd-out to signalk (localhost:2947 typically).
OpenCPN can read gpsd directly, or via signalk if you chose to.

[{"id":"9a0bfc528caf1cd7","type":"tab","label":"fix gps rollover for RMC","disabled":false,"info":"","env":[]},{"id":"8b3dfcc3196898b1","type":"switch","z":"9a0bfc528caf1cd7","name":"Filter just  GGA, GLL and RMC (not using VTG yet)","property":"payload","propertyType":"msg","rules":[{"t":"regex","v":"^(?=.*GPVTG)","vt":"str","case":false},{"t":"regex","v":"^(?=.*GPGGA)","vt":"str","case":false},{"t":"regex","v":"^(?=.*GPGLL)","vt":"str","case":false},{"t":"regex","v":"^(?=.*GPRMC)","vt":"str","case":false}],"checkall":"true","repair":false,"outputs":4,"x":510,"y":220,"wires":[[],["4b45ad5bdb5aaeba"],["4b45ad5bdb5aaeba"],["c9aedc21fae966f2"]],"inputLabels":["Input"],"outputLabels":["VTG, not used","GGA","GLL","RMC"]},{"id":"40ac89b14cd4b2e5","type":"function","z":"9a0bfc528caf1cd7","name":"calc checksum","func":"var nmea = msg.payload;\nvar checksum = 0; \n\nfor(var i = 0; i < nmea.length; i++) { \n  checksum = checksum ^ nmea.charCodeAt(i); \n}\nchecksum = checksum.toString(16);    //convert to hex\nnmea = '$' + nmea + '*' + checksum;  //make the full nmea sentence again\n\nmessage = 'Full message =' + nmea + '\\r\\n' + 'Checksum = ' + checksum ;\n\nmsg.payload = nmea;\nmsg.payload = msg.payload+\"\\r\\n\";\n\nvar msg1 = {\n     payload: msg.payload\n };\n return msg1;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1100,"y":240,"wires":[["4b45ad5bdb5aaeba","c016ba60e2b12d3e"]]},{"id":"4b45ad5bdb5aaeba","type":"udp out","z":"9a0bfc528caf1cd7","name":"","addr":"127.0.0.1","iface":"","port":"10108","ipv":"udp4","outport":"","base64":false,"multicast":"false","x":1320,"y":200,"wires":[]},{"id":"4ac892046a6980dd","type":"comment","z":"9a0bfc528caf1cd7","name":"This takes NMEA input, changes date string and adds checksum","info":"","x":630,"y":120,"wires":[]},{"id":"2cb081dbd65a7ee5","type":"inject","z":"9a0bfc528caf1cd7","name":"Inject GLL String","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"","payload":"$GPGLL,5930.030,N,00254.792,E,163415,A","payloadType":"str","x":140,"y":360,"wires":[["8b3dfcc3196898b1"]]},{"id":"8c5383b8a3a0ab82","type":"inject","z":"9a0bfc528caf1cd7","name":"Inject RMC String","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"","payload":"$GPRMC,163415,A,5930.030,N,00254.792,E,00.0,000.,171197,000.8,E*79","payloadType":"str","x":140,"y":440,"wires":[["8b3dfcc3196898b1"]]},{"id":"c016ba60e2b12d3e","type":"debug","z":"9a0bfc528caf1cd7","name":"","active":true,"console":"false","complete":"false","x":1310,"y":280,"wires":[]},{"id":"6b02859e49cc97d7","type":"inject","z":"9a0bfc528caf1cd7","name":"Inject GGA String","repeat":"","crontab":"","once":false,"topic":"","payload":"$GPGGA,163415,5930.030,N,00254.792,E,1,04,001,0001,M,040,M,,","payloadType":"str","x":139.99993133544922,"y":279.9999170303345,"wires":[["8b3dfcc3196898b1"]]},{"id":"5a9fc6ef80a924cd","type":"inject","z":"9a0bfc528caf1cd7","name":"Inject VGT String","repeat":"","crontab":"","once":false,"topic":"","payload":"$GPVTG,000,T,359,M,00.0,N,00.0,K","payloadType":"str","x":139.99993133544922,"y":199.99991703033447,"wires":[["8b3dfcc3196898b1"]]},{"id":"ec6fe99122981b0f","type":"debug","z":"9a0bfc528caf1cd7","name":"","active":false,"console":"false","complete":"false","x":1310,"y":80,"wires":[]},{"id":"c9aedc21fae966f2","type":"function","z":"9a0bfc528caf1cd7","name":"Create RMC string with correct date","func":"var nmeaFull=msg.payload;\n\nvar nmeaStripped=nmeaFull.substring(1, nmeaFull.indexOf(\"*\"));\n\nvar nmeaSplit=nmeaStripped.split(\",\");\n\nvar nmeaYear=nmeaSplit[9].substring(4, 6);\nvar nmeaMonth=nmeaSplit[9].substring(2, 4);\nvar nmeaDay=nmeaSplit[9].substring(0, 2);\nvar nmeaHour=nmeaSplit[1].substring(0, 2);\nvar nmeaMinute=nmeaSplit[1].substring(2, 4);\nvar nmeaSecond=nmeaSplit[1].substring(4, 6);\n//build a string to use with date()\nDateString=\"20\"+nmeaYear+\"-\"+nmeaMonth+\"-\"+nmeaDay+\"T\"+nmeaHour+\":\"+nmeaMinute+\":\"+nmeaSecond\n//make a proper date object out of the string\nvar d1 = new Date(DateString);\n// get the epoch timestamp from the date object\nvar timestamp =d1.getTime();\n// add 1024 weeks to the time stamp\n\n//timestamp=timestamp+(1024*7*24*60*60*1000); \ntimestamp=timestamp+619315200000; \n\n//back to date object\nvar d2=new Date(timestamp);\n//build the strings for YY MM DD HH MM SS, padded to 2 digits each\n//currently not modifying hours minutes seconds\n//nmeaSeconds=d2.getSeconds().toString().padStart(2, '0');\n//nmeaMinutes=d2.getMinutes().toString().padStart(2, '0');\n//nmeaHours=d2.getHours().toString().padStart(2, '0');\nnmeaDay=d2.getDate().toString().padStart(2, '0'); \n//wtf are months starting to count from 0 (0-11)\nnmeaMonth=d2.getMonth()+1;\nnmeaMonth=nmeaMonth.toString().padStart(2, '0');\nnmeaYear=d2.getFullYear().toString().padStart(2, '0');\n//pull the last two digits of the year\nnmeaYear=nmeaYear.toString().substr(-2);\n\n\nnmeaSplit[9]=nmeaDay+nmeaMonth+nmeaYear;\n\nvar nmeaFinal=\"NRRMC,\";\n\nvar i=\"1\";\n\ndo {\n    nmeaFinal += nmeaSplit[i] + \",\";\n    i++;\n}\nwhile (i < 11);\n\nnmeaFinal=nmeaFinal+nmeaSplit[11];\n\nmsg.payload = nmeaFinal;\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":860,"y":240,"wires":[["40ac89b14cd4b2e5"]]},{"id":"52045ad39e3088a8","type":"serial in","z":"9a0bfc528caf1cd7","name":"FurunoGP32 Serial Port Input","serial":"e8d62af109b62ece","x":140,"y":80,"wires":[["8b3dfcc3196898b1","ec6fe99122981b0f"]]},{"id":"e8d62af109b62ece","type":"serial-port","serialport":"/dev/FakeProlificRS232","serialbaud":"4800","databits":"8","parity":"none","stopbits":"1","waitfor":"","dtr":"none","rts":"none","cts":"none","dsr":"none","newline":"\\n","bin":"false","out":"char","addchar":"","responsetimeout":"10000"}]

[Richfind]

I have the same problem with 2 different GPS systems. It occurs to me that the manufacturers knew this was a problem when they designed the system. This is not the first time that the GPS system has rolled over, so they obviously knew beforehand. They did not include in the sales brochures or documentation that the GPS would be unusable after it rolled over.

Sounds like time for an enterprising lawyer to start a class action suit. The main goal would be to prevent manufacturers from ever selling a GPS that cannot deal with GPS rollover.

The secondary goal would be a large discount for a replacement system from the same manufacturer. Cash settlement usually does not work very well because the actual amount received is usually exceedingly small.

[ChristianV]

As somebody have alreay mentioned, its a known issue named date rollover affects. Most moden CPs can identify the issue and correct the right data.