Signal K Implementation

[stevead]

Sorry, but there are no PGN 129297 samples there.

What is needed is a capture from an EU Inland Waterways AIS transmission from a vessel with PGN's 129038 (Class A position report), 129794 (Class A Static and Voyage Related Data) and 129797 (Broadcast Binary Message).

129038 provides the vessel's MMSI number and Special Manoeuvre Indicator field,
129794 provides the matching MMSI number and the IMO field (which should be set to zero for EU Inland Waterways) and
129797 provides the matching MMSI number and the Designated Area Code (DAC) and Functional ID (FID) encapsulated in the binary message field.

I believe that OpenCPN should determine a vessel's "Blue Flag" status by testing for an IMO value of zero instead of testing for a DAC value of 200, which would make this discussion of how to process PGN129797 moot.

Refer to http://www.unece.org/fileadmin/DAM/t...S-SC3-176e.pdf

In anycase it would be great to have some sample data for PGN 129797 just so that we can understand how to interpret it. And while we're at it, samples of PGN 129808 Digital Selective Calling would round out my list.

[verkerkbr]

Inland shipping here in Europe with dangerous goods must show blue cone(s), depending and the danger of the goods. This blue cones are displayed also on the display on icon of the vessel.

I think that is the meaning of the blue pgn. Default should be zero.


Bram

[Hakan]

stevead...
I believe that OpenCPN should determine a vessel's "Blue Flag" status by testing for an IMO value of zero instead of testing for a DAC value of 200, which would make this discussion of how to process PGN129797 moot.


Good idea. Today's O code is looking for the DAC from VDM. Now we can use that for data from SK when originating from NMEA0183 and combine it with the IMO status for N2K data from SK.
For the moment IMO status is not sent from VDM NMEA0183 via SK. Will for sure be fixed.
Håkan

[verkerkbr]

Originally Posted by verkerkbr

Inland shipping here in Europe with dangerous goods must show blue cone(s), depending and the danger of the goods. This blue cones are displayed also on the display on icon of the vessel.

I think that is the meaning of the blue pgn. Default should be zero.


Bram

Looking a the table NMEA183 > NMEA2K


ABM (Ais adressed binary and safety related message) > 129795, 129797, 129811 129812


ABM - Addressed Binary Message ALA - Set Detail Alarm Condition ASM - Addressed Safety Message BBM - Broadcast Binary Message BSM - Broadcast Safety Message ETL - Engine Telegraph Operation Status EVE - General Event Message FIR - Fire Detection GAL - Galileo Almanac Data GEN - Generic Status Information GFA - GNSS Fix Accuracy and Integrity



BBM Ais broadcast binary message > 1129795, 129797, 129811, 129812

[stevead]

Bram, you are wrong. Don't confuse blue cones with blue flags!

Blue Flag means pass starboard to starboard.
Blue Cones identifies the type/level of hazardous cargo.

Blue Flag status is carried in the Special Manoeuvre Indicator field of PGN 129038.
Blue Cones is carried in the Binary Message Field of PGN 129797.

For the moment IMO status is not sent from VDM NMEA0183 via SK. Will for sure be fixed

Its not called IMO Status, it is called IMO Number and I would have assumed that is extracted from PGN 129794 alongside the ship's name.

The question for OpenCPN is whether it wants to achieve parity for displaying the equivalent details for inland waters vessels as it does for ocean going vessels (Ship or Combination Type, Length, Beam & Draft) and whether it wants to display the details specifically for inland waters vessels (Unique European vessel Identification Number, Number of Blue Cones). If so then it will need to parse the content of a Binary Message with a DAC value of 200 and FID of 10.

[verkerkbr]

Originally Posted by stevead

Bram, you are wrong. Don't confuse blue cones with blue flags!

Blue Flag means pass starboard to starboard.
Blue Cones identifies the type/level of hazardous cargo.

Blue Flag status is carried in the Special Manoeuvre Indicator field of PGN 129038.
Blue Cones is carried in the Binary Message Field of PGN 129797.

Its not called IMO Status, it is called IMO Number and I would have assumed that is extracted from PGN 129794 alongside the ship's name.

The question for OpenCPN is whether it wants to achieve parity for displaying the equivalent details for inland waters vessels as it does for ocean going vessels (Ship or Combination Type, Length, Beam & Draft) and whether it wants to display the details specifically for inland waters vessels (Unique European vessel Identification Number, Number of Blue Cones). If so then it will need to parse the content of a Binary Message with a DAC value of 200 and FID of 10.

Hi Steve,


your a right there are blue cone signs (dangeres goods 1, 2 or 3 cones) and blue signs (a square sign with a flashing light in the middle) indicating that ships pass each other at the wrong side),

I have never seen the indication on the screen that a ship show this blue sign.

The cone is permanent. The blue sign is temperary because of taking the inner side of a bend in a fast flowing river, like the Rhine or with approaching a mooring. Can this be switched on and off ?

Regards,


Bram

[verkerkbr]

Originally Posted by verkerkbr

Hi Steve,


your a right there are blue cone signs (dangeres goods 1, 2 or 3 cones) and blue signs (a square sign with a flashing light in the middle) indicating that ships pass each other at the wrong side),

I have never seen the indication on the screen that a ship show this blue sign.

The cone is permanent. The blue sign is temperary because of taking the inner side of a bend in a fast flowing river, like the Rhine or with approaching a mooring. Can this be switched on and off ?

Regards,


Bram

Yes, it is possible for inland schipping to show on the AIS screen the use of the blue sign.

But it can not be seen by the Ais of seegoing vessels.

There are warnings here of dangerous situations that can arise from the use of the Ais for this indication.

It is not automatically switched on or off together with the blue sign. It can easily lead to the wrong impression when not switched off.

It is only in use for inland shipping.

[Hakan]

Bram..
In OCPN blue sign, used/unused, looks like this:

[Hakan]

Originally Posted by stevead

Its not called IMO Status, it is called IMO Number and I would have assumed that is extracted from PGN 129794 alongside the ship's name.

I was referring to status of the SK information for the IMO number.
BTW is the status of that issue it's now implemented by the SK team and we just have to await next release.

[seandepagnier]

I am trying out signalk in opencpn today.

From what I can tell, it only receives signalk correct? There is no support to forward nmea connections stream to signalk or output autopilot route following correct?

if signalk-node exists it can be automatically detected by both opencpn and pypilot.

It might be interesting to allow opencpn to directly communicate with pypilot over signalk without using signalk-node in certain situations. I'm not sure how this will work if both act as clients.

[seandepagnier]

I am trying out signalk in opencpn today. It prints all signalk messages to stdout.

From what I can tell, it only receives signalk correct? There is no support to forward nmea connections stream to signalk or output autopilot route following correct?

if signalk-node exists it can be automatically detected by both opencpn and pypilot.

It might be interesting to allow opencpn to directly communicate with pypilot over signalk without using signalk-node in certain situations. Also linking opencpn to remote opencpn using signalk to finally allow syncronizing routes/tracks/waypoints and possibly other data like charts even. I'm not sure how this will work if both act as clients.

[bdbcat]

Sean...
Thanks for trying this out.
I like the idea of using sK for synchronization. Also not sure how it could work logically without a server in the loop. This calls for some thought.
Anyway, we go step-by-step.


Dave

[verkerkbr]

Originally Posted by boat_alexandra

I am trying out signalk in opencpn today. It prints all signalk messages to stdout.

From what I can tell, it only receives signalk correct? There is no support to forward nmea connections stream to signalk or output autopilot route following correct?

if signalk-node exists it can be automatically detected by both opencpn and pypilot.

It might be interesting to allow opencpn to directly communicate with pypilot over signalk without using signalk-node in certain situations. Also linking opencpn to remote opencpn using signalk to finally allow syncronizing routes/tracks/waypoints and possibly other data like charts even. I'm not sure how this will work if both act as clients.

Hi Ba,


I do not understand your question. It is possible to send route information from O to the SignalK server. However not yet in SignalK format but in NMEA183. This information is converted to SignalK and can be seen in applications like MXTommy.



This can probably be used by autopilot steering.

[hreuver]

I thought I'd just share this screenshot for those interested.

The picture shows OpenCPN in a testsetup with SignalK (and Firefox with KIP/mxtommy running in the background).

I started the programs with:
taskset -c 3 openplotter-i2c-read
taskset -c 4 opencpn
taskset -c 5 firefox
Therefore one can assume that the cpu-load of core #3 #4 and #5 (right side of htop info) are caused by openplotter, opencpn and firefox/KIP respectively. I might try later to get signalK to run on a specified core for the complete picture.

Testsetup includes for the data input a windset (app wind only) via canboat and a pressure sensor via openplotter.
Bottom line: OpenCPN can handle signalK easily in power saving mode.

===================
Some details:

The opencpn-version is a little silenced by the logging commit Leamas posted yesterday (i.e. signalK logging to DEBUG and without the ---loglevel=DEBUG option). I think it shows where the github-version of OpenCPN stands today and it is looking good (WIP).

With logging commit the coreload is a about 20-40 (OpenCPN standby with instruments and oeschart).
Using a little core (arm A53) instead of a big core (arm A73) increases the load a little to 30-50%. A53 is the same core as used in a RPI3, A73 is roughly comparable with a RPI4 (A72)

Without commit the coreload seems only a little higher, about 30-50%.
Please note AIS-data and log/speed/depth/true wind is not present in this setup.

With firefox/KIP the A73 CPU-clock goes to max (1800MHz).
Without KIP (but with firefox) the CPU-clock drops to 500MHz for all cores.
Of course this depends on your mxtommy setup, mine might be a little heavy.

From what I saw the A53 with opencpn will run at a higher frequency, somewhere in the 1000-1500MHz range (with cpufreq set to conservative and the max clock being 1900MHz).


Much of the load is caused by I/O therefore don't stare yourself blind on the core performance. Also the speed variation is still a lot, the measurement is very rough.

[seandepagnier]

Originally Posted by bdbcat

Sean...
Thanks for trying this out.
I like the idea of using sK for synchronization. Also not sure how it could work logically without a server in the loop. This calls for some thought.
Anyway, we go step-by-step.


Dave

Either pypilot or opencpn would have to listen for websocket or tcp connections for this to work. Right now they are clients.

As for being discovered with mDNS, for now probably better to require a manual connection made. With multiple signalk servers routing becomes an issue if they all auto detect each other. Maybe it can be addressed in future signalk.

For this to work efficiently, opencpn will need to handle signalk subscriptions as well as produce them, but for now just sending all messages would work.