OpenPlotter project

[damianham]

I have been looking into adding support for the XDR NMEA sentence in signalK so I can display the values in my OceanIX Android instrument display app.

As a reminder user Swokey posted these XDR sentences on page 26 of this thread;

$OPXDR,C,17.4,C,ENGT*55
$OPXDR,P,1.0004,B,AIRP,C,17.1,C,AIRT*45

And then user Conachair posted these XDR sentences on page 29 of this thread;

$YXXDR,C,7,C*54 - also from the nasa, outside temperature
$OSXDR,C,9.5,C,1W0,C,9.0,C,1W1*56 - from Openplotter, 2 x engine ds18 thermometers.

There can be multiple quadruplets for each sensor reading in a single XDR sentence and the format of each quadruplet is

Type,Value,UnitOfMeasure,Name

As you can see from the above examples Swokey's temperature readings have the names ENGT and AIRT and Conachair's temperature readings have the names 1W0 and 1W1

Applications reading data from signalK would normally subscribe to updates for a given path within the json format signalK stream. The signalK sensor processing may not have been fully worked out yet but the specification currently states that the path 'sensors.{sensorID}.sensorData' would contain the sensor reading in a standard unit of measure. At the moment the specification states that the sensor ID is UUID identifier for the sensor. It makes more sense for me for this to be the name of the sensor.

So in the case of OceanIX and using the examples from Swokey I would subscribe to sensors.AIRT.sensorData to get the value of the air temperature. This wouldn't work for Conachair's examples though as the names are different.
I have implemented an XDR parser for the signalK node server (I just need to get the tests to pass and submit a pull request) which uses the name of the sensor from the quadruplet as the sensor ID in the path.

So my point is that I think we need a set of standard names for the sensors rather than free text names. This is already the case with the 12c module which uses the fixed names of [I2CP,I2CT,I2CH,I2CR]. we also need to cater for multiple sensors of the same type as you can see from Conachair's XDR sentences.

The good news for me at least is that I am flying to Cuba tomorrow night so I don't have much more time to work on this and I will be offline for 2 weeks. I probably don't have enough time to submit the pull request to get the XDR module into signalK. There will be a whole load of discussion required around it anyway most likely before the pull request would be merged into the master branch. I can attach the XDR module I have implemented to a message on this thread and you could drop it into your signalK node server implementation and it might work.

If we could quickly agree on a standard set of names for the sensors I could also post an update to OceanIX to handle the sensor data.

[richarddaneel]

Hi Sailoog, when I put the DS18B20 sensor cable on GPIO4 it works beautifully. However, my RPi GPS add on needs that pin please tell me how I can edit the code to use different pins, many thanks

[conachair]

Originally Posted by damianham

I have been looking into adding support for the XDR NMEA sentence in signalK so I can display the values in my OceanIX Android instrument display app./////
////
If we could quickly agree on a standard set of names for the sensors I could also post an update to OceanIX to handle the sensor data.

Check out this thread and there's one on slack as well.
https://groups.google.com/forum/#!to...lk/R6cmNYAxghc
I now have arduino data "sensorX=XXX" mapping to battery voltage/current in signalk just with some dummy values for now.
The code is in git..
https://github.com/emilecantin/arduino-signalk
I deleted the tcp port & context from index.js, still works ok.
I might try to map the openplotter
$OSXDR,C,9.5,C,1W0,C,9.0,C,1W1*56 - from Openplotter, 2 x engine ds18 thermometers.
to something in signalK today.
Are the oceanX engine instruments reading any signalk data at the moment?
Exciting times

[Sailoog]

Originally Posted by damianham

I have been looking into adding support for the XDR NMEA sentence in signalK so I can display the values in my OceanIX Android instrument display app.

As a reminder user Swokey posted these XDR sentences on page 26 of this thread;

$OPXDR,C,17.4,C,ENGT*55
$OPXDR,P,1.0004,B,AIRP,C,17.1,C,AIRT*45

And then user Conachair posted these XDR sentences on page 29 of this thread;

$YXXDR,C,7,C*54 - also from the nasa, outside temperature
$OSXDR,C,9.5,C,1W0,C,9.0,C,1W1*56 - from Openplotter, 2 x engine ds18 thermometers.

There can be multiple quadruplets for each sensor reading in a single XDR sentence and the format of each quadruplet is

Type,Value,UnitOfMeasure,Name

As you can see from the above examples Swokey's temperature readings have the names ENGT and AIRT and Conachair's temperature readings have the names 1W0 and 1W1

Applications reading data from signalK would normally subscribe to updates for a given path within the json format signalK stream. The signalK sensor processing may not have been fully worked out yet but the specification currently states that the path 'sensors.{sensorID}.sensorData' would contain the sensor reading in a standard unit of measure. At the moment the specification states that the sensor ID is UUID identifier for the sensor. It makes more sense for me for this to be the name of the sensor.

So in the case of OceanIX and using the examples from Swokey I would subscribe to sensors.AIRT.sensorData to get the value of the air temperature. This wouldn't work for Conachair's examples though as the names are different.
I have implemented an XDR parser for the signalK node server (I just need to get the tests to pass and submit a pull request) which uses the name of the sensor from the quadruplet as the sensor ID in the path.

So my point is that I think we need a set of standard names for the sensors rather than free text names. This is already the case with the 12c module which uses the fixed names of [I2CP,I2CT,I2CH,I2CR]. we also need to cater for multiple sensors of the same type as you can see from Conachair's XDR sentences.

The good news for me at least is that I am flying to Cuba tomorrow night so I don't have much more time to work on this and I will be offline for 2 weeks. I probably don't have enough time to submit the pull request to get the XDR module into signalK. There will be a whole load of discussion required around it anyway most likely before the pull request would be merged into the master branch. I can attach the XDR module I have implemented to a message on this thread and you could drop it into your signalK node server implementation and it might work.

If we could quickly agree on a standard set of names for the sensors I could also post an update to OceanIX to handle the sensor data.

Good point!

ENGT and AIRT are IDs used in OpenPlotter 0.6.0 and they have been replaced by the new system so they are obsolete. As you noticed the new system is based on the type of sensor connection and IDs will be always unique.

So, my proposal is as follows...

I2C
I2CT: Air temperature
I2CP: Air pressure
I2CH: Air humidity
I2CX: Heel (Roll)
I2CY: Pitch

1W (temperature sensors)
1W0, 1W1, 1W2... : coolant temp, exhaust temp, fridge temp...

ADC (analog sensors)
ADC0, ADC1, ADC2... : Voltage and current of batteries, solar panels, wind generator...; tanks level...

PLS (pulse sensors)
PLS0, PLS1, PLS2... : Fuel and water flow, rpm, anchorage chain counter...

ADC and PLS modules are under construction. We should also agree on standard units but I suppose we could take signalk units defined as standard.

The problem I see is that we will get "sensors.1W0.sensorData" as tags and they are not explicit. Instrument panels and apps should have a custom field to rename it, isn't it?

[damianham]

On another thread https://groups.google.com/forum/#!to...lk/Q3QnOATXxSI
they discuss the XDR sentence and the OP mentions the ENGT,AIRT,HUMI and ROLL

The consensus is that their is a variety of data formats in this sentence.

The way I implemented the XDR module for signalK was to use the name provided in the XDR sentence for the signalK path - so in this respect signalK would be agnostic.

Yes OceanIX already handles engine data.

BTW signalK already has an element in the specification for engine coolant within the propulsion section and the signalK message is generated by the n2k-signalk parser. The source of the sensor data may well be an Actisense EMU-1 which generates n2k messages.

I see that the openplotter GUI has "engine coolant temperature" but I suspect the 1W temperature sensors will be more engine room sensors than coolant temperature. Please correct me if I am mistaken.

Originally Posted by conachair

Check out this thread and there's one on slack as well.

Are the oceanX engine instruments reading any signalk data at the moment?
Exciting times

[Sailoog]

Originally Posted by damianham

I see that the openplotter GUI has "engine coolant temperature" but I suspect the 1W temperature sensors will be more engine room sensors than coolant temperature. Please correct me if I am mistaken.

that is on OpenPlotter v0.6.0

OpenPlotter v0.7.0 contains the new model that I describe on my last post.

Test OpenPlotter v0.7.0beta | Sailoog

I can't find your OceanIX app, is it published?

[damianham]

https://play.google.com/store/apps/d...izness.oceanIX

Originally Posted by Sailoog

I can't find your OceanIX app, is it published?

[damianham]

Yes I think we should leave the renaming to the instrument panels and apps then the data is always in a generic form then no mapping is required in either openplotter or signalk.

Originally Posted by Sailoog

1W (temperature sensors)
1W0, 1W1, 1W2... : coolant temp, exhaust temp, fridge temp...


ADC and PLS modules are under construction. We should also agree on standard units but I suppose we could take signalk units defined as standard.

The problem I see is that we will get "sensors.1W0.sensorData" as tags and they are not explicit. Instrument panels and apps should have a custom field to rename it, isn't it?

[damianham]

I have submitted a pull request (#53) for signalk-parser-nmea0183 which implements the XDR codec.

The sensor names used are taken from the input so whatever OP generates will arrive at the consumer apps.

I will get on with adding sensor handling to OceanIX according to the sensor names below and hopefully upload an update before I ride off into the sunset tomorrow evening.

Originally Posted by Sailoog

Good point!

ENGT and AIRT are IDs used in OpenPlotter 0.6.0 and they have been replaced by the new system so they are obsolete. As you noticed the new system is based on the type of sensor connection and IDs will be always unique.

So, my proposal is as follows...

I2C
I2CT: Air temperature
I2CP: Air pressure
I2CH: Air humidity
I2CX: Heel (Roll)
I2CY: Pitch

1W (temperature sensors)
1W0, 1W1, 1W2... : coolant temp, exhaust temp, fridge temp...

ADC (analog sensors)
ADC0, ADC1, ADC2... : Voltage and current of batteries, solar panels, wind generator...; tanks level...

PLS (pulse sensors)
PLS0, PLS1, PLS2... : Fuel and water flow, rpm, anchorage chain counter...

ADC and PLS modules are under construction. We should also agree on standard units but I suppose we could take signalk units defined as standard.

The problem I see is that we will get "sensors.1W0.sensorData" as tags and they are not explicit. Instrument panels and apps should have a custom field to rename it, isn't it?

[Sailoog]

Originally Posted by damianham

I have submitted a pull request (#53) for signalk-parser-nmea0183 which implements the XDR codec.

The sensor names used are taken from the input so whatever OP generates will arrive at the consumer apps.

I will get on with adding sensor handling to OceanIX according to the sensor names below and hopefully upload an update before I ride off into the sunset tomorrow evening.

that sounds great!

Just to clarify...

these IDs will always match these magnitudes:

I2C
I2CT: Air temperature
I2CP: Air pressure
I2CH: Air humidity
I2CX: Heel (Roll)
I2CY: Pitch

But all the others, for example 1W0, might correspond to any magnitude (coolant temp, exhaust temp, fridge temp...)

I will add this proposed use of XDR to the OpenPlotter documentation if there are no more suggestions.

Have a good time in Cuba!!!

[damianham]

openplotter/ic2.py has

if conf.get('STARTUP', 'nmea_heel')=='1' and heel:
heel= round(heel,1)
list_tmp.append('A')
list_tmp.append(str(heel))
list_tmp.append('D')
list_tmp.append('I2CR')

so IC2R for heel

I just did a git pull so I am up to date

Originally Posted by Sailoog

So, my proposal is as follows...

I2C
I2CT: Air temperature
I2CP: Air pressure
I2CH: Air humidity
I2CX: Heel (Roll)
I2CY: Pitch

[Sailoog]

Originally Posted by damianham

openplotter/ic2.py has

if conf.get('STARTUP', 'nmea_heel')=='1' and heel:
heel= round(heel,1)
list_tmp.append('A')
list_tmp.append(str(heel))
list_tmp.append('D')
list_tmp.append('I2CR')

so IC2R for heel

I just did a git pull so I am up to date

Yes, sorry. I switched to I2CX:Heel to maintain coherence with I2CY:Pitch

Heel=Roll=X axis
Pitch=Y axis

Tomorrow I will change I2CR by I2CX and add Pitch on i2c.py code

[conachair]

Originally Posted by damianham

I see that the openplotter GUI has "engine coolant temperature" but I suspect the 1W temperature sensors will be more engine room sensors than coolant temperature. Please correct me if I am mistaken.

The ds18 sensors are great little things, can measure between -55°C to +125°C so should be fine on engines as well, I have 3 fitted, head block, alternator and exhaust elbow.
https://www.maximintegrated.com/en/p...e/DS18B20.html

Also, I've hit a bit of a stumbling block which maybe someone could help with:
I have an arduino mega which is fixing nmea wind data from a nasa unit with wrong checksums. Also it is sending out battery sensor data which signalK reads.
If openplotter has the /dev/ttyACM0 source from the arduino enabled signalK stops getting the data and openplotter seems to strip out the sensor data (not nmea?) , signalK still gets the wind data.
If neither OpenCPN or openplotter have ACM0 enabled as an input then signalK transmits both the sensor data and the wind data.
So not sure how to get ACM0 to feed both openplotter and signalK.
Any ideas?
This might affect others as arduino megas are a handy way to multiplex nmea data as the have 4 x serial ports.

Thanks

[richarddaneel]

Hi Conachair, as befits a newbie my ds18 problem is much more basic so please see if you can help. I cannot use GPIO4 (pin7) as my gps add-on uses that pin. How do I change the code or programme to say use GPIO12 or 16 (pin 32 or 36) on the RPi instead. many thanks Richard

[teppokurki]

Originally Posted by conachair

So not sure how to get ACM0 to feed both openplotter and signalK.
Any ideas?
This might affect others as arduino megas are a handy way to multiplex nmea data as the have 4 x serial ports.

Signal K Node server will nowadays (since a few days) serve all incoming NMEA0183 data over tcp port 10110.

Other than that you can use gpsd to connect to the serial line and have SK server and (I assume) Openplotter connect to its tcp port.