Missing "ais.sensors.class" values for AIS related PGN's

[TwoCanPlugIn]

Missing "ais.sensor.class" values for the following NMEA 2000 PGN's:

129038 Class A Position Report - 'A'
129039 Class B Position Report - 'B'
129040 Extended Class B Position Report - 'B'
129041 Aid To Navigation (AToN) Report - 'ATON'
129793 Base Station Report - 'BASE'
129798 SAR Position Report - 'SAR'

The values appear to be correctly generated for the following NMEA 2000 PGN's
129794 Class A Static and Voyage Related Data
129809 Class B Static Data Report Part A
129810 Class B Static Data Report Part B

They are also correctly generated from NMEA 0183 derived AIS data.

Impact: OpenCPN incorrectly displays AIS targets when using SignalK and the AIS data is received from a NMEA 2000 connected transponder as the 'ais.sensors.class' values are missing.

Eg. AToN report derived from NMEA 0183:
{
"context" : "atons.urn:mrn:imo:mmsi:995036044",
"updates" : [
{
"source" : {
"talker" : "AI",
"label" : "183TCP",
"sentence" : "VDM",
"type" : "NMEA0183"
},
"$source" : "183TCP.AI",
"timestamp" : "2021-12-26T16:29:32.511Z",
"values" : [
{
"path" : "",
"value" : {
"mmsi" : "995036044"
}
},
{
"path" : "",
"value" : {
"name" : "TB2"
}
},
{
"path" : "navigation.position",
"value" : {
"latitude" : -38.10014167,
"longitude" : 144.3819833
}
},
{
"path" : "sensors.ais.class",
"value" : "ATON"
},
{
"path" : "atonType",
"value" : {
"name" : "Beacon, Starboard Hand",
"id" : 14
}
},
{
"path" : "offPosition",
"value" : false
},
{
"path" : "virtual",
"value" : true
}
]
}
]
}

compare with AToN report derived from NMEA2000.
{
"context" : "atons.urn:mrn:imo:mmsi:995036044",
"updates" : [
{
"source" : {
"src" : "43",
"label" : "N2K",
"pgn" : 129041,
"type" : "NMEA2000"
},
"$source" : "N2K.43",
"timestamp" : "2021-12-26T15:38:19.794Z",
"values" : [
{
"path" : "",
"value" : {
"name" : "TB2@@@@@@@@@@@@@@@@@"
}
},
{
"path" : "navigation.position",
"value" : {
"latitude" : -38.1001416,
"longitude" : 144.3819833
}
},
{
"path" : "atonType",
"value" : {
"name" : "Beacon, Starboard Hand",
"id" : 14
}
},
{
"path" : "virtual",
"value" : true
},
{
"path" : "offPosition",
"value" : false
},
{
"path" : "",
"value" : {
"mmsi" : "995036044"
}
}
]
}
]
}

[Hakansv]

@tkurki
Please see background info for this issue at this forum post and the entire thread discussion.
To conclude:
What's seemed to be missed in this plugin is the use of:
node: 'sensors.ais.class',
The plugin NMEA0183 to Signalk does handle it correct.
It would be set to either of these classes:
typedef enum ais_transponder_class {
CLASS A
CLASS B,
CLASS ATON, // Aid to Navigation
CLASS BASE, // Base station
CLASS SART, // SART
For the detection of a SART target this summarize would be valid:
These we also handle within OCPN but I'm not sure about the relevance for this discussion.
GPSG_BUDDY, // GpsGate Buddy object
DSC, // DSC target
ARPA, // ARPA radar target
APRS // APRS position report

Please note if we can help in any way.
Thanks
Håkan

[tkurki]

Thanks for the heads up on this!

Please check the linked PR for adding these.

[tkurki]

Values other than A and B were not documented in the SK spec.

BTW does OpenCPN make use of the virtual and offPositionfields in AtoN VDM / 129041?

SignalK/specification#635

[Hakansv]

@tkurki
Thanks for your quick action! I'll have look at the PR as requested but first:

"does OpenCPN make use of the virtual and offPositionfields in AtoN VDM / 129041?"

Yes please. In the same way as of "NMEA018 to SK". See JSON example in attached picture and below how we use it in OCPN.

} else if (update_path == _T("atonType")) {
      if (value.HasMember(_T("id"))) {
        pTargetData->ShipType = value[_T("id")].AsUInt();
      }
    } else if (update_path == _T("virtual")) {
      if (_T("true") == value.AsString()) {
        pTargetData->NavStatus = ATON_VIRTUAL;
      } else {
        pTargetData->NavStatus = ATON_REAL;
      }
    } else if (update_path == _T("offPosition")) {
      if (_T("true") == value.AsString()) {
        if (ATON_REAL == pTargetData->NavStatus) {
          pTargetData->NavStatus = ATON_REAL_OFFPOSITION;
        } else if (ATON_VIRTUAL == pTargetData->NavStatus) {
          pTargetData->NavStatus = ATON_VIRTUAL_OFFPOSITION;
        }

[Hakansv]

About the PR.
What I can judge with my limited experience of JSON it looks fine.
For the use of the PGP's it may be @TwoCanPlugIn can have a look as well?

As you may have seen we have a user, TVR, who can test it once SK is updated with these changes.

[Hakansv]

A thought...
I see no SART reference in the PR?
The SART identification for OCPN is performed by the existing code and we don't use "sensors.ais.class" for that:

if (97 == mmsi / 10000000) {
            pTargetData->Class = AIS_SART;

but is there anything in "N2k - signalk" to detect and set the "sensors.ais.class" if other applications may have use of that?

[Hakansv]

@tkurki

"does OpenCPN make use of the virtual and offPositionfields in AtoN VDM / 129041?"> 

Yes please. In the same way as of "NMEA018 to SK

Would I make new issue for the above?

[tkurki]

virtual and offPosition are already there for PGN 129041

n2k-signalk/test/129041_aton_report.js

Lines 21 to 22 in 4b56bf4

	tree.should.have.nested.property('virtual.value', true)
	tree.should.have.nested.property('offPosition.value', false)

[tkurki]

I see no SART reference in the PR?

Is SART a real AIS class, if it is just derived from MMSI?

MMSI number is available in the delta message's context, maybe O could use the same logic on that?

[tkurki]

Published as @signalk/n2k-signalk@2.3.1. If you rerun your sk server's installation it should update n2k-signalk package to 2.3.1

[Hakansv]

virtual/offposition... Sorry I missed. Your faster than............
Yes, SART is well covered when derived from the mmsi. No problem on O.

Many thanks for the update and your excellent service!
Håkan

[TwoCanPlugIn]

Don't confuse SAR with SART !

SAR (Search and Rescue Aircraft) should be derived from PGN 129798 (equivalent to VDM Message 9). I would have thought that SignalK should set the value for "sensors.ais.class" as 'SAR', although from what I can see, instead the context is "aircraft.urn:mrn:imo:mmsi:"
And I think OpenCPN differentiates SAR from other vessels by the mmsi prefix (111), so I am not sure if there is any value in setting "sensors.ais.class" to 'SAR' other than for completeness/simplicity.

In anycase OpenCPN should display a SAR target as a little aeroplane!

AIS SART (Search and Rescue Transponder) as well as AIS MOB (Man Overboard) and AIS EPIRB (Emergency Position Indicating Radio Beacon) are derived from PGN 129038. I think (and Hakan will correct me), that OpenCPN checks the MMSI prefix to see if it matches that for a SART, MOB or EPIRB devices and if it matches, displays the target differently to that of a normal vessel.

As OpenCPN does the parsing to differentiate AIS SART, MOB or EPIRB, perhaps little point in SignalK doing the same parsing and setting the value of "sensors.ais.class" to something more appropriate, but from a viewpoint of completeness, perhaps SignalK should do so, to make it easy for third party apps to rely on a single mechanism to differentiate the types of AIS devices.

BTW, you could further check the validity of SAR, AToN, AIS SART, MOB & EPIRB devices as they have specific MMSI prefixes.
SAR - 111
AtoN - 99
AIS SART 970
AIS MOB - 972
AIS EPIRB - 974

[Hakansv]

@tkurki
ATONs are working as it should according to TVR's test.
There's a malfunction for Base targets somewhere in the process though. See my note
One may suspect the PGN for this failure but unlikely I suppose?

[Hakansv]

@TwoCanPlugIn
The distinguish of SAR and SART is no problem in O. It also works when passing "NMEA0183-signalk" plugin. Would be fine if "n2k-signal" could be hard tested.?
The SART is by O detected by the prefaced "97" in mmsi, correct. Subsequent dividing to SART/EPIRB/MOB is done as of your examples.