Beta Test / Technical

[Tehani]

Originally Posted by stevead

Seeking some sage advice.

Given the following definition:


If you were to coding this to create the payload (lets say a vector of unsigned char), how would you interpret the above ?

std::vector<unsigned char> data;
// Assume MMSI Number of 338375832 
// Append a trailing zero
data.push_back(33);
....
data.push_back(83);
data.push_back(20);

The reason I am asking is that if I craft my own NMEA 2000 message and transmit it to a well known brand of chart plotter, the only way I can get it to receive the correct & meaningful message is to interpret the value as hex (base 16) instead of decimal (base 10).
Eg.

data.push_back(0x33);
...
data.push_back(0x83);
data.push_back(0x20);

Am I having a blonde moment in trying to understand the standard or does one think the chartplotter is at fault ?

And if anyone is curious, this is regarding NMEA 2000 DSC stuff.

Hi Steve,

I'm reviewing how I did it. I see that to pass the ASCII block passed to binary (compacted from 6 to 8 bits) in NMEA0183, I take exclusively 30 bits, starting with the least significant, and group them 8 by 8 to send it by N2k (in little endian, of course ).

Anyway, I have requested a new check of the operation in both directions NMEA0183 <-> N2k.

I don't know exactly if this information can help you. I hope so.

Jose Luis

[Tehani]

Steve,

This is how the non-significant zeros are at the top of the 32-bit word in N2k.
It seems that your question refers to the way to pass it to Decimal. This document may help you:
https://gpsd.gitlab.io/gpsd/AIVDM.html

[Tehani]

Oops!!!
You're talking about DSC... Then I'll look at it and tell you.

[stevead]

Are you sure Kees did not already do all you need in https://github.com/canboat/canboat/? I see many DSC related PGNs being handled there.

Canboat parses the MMSI field correctly, as do I. However there are several elements to the problem.

Firstly there is the actual interpretation of the specification. Kees (canboat), myself and a well known radio manufacturer interpret the specification as the hex equivalent of the MMSI address. So an MMSI address of 235076393 has a trailing zero added and is encoded over 5 bytes.
Eg.

23 50 76 39 30

Both myself and canboat can successfully parse a PGN 129808 message that has been emitted from a VHF DSC radio from well known manufacturer. Note that aforesaid radio manufacturer is not immune from misinterpretation as they incorrectly generate the AIS AToN PGN 129793 with an error in encoding the AToN Name. But that's by the by. All three of us interpret the specification similarly.

Secondly there is the fact that a well known instrument manufacturer interprets the specification differently and consumes the MMSI address when it is encoded as

0x23 0x50 0x76 0x39 0x30

Important to note that said instrument manufacturer does not parse the MMSI address when it is also encoded in field 12 in the PGN.

Thirdly, and I have yet to fully confirm this, the SignalK -> NMEA 2000 plugin may be incorrectly generating the MMSI address upon receipt of a NMEA 183 DSC sentence and its subsequent conversion.

So the problem is simply whether myself, Kees and radio manufacturer are correct and the instrument manufacturer is incorrect.

Welcome to the world of NMEA 2000 interoperability !

[nohal]

I suppose that the well known manufacturers, unlike any of us, might be real paying members of the NMEA alliance (by some uneducated morons also called a smelly cartel) bound by the associated non-disclosure agreements, which in turn make any of us not able to do anything but guess from reverse engineering the intercepted datagrams.
So, especially if being their paying customer and owner of their equipment, which in it's price I paid sure includes a share of the forementioned alliance membership fees, would probably try to talk to their customer support, also probably included in the price of their equipment I bought, and try to make them resolve, or at least take some position towards, the interoperbility problems.
Sorry, I know this sounds like a bad joke.
I would probably expect the MMSI encoded consistently all over the standard, so if you encounterd one unit from one manufacturer doing it differently in one specific PGN, my bet would probably be they are at fault, not everybody else...

[Tehani]

I also interpreted it like this, and I have it written like this:

23 50 76 39 30

The problem is that it is not tested yet.

I have seen a well-known manufacturer establish a proprietary protocol for DSC messages between their radios and their chartplotters. We're going badly, as always with these guys ...

I appreciated whether it was worth investing a lot of time in the DSC. At the moment I only process the PGN 129808, and the rest is asleep.

I used this documentation for PGMN 129808:
(NMEA Technical Corrigendum TC# 2000 20150328)

In PGN # 129808 Field # 3 “DSC MessageAddress” shall be encoded as follows:
ForMMSI
• Each two decimal digits shall be encoded as the equivalent value in hexadecimal. As an MMSI
number is nine (9) digits long a trailing zero will be added.
• So a MMSI of 123456789 shall be encoded as 0x0C ( = 12 ), 0x22 ( = 34 ), 0x38 ( = 56 ), 0x4E ( =
78 ) and 0x5A ( = 90 ).
• When displaying the MMSI the trailing zero should be removed.

....

My personal opinion is that for PGN 129293 and following, the MMSI occupies 4 bytes, and is stored as a simple binary conversion (uint32_t) of the decimal value, without "0" in the least significant position.

[nohal]

Originally Posted by Tehani

My personal opinion is that for PGN 129293 and following, the MMSI occupies 4 bytes, and is stored as a simple binary conversion (uint32_t) of the decimal value, without "0" in the least significant position.

The MMSI is 9 digits, so I think you need 5 bytes and it does not fit into an uint32_t (Which to me actually seems to be the original source of this whole mess)

[Tehani]

Originally Posted by nohal

The MMSI is 9 digits, so I think you need 5 bytes and it does not fit into an uint32_t (Which to me actually seems to be the original source of this whole mess)

0xFFFFFFFF (uint32_t) = 4294967295 decimal (10 digits)

999999999 (decimal) = 0x2B9AC9FF (uint32_t)

As you can see, the maximum decimal value that can be represented with 9 decimal digits, fits perfectly in 32 binary bits, that is, 4 bytes.

[nohal]

Originally Posted by Tehani

0xFFFFFFFF (uint32_t) = 4294967295 decimal (10 digits)

999999999 (decimal) = 0x2B9AC9FF (uint32_t)

As you can see, the maximum decimal value that can be represented with 9 decimal digits, fits perfectly in 32 binary bits, that is, 4 bytes.

But that is not how the observed encoding is described in any of the posts above.

[Tehani]

Otherwise, using 5 bytes it is not possible to pack the definitions of PGN129793 and following, which can be seen in Kees' pgn.h.

That same 4-byte packing can also be seen in the PGN127233 (Man Overboard notification),and in the PGNs referring to AIS messages, minus 129801, 129804, where only 30 bits are used (as is done in NMEA0183).

Summarizing:
Only PGN 129808 uses 5 bytes, adding a "0" in the least significant digit and encoded from decimal by grouping two by two.
All other PGNs minus 129801 and 129804 convert the 9-digit integer decimal to a 32-bit hexadecimal.
The PGN's 129801 and 129804 reduce their impact on the message payload to 30 bits, because in reality, that is enough.

The result is dumped on the payload in little endian, as is usual in N2k.

[Tehani]

Conclusion: It could be said that the ITU and NMEA are associations that hire people with slightly damaged or overheated brains.
Either that, or they do it to annoy us.

Even they are not clear and they have to publish these things:
https://www.nmea.org/Assets/20150328...on%202.100.pdf

[Tehani]

Checked one more time.
Devices:
Matsutec AIS NMEA0183 -> Ocenav ATM105A3 -> Raymarine Axiom N2k.
Ocenav is also simultaneously providing WiFi data to Navionics Boating.

All MMSI numbers match (Matsutec, Axiom and Boating)

In AIS messages, the MMSI is encoded in pure 32-bit binary.
I do not see the reason why in the DSC messages that I have mentioned before, also encoded with 4 bytes, it has to be different.

[nohal]

That bulletin is a bit of a scary reading. I would probably be interested in the mental construct behind a "char" not being the same thing as uint8_t for them but 7 bits being int8_t ignoring the sign bit, making the resulting MMSI field both wasting bandwidth and not easily convertible to anything without any reason I can think of...

[nohal]

BTW, reading that PDF again, the reason behind the implementation is they don't support just MMSI, but also the "Geo Area" (https://www.itu.int/dms_pubrec/itu-r...0-S!!PDF-E.pdf) as address, which is 10 digits long and as such can't be converted to uint32_t.

[Tehani]

Originally Posted by Tehani

My personal opinion is that for PGN 129293 and following, the MMSI occupies 4 bytes, and is stored as a simple binary conversion (uint32_t) of the decimal value, without "0" in the least significant position.

Sorry, I meant 129793, my eyesight is failing me ...
7 and 2 are beginning to seem the same to me.