Signal K Implementation

[Hakan]

Dave..
A small AIS load test.
Here I'm using a AIS feed that includes some 600 AIS targets. Streaming from my Win10 to SignK on RPi4 via UDP. The test of performance is done on a RPi3 wlan connected to RPi4-SignK.
CPU load on the RPi3 when:
Connected to SignK via SignalK socket and normal, ~50 AIS targets >> 40%
Connected to SignK via SignalK socket and about 600 AIS targets >> 55%
Connected to SignK via TCP/multiplexer and about 600 AIS targets >> 60%
Connected to SignK via TCP/multiplexer and normal, ~50 AIS targets >> 40%

Note: When TCP connected also depth, wind etc are parsed by the multiplexer and Dashboard.
Shots:
1. RPi3 when connected to SignK by socket and 600 AIS
2. Also when socket connected. S/Y MOMO is my boat as mentioned in my previous post.

[verkerkbr]

Originally Posted by verkerkbr

Good Morning Dave,

it did a simple test in the past. Outgoing output setting in OpenCPN. TCP localhost port 2000. And in the SignalK server setup new connection for incoming NMEA183 on port 2000.

That worked. See image with MX Tommy app (SignalK) showing distance and course of the OpenCPN route.

There is also an application for use as an autopilot called Pypilot made by Sean Depaigner. Using a route from OpenCPN to steer the autoplilot. Have not tried this yet. (Boat in winter storage).

But it is perhaps a good idea to look at the code of the Pypilot to see what is needed as output from OpenCPN.

Regards,


Bram

Small addition: I had restricted the output to SMB .

[bdbcat]

Hakan...
Your observations comparing sK to old-fashioned NMEA0183-by-TCP are generally correct.
1. We can, and will, adapt Dashboard to accept signalK input. I plan to prototype this soon, and see how it goes.
2. Overall, the boat data interfacing is in a time of transition. There are very few signalK clients available, other than a few chart plotter apps like OCPN. As far as I can see, there are no signalK compatible autopilots beyond pyPilot. We hope that situation will improve, in time. Meanwhile, signalK for OCPN is available as another tool in the OCPN toolbox, and may be useful for particular use cases.
3. The especial value of signalK is that, by autoDiscovery, it enables a real plug-and-play environment. This will become even better as more devices adopt signalK. And it will be very welcomed by new users, not to mention tech support personnel.



The current situation reminds me of the early days of WiFi. Lots of fiddling required to get everyone to play nicely. Strange device drivers, arcane CLI commands, etc. Now, of course, WiFi really is a reliable "plug-and-play" environment. We hope to see signalK evolve in the same way.



Bottom line: Most users today are well served by TCP/UDP. But we are ready for future developments.


Dave

[bdbcat]

Hakan...
I do not know why the s/y Momo (ownship) is not being filtered away by the logic. Works fine on my local test with live AIS data. I only can see three or four targets in my present location.


You may like to try some debug to analyze. The code for restricting ownship from the AIS decoder is at AIS_Decoder.cpp:358. There you will see the code:

        if (context == m_signalk_selfid) {
#if 0
            wxLogMessage(_T("** Ignore context own ship.."));
#endif
            return;
        }

Stepping through this method will be instructive.


Thanks
Dave

[verkerkbr]

Originally Posted by bdbcat

Hakan...
Your observations comparing sK to old-fashioned NMEA0183-by-TCP are generally correct.
1. We can, and will, adapt Dashboard to accept signalK input. I plan to prototype this soon, and see how it goes.
2. Overall, the boat data interfacing is in a time of transition. There are very few signalK clients available, other than a few chart plotter apps like OCPN. As far as I can see, there are no signalK compatible autopilots beyond pyPilot. We hope that situation will improve, in time. Meanwhile, signalK for OCPN is available as another tool in the OCPN toolbox, and may be useful for particular use cases.
3. The especial value of signalK is that, by autoDiscovery, it enables a real plug-and-play environment. This will become even better as more devices adopt signalK. And it will be very welcomed by new users, not to mention tech support personnel.



The current situation reminds me of the early days of WiFi. Lots of fiddling required to get everyone to play nicely. Strange device drivers, arcane CLI commands, etc. Now, of course, WiFi really is a reliable "plug-and-play" environment. We hope to see signalK evolve in the same way.



Bottom line: Most users today are well served by TCP/UDP. But we are ready for future developments.


Dave

Hi Dave,

don't forget that you can convert SignalK to NMEA2000. Then there are a lot of clients for the data export from OpenCPN.

And for routes etc. you need the data from OpenCPN. It would be nice if the output of OpenCPN could be used direct in the SignalK format

And SignalK can easily mix the incoming and outgoing streams. NMEA183, NMEA2K, SignalK.

Plus all the possibilities on other remote systems (internet ?) with this HTML SignalK in a browser.

Since NMEA2K is opened by SignalK/canboat the marine data communication is no longer closed,

The NMEA organisation is working on another standard called Onenet:

https://www.nmea.org/content/STANDARDS/OneNet

Regards,


Bram

[bdbcat]

Bram...


re:
don't forget that you can convert SignalK to NMEA2000.


And how does one do that today? By external hardware gateway? Or maybe in OCPN core?


Dave

[verkerkbr]

Originally Posted by bdbcat

Bram...


re:
don't forget that you can convert SignalK to NMEA2000.

And how does one do that today? By external hardware gateway? Or maybe in OCPN core?

Dave

Hi Dave,

if you look at the applications in the SignalK server list you can find:

"SignalK to NMEA2000" plugin by Scot Bender. So you can transfer the SignalK to an NMEA2K system. Or an nmea183 windset via SignalK to NMEA2K.

This Scot Bender developed a lot of instruments for SignalK. However only for Apple systems.

https://www.wilhelmsk.com/


You need a canbus adapter. I'am using the small and cheap Canable canbus. But the NGT-1 from Actisense can also be used.


Regards,


Bram

[bdbcat]

Bram...


OK, just to be extra-clear, so that all readers can follow the jargon, and imagine the wiring:


One can add a plugin to the node.js signalK server to convert signalK to N2K, and output the data by canbus or NGT-1 USB adapter attached to the device running the server. Often this is a separate rPI running OpenPlotter.


More detail:
Do we have a list of N2K client devices (e.g. autopilot), and their required pgn's? This will lead us to the required signalK sentences that need to be output by OCPN core...



Accurate?
Dave

[verkerkbr]

Originally Posted by bdbcat

Bram...


OK, just to be extra-clear, so that all readers can follow the jargon, and imagine the wiring:


One can add a plugin to the node.js signalK server to convert signalK to N2K, and output the data by canbus or NGT-1 USB adapter attached to the device running the server. Often this is a separate rPI running OpenPlotter.


More detail:
Do we have a list of N2K client devices (e.g. autopilot), and their required pgn's? This will lead us to the required signalK sentences that need to be output by OCPN core...



Accurate?
Dave

I don't have an autopilot with NMEA2K and I don't know what these systems need. My PyPilot system is not yet fitted.


This SignalK to the NMEA2K PGN's is still work in progress.


Accoding to the plugin SignalK > NMEA2K, these PGN's are allready available:

AIS (129794, 129038, 129041)Enabled

Battery (127506 & 127508)Enabled

Battery Mapping

COG & SOG (129026)Enabled

Depth (128267)Enabled

Temperature, exhaust (130312)Enabled

Engine Mapping

Engine Parameters (127489,127488)Enabled

Engine Mapping

Location (129025,129029)Enabled

Heading (127250)Enabled

Speed (128259)Enabled

System Time (126992)Enabled

Tank Levels (127505)Enabled

Outside Temperature (130312)Enabled

Inside Temperature (130312)Enabled

Engine Room Temperature (130312)Enabled

Refridgerator Temperature (130312)Enabled

Wind (130306)Enabled

Bram

[Hakan]

Autopilot N2K
Check here what Douwe did, although using an Actisense converter
https://github.com/douwefokkema/AutoTrackRaymarine_pi

[rgleason]

I believe Dashboard-tactics_pi is a signal k client. That is just one of the reasons I think it should be an internal plugin in lieu of dashboard.

[Hakan]

Originally Posted by bdbcat

Hakan...
I do not know why the s/y Momo (ownship) is not being filtered away by the logic. Works fine on my local test with live AIS data. I only can see three or four targets in my present location.


You may like to try some debug to analyze. The code for restricting ownship from the AIS decoder is at AIS_Decoder.cpp:358. There you will see the code:

        if (context == m_signalk_selfid) {
#if 0
            wxLogMessage(_T("** Ignore context own ship.."));
#endif
            return;
        }

Stepping through this method will be instructive.


Thanks
Dave

Dave..

Thanks for the hint. I understand the code you made for SignK is quit different from when passing through the multiplexer.
From here: m_signalk_selfid = (root["self"].AsString()); I see that a lot info is passed from the Signal-K server. Here you're looking for info about the own ship as stated at the SK server. And on my server on the RPi4 I didn't entered any own ship information.
So when having fed my SK server with a MMSI number the own ship AIS target is no longer drawn on the RPi3 client.
Thanks
Håkan

[Hakan]

Originally Posted by rgleason

I believe Dashboard-tactics_pi is a signal k client. That is just one of the reasons I think it should be an internal plugin in lieu of dashboard.

I suppose that's a misunderstanding? Only GPS data are shown. And actually I've not investigated how Dashboard does receive that.

Here all missing data are sent to SingK and are also returned. That I can see when I switch input from SignalK socket to a TCP connection. Then all data are shown on the Dashboard.
Håkan

[bdbcat]

Hakan...
re:
So when having fed my SK server with a MMSI number the own ship AIS target is no longer drawn on the RPi3 client.

You got it. Does not really matter what your ownship MMSI is, just as long as it is not matching some received external target. I think the OpenPlotter default MMSI is something like "123456789", a nonsense number that will never be seen as a valid target.



Thanks for looking
Dave

[Hakan]

Dave..
Ok, Understood. My list was total empty after some SK-reinstall and other stuff.
Håkan



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
9:27:03 PM: ** Signal K unhandled update: navigation.magneticVariationAgeOfService
9:27:03 PM: ** Signal K unhandled update: navigation.datetime
9:27:03 PM: ** Signal K unhandled update: environment.water.temperature
9:27:03 PM: ** Signal K unhandled update: navigation.log
9:27:03 PM: ** Signal K unhandled update: navigation.trip.log
9:27:04 PM: ** Signal K unhandled update: navigation.speedThroughWater
9:27:04 PM: Context: vessels.urn:mrn:imo:mmsi:265514850, 265514850
9:27:04 PM: Got MMSI from context.