OpenMarine

Full Version: GPS longitude error
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I seem to have GPS issue with kplex and signalk. 

I get a correct fix, but then every 30s or so longitude goes to 0 degrees. Then jumps back to my correct position. 

This is not the fault of the GPS unit (BU-353), as it also happens when I have signalk process the output from my Simrad NSS8 GPS.

Interestingly blocking GPS sentences in OpenCPN doesn't remove the issue. 

Any suggestions?

Code:
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $IIGLL,3638.6111,N,00627.1660,W,100028.020,A*33<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRMC,090028,A,3638.6111,N,00627.1660,W,6.2,302.2,180619,1.3,W*73<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIHDG,299.06,-1.32,E,,*0B<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKROT,-54.10,A*13<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRSA,2.14,A,,*00<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRMC,090028,A,aN0000NaN,N,NaN0000NaN,E,6.2,302.2,180619,1.3,W*14<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $INMWV,281.00,R,4.73,M,A*32<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIVWR,79.00,L,9.19,N,4.73,M,17.03,K*5D<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRSA,2.14,A,,*00<0x0D><0x0A>
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $SKGGA,090028,3638.6111,N,00627.1660,W,GNSS Fix,10,0.9,-3.29,M,-0.01,M,,*29<0x0D><0x0A>
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $IIGLL,3638.6111,N,00627.1660,W,100028.020,A*33<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRMC,090028,A,3638.6111,N,00627.1660,W,6.2,302.2,180619,1.3,W*73<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $INMWV,NaN,R,4.73,M,A*46<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIVWR,NaN,R,9.19,N,4.73,M,17.03,K*02<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIHDG,298.99,-1.32,E,,*0C<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKROT,-49.29,A*15<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRSA,2.14,A,,*00<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRSA,2.14,A,,*00<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $INMWV,NaN,R,4.73,M,A*46<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIVWR,NaN,R,9.19,N,4.73,M,17.03,K*02<0x0D><0x0A>
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $SKGGA,090028,3638.6111,N,00627.1660,W,GNSS Fix,10,0.9,-3.29,M,-0.01,M,,*29<0x0D><0x0A>
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $IIGLL,3638.6111,N,00627.1660,W,100028.020,A*33<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRMC,090028,A,3638.6111,N,00627.1660,W,6.4,302.3,180619,1.3,W*74<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIHDG,298.95,-1.32,E,,*00<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKROT,-38.22,A*18<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRSA,2.14,A,,*00<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $INMWV,NaN,R,4.73,M,A*46<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIVWR,NaN,R,9.19,N,4.73,M,17.03,K*02<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $INMWV,NaN,R,4.73,M,A*46<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIVWR,NaN,R,9.19,N,4.73,M,17.03,K*02<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRSA,2.14,A,,*00<0x0D><0x0A>
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $SKGGA,090028,3638.6115,N,00627.1667,W,GNSS Fix,10,0.9,-3.29,M,-0.01,M,,*2A<0x0D><0x0A>
<MAROON>11:00:32 (TCP:192.168.8.251:10110) $IIGLL,3638.6115,N,00627.1667,W,100028.020,A*30<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $SKRMC,090028,A,3638.6115,N,00627.1667,W,6.4,302.3,180619,1.3,W*77<0x0D><0x0A>
<GREEN>11:00:32 (TCP:192.168.8.251:10110) $IIHDG,298.96,-1.32,E,,*03<0x0D><0x0A>
This issue is typpical when having more than one source for gps.
The working gps sends many data.
The other one tells you that it doesn't get a fix -> 0 but not so often.
When you mix both data it will show up as you said.

You can try to find double Signal K paths in "Signal K diagnostic". The wrong data has to come from somewhere.
In kplex you can filter nmea0183. In Signal K sentences can be filtered in node red (this will be easier in v2.x.x).
I have been having the same problem outside of openplotter (bad GPS fixes).
Thanks for the insite. I have a Garmin 152H that is solid and smooth when underway.
My class B AIS also sends GPS strings, but it is erratic by a few meters, so I prefer the Garmin.
But both are connected to opencpn and that must be where the bad fixes com from. I'll filter the AIS fixes and see if the problem goes away.
Thanks!
I forgot about this until my recent passage.

I have a GPS (serial) attached to the Pi. Signalk seems to pick up sentences from this. The Pi is also connected to my NMEA2000 network.

I then have a chartplotter Simrad NSS8. This too is connected to the NMEA2000 network. The NSS8 also outputs its GPS sentences via the network, and again is picked up by Signalk, hence the duplication.

Is Node Red the way to go then to block one of these? There doesn't seem to be any open in the Openplotter settings, nor within Signalk to filter sentences.

I have no experience of using Node Red, is there a template to follow to do what I need?

Thanks
(2019-09-03, 12:14 AM)mikedeflieslife Wrote: [ -> ]I have no experience of using Node Red, is there a template to follow to do what I need?

This solution was published by sbender from the Signal K Team on the signalk-dev forum and it is really good. If the prefered gps is working it filters every other gps. If prefered gps is offline it feallback to other gps.
I think about adding this to the openplotter gui tools.
(https://app.slack.com/client/T02ENM6QA/C...225.072600)

It prefers N2K src=150. (It uses a subflow. If you didn't work with nodered subflow google it to be able to edit the prefered gps)

Code:
[{"id":"1a05e1f9.8eca1e","type":"subflow","name":"Prefer N2k GPS","info":"","category":"","in":[{"x":40,"y":40,"wires":[{"id":"d6944a31.d96088"}]}],"out":[{"x":380,"y":40,"wires":[{"id":"d6944a31.d96088","port":0}]}]},{"id":"d6944a31.d96088","type":"function","z":"1a05e1f9.8eca1e","name":"prefer Antenna","func":"\nconst timeout = 5\nconst prefered = '150'\nlet lastSeen = context.get('lastSeen')\n\n//node.error(`${JSON.stringify(msg.source)}`)\n\nif ( msg.source.src === prefered )\n{\n    node.send(msg)\n    context.set('lastSeen', Date.now())\n    //node.error('go it')\n} else if ( !lastSeen ) {\n    node.send(msg)\n    //node.error('no last')\n} else if ( Date.now() - lastSeen > (timeout *1000)) {\n    node.send(msg)\n    //node.error('timeout')\n}\n\n","outputs":1,"noerr":0,"x":220,"y":40,"wires":[[]]},{"id":"f8b48a68.917e28","type":"tab","label":"Input Filters","disabled":false,"info":""},{"id":"e61d660a.610a38","type":"signalk-input-handler","z":"f8b48a68.917e28","name":"navigation.position","context":"vessels.self","path":"navigation.position","source":"","x":130,"y":140,"wires":[["a638f26c.ad395"]]},{"id":"9397e0dc.6e543","type":"signalk-input-handler-next","z":"f8b48a68.917e28","name":"","x":780,"y":140,"wires":[]},{"id":"12c2f5e6.84575a","type":"signalk-input-handler","z":"f8b48a68.917e28","name":"navigation.datetime","context":"vessels.self","path":"navigation.datetime","source":"","x":130,"y":80,"wires":[["a638f26c.ad395"]]},{"id":"64f51379.986e4c","type":"signalk-input-handler","z":"f8b48a68.917e28","name":"navigation.speedOverGround","context":"vessels.self","path":"navigation.speedOverGround","source":"","x":160,"y":200,"wires":[["a638f26c.ad395"]]},{"id":"a638f26c.ad395","type":"subflow:1a05e1f9.8eca1e","z":"f8b48a68.917e28","name":"","x":500,"y":140,"wires":[["9397e0dc.6e543"]]},{"id":"25454890.bf3828","type":"signalk-input-handler","z":"f8b48a68.917e28","name":"navigation.courseOverGroundTrue","context":"vessels.self","path":"navigation.courseOverGroundTrue","source":"","x":180,"y":260,"wires":[["a638f26c.ad395"]]}]