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
#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


Messages In This Thread
RE: Problems with intermittent bad GPS data - by tkurki - 2020-05-22, 08:46 PM

Forum Jump:


Users browsing this thread: 1 Guest(s)