nmea0183-signalk
nmea0183-signalk copied to clipboard
SignalK
XDR support
To get proper support for XDR we could first document some of the sentences out there and then create a solution that works well for them and can be easily extended to cover other sentences.
In practice this is probably another mapping level not unlike the one we have for codecs.
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/
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<CR><LF>
// 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
https://github.com/SignalK/signalk-server-java/blob/e474ec29f988a9157cd371212ca3392482f49817/src/main/java/net/sf/marineapi/nmea/parser/CruzproXDRParser.java
I started work on this in my own fork of the repo: https://github.com/tkurki/signalk-parser-nmea0183/commit/016291301a327e37fd647b287f76d24ecd16c9fc
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.
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
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
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.
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.
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.
Funny thing @rob42 I just discovered I was trying to decode your NMEA XDR from FreeIMU... I wondered where I got that reference
:-) 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!
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?
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.
No, but I'll check. It may not be a common solution to be distributed together with OCPN. For OpenPlotter it may do though?
@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.
