Support for IEC Standard 61162-450 NMEA sentences

[NikolajDL]

I'm in the process of testing a VDR system sending the IEC Standard 61162-450 NMEA sentences, instead of just the regular IEC 61162-1 sentences. Is there any chance of enabling support for this standard in the near future?

The IEC 61162-450 standard describes a block of additional data prefixed to each NMEA sentences, to change the protocol from a single talker, multiple listeners-protocol, to a multiple talkers, multiple listeners-protocol. In our particular case, we really don't use the multiple talkers-part, since the data still only comes from a single VDR source system, but we are required to consume this particular syntax and it would be very helpful if this tool, could simulate this block of additional data at least partially.

The IEC 61162-450 NMEA sentences have the following syntax:

\p1:v1,...,pn:vn*hh\<the regular NMEA sentence>

where p1 is the first parameter, v1 is the first value, pn is the nth parameter and vn is the nth value. The hh is the checksum, generated in a similar fashion to the regular NMEA sentence. The available and valid parameters are fixed and described in the Standard.

An example sentence of this format could look like this:

\s:002131,c:1677664386*B4\$GPGLL,5546.791377,N,01034.130717,E,095346.551,A*33

I'm willing to contribute to this feature myself, if you make the source code available for forking.

[panaaj]

I agree this is a valuable feature to add.

I do not have access to the standard you refer to but from your description it seems that it would be reasonably straightforward to add.

The questions I have are related to how this should be implemented?

Does the app just provide a set of valid parameter types per sentence and then allow a value to be entered?

Do the values need to change or can they remain static?

[NikolajDL]

Hi Panaaj, thank you for responding.

In our particular usecase, the values of the parameters doesn't really matter, since we're basically still just using the regular NMEA sentence - we're just forced to take the IEC 61162-450 NMEA standard messages into account, because those are the messages our customers VDR systems provide. But for the feature to be useful to others, I guess they should in some way reflect their intended usage in the simulator as well.

I think some could just be static and some could change, for instance there's a source id-parameter which could simply be static, and a unix timestamp-parameter which could reflect the realtime. Most of the parameters are merely meta information about the origin and context of the NMEA sentence, and to be honest, since we don't really use these parameters for other than validating the checksum, I havn't yet had a look into the meaning of all but a few of them.

Not all parameters are necessarily required either. In our case we just receive the source id and the timestamp.

While I cannot share the standard document, I can share a short description of the interface and syntax of the IEC 61162-450 NMEA messages. It is split up into two parts; the TAG-block and the NMEA message (which is just the regular message sent today). It looks like this:

\<TAG-block\<NMEA message>

Just like the example in my original message. The TAG-block (an acronym for Transport, Annotate, Group) contains a comma-separated list of the parameters, ending with a 16-bit checksum (just like the NMEA message). This is a list of the possible parameters:

• "c" UNIX timestamp
• "d" Destination identification
• "g" Sentence grouping
• “n" Line count
• "r" Relative time
• "s" Source identification
• "t" Free text
• "a" General authentication

As I said, the TAG-block may contain only some or all of the parameters, so it would be useful if you could check which parameters you wanted present in your message. A more in-depth description is available in the standard document, so I'm afraid I'm unable to share more, but I reckon you could get away with leaving most of the values static or empty, regardless of their semantic meaning. They're after all meant to enable support for multiple talkers, while the simulator is just a single talker.

[panaaj]

Here is the proposed "prefixed" output that can can will be available via a setting:

\c:1677816830,s:nmeasim*40\$IIVHW,17.4,T,17.4,M,5.3,N,9.7,K*5D

I have the following questions that the spec will likely provide the answers for:

1. Are you able to confirm what the input for the checksum calculation is?

Checksum: based on the example you supplied where the prefix checksum is B4.

 \s:002131,c:1677664386*B4\$GPGLL,5546.791377,N,01034.130717,E,095346.551,A*33

the checksum formula is use that correctly calculates the checksum of the NMEA sentence part as 33 does not create a matching checksum for the prefix. These are the results I get are following:

\s:002131,c:1677664386\ => 6F
s:002131,c:1677664386 => 40

I can only conclude that the parts of the prefix I am supplying to the calculation is not correct.

2. What are valid values for s:? Can these be characters as well as numbers?

[NikolajDL]

Your proposed output would be perfectly sufficient for my use case.

A: 1. Are you able to confirm what the input for the checksum calculation is?

The part used for the checksum is everything from the first \ until the checksum separator *. So in your example, the checksum would be calculated based on this part: s:002131,c:1677664386. The checksum B4 in my original comment, weren't calculated, I just created it as a short example by hand. When I calculate the checksum now, for that particular string, I get the hex number 0x33. I'm not sure exactly what causes the discrepancy.

I can share a minimal example of the checksum calculation we use in python, but it's exactly the same function used for calculating the NMEA sentence checksum:

tag_string = 's:002131,c:1677664386'
calculated_checksum = hex(reduce(operator.xor, map(ord, tag_string), 0))

That is the same function I use for validating the checksum of the NMEA messages.

A: 2. What are valid values for s:? Can these be characters as well as numbers?

Yes, as far as I'm aware alphanumeric characters are valid, so both letters and numbers.

[panaaj]

What platform do you use Windows, Linux? I'll create a version for you to test.

[NikolajDL]

I'm using mostly Windows. I'm looking forward to it.

[panaaj]

Here is a link to the Windows version preview

[NikolajDL]

I've just tested it and it seems to work exactly as intended.

[panaaj]

Added v1.5.0