Nmea XDR conventions?

[joachim bakke]

I am wondering whether there are defined conventions for the xdr id's. It is meant to be groups of four values (type,value,unit,id). The ones i have seen are ENGT ( engine temperature), HUMI (humidity), AIRT (air temperature) and ROLL ( roll angle).

Assuming these are standard, how would I go about adding logics to an XDR sentence in nmea0183 parser? Check for every id value for a match to this expanding list and map?

[Teppo Kurki]

sunnuntai 14. helmikuuta 2016 joachim bakke <joachi...@gmail.com> kirjoitti:

I am wondering whether there are defined conventions for the xdr id's. It is meant to be groups of four values (type,value,unit,id). The ones i have seen are ENGT ( engine temperature), HUMI (humidity), AIRT (air temperature) and ROLL ( roll angle).

Assuming these are standard, how would I go about adding logics to an XDR sentence in nmea0183 parser? Check for every id value for a match to this expanding list and map?

Create an object with the well known ids as property names and SK paths as values. Then use the object to look up the path to go into the delta message.

If the ids are user defined we need to have a way to configure the mapping.

That leaves unit conversion to tackle.

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Bremford]

It's meant to be four values but there are plenty of variations. Here are temperature sentences from two different masthead anemometers I have:

$WIXDR,C,022.0,C,,*52
$YXXDR,C,20,C*61

And the Airmar device at http://www.airmartechnology.com/uploads/installguide/PB100TechnicalManual_rev1.007.pdf offers a format for their WIXDR sentence like this:

$WIXDR,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>,<13>,<14>,<15>,<16>*hh<CR><LF>

This field seems to be a bit of a dumping ground for data, and I don't think these sentences will ever be self-explanatory. You will always need some context to determine what they mean, and that will have to come from the person setting up a SignalK server on their vessel: maybe saying "the device on this port reports air temperature in field 2", or "the device with a prefix of WI reports air temperatures in field 2", or some other variation.

Cheers... Mike

[joachim bakke]

Thanks Mike,

This is what I feared. It seems Airmar is not  even following their own specification of WIXDR. I think you are right, that this is indeed a dumping ground. The best I can do then is provide a start for the obedient tuples of four, and then we can see which ones need special attention as people start missing values.

Pseudocode suggestion:

list = [[name:PTCH,unit:deg, signalkMap:map to value in sk tree],[name: ROLL, unit: deg,signalkMap:map to value in sk tree]],[...,...,,...].]]

value x = number of quadruples 

for every x[3], check if variable equals item in list

  map to value in tree, value of x[2] (converted from list[item][unit]

mandag 15. februar 2016 15.30.56 UTC+1 skrev Mike følgende:

It's meant to be four values but there are plenty of variations. Here are temperature sentences from two different masthead anemometers I have:

$WIXDR,C,022.0,C,,*52
$YXXDR,C,20,C*61

And the Airmar device at http://www.airmartechnology.com/uploads/installguide/PB100TechnicalManual_rev1.007.pdf offers a format for their WIXDR sentence like this:

$WIXDR,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>,<13>,<14>,<15>,<16>*hh<CR><LF>

This field seems to be a bit of a dumping ground for data, and I don't think these sentences will ever be self-explanatory. You will always need some context to determine what they mean, and that will have to come from the person setting up a SignalK server on their vessel: maybe saying "the device on this port reports air temperature in field 2", or "the device with a prefix of WI reports air temperatures in field 2", or some other variation.

Cheers... Mike

On 14 February 2016 at 21:26, Teppo Kurki <t...@iki.fi> wrote:

sunnuntai 14. helmikuuta 2016 joachim bakke <joachi...@gmail.com> kirjoitti:

I am wondering whether there are defined conventions for the xdr id's. It is meant to be groups of four values (type,value,unit,id). The ones i have seen are ENGT ( engine temperature), HUMI (humidity), AIRT (air temperature) and ROLL ( roll angle).

Assuming these are standard, how would I go about adding logics to an XDR sentence in nmea0183 parser? Check for every id value for a match to this expanding list and map?

Create an object with the well known ids as property names and SK paths as values. Then use the object to look up the path to go into the delta message.

If the ids are user defined we need to have a way to configure the mapping.

That leaves unit conversion to tackle.

--
You received this message because you are subscribed to the Google Groups "Signal K" group.

To unsubscribe from this group and stop receiving emails from it, send an email to signalk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[rob...@42.co.nz]

Ive dealt with this issue in Freeboard too. The XDR in question was from Cruspro and is only relevant to them,
// Cruzpro YXXDR sentence
//from Cruzpro - The fields in the YXXDR sentence are always from the same "critical" functions, in order:
                    //RPM
                    //Battery #1 Volts
                    //Depth
                    //Oil Pressure
                    //Engine Temperature

* Cruzpro non-standard XDR sentence parser.
 * The scheme for resolving the values to freeboard keys is done via the freeboard.cfg properties.
 * Under the spec each value has a name, and the names are concatenated to a string as 'getDevice()'. This string is
 * looked up as property freeboard.nmea.YXXDR.cat_string=key1,key2,key3,keyn
 * <p>
 * The number of keys should match the values in the XDR. A blank key (key1,,key3) is skipped.
 * In the case of Cruzpro (3 fields per value) the device string is 'MaxVu110'

Basically its a really good example of why we need SignalK :-) I think its safe to say that XDR is not standard in any useful way, each variant is it own format

Rob