OpenPlotter project

[Sailoog]

Originally Posted by bcn

Point 1: that's clear now, but needs to be reflected in the docs and perhaps in the menu itself

Point 2: sure, but should get the NMEA0183 data stream from the SK server, or not?

1. Yes, you are right, the docs are really obsolete now. v0.9.0 will be a major upgrade with the fully signal k implementation and all will change. I don't know if it is worth to waste time updating it.

2. It seems that the SK NMEA 0183 output is just a bypass from the NMEA 0183 input. There is not a SK to NMEA 0183 converter yet. I think teppo was working on it.

[Sailoog]

@sparticle, @affinite

glad to heard you are using OP for real navigation we don't consider OP a final product at all, but if you know what you are doing, why not?

I am really sorry because I can't read forums and work on it every day. The sailing season started here

There are more people working on the code now and v0.9.0 is progressing right. Final v1.0.0 is coming......

Thanks for your support!!!!

[bcn]

Originally Posted by Sailoog

2. It seems that the SK NMEA 0183 output is just a bypass from the NMEA 0183 input. There is not a SK to NMEA 0183 converter yet. I think teppo was working on it.

That's a pity. So we are on the same with CANBOAT on bare bones.

Or to implement the OCPN SK ServerClient plug-in. Which will deliver just NMEA0183 into/out off OCPN.
Running circles.

Or basically:
we have at this moment no different functionality using either the Antisense CAN-USB gateway or the OpenPlotter CAN-USB gateway and CANBOAT.

Hubert

[affinite]

Originally Posted by Sailoog

@sparticle, @affinite

glad to heard you are using OP for real navigation we don't consider OP a final product at all, but if you know what you are doing, why not?

I am really sorry because I can't read forums and work on it every day. The sailing season started here

There are more people working on the code now and v0.9.0 is progressing right. Final v1.0.0 is coming......

Thanks for your support!!!!

The v8 OP iahve running on the boat just works but I don't think I'm pushing it too hard.
I've resisted the temptation to update the on-boat computer whilst cruising so as to keep it stable.
Having said all that I do run a backup chartplotter in parallel with the OP computer and I have an spare OpenCPN laptop in the cupboard

[Sailoog]

Originally Posted by bcn

That's a pity. So we are on the same with CANBOAT on bare bones.

Or to implement the OCPN SK ServerClient plug-in. Which will deliver just NMEA0183 into/out off OCPN.
Running circles.

Or basically:
we have at this moment no different functionality using either the Antisense CAN-USB gateway or the OpenPlotter CAN-USB gateway and CANBOAT.

Hubert

Agree. I prefer the first option (OCPN SK plug-in) due to the NMEA 0183/2000 limitations. Do you know if any serious work is being done? I'm sure is a matter of time, we need a stable Signal k release ASAP.

[Sailoog]

Now OpenPlotter is included with NOOBS installer

NOOBS (New Out Of the Box Software) is an easy operating system installation manager for the Raspberry Pi. We have built a NOOBS version with OpenPlotter included:

Download OpenPlotter RPI v0.8.0 NOOBS | Sailoog

This release is the last OpenPlotter v0.8.0. No updates, just the new installer.

If no bugs are reported, this will be the standard OpenPlotter installation method. That means:

• Easier installation. Just copy NOOB files to the root directory of your SD and run it on the Raspberry.
• Multiple OS in the same SD card. You will be able to run OpenPlotter and Kodi (software media center) without switching cards.
• Recovery system. A copy of all your OSes will remain in the SD. You will be able to recover the original images in case of SD corruption or unstable system without removing the SD.

Keep working on v0.9.0

[Sailor_Hutch]

Am setting up with a lot of sensors (initially for raspberry) like MQ-2 (combustible gas), MQ-6 (LPG), MQ-7 (carbon monoxide), bilge water level, etc. How does OpenPlotter handle those? Some are analog, others are comparator logic 1/0, and still others use i2c or spi for communications.

[rgleason]

Re Seatalk1 from st60 tridata & wind + st4000 series wheelpilot TO /FROM nmea0183 another very good alternative is gadgetpoole.de Tiny Seatalk Link offered w galvanic isolation, usb or RS232 and does bidirectional and has programming to adjust operation and sentences. Very good manual too.

[Arne Henriksen]

Any of you looked into Pebble and getting NMEA data to such a device?
Just figured out the original Pebble is now available used, pretty cheap...

I found this:
Pebble smartwatch app for boats
Boat Remote

It's kind of discontinued but on GitHub.
Using KPLEX as data source, and written in Python I guess the server part could quite easily be integrated in an OpenPlotter setup?

[Tacmed]

Has anyone connected to the NMEA output on these?
I have been using openplotter for months and know my way arround the system well.
The guy on the yacht next door(we are liveaboards) and liked how i had my system outputting to my EDO intruments on my android tablets and phone.

I connected the official USB to RS422 device to his NMEA output at 4800 baud. All i got was the odd part sentances with no full strings. The LED flashes to indicate date is comming in.
I have tried the wire reverse, common ground...usual stuff to no avail.

Has anyone tried to connect to one of these?

They seem to be common units. All instruments connect in, one seatalk output for displays, a NMEA in for GPS and an NMEA output D+ and D- type NMEA.
The autohelm documentation says 4800 baud and a list of sentances it will spit out.

I couldnt remember the linux terminal command to show raw data on the linux terminal.

I did check the kplex config file and all seemed okay.

Cheers.

[Arne Henriksen]

Originally Posted by Tacmed

...
I couldnt remember the linux terminal command to show raw data on the linux terminal.

cat /dev/<port>

should show you the raw data input, if I remember correctly..

[Tacmed]

Originally Posted by Arne Henriksen

cat /dev/<port>

should show you the raw data input, if I remember correctly..

Thank you . Looks like i am missing some of each message. I will make an opto isolator reciever and this should help match the data hardware platform.

[muttnik]

Originally Posted by Arne Henriksen

cat /dev/<port>

should show you the raw data input, if I remember correctly..

There's other ways to do it but my preferred is:

(sttty <baud>; cat ) < /dev/<port>
e.g.:
(stty 4800; cat) < /dev/ttyUSB0

By default linux serial ports are set to 9600 baud (8 bit / no parity). On linux you can do "stty -F /dev/<port> 4800" then cat but that won't necessarily work on some other unix-like OSes like OS X where an stty only has effect for as long as the device it operates on is open. The trick above holds open the port as standard input to a subshell where the stty and the cat are run.

Note that while 9600 is the linux default baud, kplex will set a serial port to 4800 (the NMEA-0183 standard) unless you tell it otherwise. kplex will also reset the serial port to whatever it was before kplex started when it shuts down.

[Tacmed]

Thanks guys. Looks like the data that comes out of the autohelm nmea output is missing checksums. Explains why kplex is ignoring the data stream.

[muttnik]

Originally Posted by Tacmed

Thanks guys. Looks like the data that comes out of the autohelm nmea output is missing checksums. Explains why kplex is ignoring the data stream.

Hmm...kplex shouldn't ignore sentences with missing checksums unless you have "checksum=yes" in the config. However if it doesn't have checksums it *might* not be terminating lines correctly which might not be obvious from terminal output. Have a go at sticking "strict=no" into the config file for that input interface: that will accept sentences terminated with any of <CR>, <LF> or <NULL> rather than "correct" <CR><LF> terminated sentences.