opencpn has still flaws in NMEA ouput

[kumado77]

Dear programmers,
after having solved the connection of a GPS repeater to opencpn I identified many flaws in the ouput of NMEA phrases to listeners.


It's a pity, because opencpn is a great tool - gorgeous for looking on a PC's display, but not safe to send reliable NMEA signals to processors like autopilot or repeaters.
Please check my last article of how to hook up a GPS repeater.
In essence the flaws:
1) No communication hand shake between multiplexer and opencpn - overflow of buffer at listeners
2) Lack of GSA phrase in the NMEA sentences filter menu. Can be added manually, but could be also in the pick list. The content is made by the GPS and needs only to be routed through (with proper CRC)

3) Double RMC sentences with different content sent within milliseconds
4) ID (eventually set to GP at connection ) is not put through in NMEA sentence
5) Field #10 for magnetic deviation MUST in RMC be filled, can not be left empty, when no data available

6) Baudrate of 9600 for receiving GPS data delivers 2 sets of GPS data sent to ouput, one with good content, the other nearly empty
8) Waypoint info (RMB; APL, WPL) not sent over always. These infos can be seen on opencpn display, but is not sent as NMEA phrases
9) RMB sent not often enough. In the moment 5-10 seconds, should be down to 1-2 seconds for getting proper new bearing to waypoint.


All of them no big issues, since well identified. With them implemented, a easy USB-RS232/RS485 cnverter can be used and require no more a postprocessor fpr correcting the NMEA ouput so far prodcued by opencpn

Best regards

[bdbcat]

kumado77...

We can talk about a few of these points, if you like.

Taking some to start:

1) No communication hand shake between multiplexer and opencpn - overflow of buffer at listeners.

Of course, we could add the option to enable software or hardware flow control for special cases. But I have to say, in 10 years of interfacing OpenCPN to a variety of devices, we have never seen a device that could not process a few NMEA sentences at 1 Hz. rate. Never.
If a device truly cannot keep up with a steady stream of NMEA data, then no amount of flow control will help them in the long term.

And, by the way, I have never seen an NMEA listener that included hardware flow-control pins. Very rare, if at all.

So this one goes into the category of "Feature Request", not bug, for special situations.




5) Field #10 for magnetic deviation MUST in RMC be filled, can not be left empty, when no data available

It it normal for NMEA messages to omit data which is unavailable. If deviation is unknown, it is not sent by OpenCPN.
Again, we could add an option to send an "invented" value in the RMC message, to be used in special cases. Probably we would use the estimated deviation at the ownship position.

And again, I consider this a "Feature Request" for special cases, not a bug.

More later....

Regards
Dave

[rgleason]

Are you sure there isn't something else happening? Like something going on with your GPS Nasa Clipper repeater? I don't know how you could test this, but perhaps set a filter for that sentence to be inbound only, not out. Then see if it is still doubled? Maybe you've got some ricochet happening?

3) Double RMC sentences with different content sent within milliseconds


Another way to test. Filter that sentence both in and out. Then get a puck and see if it still happens.
Have you checked all your connections from the GPS repeater? That might be a source of the problem, any possible interference from other wires?

[rgleason]

"6) Baudrate of 9600 for receiving GPS data delivers 2 sets of GPS data sent to ouput, one with good content, the other nearly empty"

What? Normally GPS is 4800. AIS is set at 38400, Opencpn can also see "data" coming from Nmea2000 at about 230400, but it is gibberish.


Try setting it 4800.


"8) Waypoint info (RMB; APL, WPL) not sent over always."


Could this be also related to above?

[sy_gilana]

Beware of circular paths, ie NMEA coming in to O and then leaving O and then getting re-routed back in again via another device a few milliseconds later.

I suggest divide and conquer.


I suspect the issues you have are NOT from O, but some other anomaly.

Sometimes to find the real problem, all assumptions must be disregarded.

Never heard of 96k for NMEA streams.

Good luck finding the issue, and please report back.

[CapnRon47]

I have an issue with NMEA INPUT, so I thought I would start here as this topic has at least 2 out of the 3 terms! I am running the SignalK Server, on a Raspberry Pi, with a plugin that is generating NMEA 0183 sentences from SignalK sentence inputs. I am running OpenCPN ver 4.8.6 on the same Raspberry pi. If I open a terminal on the Rpi and type Telnet localhost 10110 I see the stream of NMEA 0183 sentences coming from the Signalk Server. But if I go to OpenCpn and use that as a data connection I do not see any sentences in the NMEA Debug Window. If I send the same NMEA sentences from an external source (its own IP and port #) to this Rpi, then I do see the sentences on the OpenCPN NMEA Debug window. Is there any reason why OpenCPN does not recognize "localhost" as a source?

thanks,
Ron

[bdbcat]

Ron...

OpenCPN does not recognize anything other than Q4 notation in the address field.

"localhost" is a semi-standard shorthand notation, used on many systems and apps. In OpenCPN, Instead of "localhost", use ip of 127.0.0.1. It is the same thing.

Dave

[CapnRon47]

That was the first alternative I tried, but with the same result; nothing in the debug window or dashboard.

[Paul Elliott]

Originally Posted by bdbcat

Ron...

OpenCPN does not recognize anything other than Q4 notation in the address field.

"localhost" is a semi-standard shorthand notation, used on many systems and apps. In OpenCPN, Instead of "localhost", use ip of 127.0.0.1. It is the same thing.

Dave

Using OCPN 4.8.4 , I entered "localhost" in the "Address" field and port# in the "DataPort" field and it connects just fine.

[bdbcat]

@Paul...
Glad "localhost" works for your system. It does not work everywhere....

@Ron:
Dunno what's up here with Sk server localhost. Is this a TCP/IP or UDP connection?

Dave

[bdbcat]

Ron...

Sorry, cannot help debug right now. Don't have the HW setup at the mo.
Maybe some other user has a similar setup, and can respond. Otherwise, it goes on the FLyspray list.

BTW, this thread has drifted.
Very few people read all threads every day. You will get better coverage if you start a new thread with very specific title. I suggest:
"SignalK on RPI as localhost"

That would get my attention.

Thanks
Dave

[seandepagnier]

It is for sure a bug in the databus design that it drops packets to prevent recursion of the event loop. This definately happens constantly on slow computers with lots of connections.

I saw more errors than success in the debugger window on a raspberry pi with ais, gps, and autopilot connections also functioning as a repeater.

It could use poll and regular sockets rather than wxsockets and events, and give correct operation with less cpu.

[bdbcat]

Sean...

It could use posix poll, and sockets, sure. But that gives us one more platform dependency to be maintained....

Dave

[did-g]

Originally Posted by boat_alexandra

It is for sure a bug in the databus design that it drops packets to prevent recursion of the event loop. This definately happens constantly on slow computers with lots of connections.

I saw more errors than success in the debugger window on a raspberry pi with ais, gps, and autopilot connections also functioning as a repeater.

It could use poll and regular sockets rather than wxsockets and events, and give correct operation with less cpu.

Is there a reproducible test?

Could using some kind of queue in wxSocket receiver help?

ie not sending an event for every NMEA put one with a list of NMEA sentences and moving it around, should work for TCP not sure for UDP datagrams and wsocket.


Moreover it's likely current code silently drops packets if OS buffers are full (wxSOCKET_WOULDBLOCK error), what should be done is not obvious, at least it should ring some kind of alarm.

[CapnRon47]

I am going to close out my question here since it was not really an OpenCPN issue. The issue turned out to be about getting the correct UUID (vessel ID) in the Signalk Server. Once that was corrected OpenCPN began showing the NMEA data in the debug window and dashboard; and it did not matter whether I used "localhost" or "127.0.0.1" as the source, both worked.

thanks,
Ron