This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problems with intermittent bad GPS data
#1
Photo 
Hi all,
A few months ago, I posted here about having problems with getting intermittent bad GPS strings from OP. Every so often, I'd get a LAT that was 00.000, which would cause my track to plot a line down to the equator and back. I turned off pretty much all of my SignalK to NMEA tools, and it seemed to rectify the problem. I also logged the data from my GPS, and confirmed that it was consistently giving me good data.

A few days ago, I decided to try the new beta version of OpenCPN, and switched to a SignalK connection to OpenPlotter. I'm at home now, but I leave it all running to keep track of AIS in the nearby marinas, and to see if the problem I described above is going to come back. It did come back. Here's an image of the track from my stationary system:

[Image: opencpn.jpg]
I zoomed out so you can see where the tracks go. The erroneous entries show in the track log like this:

Code:
     <trkpt lat="20.705389500" lon="-105.298959167">
       <time>2020-05-18T22:33:11Z</time>
     </trkpt>
     <trkpt lat="0.000000000" lon="0.000000000">
       <time>2020-05-18T22:33:17Z</time>
     </trkpt>
     <trkpt lat="20.705337000" lon="-105.298930500">
       <time>2020-05-18T22:33:19Z</time>
     </trkpt>

Here's another one:
Code:
     <trkpt lat="20.705309667" lon="-105.298937167">
       <time>2020-05-18T22:35:27Z</time>
     </trkpt>
     <trkpt lat="-89.906772203" lon="-89.906772203">
       <time>2020-05-18T22:35:31Z</time>
     </trkpt>
     <trkpt lat="20.705326167" lon="-105.298942667">
       <time>2020-05-18T22:35:34Z</time>
     </trkpt>

I've turned off tracking and cleared tracks several times, and after about a day I get this again. 

I can switch back to NMEA for OpenPlotter, and perhaps that would solve the problem for the moment, but I'm very interested in moving to SignalK as much as possible. This is becoming a barrier to me doing that. Since I had this problem in the past with OpenCPN 5.0, I'm reluctant to submit this as a bug to the OpenCPN team, as I think this may be a case of bad SignalK data coming from OP.

Does anyone have any ideas on how I might continue to troubleshoot this?

TIA

Andy
Reply
#2
Hello,
I've no idea how you'd troubleshoot the problem, but I've got the same thing with my setup. I'd put it down to my somewhat shonky SeaTalk - NMEA converter occasionally not being able to keep up with with the data flowing into it. Given the random nature of the problem I've never been able to tie down exactly what's going on with the boat when it happens. We've made some pretty long passages without any problems, and then been hit with it during a 5 mile hop between islands.

We don't use Signal K at all. It's NMEA all the way for us. How did you get rid of the problem originally?

Cheers
Dez
Reply
#3
I'm seriously considering writing a Node-Red script to just filter the bad stuff out, but I really, really don't want to do that if I can avoid it. It would have to do something like calculate distance from the last recorded point and then if it exceeds a certain amount, throw away the packet. In my case, for example, I could set it at 5 miles or something.
Reply
#4
Code:
[
   {
       "id": "39c8b420.aad2fc",
       "type": "serial in",
       "z": "1ffaa926.033937",
       "name": "",
       "serial": "e07f345a.d8c5c8",
       "x": 210,
       "y": 720,
       "wires": [
           [
               "dc3b0e5f.05996",
               "3b2c93cd.703aec",
               "b3c3d3a.4effc3"
           ]
       ]
   },
   {
       "id": "dc3b0e5f.05996",
       "type": "debug",
       "z": "1ffaa926.033937",
       "name": "",
       "active": false,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "false",
       "x": 570,
       "y": 620,
       "wires": []
   },
   {
       "id": "3b2c93cd.703aec",
       "type": "signalk-send-nmea0183",
       "z": "1ffaa926.033937",
       "name": "",
       "nmea0183Event": "nmea0183out",
       "x": 600,
       "y": 740,
       "wires": []
   },
   {
       "id": "b3c3d3a.4effc3",
       "type": "udp out",
       "z": "1ffaa926.033937",
       "name": "",
       "addr": "127.0.0.1",
       "iface": "",
       "port": "10111",
       "ipv": "udp4",
       "outport": "",
       "base64": false,
       "multicast": "false",
       "x": 650,
       "y": 840,
       "wires": []
   },
   {
       "id": "e07f345a.d8c5c8",
       "type": "serial-port",
       "z": "",
       "serialport": "/dev/ttyUSB0",
       "serialbaud": "38400",
       "databits": "8",
       "parity": "none",
       "stopbits": "1",
       "waitfor": "",
       "dtr": "none",
       "rts": "none",
       "cts": "none",
       "dsr": "none",
       "newline": "\\n",
       "bin": "false",
       "out": "char",
       "addchar": "",
       "responsetimeout": "10000"
   }
]




You could try deleting the serial signalk usb input in the serial app and using node red to bring the serial in, then send it udp on maybe port 10111 and send it to signalk as well. Leave opencpn on for a day listening to 10111 and another day on 10110. Might tell you something...  easy to record the data to a file as well, maybe both signalk & NMEA to see if they match?
Reply
#5
what about using GPSD? it will help with signal stabilization.

serial->GPSD->SK
Reply
#6
I don't know, I can give it a try, but I've done a lot of logging on the incoming USB serial port and I haven't seen any bad packets.
Reply
#7
(2020-05-20, 04:53 PM)PaddyB Wrote: You could try deleting the serial signalk usb input in the serial app and using node red to bring the serial in, then send it udp on maybe port 10111 and send it to signalk as well. Leave opencpn on for a day listening to 10111 and another day on 10110. Might tell you something...  easy to record the data to a file as well, maybe both signalk & NMEA to see if they match?

Oops, mistake in that node red - the signalk node sends nmea out from sigK , not nmea in to sigK, to get it working I set up another UDP output and an nmea connection into signalk. 
Seems to work though, the USB GPS dongle sends data straight to opencpn and also to signalk. Might be problematic to send other data like barometer etc to opencpn for the logbook/dashboard from signalk though.
Reply
#8
(2020-05-20, 06:07 PM)Sailoog Wrote: what about using GPSD? it will help with signal stabilization.

serial->GPSD->SK

Are there many cases that support this? Or is this just one user's anecdotal evidence? Having signal problems and attributing improvement to something you did is easy, even if the improvement was not related.

(2020-05-19, 02:27 PM)abarrow Wrote: I can switch back to NMEA for OpenPlotter, and perhaps that would solve the problem for the moment, but I'm very interested in moving to SignalK as much as possible. This is becoming a barrier to me doing that. Since I had this problem in the past with OpenCPN 5.0, I'm reluctant to submit this as a bug to the OpenCPN team, as I think this may be a case of bad SignalK data coming from OP.

Does anyone have any ideas on how I might continue to troubleshoot this?

Could this be just a case of your gps sometimes outputting bogus data?

What should be easy enough to verify: you should log the raw input data in SK Server. It is logged timestamped in the original format, NMEA0183 or N2K, prior to any conversions.

The data log files are hourly, so you should be able to find the offending input data where your track jumps.

If the input is nmea0183 it will have a checksum - precisely a mechanism for ensuring that the data is as output by the device. If the original nmea0183 data is good but the track still jumps we have a bug to hunt.

Early this year I took a stab at a more comprehensive approach to Signal K history db storage and retrieval. I used my last season's data, including the track. Turned out that also my data included bogus positions.

Now that you reminded me of this I should write a position sanitizer plugin, that would filter out data where either coordinate changes more than a certain amount compared to the latest & fresh position (getting no data for a while must disable the check, you may have moved with the gps connection not working). I think comparing the coordinates individually is enough, no need to calculate the distance between.

And as an exercise to the readers: how to deal with the 180th meridian? And what about the poles?
Reply
#9
Okay, at this point I've had my workstation running OpenCPN and pointing to my OpenPlotter server using SignalK. I've also got OpenCPN running on my OpenPlotter system which I'm accessing via VNC - that one is pointing to OpenPlotter and using TCP port 10110. Both have had tracking turned on for 24 hours.

Neither are showing a problem right now.

The only change has been that the beta version of OpenCPN was updated a day ago. I haven't heard of anyone else having this sort of problem with SIgnalK, but I'm hoping the update to OpenCPN solved the problem. We'll see.
Reply
#10
(2020-05-22, 08:46 PM)tkurki Wrote:
(2020-05-20, 06:07 PM)Sailoog Wrote: what about using GPSD? it will help with signal stabilization.

serial->GPSD->SK

Are there many cases that support this? Or is this just one user's anecdotal evidence? Having signal problems and attributing improvement to something you did is easy, even if the improvement was not related.
No more cases, just trying to isolate the problem. My bet was for a device malfunction but now it seems an OpenCPN beta issue.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)