Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Old 22-02-2016, 01:51   #451
Marine Service Provider

Cruisers Forum Supporter

Join Date: May 2013
Location: Brighton UK
Boat: 78ft ex racing catamaran
Posts: 63
Re: OpenPlotter project

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.
__________________

__________________
damianham is offline   Reply With Quote
Old 22-02-2016, 02:43   #452
Registered User

Join Date: Apr 2015
Location: Cape Town
Posts: 22
Re: OpenPlotter project

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
__________________

__________________
richarddaneel is offline   Reply With Quote
Old 22-02-2016, 02:46   #453
Registered User

Join Date: Nov 2007
Location: Probably and anchorage or a boatyard..
Boat: Ebbtide 33' steel cutter
Posts: 2,846
Re: OpenPlotter project

Quote:
Originally Posted by damianham View Post
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

__________________
conachair is offline   Reply With Quote
Old 22-02-2016, 03:57   #454
Registered User

Join Date: Jul 2015
Location: Barcelona, Catalonia.
Posts: 277
Re: OpenPlotter project

Quote:
Originally Posted by damianham View Post
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?
__________________
OpenPlotter Project
Site:www.sailoog.com/en/openplotter
Support: www.openmarine.net
Sailoog is offline   Reply With Quote
Old 22-02-2016, 04:41   #455
Marine Service Provider

Cruisers Forum Supporter

Join Date: May 2013
Location: Brighton UK
Boat: 78ft ex racing catamaran
Posts: 63
Re: OpenPlotter project

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.

Quote:
Originally Posted by conachair View Post
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

__________________
damianham is offline   Reply With Quote
Old 22-02-2016, 04:54   #456
Registered User

Join Date: Jul 2015
Location: Barcelona, Catalonia.
Posts: 277
Re: OpenPlotter project

Quote:
Originally Posted by damianham View Post
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?
__________________
OpenPlotter Project
Site:www.sailoog.com/en/openplotter
Support: www.openmarine.net
Sailoog is offline   Reply With Quote
Old 22-02-2016, 05:22   #457
Marine Service Provider

Cruisers Forum Supporter

Join Date: May 2013
Location: Brighton UK
Boat: 78ft ex racing catamaran
Posts: 63
Re: OpenPlotter project

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

Quote:
Originally Posted by Sailoog View Post

I can't find your OceanIX app, is it published?
__________________
damianham is offline   Reply With Quote
Old 22-02-2016, 05:47   #458
Marine Service Provider

Cruisers Forum Supporter

Join Date: May 2013
Location: Brighton UK
Boat: 78ft ex racing catamaran
Posts: 63
Re: OpenPlotter project

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.

Quote:
Originally Posted by Sailoog View Post

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 is offline   Reply With Quote
Old 22-02-2016, 07:11   #459
Marine Service Provider

Cruisers Forum Supporter

Join Date: May 2013
Location: Brighton UK
Boat: 78ft ex racing catamaran
Posts: 63
Re: OpenPlotter project

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.

Quote:
Originally Posted by Sailoog View Post
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 is offline   Reply With Quote
Old 22-02-2016, 07:50   #460
Registered User

Join Date: Jul 2015
Location: Barcelona, Catalonia.
Posts: 277
Re: OpenPlotter project

Quote:
Originally Posted by damianham View Post
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!!!
__________________
OpenPlotter Project
Site:www.sailoog.com/en/openplotter
Support: www.openmarine.net
Sailoog is offline   Reply With Quote
Old 22-02-2016, 07:57   #461
Marine Service Provider

Cruisers Forum Supporter

Join Date: May 2013
Location: Brighton UK
Boat: 78ft ex racing catamaran
Posts: 63
Re: OpenPlotter project

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

Quote:
Originally Posted by Sailoog View Post
So, my proposal is as follows...

I2C
I2CT: Air temperature
I2CP: Air pressure
I2CH: Air humidity
I2CX: Heel (Roll)
I2CY: Pitch
__________________
damianham is offline   Reply With Quote
Old 22-02-2016, 08:03   #462
Registered User

Join Date: Jul 2015
Location: Barcelona, Catalonia.
Posts: 277
Re: OpenPlotter project

Quote:
Originally Posted by damianham View Post
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
__________________
OpenPlotter Project
Site:www.sailoog.com/en/openplotter
Support: www.openmarine.net
Sailoog is offline   Reply With Quote
Old 22-02-2016, 08:43   #463
Registered User

Join Date: Nov 2007
Location: Probably and anchorage or a boatyard..
Boat: Ebbtide 33' steel cutter
Posts: 2,846
Re: OpenPlotter project

Quote:
Originally Posted by damianham View Post
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 -55C to +125C 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
__________________
conachair is offline   Reply With Quote
Old 22-02-2016, 09:00   #464
Registered User

Join Date: Apr 2015
Location: Cape Town
Posts: 22
Re: OpenPlotter project

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
__________________
richarddaneel is offline   Reply With Quote
Old 22-02-2016, 12:44   #465
Registered User

Join Date: Feb 2016
Posts: 12
Re: OpenPlotter project

Quote:
Originally Posted by conachair View Post
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.
__________________

__________________
teppokurki is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Want To Buy: Project Boat: Engineless 35'ish blue water cruiser project Max Sail Classifieds Archive 52 24-03-2013 13:27
Greetings + my project Marco Meets & Greets 8 27-02-2009 17:28
Major Project: What is the best way to organize our discussions? Andy R Forum Tech Support & Site Help 6 04-04-2006 15:21
Our ongoing project - Offshore 41 By Invitation Construction, Maintenance & Refit 7 04-12-2005 07:42
Portal sailing website project CaptainTom Meets & Greets 2 20-03-2003 07:50


Our Communities

Our communities encompass many different hobbies and interests, but each one is built on friendly, intelligent membership.

» More about our Communities

Automotive Communities

Our Automotive communities encompass many different makes and models. From U.S. domestics to European Saloons.

» More about our Automotive Communities

Marine Communities

Our Marine websites focus on Cruising and Sailing Vessels, including forums and the largest cruising Wiki project on the web today.

» More about our Marine Communities


Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 00:36.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.