Posts: 97
Threads: 21
Joined: May 2017
Reputation:
0
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.
Posts: 97
Threads: 21
Joined: May 2017
Reputation:
0
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 !
Posts: 97
Threads: 21
Joined: May 2017
Reputation:
0
2017-06-29, 02:49 PM
(This post was last modified: 2017-06-29, 02:53 PM by JD1.)
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!
Posts: 3,074
Threads: 64
Joined: Mar 2016
Reputation:
296
Could you explain how have you connected the converter to that pseudo NMEA 2 talker finally? it could be useful for others.
Posts: 97
Threads: 21
Joined: May 2017
Reputation:
0
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 ....