OpenCPN loses Position & Heading

[night0wl]

hi all,

just working to get my NMEA / AIS streams active in OpenCPN after a long absence from the boat. When I left, everthing seemed to work just fine. Now, however, I'm seeing really weird behavior. See attached screenshot



First of all, for whatever reason, OpenCPN seems to periodically lose heading and location. When I look at the NMEA log, I see that my NMEA0183 coming from my Raymarine Seatalk Interface box (4800 baud with a prolific pl2303 serial usb which is through a powered usb hub) gives this kind of screenshot. Note here, my instruments are being repeated through a Raspberry Pi & WiFi via Kplex. *ALSO* note that I periodically see these messages stating that a certain NMEA sentence is changing its datasource to the active connection.

Anyone else experienced this? This occurs regardless of whether the USB data sources are plugged directly into my macbook opencpn or if i'm connecting to a TCP data source.

Also, my boat is pointed due south (180). I see 180 mentioned in the NMEA debug log for heading data. Yet my ships icon is pointing due north (0 degrees/ 360 degrees). Any idea whats up there?

Lastly, I periodically completely lose the ship icon. It will appear many thousands of miles away. Really odd!

[bdbcat]

nightowl...

Use standard debugging practices.

In your case, simplify, simplify, simplify.

Break your config down to the bare minimum. Make this work. Add more stuff until it breaks.

I can see immediately in your log that there are some bogus characters in the IIGLL and IIRMC sentences, sometimes. This is probably your root problem.

Good Luck
Dave

[nohal]

nightOwl...
Could you record a bit of the NMEA stream and post here? There are a lot of very weird characters in it on your screenshot (compare the IIHDG sentences for example). The checksums also look suspicious (again look at the HDG sentences), but I'm a bit lazy to compute them from a bitmap.
I also see no serial data at all there, just TCP from 192.168.129.1 so it's virtually impossible to tell you what's up.

Pavel

[night0wl]

Originally Posted by nohal

nightOwl...
Could you record a bit of the NMEA stream and post here? There are a lot of very weird characters in it on your screenshot (compare the IIHDG sentences for example). The checksums also look suspicious (again look at the HDG sentences), but I'm a bit lazy to compute them from a bitmap.
I also see no serial data at all there, just TCP from 192.168.129.1 so it's virtually impossible to tell you what's up.

Pavel

Pavel - the data is coming entirely through my Raspberry Pi running kplex right now. That is why everything is coming over TCP. These errors occur regardless of whether I'm getting the data via TCP or when the USB (Serial to USB) is directly plugged into my macbook.

The AIS data is rock solid, so I'll "unplug" (by commenting out the AIS serial port in kplex conf).

(EDIT) Here is the Nmea stream recorded from the server side.
http://www.filedropper.com/nmeastream

I did notice that my console displays weird characters...however, when I open the file in a text editor, those weird characters arent there.

[nohal]

nightOwl...
Probably your text editor does not show the "undisplayable" chars - they are still there. At which point in the chain did you record the data? If not before kplex, the next step would obviously be to record the stream before it enters it.

Pavel

[night0wl]

Originally Posted by nohal

nightOwl...
Probably your text editor does not show the "undisplayable" chars - they are still there. At which point in the chain did you record the data? If not before kplex, the next step would obviously be to record the stream before it enters it.

Pavel

Here is what I did to record the nmea stream. First, I turned OFF the kplex service. Then I launched kplex via standalong command line, redirecting the output to a flat flie (nmeastream). I then did Cntrl+C after about a few minutes.



Then I scp the file from the raspberry pi to my macbook (had ssh on both ends).


How would i record the nmea stream before kplex? Also, as I've mentioned before, when I plug the USB directly to the macbook running OpenCPN, I still get these weird errors on the nmea debug window. Unfortunately, I do not know how to record the NMEA stream on my macbook since the plugin (VDR) does not have a mac version and I dont know how to make from source

[night0wl]

What would cause odd characters in the data stream?

[night0wl]

Originally Posted by night0wl

Here is what I did to record the nmea stream. First, I turned OFF the kplex service. Then I launched kplex via standalong command line, redirecting the output to a flat flie (nmeastream). I then did Cntrl+C after about a few minutes.



Then I scp the file from the raspberry pi to my macbook (had ssh on both ends).


How would i record the nmea stream before kplex? Also, as I've mentioned before, when I plug the USB directly to the macbook running OpenCPN, I still get these weird errors on the nmea debug window. Unfortunately, I do not know how to record the NMEA stream on my macbook since the plugin (VDR) does not have a mac version and I dont know how to make from source

Ok, i got ZTERM and did a capture with JUST the NMEA instruments. Interestingly enough, no issues at all. No collisions, no mess-ups.

Here is the capture

http://www.filedropper.com/test7-8-14

[night0wl]

EUREKA!

I figured out my problem. Turns out, the AIS bare wire to DB9 connections were *just* a bit loose. Apparently, this causes interference, resulting in screwing heading data coming from the the AIS connection (which is repeating since the ICOM MXA-5000 has a data in port coming from my Seatalk / NMEA interface output.

I didn't even need the NMEA data going to AIS. In any case, I've tightened all the cabling down and it seems to be working just fine now. This was an exercise in how to diagnose things...which I'm sure will be useful when I fully productionize this system.

[night0wl]

i stand corrected. got my new tablet, and this issue has returned. im stumped. Any advice????

[nohal]

nightOwl...
Same as before - make it as simple as possible, isolate the culprit and kill it.

Pavel

[night0wl]

Pavel -

I've been working to simplify things. So far, I've determined now that the AIS is rock solid. It works, the data stream is clean. its the NMEA0183 4800 baud instrument stream thats suspect. So I went about gathering nmea data captures at various points. Can someone help me decifer which of these looks "suspect"???


First log capture: This is a capture of the nmea stream using Zterm on mac when the laptop is directly connected to the NMEA out of the Raymarine Seatalk/NMEA box interface box to the RS232 OUT port
http://www.filedropper.com/01directusb_2

Second log capture: This is a capture of nmea stream from the raspberry pi using Minicom directly connected to the NMEA out of the Raymarine Seatalk/NMEA box interface box to the RS232 OUT port. http://www.filedropper.com/02raspiusbdirectwithminicom

Third log capture: This is a capture of the nmea stream from the raspberry pi, however the data is being sent through kplex. I've redirected the kplex output to a file to capture. http://www.filedropper.com/03raspius...redirecttofile

I'm so close to having this project complete successfully and move on to other cool efforts like adding engine senders/data to the nmea stream. *Appreciate all the help you can provide!*


*EDIT*...just realized all the captures off the Pi were from an UNPOWERED USB hub. I'm going to try the captures directly plugged into the Pi as well as into a powered usb hub.

[nohal]

nightOwl...
01 seems OK, both 02 and 03 are full of errors.

Pavel

[night0wl]

Originally Posted by nohal

nightOwl...
01 seems OK, both 02 and 03 are full of errors.

Pavel

Pavel,

Can you suggest additional tests?

As it stands, I'm thinking there could be 2 issues. First is some kind of driver issue with the PL2303 on Debian/Raspbian. The other is that its an issue with the Pi itself. Going to try and eliminate the usb hub from the equation too.

Anyone know if there is an updated or better driver for the PL2303 for linux?

[nohal]

nightOwl...
I don't think there are any other drivers for the Prolific adapter than the ones in the Linux kernel.
Of course try without the hub. Also try with different cable, if you have one. Preferably with FTDI chip which is generally better and not faked that often.
What I would do myself would be dumping the conversion to USB completely and using the UARTs on RPi (They are 3.3V TTL, of course you need something like MAX232 in front of them, or better a RS-422 equivalent if the Raimarine thing follows the NMEA specs)

Pavel