Signal K Implementation

[bdbcat]

All...
Back to signalK-output discussion.
After a round of exhausting reading about N2K interfaces (another topic entirely), I come back to the point:
1. In the real world, what device would listen to and care about signalK output from OCPN core? Over what channel should that signalK data be sent?

Today, the only useful one that I can see would be the current node.js signalK server, when enabled by a plugin to an N2K converter, talking to an autopilot on the N2K bus. I see nothing equivalent for the other signalK servers available (e.g. iKommunicate, and the other non-js signalK servers).
2. Please keep in mind that we are only talking here about route and waypoint following activities, including minimal autopilot control. So far, this seems to be the only data of relevance that OCPN core could send as signalK.



It seems unavoidable that we must conflate the signalK-output discussion with N2K conversion-and-output.


Examples of more real-life use cases, with real hardware, would help.


Dave

[seandepagnier]

pypilot currently accepts route following nmea APB messages. In the future it could accept signalk for this, as well as communicating other data like rudder angle or any sensors attached to the autopilot, as well send the sensors opencpn may have.

The pypilot plugin for opencpn already communicates via signalk on a tcp socket. Eventually maybe it could use the same tcp connection as the core rather than managing this through the plugin, but this is a slight advantage.

The pypilot implementation of signalk differs from the node implementation. The differences are not great, but it is unclear if an agreement can be found to make them compatible in the near future. It is difficult for me to accept unnecessary data bloat, the lack of dynamic fields, or the use of websockets since this only adds to lag and network congestion.

The standard implementation is written in javascript which as far as I can tell was chosen because the authors already knew it, not because it is the right language or platform to use. I don't operate a web browser for anything at sea or when disconnected from the internet.

There is also the failure of signalk to work on unreliable transports such serial ports due to lack of checksum. At this time there are no obvious advantages for most users because nmea0183 already works and supports all the data needed.

[bdbcat]

Sean...
I agree with much of what you say.
1. I also don't like to see javascript as the only viable implementation of sK. It seems limiting, as far as acceptance goes. And it probably is not the best platform for performance.
2. I am less concerned about the bloat in sK as defined today. This is why I am currently prototyping some simple (high level) sK interfaces for OCPN. I want to show, clearly, that the sK message traffic is not a significant factor in overall system performance, with "normal" hardware. But maybe I will be shown wrong....
3. I am now using WebSockets for communication, since the available sK servers do better with this method than with raw TCP. But again, this seems to be only by convention, not because it is "better" for our application.



Thanks for the input

Dave

[LennartG]

Dave,
the Garmin GHC20 seems to request the RMB, RMC, GLL, GSV, GGA, plus AMB but I assume that GSV and RMC can be omitted. (not tried).
The current SK to N2K interface can not handle the APB translations into PGN's '127237' '129283' and '129284', Nor is it translating RMB but I think that the PGN's generated from other NMEA0183 sentences are sufficient.

Still the '127237' '129283' and '129284' are show-stoppers. See also 'http://forum.openmarine.net/showthread.php?tid=2065&pid=11310'
/Lennart

[teppokurki]

Is autopilot control the only data that O produces itself?

I agree with the points that using sk does not provide any clear advantages over NMEA0183. But at the same time I want to point out that using one format/protocol everywhere will pay itself back over time: in network effects, ease of debugging, accumulated expertise.

The pypilot implementation of signalk differs from the node implementation

Separate thread for this: Pypilot and Signal K

The standard implementation is written in javascript which as far as I can tell was chosen because the authors already knew it, not because it is the right language or platform to use. I don't operate a web browser for anything at sea or when disconnected from the internet.

Node.js does provide one specific advantage: portability, including plugin portability.

But the reason why there is no server in language Z is the same as why there is no feature X in open source software Y: nobody has been willing and able to put the effort there. I would be more than happy to support this kind of work!

Please, the idea that JS is used only in browsers is outdated. As for "at sea" witness all the people running OpenPlotter, with SK included.

There is also the failure of signalk to work on unreliable transports such serial ports due to lack of checksum.

Again, let's have a PR to add a checksum to the spec and be done with it. Not exactly rocket science. I admit I could have moved this forward with more intensity, but there seems to be very little pull for it.

[teppokurki]

Originally Posted by bdbcat

All...
1. In the real world, what device would listen to and care about signalK output from OCPN core? Over what channel should that signalK data be sent?

As you said, sk node server with an autopilot at the end of the processing chain.

Both TCP and WebSocket are duplex, O can send data over the same connection.

[teppokurki]

Originally Posted by Hakan

Dave..
BTW: Some more log messages to omit after the debug period is ended.
I got 8000 rows of this for a 10 minutes period.

9:27:03 PM: ** Signal K unhandled update: navigation.magneticVariationAgeOfService
9:27:03 PM: ** Signal K unhandled update: navigation.datetime

This sounds like the subscription protocol is not working. You don't even need the unsubscribe message when using websockets if you use the query parameter ?subscribe=none

https://signalk.org/specification/1....aming_api.html

[teppokurki]

Originally Posted by LennartG

Dave,
the Garmin GHC20 seems to request the RMB, RMC, GLL, GSV, GGA, plus AMB but I assume that GSV and RMC can be omitted. (not tried).
The current SK to N2K interface can not handle the APB translations into PGN's '127237' '129283' and '129284', Nor is it translating RMB but I think that the PGN's generated from other NMEA0183 sentences are sufficient.

Still the '127237' '129283' and '129284' are show-stoppers. See also 'http://forum.openmarine.net/showthread.php?tid=2065&pid=11310'
/Lennart

If the autopilot input is 0183 it makes no sense to convert to SK and then back.

Clearly we need to invest in the O-SK-N2KAutopilot story.

[LennartG]

teppokurki,
I fully agrre on that, the GHP interfaces both RS422 (-> RS232 through a converter) and NMEA2K but as there are other instruments using NMEA2K (that are currently interfaced, one way, through TwoCan) it would be nice to reduce the number of interfaces.
Either TwoCan gets two-way NMEA2K communication or SK fixes the missing PGN's.
I have no need for fancy displays, just the interfaces.
/Lennart

[rgleason]

https://opencpn.org/wiki/dokuwiki/do...tware:nmea2000

PGN from Jose Louis

[rooiedirk]

Dave,
For some reason I can't get an websocket connection to my rpi.
log output:
14:54:52 CET: makeDataStream Signal K:10.42.0.79:8375
14:54:52 CET: ConnectionParams CTOR
14:54:53 CET: SK server autodiscovery finds no WebSocket server.
14:54:53 CET: Opening Signal K WebSocket client: Signal K:10.42.0.79:8375


But if I try to close O afterwards it will hang. I found it hangs in the while loop

void SignalKDataStream::CloseWebSocket()
{
    if(m_wsThread){
        m_wsThread->Delete();
        //TODO These timing loops could be tightened up
        // and add a deadman of say 2 secs.
        wxMilliSleep(1000);
        while(IsThreadRunning()){
            wxMilliSleep(10);
         }

It looks like a failure at starting forgets to set the running flag back to false.


PS the same loop keeps running if I try to disable the SignalK connection.

[bdbcat]

teppokurki....


re:
"This sounds like the subscription protocol is not working. You don't even need the unsubscribe message when using websockets if you use the query parameter ?subscribe=none"

This log flooding message stream comes from OCPN, and is for info only. It indicates that we are getting sK messages that we have no use for. If subscribed to "all", this will be a common situation.


Superfluous logging is being removed from source code as encountered.
Thanks
Dave

[bdbcat]

rooiedirk...
Have you checked "Auto discovery"? The websocket interface will most probably be on port 3000. Port 8375 is the TCP raw interface, and will not connect using a websocket protocol.



I agree with your observation about the failure if the connection is not established. I'll fix the code.


Thanks
Dave

[bdbcat]

All...


I agree strongly with this comment from teppokurki:


I agree with the points that using sk does not provide any clear advantages over NMEA0183. But at the same time I want to point out that using one format/protocol everywhere will pay itself back over time: in network effects, ease of debugging, accumulated expertise.


My addition:
We would all like to see signalK proliferate.
But it is not enough to "wish". We must "do".
OCPN is a relatively important player in the PC navigation space, and we have something of an obligation to play our part fully if we want to sit at the first table.


Dave

[seandepagnier]

Originally Posted by teppokurki

As you said, sk node server with an autopilot at the end of the processing chain.

Both TCP and WebSocket are duplex, O can send data over the same connection.

Is it correct that currently the only signalk message for opencpn to output is the nmea0183 APB equivalent? This is converted to either n2k or nmea0183 to control actual autopilots by sk node?

How about messages for manual control? Will this work with other autopilots over n2k? What messages are currently converted related to autopilots that opencpn can support in a generic way?

What about messages for informing the autopilot how narrow the channel is based on the chart or active route "area" this would allow the autopilot to trade efficiency for accuracy in some cases.

The pypilot plugin already sends a lot of different messages to configure the autopilot gains, calibrate sensors, set current/temperature limits and much more. It would be interesting to see what settings are similar to other autopilots supported through signalk.