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.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Graphing with node red and signalK
#21
I didn't recall which version of the repository I used but I re-installed the stable ppa and still get the same error message (E: Unable to locate package opencpn-plugin-vdr). Do I need to downgrade OpenCPN (I am on 4.6.2) ?
I have upgraded to OpenPlotter 0.11.9 now.
Further testing has shown no crashing if I block the feed from the chart plotter and just have the feed from the GPS puck.
Reply
#22
I officially give up on trying to figure out what is going on. Did you do anything to the signalK server in the newest release?
I have currently disabled the feed from the GPS puck, enabled the feed from the chartplotter and it's been running for an hour without crashing. I will run it longer of course but unless I can somehow install VDR, the errors are so infrequent as to make it all but impossible to catch them without VDR (or attribute them to any particular software/hardware configuration).
There was the upgrade to OpenPlotter, there was one minor Ubuntu upgrade but of course I was messing around with the ppa and stuff so who knows what all has changed. I will set up a node red chart for depth under keel in addition to the wind chart and maybe that will stress things a bit more, who knows. I will post any significant news as they happen.
Reply
#23
VDR is installed on OpenPlotter. Enable it and try to record that killer plotter.
Reply
#24
Saillog:
I am finally able to supply the info you need. Today the configuration that ran fine yesterday for over an hour crashed almost immediately and repeatedly <shrug>
The following was captured on OpenCPN ver 4.6.1 running on the pi. OpenPlotter had the NMEA feed from the chart plotter enabled. When OpenPlotter started up, there was no action on the signalK diagnostic screen until I restarted the signalK server.

Here is the terminal window with all it's error messages:
pi@openplotter:~ $ openplotter
Connection is already closed.
Signal K starting
No settings/defaults.json available
[Errno 111] Connection refused
signalk-server running at 0.0.0.0:3000

Cannot open NGT-1-A device /dev/ttyOP_N2K

GET /signalk/v1/api/vessels/self 200 36.674 ms - 19
no unit for navigation.gnss.differentialReference
no unit for navigation.gnss.horizontalDilution
no unit for navigation.gnss.geoidalSeparation
no unit for navigation.gnss.satellites
no unit for navigation.gnss.quality
TypeError: Cannot read property 'toUpperCase' of undefined
at NMEA0183._decoder (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/codecs/GLL.js:52:15)
at NMEA0183.decode (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/NMEA0183.js:259:26)
at Parser._decode (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:128:44)
at /home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:172:26
at arrayEach (/home/pi/.config/signalk-server-node/node_modules/lodash/lodash.js:537:11)
at Function.forEach (/home/pi/.config/signalk-server-node/node_modules/lodash/lodash.js:9359:14)
at Parser._transform (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:169:7)
at Parser.Transform._read (_stream_transform.js:167:10)
at Parser.Transform._write (_stream_transform.js:155:12)
at doWrite (_stream_writable.js:334:12)
pi@openplotter:~ $

I will send the VDR file via email
Reply
#25
Is there any way that I can feed the VDR file to the signalK engine to maybe help locate the issue of the crashing ?

The only other way I could see helping would be by filtering out different NEMA sentences until the system doesn't seem to crash any more. WIth the issue being intermittent this would likely take some time but should be doable .....

BTW, the reason I could not run VDR on my computer is that it is not in the OpenCPN repository for Ubuntu 16.10 or 17.04
Reply
#26
You have sent me this by email:

$SDDBT,15.8,f,4.8,M,2.6,F*32
$VWMTW,40.0,C*16
$VWVHW,090.5,T,074.5,M,0.00,N,0.0,K*6E
$GPGGA,191311.74,4840.434

I was expecting a text file containing several lines and no this pasted text with just 4 lines. The last one ($GPGGA) is incomplete. Is this what you are getting or is this a copy paste issue? If this is what you are getting obviously is the source of the problem.
Reply
#27
That is a copy/paste issue, sorry about that! I will try again (via email)

Edit: I have sent the copy/pasted file again (via email) however on examination of the fragment that you previously received, I noticed that at the point it cuts off there is an unprintable character in the original file. Chances are that the second version I emailed will cut off at the same spot.
This brings up an interesting question - should there be non printable characters in a NMEA 0183 data stream ? The original file is peppered with them. They only show up in the data portion of the stream (ie every sentence has a properly formed '$xxxxx,' bit followed by the data). The non-printable character does not show up in a particular NMEA sentence of a particular sender. From the same sender, one string might be ok, the other has the non printable character in it.
It would seem to me that there is data corruption going on ......
I have another NMEA to USB converter that I can try out. Also, it could be that I did not correctly hook up the existing converter. I will investigate when I am on the boat next.

Thank you for your help !

Edit 2: The unprintable character seems to show up in place of an expected comma rather than any actual data so although it appears random as far as when it shows up, it only seems to replace the comma character. I only have the original file in ASCII and not hex so I don't know if it substitutes the same hex data all the time or what ..... weird !

Although I obviously need to get to the bottom of this corruption, I wonder if the signalK engine should not handle this error more gracefully during data validation ....
Reply
#28
I tested three different USB to RS422/485 converters, same model, same revision of pcb
One has no output, one has a fairly high rate of errors and one, the one I was using before , had only the occasional error.
I verified hookup and the only way I get the receive light flashing is with the current hookup ... so verified as correct.
When I looked at the VDR file of the best of these converters, I found that the only character, a comma, hex 2C, is converted to hex 0C. It just drops one bit. Dropping of the comma happens randomly, but no other characters seem to be affected (although this was only verified with a small sample of errors)
The independent GPS puck which, when enabled goes directly to USB without going thru a NMEA 0183 to USB converter, shows no errors.

Based on this, I suspect that either the converters I have are crap or that the NMEA 0183 signal is at a marginal voltage and the converter has issues with that.

In any case, signalK should validate any incoming sentence to make sure the characters in the string are between hex 20 and 7F and any string that contains other characters should be discarded.

I would be interested to hear if anyone else has run into the issue of errors from their NMEA 0183 converter and how this was resolved (keeping in mind that only signalK barfs at these errors and all other consumers of the NMEA data seem to automatically discard the bad data or at least don't crash)

The NMEA 0183 to USB converter is the one that is officially supported, green light flashes strong and clear on all units tested (even the one that gave no output)
Reply
#29
finally you have find out the source of the mysterious killer NMEA stream. I suspect your rs422 converters are not guilty but your plotter. Are you using the correct baud rate?

Anyway, the signal k plugin should not crash so easily with corrupted data. I will test your VDR file and report to signak k developers.
Reply
#30
It sounds like a typical hardware problem (noise, cable or ground problems).
Try to power the rpi with an 230V usb adapter or a powerbank. Connect only power and usb RS422 and try again.
Use wifi AP to access to your rpi. If it does work better try the adapter which didn't work.
Shut down everything on the 12 V side (also recharger) to reduce noise produced by other devices.
Some NMEA 0183 connections need resistors (ask google "Why and for what is 3 k ohm needed? NMEA").
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)