This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
XDR to Signal K delta converter
#1
I've got a bunch of sensors that use the XDR message to output data - everything from environmental to pitch & roll to tank levels.

Signal K doesn't support XDR conversion natively so I was forced to write a C program for linux (Raspberry Pi) to get my sensor data into Signal K.

I tried to write it in a manner which is useful for "all" XDR messages.
The basics are:
The program uses TCP sockets for input and output. It connects to the input as a client and offers a server socket for the Signal K server to connect to. It uses a dictionary to look up definitions of the incoming XDR messages. The matching is done on the 4th field of each quadruple in the XDR message. For example in the first messages below the matching is done on the ENV_OUTSIDE_T and ENV_ATMOS_P fields. All you would need to do for any XDR message is record this value in the dictionary and supply the correct Signal K path

$IIXDR,C,28.7,C,ENV_OUTSIDE_T,P,101400,P,ENV_ATMOS_P,H,47.38,P,ENV_OUTSIDE_H*32
$IIXDR,C,,C,ENV_WATER_T,C,28.69,C,ENV_OUTAIR_T,P,101400,P,ENV_ATMOS_P*69

Here is an example of definitions in the dictionary to generate signal k deltas for the XDR messages above
{type = "Outside temperature"
data = "temperature";
units = "C";
name = "ENV_OUTSIDE_T";
expression = "(x+273.15)";
sk_path ="environment.outside.temperature" },

{type = "Outside pressure";
data = "pressure";
units = "Pa";
name = "ENV_ATMOS_P";
expression = "(x*1)";
sk_path ="environment.outside.pressure" },

Here is another one for water tank levels
            {type = "WaterLevel";
            data = "volume";
            units = "%";
            name = "WATER#0";
            expression = "(x/225)"
            sk_path ="tanks.freshWater.0.currentLevel" },

The name field is matched as explained above and the program associates the data in the XDR message with the provided sk_path field as a pair in an output Signal K delta message.

The program also caters for the conversion of the XDR data to Signal K SI requirements with the expression field. In the example definition above the liters value provided in the XDR message is divided by the tank capacity (x/225) to meet the ratio requirement of Signal K. The expression (x+273.15) is similarly used to convert from Celcius to Kelvin and similarly degrees to radians are catered for.

The program also looks for a "special" value in the type field in the dictionary - "Vessel attitude". When it finds this it produces the the navigation attitude object. Because it isn't possible to directly associate the ROLL, PITCH and YAW data which can be in different messages a "rolling association" is maintained - as new values are received they are associated with the previously received associated elements.

I'm happy to share the code if anyone is interested.
Reply
#2
Please share!

Your approach to creating a generic, configurable XDR mapping seems viable to me.

Have you considered turning this into a configurable server plugin? That would make it much more approachable:
- compiling and running a separate C app as a daemon is rather daunting to most users
- a plugin would be installable in the App store
- a plugin provides the configuration form out of the box, when you create a schema for your plugin config data
- a plugin is cross platform out of the box




Sent from my iPhone using Tapatalk
Reply
#3
(2019-07-08, 01:12 PM)tkurki Wrote: Please share!

Your approach to creating a generic, configurable XDR mapping seems viable to me.

Have you considered turning this into a configurable server plugin? That would make it much more approachable:
- compiling and running a separate C app as a daemon is rather daunting to most users
- a plugin would be installable in the App store
- a plugin provides the configuration form out of the box, when you create a schema for your plugin config data
- a plugin is cross platform out of the box




Sent from my iPhone using Tapatalk
The C code is here:
https://github.com/GaryWSmith/xdr2sk

I have no clue on where to start with a plugin but I'll give it a bash. Can you point me to a starting point? A demo plugin or something?

Thanks
Reply
#4
Thank you for the work https://github.com/GaryWSmith/xdr-parser-plugin Gary! As a new SK user, this was very helpful. My XDR has the 4th quartile blank, so I edited the ~/.signalk/plugin-config-data/xdrParser-plugin.json file since the GUI makes it a required field.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)