feature: add ais class

[tkurki]

sensors.ais.class

[tkurki]

@Hakansv How does this look to you?

[Hakansv]

@tkurki
What I can judge it seems good to detect AIS transponder type "A" and "B" from the message types listed.
I can't understand the code you use in SK enough to validate the example "parse(!AIVDM......). But there are also other sender key used. So my question will be if also !BSVDM are understood. For example a Norwegian source use that sender key. See my shot.

The path "sensors.ais.class" will be good. No comments.

The rest of our classes can be found out by the mmsi number apart maybe the Inland blue paddle. As mentioned the info can be found in AIS message 3 OCPN AIS decoder
The detection of "A" or "B" is crucial and we are really happy for you efforts with this. The blue paddle is so far a bonus and not at all time important in the same way. It may take a time before our Inland barge friends go for SignalK, but you never know.
Thanks.
Håkan

[tkurki]

Ignoring the talker ID was implemented a while ago in the ggencoder that is used to decode VDM, it is working if you have installed recently. Additionally I updated the dependency minimum version and modified a test to make sure.

Do you have an example sentence for the blue paddle - whatever it is?

[Hakansv]

@tkurki @bdbcat
A reflection.
We may not put things to the future but rather try our best to make a complete package from start? I mean the start of OCPN supporting SignalK in next release.
So, instead of setting your ais.class to like "A" or "B" a enum list would preferable set the class value to a long or int 1 - 8. Than it would pass directly into OCPN tag. If that method would clash to others use of SignalK a text like our class names below would be feasible as well.
As mentioned O use these classes sorted as an enum like this:

typedef enum ais_transponder_class
{
	AIS_CLASS_A = 0,				   Detected by VDM message 1, 2, 3 or 5
	AIS_CLASS_B,					   Detected by VDM message 18 or 19
	AIS_ATON,	 // Aid to Navigation  Detected by VDM message 21
	AIS_BASE,	  // Base station	   Detected by VDM message 4
	AIS_DSC,	// DSC target		   Detection by sentance xxDSC,
	AIS_GPSG_BUDDY, // GpsGate Buddy   Detection by $FRPOS,..... GpsGate Position message
	AIS_SART,	// SART				   Detected by VDM message 1, 2, 3 or 5 and mmsi starts with 97
	AIS_ARPA,	// ARPA radar target   N/A Sentance xxTLL,... or xxTMM,... Radar rendering not applicable through SignalK?
	AIS_APRS	// APRS position report Detection by sentance xxWPL,.............*yy
	

If Signal would transfer the classes as of above list the only remaining issue would be the inland blue paddle mentioned in earlier post.
Which SignalK path to use for that is out of my mind but maybe sensors.ais.inland.bluepaddle 0/1?

Again I've not investigated how corresponding N2K messages will apply to this logic. But that may be a part of the SignalK concept since one the goals to implement SK in OCPN would be a path to the N2K world.

I'm sorry for this late extension but I think it's essential to try to cover this concept in whole at this early state of implementation?

Thanks
Håkan

[Hakansv]

@tkurki
My posting was done before I detected your posts. I may put my mail alert on :)
I'll check for a blue paddle example.
Håkan

[Hakansv]

@tkurki
Here's a file containing VDMs and a blue flag. Is it anything you can use or should I try to extract the particular sentence?

InlandRhein_vdr.txt

[tkurki]

A single sentence would be helpful.

[Hakansv]

OK, pretty sure it's here. (I'd catch them "on the fly")
!AIVDM,1,1,,A,339n@P00PLt=MH6n0lq72000,071\n
!AIVDM,1,1,,B,339n@PP@jPLtAtMGQUt4cS211P,059\n

[Hakansv]

And to be sure the HTML parser didn't changed it. As "code" instead

!AIVDM,1,1,,A,339n@`P00`PLt=`M`H6n0lq72000,0*71\n
!AIVDM,1,1,,B,339n@`PP@jPLtAtM`GQUt4cS211P,0*59\n

[Hakansv]

@tkurki

Ignoring the talker ID was implemented a while ago in the ggencoder that is used to decode VDM, it is working if you have installed recently. Additionally I updated the dependency minimum version and modified a test to make sure.

Ok, I have tested to pass !BSVDM sentences through SignalK and it works like a charm. My comment was more due to I not fully understand the use of examples in the code. Thanks.

...............................sentence for the blue paddle - whatever it is?

You saw a rendering example above. It's for Inland traffic signaling "I intend to meet Starboard-Starboard" instead of normal Port-Port. A AIS electronic adption to the old fashion hardware blue paddle out from a window or swinged out on the barge bridge.

[Hakansv]

@tkurki
I've updated SK to version 1.21.0
No more sensors info like AIS Id etc. Or did I miss some settings?
Håkan

[Hakansv]

Sorry.... I was to eager I think. All data appeared after 10 minutes. Sorry.
Håkan

[tkurki]

Reading up on https://en.wikipedia.org/wiki/Blue_sign... so it is not about A/B as I interpreted you talking about classes that they refer to the AIS A and B class transponders. So as I understand that is more related to the navigational status of the vessel, just available as special manouver being set to value 2.

I think we are starting to replicate how OpenCPN works internally in Signal K. I don't think that's the best way to go about it.

Take blue sign for example: while it is transmitted over AIS it is really not about AIS - a computer vision system in not so distant future may be able to discern the white flashin light and/or the blue paddle, mark it with special status, paint the vessel blue on the OpenCPN screen and set something like navigation.status.cevni to starboardPass in the Signal K data model.

AIS_DSC is not an AIS target but something else: notifications, cancelations, position requests etc that need homes in the Signal K data model - something we have yet to do.

AIS_GPSG_BUDDY is a regular (non-self) vessel in the SK data model and the fact that the data came from GpsGate Buddy system should be included in the messages' source information. This is similar to Signal K cloud that Scott is running - O may get data from other vessels via Signal K -native routes. (I am also working on a similar system for next season). Just googling APRS, sounds like something similar.

ATON, BASE and SART you already are handling, I assume? Different root paths in SK.

ARPA again has nothing to do with AIS, right? So those would be just vessels in Signal K, with some metadata to be expressly defined to tell that the data originated from radar signals. Interesting, and something that works pretty well in the SK data model with multiple vessels.

Hope I am making this clear?

To sum this up, the use cases that O-SK integration exposes are really interesting and reflects the long history and comprehensive functionality in O. Stuff I am eager to work with in Signal K, but as this PR is just about AIS status I'll follow this up soon with more separate issues here in nmea0183 parser and in the Signal K specification.

[bdbcat]

Teppo...
I agree philosophically with your position. And I think we can keep the sK and OCPN data models logically separated. From our viewpoint, SK is a model of observed reality, synthesized by the decoding of various forms of data obtained over a wide variety of channels. It is up to OCPN to extract information from that model (as available over the sK data stream), and present it to the user in a clear way.

So I think our primary interest in the current work is to ensure that all data which OCPN cares about (and presumably a navigator cares about) are somehow captured from the available sensor streams, and so become available in the sK model somewhere.

So, specifics: In the case of BlueFlag, the sensor source which the sK NMEA parser has access to now is AIS VDM message from NMEA0183 channel. We would be happy if that information were to be encoded as a navigation.status field, as you note. And we could say the same thing about other attributes or message types such as AIS_DSC, GPS_BUDDY, etc.

I realize that this rich source of sensor data available from VDM messages will lead to non-trivial extensions to the sK data model. So it may not be implemented overnight. But as a direction forward, I think it makes sense.

Thanks for using OCPN as a "trial horse".
Dave

[bdbcat]

As a point of thought...
One should ask: "Is the sk NMEA0183 parser reversible? Can one generate an equivalent VDM message from the contents of the sK JSON stream?"
If not, then there is work to be done...
Dave

[Hakansv]

@tkurki
Apart from the more intricate things to considder this would be straight forward and then out of the discussion?

const msgTypeToTransmitterClass = {

1: "A",
2: "A",
3: "A",
4: "BASE"
5: "A",
18: "B",
19: "B",
21: "ATON"
24: "B"

[tkurki]

Makes sense to me. What about SAR?

[Hakansv]

Thanks Teppo!
Due to kind of negligence I actually forgot SAR Aircraft. Mainly because we don't have a nice shortcut for that but instead a variable name. The sentence used for that is 9.
And we have to find out a suitable name to our list. SAIR would be good but maybe to close to SART. What about SARAIR? See the new list below.

SART is not that obvious. It's a "A" ship and MMSI starts with 97 and it's also further divided. SART also depends on navigation.state. Navstatus = 14 (RESERVED_14) is one, your have called it "ais-sart", next we need here is navstatus = 15 "UNDEFINED". 14 is a active SART, 15 is a testing SART. So rather important.

So, then we've covered what could be called classes apart from APRS but that's another hook I think since it's handled in $xxWDR. Could we test what we now and come back to that?

Revised the list again:
const msgTypeToTransmitterClass = {
1: "A",
2: "A",
3: "A",
4: "BASE"
5: "A",
9: "SARAIR"
18: "B",
19: "B",
21: "ATON"
24: "B"
}

[Hakansv]

@tkurki
Reading this doc and others it may be wise exclude 24: in the transmitter class list. At some special circumstances it can be used by a "A" transponder as well. Message 18 and 19 would be enough to identify a class "B"

[tkurki]

@Hakansv 24 now excluded and the test label B fixed to A.

FYI if you want to try this out:

git clone https://github.com/SignalK/signalk-parser-nmea0183.git
cd signalk-parser-nmea0183
npm install
echo '!AIVDM,1,1,,B,13aGra0P00PHid>NK9<2FOvHR624,0*3E' | bin/nmea0183-signalk

and you should have that sentence converted to SK delta.

If you want to get fancy install json pretty printer with npm install -g json and you can do echo '!AIVDM,1,1,,B,13aGra0P00PHid>NK9<2FOvHR624,0*3E' | bin/nmea0183-signalk | json.

Let me know if everything seems to be in order, I'm eager to get this published!

[Hakansv]

@tkurki
Funny... A native Windower on Linux never used this code type.. :)
Anyhow although a probably dated npm-something. (2.6.11) I may update.
The master I got has not much about AIS class. the last commit is : "fix: AIS status 'motoring' d..."
It seems you're on branch AISclass. I'll try that. but so far:
From master Received this:

echo '!AIVDM,1,1,,B,13aGra0P00PHid>NK9<2FOvHR624,0*3E' | bin/nmea0183-signalk
{"context":"vessels.urn:mrn:imo:mmsi:244710052","updates":[{"source":{"sentence":"VDM","talker":"AI","type":"NMEA0183"},"timestamp":"2020-02-12T22:07:01.996Z","values":[{"path":"","value":{"mmsi":"244710052"}},{"path":"navigation.speedOverGround","value":0},{"path":"navigation.courseOverGroundTrue","value":1.0489428806880967},{"path":"navigation.position","value":{"longitude":5.412491666666667,"latitude":53.17}},{"path":"navigation.state","value":"motoring"}]}]}
Encountered an error: Sentence "" is invalid

[Hakansv]

OK, from aisclass:

echo '!AIVDM,1,1,,B,13aGra0P00PHid>NK9<2FOvHR624,0*3E' | bin/nmea0183-signalk
{"context":"vessels.urn:mrn:imo:mmsi:244710052","updates":[{"source":{"sentence":"VDM","talker":"AI","type":"NMEA0183"},"timestamp":"2020-02-12T22:25:54.048Z","values":[{"path":"","value":{"mmsi":"244710052"}},{"path":"navigation.speedOverGround","value":0},{"path":"navigation.courseOverGroundTrue","value":1.0489428806880967},{"path":"navigation.position","value":{"longitude":5.412491666666667,"latitude":53.17}},{"path":"navigation.state","value":"motoring"},{"path":"sensors.ais.class","value":"A"}]}]}
Encountered an error: Sentence "" is invalid

This: "sensors.ais.class","value":"A"} looks fine and that's how I prepared it in O AIS decoder.
Since we've several classes and other things to do with this is it possible to make a not official SK update and will install and stress it.
Håkan