NMEA from Cobham AIS using multicast address

[iraznatovic]

Originally Posted by Hakan

Wireshark - good.
Can you also see if there is something looking as NMEA 0183 messages?
This is the basic test. No NMEA 0183 no interpretation in OCPN!
If so I think you've to go back to oxygen's post above. It could be some internal messages instead of NMEA 0183.

If you find good NMEA 0183 messages then it's all about network handling.
Håkan

This is the excerpt from wireshark:



I guess the most interesting part is the data segment:
!AIVDO, 1,1,,,13rk`eOP001E<AvHA4s00?v>2000,0*20..

[did-g]

Originally Posted by iraznatovic

This is the excerpt from wireshark:



I guess the most interesting part is the data segment:
!AIVDO, 1,1,,,13rk`eOP001E<AvHA4s00?v>2000,0*a20..

The ASCII null in data is bad news. I made a pull request 728 some time ago for dealing with them but it's a bit of a hack .

Can you compile opencpn?

[iraznatovic]

Getting warmer!
I found an online decoder (https://rl.se/aivdm) that successfully translated the data from one of the packets I got using wireshark. This is exactly the information I need displayed on the chart!
==========================================

!AIVDM,1,1,,B,13f7@P5Oh8QGE`bH5EN>4:`B0000,0*79
MMSI : 249680000
Latitude : 42.088733°
Longitude : 19.079288°
Speed : 0.8 knots
Heading : 340°
Course over ground : 360°
Rate of turn : 720°/min
Navigational status: 5
Nearest place : Bar, Montenegro

RL.SE AIVDM/AIVDO Decoder, build #213

[iraznatovic]

Getting warmer!
I found this site (https://rl.se/aivdm) featuring on-line AIVDM/AIVDO decoder and got exactly the data I need to display on chart! This means that, theoretically, I can read the data sent by Sailor on the network - just a matter of setting the OpenCPN ...

!AIVDM,1,1,,B,13f7@P5Oh8QGE`bH5EN>4:`B0000,0*79
MMSI : 249680000
Latitude : 42.088733°
Longitude : 19.079288°
Speed : 0.8 knots Heading : 340°
Course over ground : 360°
Rate of turn : 720°/min
Navigational status: 5
Nearest place : Bar, Montenegro

RL.SE AIVDM/AIVDO Decoder, build #213

[iraznatovic]

Originally Posted by iraznatovic

I guess the most interesting part is the data segment:
!AIVDO, 1,1,,,13rk`eOP001E<AvHA4s00?v>2000,0*20..

Originally Posted by Hakan

Wireshark - good.
Can you also see if there is something looking as NMEA 0183 messages?
This is the basic test. No NMEA 0183 no interpretation in OCPN!
If so I think you've to go back to oxygen's post above. It could be some internal messages instead of NMEA 0183.

If you find good NMEA 0183 messages then it's all about network handling.
Håkan

Sorry if I repeat my self but I posted already 2 times this message and it did not show on the forum.
The news is that I have progress on this issue. I found an on-line AIVDM & AIVDO NMEA sentence decoder (https://rl.se/aivdm) and one of the messages captured by wireshirk (not the previous one I left on the forum - a new one) and it decodes the message in exactly the data I want Open CPN to display:

!AIVDM,1,1,,B,13f7@P5Oh8QGE`bH5EN>4:`B0000,0*79


MMSI : 249680000
Latitude : 42.088733°
Longitude : 19.079288°
Speed : 0.8 knots
Heading : 340°
Course over ground : 360°
Rate of turn : 720°/min
Navigational status: 5
Nearest place : Bar, Montenegro


So the only thing remaining is figuring out a way to display it in OpenCPN

[muttnik]

The data are there: You'll see the sentence in wireshark preceded by a source TAG block which OCPN will ignore. I won't be able to look at the code until this evening and my knowledge is a little out of date, but what I think did-g was saying was that that NULL before the start of the TAG may result in the rest of line getting discarded.

That's not something that "should" happen (anything outside of a sentence should be irrelevant) but I recall that input was not dealt with purely as a stream but parsed on a line. I think did-g was asking if you have the ability to compile ocpn from source and is referencing a particular fix he/she has submitted

[bdbcat]

did-g...

Which NULL in the data packet is causing the trouble?

Dave

[muttnik]

Originally Posted by bdbcat

Which NULL in the data packet is causing the trouble?

There's one terminating the string "UdPbC" before the source TAG which precedes the sentence: 6th character in the wireshark screenshot. If you were just scanning for $ or ! to start the sentence then all would be good but I seem to remember you do some funky stuff with creating a string out of the input buffer then doing parsing on that. Leading NULL could end that string before you want it.

Of course I should probably wait until this evening and actually look at the code since it's about a year since I did...

[bdbcat]

muttnik...
OK, thanks, I see that.

did-g tried to address that in an old pull request. I rejected it, since it looked a little shakey, and would need massive regression testing.

Thinking about a workable solution....

Dave

[muttnik]

Not ideal but if this is indeed a quirk of the current parsing mechanism a temporary workaround would be to have something else read the data and strip out anything OCPN might not like. kplex running on the ubiquitous raspberry pi connected to the network could read multicast, would strip out non-NMEA data (and the TAG blocks) and make it available as, say, tcp which more apps (e.g. iNavx on your iPad?) could make use of.