This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Graphing with node red and signalK
#31
Just to close this thread out for anyone interested ....
I traced the errand characters to definitively come from the NMEA 0183 bus. Several NMEA0183 to USB converters were tested. Two turned out to be defective but two others worked fine and had occasional corrupted characters. The corruption was also present on a different computer and also present with the NMEA line terminated with a 150 ohm resistor. I am unable to trace the issue further and to the source as I do not have anything to check out the Seatalk bus. The characters could be generated by one of three instruments on the Seatalk bus feeding the chartplotter or the chartplotter (Raymarine E80) could be generating them.
As mentioned before, the corrupted characters were not allowed under NMEA 0183 specs and they should not be able to crash the signalK server. Sailoog will address the issue with the signalK developer and I hope that data validation on the input to signalK can eliminate the crashing in the future.
  Reply
#32
So I have one more update .... It turns out that my AIS receiver is a version '1' NMEA0183 talker and this caused the corruption of the NMEA0183 data. It would appear that none of the listeners in my system are opto isolated on their input (not even the Raymarine chart plotter ?!) and it would appear that this causes all kinds of intermittent grief. I managed to reduce the interference but was unable to remove it completely.
Let it be known that having version '1' NMEA0183 equipment mixed with version '2/3' NMEA0183 equipment without isolation/buffer in between is major bad juju !
  Reply
#33
The last and final update:
I feel stupid for taking this long to discover the issue but it required an oscilloscope to finally eliminate all errors.
As mentioned before, the AIS unit was a version 1 NMEA talker. This was easy to determine because it has a TX line and a ground line as the output. My Raymarine plotter uses Nmea version 2/3/4 nomenclature with a TX+, TX-, RX+ and RX- lines. Unfortunately, behind the curtain is a version 1 talker/listener. When hooked up to the RS422 to USB converter in the expected manner, the signal was just barely decoded by the converter. Actually some converters didn't decode it at all and some converted it mostly ... but with an error here and there. Errors might show up almost immediately or not at all over a 24 hr test run. Even temperature seemed to influence the error rate.
Once I realized I was dealing with the old NMEA protocol and hooked it up correctly to the converter, it seemed very solid over a 24 hr run with no errors.
Due to the intermittent nature of the errors, I can't be 100% certain that everything is working properly but I am 99.99% sure that all is ok!
  Reply
#34
Congratulations and thanks for investigating the case to the end. How have you hooked it up correctly to the converter?

I have good news for you.

Even if those signal k crashes are due to electrical/connection/format issues, a crash it have never to happen. I have reported the case to signal k developers and they identified and fixed the bug. It will be added into the next openplotter major update. If you do not want to wait you should do:

Delete folder: /home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk
Open terminal and type:

Code:
cd /home/pi/.config/signalk-server-node/node_modules
git clone https://github.com/SignalK/signalk-parser-nmea0183.git nmea0183-signalk
cd nmea0183-signalk
npm install

and reset

Thanks for reporting
  Reply
#35
(07-07-2017, 12:45 PM)Sailoog Wrote: Congratulations and thanks for investigating the case to the end. How have you hooked it up correctly to the converter?

I have good news for you.

Even if those signal k crashes are due to electrical/connection/format issues, a crash it have never to happen. I have reported the case to signal k developers and they identified and fixed the bug. It will be added into the next openplotter major update. If you do not want to wait you should do:

Delete folder: /home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk
Open terminal and type:

Code:
cd /home/pi/.config/signalk-server-node/node_modules
git clone https://github.com/SignalK/signalk-parser-nmea0183.git nmea0183-signalk
cd nmea0183-signalk
npm install

and reset

Thanks for reporting

WoooHoooo !!!  Thanks very much for sorting this out!
Yes, I have (finally) managed to hook everything up right (how long does it take to hook up two wires, jeesh) and have not had a crash since. I do still have the rare occasion here and there where some corruption occurs but as I said, it hasn't crashed signalK. I think in my last test there were 4 errors that I saw over 3 days so not bad at all.
Thanks again !
  Reply
#36
Could you explain how have you connected the converter to that pseudo NMEA 2 talker finally? it could be useful for others.
  Reply
#37
The TX+ line goes to RX+ on the converter, the TX- goes to ground on the converter. Since the talker's output on TX- is grounded, it has to be to ground on the converter with the converter's RX- left floating.
In my case, the talker is a Raymarine E80 chart plotter, which seems quite popular. It uses RX+/RX-/TX+/TX- nomenclature but should use data/ground nomenclature instead. The E80 NMEA0183 end is optically isolated but the inexpensive converter from China to go to USB is not optically isolated. The RX- and TX- lines from the E80 need to go to the ground pin on the converter.

For those that are curious for the technical reasons, the converter input chips sense the differential between RX+ and RX-. Since RX- leads to ground on the E80, it effectively is grounded. The RX+ line of the converter then moves between zero volts and some positive voltage (around 8V in my case). The receiver chip can sense the differential between zero and 8V but can not properly decode the second state where both lines are zero. If the RX- end is left floating, it moves to +5V so the input chip sees 8V-5V or 3V in one state and 0V-5V or -5V in the second state.

I hope that makes sense ....
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)