ATON display

[Aldebaran17]

In my OpenCPN (current version on Raspberry Pi) AtoNs are displayed with the same icon as ships are. See here:



The edges of this wind farm are marked by AtoNs, the info on one of them is displayed in the AIS target query. Which correctly says AtoN. There is only one ship visible in this screen shot, a working boat, which is moving from one turbine to the next on the western edge.

Is there anything wrong with my settings? Or with the incoming data? Which come via N2K and TwoCan plugin.

Best,

Manfred

[stevead]

What version of the TwoCan plugin and what version of OpenCPN are you using ?

What brand & model of AIS are you using ?

Can you provide both a TwoCan log (any format will do) and a copy of the NMEA Debug log?

There is something weird, as it should not be displayed as a Class A AIS vessel.

Find attached a screenshot displaying an AToN correctly.

To the best of my memory, I do not remember any bug fixes regarding AIS AtoN's in the TwoCan plugin, nor do I recall any changes to OpenCPN regarding the display of AToN's, but then again, my memory could be failing me.

Thanks,

[Aldebaran17]

Steve,

I will collect all the information requested when I will be on the boat next time, possibly this weekend.

Manfred

[HeywoodJ]

In ais.cpp AtoN drawing starts at line 583 with definition of the shapes. Going down to line 674 there is a switch/case based on ShipType that begins with a value of 9. AtoN marking an obstruction on a wind farm should be a type 3 mark (AIS message 21 and IALA definitions). I suspect the case for type 3 is falling through the cracks and thus gets drawn as the default? I did not dig through to see if it is getting caught somewhere else (as there are other cases below 9), but I’d be curious to see if a) the message is showing type 3, and b) if other AtoN (with type > 8) get drawn properly in the same installation.

[bdbcat]

HeywoodJ...


Nice detective work.
But I think the problem goes like this:


1. Somehow, the td->Class for this record is not being set to "AIS_ATON". Seems to be defaulting to AIS_CLASS_A (0).


2. As a first result, at line 1416, the method "AtoN_Diamond" is not being called. If it were actually called, then nothing would be drawn, since as you note, the switch statement does not activate on "3" as it should. This is a bug. Evidently, no one has noticed a "missing" AIS ATON transponder on a wind turbine before.


3. As the next result, the target is rendered as AIS_CLASS_A.



So, we need to inspect the data stream to see what goes wrong.



Thanks for actually reading the code

Dave

[Aldebaran17]

Thanks for your efforts.

I will provide the stream of data as soon as I can. However, since we will go to hibernation - sailing wise - soon in my part of the world, and since the wind farm is 25miles offshore, I may not be able to capture the signal, before my mast is unstepped next week.

If you look at the info on Marinetraffic, your suspicion is reconfirmed. Sounds like AtoN Type 3.

In the code I can see that all types below 9 and 31 are missing in the list. In the english channel there are many light ships which send AtoN signals as well.

Where is the ship?
OffShore Structure NG3 WINDFARM is currently located at UKC - North Sea at position 53° 50' 46.788" N, 8° 9' 54.414" E as reported by MarineTraffic Terrestrial Automatic Identification System on 2021-11-05 06:30 UTC (34 minutes ago)

Best,

Manfred

[stevead]

Just for the hell of it manufactured some AIS AToN data for each of the 32 different Aid To Navigation types. Using virtual/real and on/off position flags.

All appear to be displayed correctly, so I think we will will need an actual data sample from Manfred to track this down.

Here is the manufactured sample data (in this case with the off position flag set)

!AIVDM,1,1,,A,E>lt;R022S0bV:0000000000000E:SAOm6GT0200@3P@10,4*4F
!AIVDM,1,1,,A,E>lt;R@a2S2a2W1Rh87TW:00000E:Tg?m6GT0200@3P@10,4*08
!AIVDM,1,1,,A,E>lt;RQ90QWW000000000000000E:V=0m6GT0200@3P@10,4*1D
!AIVDM,1,1,,A,E>lt;RiS4d2R@7S3@Fh9T7a2P00E:Wbhm6GT0200@3P@10,4*08
!AIVDM,1,1,,A,E>lt;S22VRa3RW1dh;a2QUP0000E:a8Om6GT0200@3P@10,4*3A
!AIVDM,1,1,,A,E>lt;SBV4ST:F@;Tb47bb@9RQb7m:bV@m6GT0200@3P@14Th00000000000,4*10
!AIVDM,1,1,,A,E>lt;SS64ST:F@;Tb4@9RQb7a9PE:d40m6GT0200@3P@10,4*6A
!AIVDM,1,1,,A,E>lt;SkV2PR4W3h64ST:@397W:0E:eQgm6GT0200@3P@10,4*07
!AIVDM,1,1,,A,E>lt;T462PR4W3h64ST:@92Pa00E:fwPm6GT0200@3P@10,4*77
!AIVDM,1,1,,A,E>lt;TDQ2PQWWF@1Pa24W0V@700E:hM@m6GT0200@3P@10,4*7C
!AIVDM,1,1,,A,E>lt;TU12PQWWF@1Pa24W0V@2P0E:irwm6GT0200@3P@10,4*61
!AIVDM,1,1,,A,E>lt;TmQ2PQWWF@1Pa24W0V@9P0E:kHhm6GT0200@3P@10,4*15
!AIVDM,1,1,,A,E>lt;U612PQWWF@1Pa24W0V@;P0E:lnPm6GT0200@3P@10,4*34
!AIVDM,1,1,,A,E>lt;UFQ2PQWWF@87a:@40W2000E:nD?m6GT0200@3P@10,4*0A
!AIVDM,1,1,,A,E>lt;UW12PQWWF@9b0a17Pa2@40m:oiwm6GT0200@3P@13Q000000000000,4*6B
!AIVDM,1,1,,A,E>lt;UoQ2PQWWF@892S2a92R@1TE:q?hm6GT0200@3P@10CSQC843lU820C,4*67
!AIVDM,1,1,,A,E>lt;V812PQWWF@892S2a92R@1TE:reOm6GT0200@3P@10CSQC84m0DPShD,4*68
!AIVDM,1,1,,A,E>lt;VHQ2PQWWF@4aWV0b2R@20WE:t;?m6GT0200@3P@11iDP0000000000,4*28
!AIVDM,1,1,,A,E>lt;Va12PQWWF@9PS2h;Pb2a00E:ua0m6GT0200@3P@10,4*00
!AIVDM,1,1,,A,E>lt;VqQ2PQWWF@9`2QTPV@6Pa5m:w6gm6GT0200@3P@10,4*7A
!AIVDM,1,1,,A,E>lt;W:367Pb4W3h1Pa24W0V@6Pm;0TOm6GT0200@7P@14Rp3P000000000,4*1A
!AIVDM,1,1,,A,E>lt;WJS67Pb4W3h1Pa24W0V@6Pm;22@m6GT0200@7P@14Rp1@000000000,4*73
!AIVDM,1,1,,A,E>lt;Wc367Pb4W3h1Pa24W0V@6Pm;3Owm6GT0200@7P@14Rp4h000000000,4*5C
!AIVDM,1,1,,A,E>lt;WsS67Pb4W3h1Pa24W0V@6Pm;4ugm6GT0200@7P@14Rp5h000000000,4*00
!AIVDM,1,1,,A,E>lt;`<367Pb4W3h87a:@40W2@6m;6KPm6GT0200@7P@10DRh0000000000,4*34
!AIVDM,1,1,,A,E>lt;`LS67Pb4W3h9b0a17Pa2@4E;7q?m6GT0200@7P@10CQ83@DRh00000,4*49
!AIVDM,1,1,,A,E>lt;`e367Pb4W3h892S2a92R@1m;9Fwm6GT0200@7P@120CSQC843lU820,4*22
!AIVDM,1,1,,A,E>lt;`uS67Pb4W3h892S2a92R@1m;:lhm6GT0200@7P@120CSQC84m0DPSh,4*26
!AIVDM,1,1,,A,E>lt;a>367Pb4W3h4aWV0b2R@20m;<BPm6GT0200@7P@13QiDP000000000,4*72
!AIVDM,1,1,,A,E>lt;aNS67Pb4W3h9PS2h;Pb2a0E;=h?m6GT0200@7P@10,4*3F
!AIVDM,1,1,,A,E>lt;ag367Pb4W3h9`2QTPV@6PaE;?>0m6GT0200@7P@12h000000000000,4*62
!AIVDM,1,1,,A,E>lt;awS67Pb4W3h64ST:@;2aaRm;@chm6GT0200@7P@130000000000000,4*12

Note this test was performed on a recent OpenCPN beta release.

[Aldebaran17]

Originally Posted by stevead

Just for the hell of it manufactured some AIS AToN data for each of the 32 different Aid To Navigation types. Using virtual/real and on/off position flags.

All appear to be displayed correctly, so I think we will will need an actual data sample from Manfred to track this down.

Note this test was performed on a recent OpenCPN beta release.

Steve,

I will not be able to provide actual data until next spring. Could not catch a signal from the berth (20nmi distance and some buildings in between).
Since the new beta version is displaying all AtoN types, the problem may be gone anyhow, when the beta is released and installed on my Pi.

Will keep you posted, but it will take a while.

Best,

Manfred

[TVR]

I see exactly the same issue, using the SignalK sample NMEA 2000 data (signalk-server/samples/aava-n2k.data). So it should be simple to reproduce.

In the SignalK data browser, all AtoNs have a valid AtoN Type (for example, "id": 20, "name": "Cardinal Mark N"):



But OpenCPN displays type "Unknown":



So it definitely looks like a parsing error. Let me know if there's any more info I can provide to help.

[TVR]

I see exactly the same issue, using the SignalK sample NMEA 2000 data (signalk-server/samples/aava-n2k.data). So it should be simple to reproduce.

In the SignalK data browser, all AtoNs have a valid AtoN Type (for example, "id": 20, "name": "Cardinal Mark N"). But in the OpenCPN AIS Target List, the type is listed as "Unknown"

So it definitely looks like a parsing error. Let me know if there's any more info I can provide to help.

[Hakan]

If every path for the Aton is correct I think AtoN type 20 is well defined in OCPN.
Example:

switch (td->ShipType) {
    case 9:
     case 20:  // Card. N

Now I don't have a type 20 around but some other Atons. See pict.

To find out if the Signalk path is correct parsed from N2k or there's a OCPN issue please check what's arrived to OCPN by a HTML view of the JSON data. (it may be you need a browser like Firefox to view JSON data correct.)
Enter something similar to this in your browser on the same local net as the Signalk server: http://192.168.1.73:3000/signalk/v1/api/ and look at the "atons"
You've to know the IP address of your SK server and change accordingly.
Well there can look further into the data received by OCPN. See my example on pict 2

[TVR]

Here you go - screenshots from the SignalK data browser, the JSON data in Firefox, and the OpenCPN AIS Target query.

From what I can see, the AtoN type is populated in SignalK and the JSON data, but all AtoNs are listed as type "Unknown" in the OpenCPN AIS Target list.

[Hakan]

So, that's the "Unknown" part.
Something strange here.

I've OCPN 5.6.0 on Win 10. (And all it the same on my RPi) There is the "Type" correct and "Nav status" undefined as it should for a Aton. See pict.

For any reason it's mixed up in your pictures.

What's your system and OCPN version?
Do you have any other Atons, but type 20, around to check if it's the same?

And if possible some NMEA sentences with Aton type 20 as of your example to copy here or did you get them from N2k via SK to OCPN?

[Hakan]

Looking further.
There is a malfunction in your data!
The AIS class is listed as class "A" and not "AtoN". As discussed in earlier in this thread that's the cause for the "misbehavior" in OCPN.

Since it's a class A it will naturally takes another track in OCPN and treated like a ship target.

So where is the class A mistake? SK interpretation of the PGP key or the N2k source?

[Hakan]

Even further...
looking here: https://github.com/canboat/canboat/b...analyzer/pgn.h
is there no AIS Class info in the PGP 129041 but it would have been interpreted to Class AtoN by SK since they are dealing with this ("AIS Aids to Navigation (AtoN) Report") PGP?
Maybe a note to the SK team? (Join the Signal K community on Slack!)