ATON display

[stevead]

I can't see from the screenshots the value of sensors.ais.class.

That SignalK value determines how OpenCPN differentiates the AIS vessels.

It is possible that SignalK is setting this value incorrectly. They've made a similar mistake elsewhere in the SignalK to NMEA 2000 plugin. That bug report is here Not unreasonable to expect that they would have made a similar error in the N2Kto SignalK plugin.

[Hakan]

If there's no SK solution in sight there's a theoretical possibility in OCPN to set the Class to "AIS_ATON" if there's no available "sensors.ais.class" and "atonType" is present.
But this seems a bad hack to repair a deficiency from surrounding system. Though I think similar hacks have been implemented before?

[TVR]

Using the N2K sample data and looking in the SignalK data browser, some ships include AIS class but not all. Whereas AtoNs and Shore Basestations never include AIS class.

Ship with AIS Class:


Ship without AIS Class:


Shore Basestation without AIS Class:


AtoN without AIS Class:


The OP is seeing the same issue with live data, so I think the sample data is valid. Which means there's two possibilities - either SignalK isn't populating the AIS class correctly in some cases, or it's not always included in the source data.

The raw data feed is here - is anyone clever enough to see whether the AIS class is included for AtoNs?

[TVR]

Further to my previous post, any targets without sensors.ais.class are displayed in OpenCPN as Class A. This includes both ships and AtoNs.

We can also see that AIS Type is often displayed as "Unknown". I believe this is taken from design.ais.shiptype, which is also sometimes missing from the SignalK data.

[stevead]

I think I may have sent you off on a bum steer, however, I think there is a major disconnect in the way that AIS information is generated by SignalK and consumed by OpenCPN.

From what I can tell, OpenCPN differentiates SignalK AIS targets with the following:

else if (update_path == _T("sensors.ais.class")) {
      auto aisclass = value.AsString();
      if (aisclass == _T("A")) {
        pTargetData->Class = AIS_CLASS_A;
      } else if (aisclass == _T("B")) {
        pTargetData->Class = AIS_CLASS_B;
        pTargetData->NavStatus =
            UNDEFINED;  // Class B targets have no status.  Enforce this...
      } else if (aisclass == _T("BASE")) {
        pTargetData->Class = AIS_BASE;
      } else if (aisclass == _T("ATON")) {
        pTargetData->Class = AIS_ATON;
      }

but from what TVR has observed, non-ship targets such as AToN's, Base Stations and quite possible SAR's lack a value for "ais.sensors.class" so are displayed incorrectly.

I can't understand where SignalK encodes all of this, whether it is in CanBoat, SignalK Server or N2K-SignalK plugin. And I thought OpenCPN was obfuscated!

From what I can tell, "ais.sensors.class" is derived from whether the AIS transmission is sent by a Class A or Class B transponder. Big commercial vessels, Base Stations and AToN's all use Class A transponders, so differentiating on this value will never work.

So the disconnect is that the current approach that OpenCPN uses to differentiate SignalK AIS targets seems to be wrong and that the SignalK schema doesn't provide practical means do so.

The SignalK schema reminds me of the protocol wars about 30 years ago; ISO TP4 vs TCP/IP, one was academically correct, the other was practical.

[Hakan]

We have the different types/classes of AIS transponders as of the OCPN table "Class" so I think that's correct used.
See the example below from here: https://www.amsa.gov.au/safety-navig...cation-systems
Or here: https://www.sostechnic.com/epirbs/ai...fais/index.php

AIS units can be carried on board vessels and aircraft to support maritime safety and search and rescue operations. There are many different types of AIS units and stations:

• AIS units are carried on board vessels
• AIS carried on board aircraft to support maritime safety
• AIS base stations are non-shipborne stations which can relay information from AtoN and vessels
• AIS AtoN which can be a physical aid to navigation or a virtual aid which broadcasts information
• AIS search and rescue transmitters (SART) which are self-contained radio devices used to locate a survival craft or vessel in distress by sending updated position reports
• AIS man overboard units which are designed to be carried by your crew and used in the event of a man overboard situation or other personal emergency.

AIS on board vessels can be classified as Class A and Class B.

So, a AIS Transceiver in a Aids-to-navigation unit, ATON, is not a Class A transponder.

SignalK does call this JSON path sencors.ais.class and that's also used for AtoN like in my shot below where the class is "aton"
So, I see no reason why it should not be used also for the N2k PKG 129041 or for e.g. base stations. It would be logical to set the sencors.ais.class to "aton" when the PGP 129041 is received like when the same info is received from NMEA0183.

[stevead]

I apologize, you are correct.

I didn't realize that different transmitters & modes (FATDMA, RATDMA) were used by AToN & Base Station transponders in addition to the SOTDMA used by Class A and CSTDMA used by Class B.

How come TVR isn't seeing the "ais.sensors.class" value as you are seeing or as expected ?

To the best of my knowledge there isn't a field in PGN 129041 that defines the type of transmitter, it is simply that the PGN itself denotes that it is an AToN so I can't understand why "ais.sensors.class" has no value. Admittedly I don't have access to the NMEA 2000 standard, so there could well be a field that defines this, but I am unaware of it.

[rgleason]

Dave,
Actually, I noticed that the 3 wind turbines next to Block Island did not have Aton symbols and mentioned it somewhere, a long time ago, but they were new and we thought they perhaps had not been tagged yet.

[Hakan]

re: How come TVR isn't seeing the "ais.sensors.class" value as you are seeing or as expected ?
My data is from NMEA0183/VDM by the SK plugin "NMEA0183-signal" where the sensors.ais.class is set correct.
TVR's data is from N2k pgn 129041, and the SK plugin "n2k-signal".

[stevead]

Hakan,

Here is some N2K data in candump format containing AIS AToN & Base Station reports. Sorry but I don't have my RPi with me and I can't remember how to configure Signalk Server to read candump logs, however to dump the logs with canboat is something like

candump2analyzer melbourne.log | analyzer -json

which I think can then be fed into to Signalk Server ?

If indeed the N2K to SignalK plugin is not generating "ais.sensors.class" values, then perhaps a bug should be filed against the SignalK folks.

It seems wrong to help debug a "competitors" product!

[TVR]

Thanks everyone, I've finally traced the error to the n2k-signalk plugin.

ais.sensors.class should be populated for every AIS-related N2K PGN message. But the n2k-signalk plugin only populates this value when it receives class A or class B static data.

ais.sensors.class is correctly populated in these PGN's:

• PGN 129794 (AIS class A static and voyage related data)
• PGN 129809 (AIS Class B "CS" static data, part A)

But ais.sensors.class is not populated in these PGN's:

• PGN 129038 (AIS Class A Position Report)
• PGN 129039 (AIS Class B Position Report)
• PGN 129040 (AIS Class B Extended Position Report)
• PGN 129041 (AIS Aids to Navigation (AtoN) report)
• PGN 129793 (AIS UTC and Date Report (Base Station))
• PGN 129798 (AIS SAR aircraft position report)
• PGN 129810 (AIS Class B "CS" static data, part B)

Whenever the AIS class is missing, OpenCPN assumes it's Class A and displays the wrong symbol.

[stevead]

That's a bit of a serious bug in the N2K-SignalK plugin !
As a bit of an academic exercise, added Socket CAN support to the Ubuntu kernel in Windows Services for Linux, so I could then replay NMEA 2000 log files over the CAN bus to SignalK Server.
Generated the following examples illustrating the missing "ais.sensors.class" values.
Eg. Aid To Navigation report.
NMEA 2000 data source:

{  
   "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"
               }
            }
         ]
      }
   ]
}

compared to NMEA 183 data source

{ 
   "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
            }
         ]
      }
   ]
}

Similarly for Class B position reports.
NMEA 2000 data source:

{
   "context" : "vessels.urn:mrn:imo:mmsi:503067900",
   "updates" : [
      {
         "source" : {
            "src" : "43",
            "label" : "N2K",
            "pgn" : 129039,
            "type" : "NMEA2000"
         },
         "$source" : "N2K.43",
         "timestamp" : "2021-12-26T15:38:22.096Z",
         "values" : [
            {
               "path" : "navigation.speedOverGround",
               "value" : 4.78
            },
            {
               "path" : "navigation.courseOverGroundTrue",
               "value" : 0.7086
            },
            {
               "path" : "navigation.position",
               "value" : {
                  "latitude" : -38.1127949,
                  "longitude" : 144.3926099
               }
            },
            {
               "path" : "",
               "value" : {
                  "mmsi" : "503067900"
               }
            }
         ]
      }
   ]
}

whereas for NMEA 183 data source

 {
   "context" : "vessels.urn:mrn:imo:mmsi:503067900",
   "updates" : [
      {
         "source" : {
            "talker" : "AI",
            "label" : "183TCP",
            "sentence" : "VDM",
            "type" : "NMEA0183"
         },
         "$source" : "183TCP.AI",
         "timestamp" : "2021-12-26T16:30:10.452Z",
         "values" : [
            {
               "path" : "",
               "value" : {
                  "mmsi" : "503067900"
               }
            },
            {
               "path" : "navigation.speedOverGround",
               "value" : 0
            },
            {
               "path" : "navigation.courseOverGroundTrue",
               "value" : 0
            },
            {
               "path" : "navigation.position",
               "value" : {
                  "latitude" : -38.13729667,
                  "longitude" : 144.36572
               }
            },
            {
               "path" : "sensors.ais.class",
               "value" : "B"
            }
         ]
      }
   ]
}

Who's going to file a bug report against the SignalK folk?

[Hakan]

Steve..
I do agree about your findings.
With your insight about N2k I'd suggest you file it here if you don't mind: https://github.com/SignalK/n2k-signalk/issues
I'll of course do what I can to support it.

Thanks
Håkan

[stevead]

Filed under the following SignalK N2K issue

I wonder how long it will take for a fix as another possibly related bug I submitted has been languishing for almost four months.

As I said, it just seems wrong to debug a competitor's product!

[Hakan]

steve..
Thanks for the issue. Very good you also mentioned the missing Base and SAR. I think the class SART can be mentioned as well. I'll see what I can fill in.



I can't say I see SignalK as a competitor of any kind. SK is a big advantage we, OCPN, has a grateful use of. The SK team works hard on a voluntary base the same as we.

And - In what way does OCPN compete with anyone? All here are sharing knowledge and efforts for joy to our and others delight by developing the best navigation tool. Isn't that enough?