XDR support about nmea0183-signalk

[joabakk]

References:
/1/ Nexus, from http://www.nexusmarine.se/wp-content/uploads/2011/11/NMEA-HPC-Compas.pdf
/2/ Airmar, from http://www.airmartechnology.com/uploads/installguide/GCR200UserManual.pdf

[["PTCH","deg","navigation.attitude_pitch"],
["PIT","deg","navigation.attitude_pitch"],// ref /1/
["ROLL","deg","navigation.attitude_roll"],
["ROL","deg","navigation.attitude_roll"]];// ref /1/

["WCHR","deg",""],//relative wind chill, ref /2/
["WCHT","deg",""]];*///theoretical wind chill, ref /2/

[tkurki]

From http://www.cruisersforum.com/forums/f13/openplotter-project-152754-31.html

$YXXDR,C,7,C*54 - also from the nasa, outside temperature

$OPXDR,C,17.4,C,ENGT_55
$OPXDR,P,1.0004,B,AIRP,C,17.1,C,AIRT_45

Temperatures
$WIXDR,C,022.0,C,,_52
$YXXDR,C,20,C_61

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

[tkurki]

// 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

[tkurki]

https://github.com/SignalK/signalk-server-java/blob/e474ec29f988a9157cd371212ca3392482f49817/src/main/java/net/sf/marineapi/nmea/parser/CruzproXDRParser.java

[tkurki]

I started work on this in my own fork of the repo: tkurki@0162913

In case anybody wants to help I can add you as collaborator, like I already added @joabakk and @fabdrol in case they can pitch in.

[joabakk]

The "official" sources for nmea 0183 sentences tend to repeat what Airmar notes in their manual. If you add a "compliant" example, I can help populate. I think it's valid to reference as many of these as possible, because there is bound to be conflicts over XDR

[joabakk]

https://github.com/sailoog/openplotter/blob/master/i2c.py

[tkurki]

See #58

[joabakk]

How about a user configurable XDR translation controlled from a plugin? I have some old date from a self made compass, and for sure I won't use that format any more. But I'd like to get that data into use.
For some special cases where XDR is output, it may be easier to configure than to have a plethora of sensor codes in the parser.
Not even sure it is possible to control the parser that way, but an idea at least

[tkurki]

Writing a new XDR mapping in javascript is not too many lines of code.

Trying to make the same thing via a universal, configurable engine would take a lot more effort, with maybe very little gain.

I would rather create a system where you can add XDR mappings as javascript files added to a directory.

[joabakk]

I follow you @tkurki. I'm just such a fan of the plugin mechanism, so I think of that for every purpose. I'll tweak your code to suit my one time need and we can keep it alive until someone takes up the ball.

[rob42]

I wrote an XDR handler for the java server. Its not simple, and the whole XDR format is basically "I'll send what suits me and you work it out". Some awful stuff in there. It was never meant to be shared, just a way to send proprietary data over an existing protocol.
I did mine using external mappings, but each new XDR was just as much work as adding custom code, so I favour @tkurki - just write a convertor for each XDR. That allows for all the weirdness you will find in that rabbit hole.

[joabakk]

Funny thing @rob42 I just discovered I was trying to decode your NMEA XDR from FreeIMU... I wondered where I got that reference

[rob42]

:-) The FreeIMU XDR was an attempt to send the roll, pitch,yaw data in NMEA!
https://github.com/rob42/FreeIMU-20121106_1323/blob/master/FreeBoardIMU/FreeBoardIMU.ino
Much simpler in the new SignalkIMU https://github.com/SignalK/signalk-imu which just sends the signalk data directly!

[rob42]

The FreeIMU code predates signalk

[Hakansv]

Any efforts to add XDR will in future be most appreciated by OCPN users.
Comments about its use here: https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:advanced_features:nmea_sentences
Please scroll down to find XDR and used Transducer Name.
The Transducer Name opaqueness may be solved if SignaKl only let it pass and let the user sort accordingly. Transducer type "C" can for example use several names for different sensors.
What may be handy is a flag for numbers of passed quadruples?

[tkurki]

Have you tried the plugin https://www.npmjs.com/package/xdr-parser-plugin, available in the server's Appstore?

One option is to create a "OCPN XDR Plugin" that would parse the same XDRs that O already understands. Or preconfiguration for xdr-parser-plugin for O's sentences.

[Hakansv]

No, but I'll check.
It may not be a common solution to be distributed together with OCPN. For OpenPlotter it may do though?

[Hakansv]

@tkurki
I've tried the xdr-parser-plugin and it works rather good. Thanks. The shot shows the result when using both MDA and XDR for the same sensor.
So I look forward to a common SignalK implementation using similar methods as the plugin.