OpenPlotter project

[Sailoog]

Originally Posted by teppokurki

With a "reverse public tunnel" (my expression) tool like https://ngrok.com/ you can create a tunnel from a publicly accessible host to a server running locally behind a NAT + firewall + service provider restrictions. I've successfully published onboard sailing data with a Signal K server + sailgauge/instrumentpanel.

Another option for private remote access is setting up a VPN. I can access my onboard SK server or the RPi via ssh by opening a VPN connection to the onboard VPN server. Access to your MFD with the tablet apps should also be possible, but can't yet vouch for it.

For those willing to go with Ansible setting up a VPN over 4G uplink: https://github.com/tkurki/marinepi-p...ia.yml#L29-L43

Maybe OpenPlotter could include either or both of these techniques as options?


Maybe OpenPlotter could include such functionality as an option?

Nice, I will give it a go on v0.9.0
Thanks!

[Sailoog]

Originally Posted by Nick_Currawong

Hi guys,

I have created a version of RTIMULib2 to handle my IMU MPU9255.

So how do I replace/update the libraries within openplotter?
I have compiled the RTIMULib , RTIMUDrive* , RTIMUDemo* libraries.

Openplotter can see the bmp180 sensor but not the IMU (greyed out), when I "reset and then calibrate " the RTIMUDemoGL sees my sensor.

I am using a Raspberry pi 2 and version 0.8.0 beta.

Any ideas and help grateful accepted.

Thanks

Great work! I was planning to include your version and this one https://github.com/jeff-loughlin/RTIMULib2 to v0.9.0

You should install the python part too:

cd python 
python setup.py build 
sudo python setup.py install

Do you have plans to add more boards or keep working on Richards code?

let me know if you can detect MPU9255 finally

Thanks!

[petter5]

Originally Posted by Sailoog

Great work! I was planning to include your version and this one https://github.com/jeff-loughlin/RTIMULib2 to v0.9.0

You should install the python part too:

cd python 
python setup.py build 
sudo python setup.py install

Do you have plans to add more boards or keep working on Richards code?

let me know if you can detect MPU9255 finally

Thanks!

Would really like if the Emlid Navio+ HAT board was fully detected and supporter " out of the box" https://emlid.com/shop/navio-plus/
and https://github.com/emlid/Navio

[Nick_Currawong]

Hi Sailoog,

I ran the python commands from my ../git/RTIMULIb2/Linux/Python dir. They ran successfully, reboot'ed but still no good.
The install command wrote to /usr/local/lib/python2.7/dist-packages/RTIMULib-8.0.0.egg-info

Any other ideas , or places to check?

No plans to add extra devices, I don't mind adding the extra devices but can't do anything for the next months as we are sailing so no nice big monitor/keyboard onboard or lots of spare time.

Just got my touch screen to work, so very happy with that.

Thanks

[Nick_Currawong]

Hi guys,

Another question,

I would like opencpn dashboard to display the extra information from my bmp180 sensor (air temp & pressure). I understand that the dashboard uses the "old" NMEA sentences not the sentences produced by openplotter.
Can or how do I convert/rewrite the produced sentence to a different format?

Sorry if this has been asked before or under a different thread.

Thanks

[stakston]

Originally Posted by Nick_Currawong

Hi guys,

Another question,

I would like opencpn dashboard to display the extra information from my bmp180 sensor (air temp & pressure). I understand that the dashboard uses the "old" NMEA sentences not the sentences produced by openplotter.
Can or how do I convert/rewrite the produced sentence to a different format?

Sorry if this has been asked before or under a different thread.

Thanks

I use the NMEA Converter plugin to Opencpn to fix this. At least for temperature. Install the plugin and add the conversion formula. I used this formula for my setup: $XXMTA, $OSXDR2, $OSXDR3

You could also convert the Pressure into a field that the Dashboard can display. Maybe use on that is not in use for your setup, like Heel. Have not tried this but should work.

Gaute

[damianham]

Hi guys

I am back from my travels for a short while and I want to pick up where I left off with sensor data display. I have implemented a sensor data display feature in my OceanIX android app but I see that the XDR codec changes (to handle sensor data from NMEA-0183 data stream) haven't yet been committed into the signalK repo.

There are dev 2 teams at work here - signalK and openplotter so it needs a bit of a co-ordinated effort.

Anyway from what I can see, Teppo Kurki's uncommitted fork at https://github.com/tkurki/signalk-pa...76d24ecd16c9fc

does not include code to handle the NMEA 0183 messages generated by OpenPLotter. I submitted an XDR codec implementation for signalK that would have handled the NMEA messages generated by OpenPlotter but this worked on the basis of generic pass through which the signalK team are not in favour of (although looking at the specification I think it was actually compliant).

So according to the signalK specification if we have a temperature sensor inside the engine room (not sure what happens in catamarans...)
openplotter needs to generate an NMEA sentence that can be translated by the signalK XDR codec to "environment.inside.engineRoom".

Currently there is nothing in the implementation of openplotter/1w.py to suggest that the location of the temperature sensor can be identified.

I could be mistaken but I think this means that OP will have to generate signalK format data and send it to the signalK server in order for this to work.

regards
damian

[Sailoog]

Originally Posted by Nick_Currawong

Hi Sailoog,

I ran the python commands from my ../git/RTIMULIb2/Linux/Python dir. They ran successfully, reboot'ed but still no good.
The install command wrote to /usr/local/lib/python2.7/dist-packages/RTIMULib-8.0.0.egg-info

Any other ideas , or places to check?

No plans to add extra devices, I don't mind adding the extra devices but can't do anything for the next months as we are sailing so no nice big monitor/keyboard onboard or lots of spare time.

Just got my touch screen to work, so very happy with that.

Thanks

It's strange.
These are all the commands I do to compile. Try to do exactly but changing the repo:

cd 
git clone https://github.com/sailoog/RTIMULib2.git 
cd RTIMULib2/Linux 
mkdir build 
cd build 
cmake .. 
make -j4 
sudo make install 
sudo ldconfig 
cd .. 
cd RTIMULibCal 
make -j4 
sudo make install 
cd .. 
cd RTIMULibDrive 
make -j4 
sudo make install 
cd .. 
cd RTIMULibDrive10 
make -j4 
sudo make install 
cd .. 
cd RTIMULibDemo 
qmake 
make -j4 
sudo make install 
cd .. 
cd RTIMULibDemoGL 
qmake 
make -j4 
sudo make install 
cd .. 
cd python 
python setup.py build 
sudo python setup.py install

[Sailoog]

Originally Posted by damianham

Hi guys

I am back from my travels for a short while and I want to pick up where I left off with sensor data display. I have implemented a sensor data display feature in my OceanIX android app but I see that the XDR codec changes (to handle sensor data from NMEA-0183 data stream) haven't yet been committed into the signalK repo.

There are dev 2 teams at work here - signalK and openplotter so it needs a bit of a co-ordinated effort.

Anyway from what I can see, Teppo Kurki's uncommitted fork at https://github.com/tkurki/signalk-pa...76d24ecd16c9fc

does not include code to handle the NMEA 0183 messages generated by OpenPLotter. I submitted an XDR codec implementation for signalK that would have handled the NMEA messages generated by OpenPlotter but this worked on the basis of generic pass through which the signalK team are not in favour of (although looking at the specification I think it was actually compliant).

So according to the signalK specification if we have a temperature sensor inside the engine room (not sure what happens in catamarans...)
openplotter needs to generate an NMEA sentence that can be translated by the signalK XDR codec to "environment.inside.engineRoom".

Currently there is nothing in the implementation of openplotter/1w.py to suggest that the location of the temperature sensor can be identified.

I could be mistaken but I think this means that OP will have to generate signalK format data and send it to the signalK server in order for this to work.

regards
damian

Welcome damian,

This is the situation now...
Signal K is about to release the first stable version 1.0.0 (few weeks). There is some work done in the Signal K implementation for OpenCPN too.

Non standard XDR functions was a provisional solution in OpenPlotter to manage data internally because by that time it was a NMEA 0183 based system. But now we are dealing with N2K and many sensors and we need to be able to show compatible data externally.

We are waiting for Signal K 1.0.0 and Kplex 1.3.3 to release OpenPlotter 0.8.0 stable. We need to do it ASAP because the unexpected Raspberry 3 unmounted our version system and there are lots of new features and fixes from our last stable version.

The day we release v0.8.0, we will start working on v0.9.0 (actually we have already started) and in the first place of the to do list, is the complete Signal K implementation. That means...

• Sensors and calculations that generate data which can be represented by standard NMEA 0183 sentences, will have the option of generating either NMEA 0183 or the corresponding Signal K path. (Heading, Magnetic variation, True heading, Rate of turn, True wind...)
• Sensors which don't have standard NMEA 0183 sentences, will generate only the corresponding Signal K path. (Weather sensors: Pressure, Temperature, Humidity...)
• Sensors which don't have standard NMEA 0183 sentences and could be multiple, user will chose the wanted Signal K sentence from a list when defining the sensor. (1W and the future SPI for analog sensors)

I think this is the logic step and it should work for your app and the others.

[damianham]

Originally Posted by Sailoog

Welcome damian,

This is the situation now...
Signal K is about to release the first stable version 1.0.0 (few weeks). There is some work done in the Signal K implementation for OpenCPN too.

Non standard XDR functions was a provisional solution in OpenPlotter to manage data internally because by that time it was a NMEA 0183 based system. But now we are dealing with N2K and many sensors and we need to be able to show compatible data externally.

We are waiting for Signal K 1.0.0 and Kplex 1.3.3 to release OpenPlotter 0.8.0 stable. We need to do it ASAP because the unexpected Raspberry 3 unmounted our version system and there are lots of new features and fixes from our last stable version.

The day we release v0.8.0, we will start working on v0.9.0 (actually we have already started) and in the first place of the to do list, is the complete Signal K implementation. That means...

• Sensors and calculations that generate data which can be represented by standard NMEA 0183 sentences, will have the option of generating either NMEA 0183 or the corresponding Signal K path. (Heading, Magnetic variation, True heading, Rate of turn, True wind...)
• Sensors which don't have standard NMEA 0183 sentences, will generate only the corresponding Signal K path. (Weather sensors: Pressure, Temperature, Humidity...)
• Sensors which don't have standard NMEA 0183 sentences and could be multiple, user will chose the wanted Signal K sentence from a list when defining the sensor. (1W and the future SPI for analog sensors)

I think this is the logic step and it should work for your app and the others.

That makes a lot of sense. If I can find some time and can setup a dev environment I will help out with a fork and some pull requests.

[Sailoog]

Originally Posted by damianham

That makes a lot of sense. If I can find some time and can setup a dev environment I will help out with a fork and some pull requests.

That sounds great. Before pushing code let me know to coordinate branches and people working on it.

[Nick_Currawong]

Hi Sailoog,

Thanks for the list of commands, I tried them but don't help.

I think the issue was it was picking up a different version somewhere, so I deleted everything starting with RT* & IMU* from under /usr and reran the steps again and it worked.

There seemed to different versions of Python which all had a copy.

In that process I did spot a typo in ../RTIMULib2/RTIMULib/RTIMUSettings.cpp
I had not changed the detected comment to the correct device (I.e. 9255 , if found).

I have updated my GitHub copy.

Onto making getting the output to/from my chart plotter.

Thanks again.

[Alekoy]

Some quick questions for other users.

I am about to install everything onboard my friends boat (Archambault A40RC).
So far I have tested with a MPU-6050 and some short wires.

My plan is to build a small box that I am going to mount to the roof, near the mast, the box will have the IMU, pressure/temp and humidity/temp sensors inside.

The questions;
-Have anyone had success with ~8 meters of cable for the i2c-bus, and what cable did you use?
-Does the type of IMU used make a big difference? should I buy a LSM9DS1 or keep using the MPU-6050?
-Does the placement of the IMU make a big difference?

[Didier B]

Originally Posted by Alekoy

My plan is to build a small box that I am going to mount to the roof, near the mast, the box will have the IMU, pressure/temp and humidity/temp sensors inside.

The questions;
-Have anyone had success with ~8 meters of cable for the i2c-bus, and what cable did you use?
-Does the type of IMU used make a big difference? should I buy a LSM9DS1 or keep using the MPU-6050?
- Does the placement of the IMU make a big difference?

- I connect I2C sensors through a telephone cable (2 pairs, 5m) without problem ;
- The IMU should be in a water proof enclosure, I think I'll seal mine into epoxy before final installing ;
- The atmospheric sensors need to be in a vented enclosure which will only protect them from mechanical hazards. (therefore : 2 enclosures !).

I will install the sensors below deck, in the the front part, at a ~4 m distance from the engine (using the 5 m telephone cable). This place is permanently vented by two dorade air vent. I cannot imagine to expose a pcb assembly to sea spray and/or marine corrosion.
I will keep on board in a water proof enclosure 4 or 5 spare parts of the atmo sensors...

I plan to use a 1W sensor for air temperature, if a precise reading of outside temperature is needed (no air cond. nor heating system in the boat, exept the engine and the crew )

Some pictures of the above on the V0.8.0 up and running, and further studies (SPI I/F

[Alekoy]

Originally Posted by Didier B

...

Thanks!

Good idea to make it waterproof with epoxy.