Twocan - a new Plugin

[rgleason]

Dear Steven,

Through my interest in the VSR Alternator Regulator and Backstage software, I found this on Rick's website. It might be useful software for CAN that runs on Windoz.

https://offgridsoftwaresolutions.com...an-log-viewer/


"CAN Log Viewer software is a free viewer, player, recorder and converter of CAN (Controller Area Network) logs. It can play your CAN recordings or display live data from our USB and Wi-Fi gateways on a PC screen in real time and highlight changing data."


His website has some good equipment for LiFePo

[LennartG]

Steven,
first sea trials today turned up some communication problems:

I am using a USB connected GPS (Globalsat BU-353-S4) connected to a dedicated input port plus an output port used to send 'GPRMC' (filtered in the port settings) to the VHF. I am also using the TwoCan interface to gather depth and teperature data from NMEA2000.

The GPS data gets totally 'screwed up' so the course is reported up to 180 degrees wrong even if the position seems correct.
Looking at the GPS data in the debug window shows that the GPS data itself is being affected, the erroneous data is really what the GPS is transmitting.
Disabling the TwoCan plugin returns the GPS transmitted information to normal with correct course, so the TwoCan interface must be transmitting something that messes up the GPS even if nothing is shown in the debug window. Note that this is an 'input port only'.

Also noted the VHF is receiving not only 'GPRMC' but also all virtual ports data from the TwoCan interface. They are simply not filtered by the port settings. Putting these two findings together makes me do these uneducated guesses:


a) Virtual port data is not filtered by the port settings, it is bypassing the port filters.
b) An 'input port only' is still transmitting available virtual output data thru the port even if not shown in the debug window.

As it is right now I am to use either GPS or echo sounder as they interfere with each other.
Assume this is perhaps not a TwoCan error but it is definitely related to the TwoCan interface.


System Ubuntu 16.04, OpenCPN 5.0, TwoCan 1.4.


/LennartG

[LennartG]

Steven,

continuing on #62 and further examining my logs reveals that my assumption 'b)' may be wrong, there could be another cause as my autopilot (Garmin GHC20) is receiving GPS and other data thru the serial port.

This GPS data then seems to be retransmited on the virtual port possibly causing a data conflict.

Is TwoCan outputting data not explicitly allowed allowed in the setting? Not being onboard I can not check right now but I will remember only allowing heading, depth and temperature to be transmitted. Still I can see e.g. 'IIRMC' and other gps data in the logs.
Where do these come from?


/LennartG

[stevead]

Hi Lennart,

TwoCan does not send RMC sentences. It only sends GLL and GGA in response to decoding PGN's 129025 and 129029 respectively.

Is TwoCan outputting data not explicitly allowed allowed in the setting?

It shouldn't, but I'll verify.

The only thing I can think of is if TwoCan is sending erroneous Heading (HDG) or Velocity and Track Made Good (VTG) sentences, which may be screwing up OpenCPN's calculations. If you disable these from the TwoCan settings, are the real GPS sentences correct ?

Can you see any differences between the OpenCPN NMEA Debug Window and the TwoCan Debug Window. Given you only have a depth, heading & temperature NMEA 2000 sensors, there should only be those sentences in the TwoCan debug Window.

a) Virtual port data is not filtered by the port settings, it is bypassing the port filters.

I think your observation is correct. I do not believe that that virtual port data is filtered. Others may correct me, however when I was thinking about bi-directional support, this was an issue I dwelt upon (how not to retransmit NMEA 2000 data that originated from the NMEA 2000 network as all plugins receive all OpenCPN sentences via the "WANTS_NMEA_SENTENCES" setting.

[stevead]

Further to my last post, I can verify that no RMC sentences are sent by TwoCan, and if there is a NMEA 2000 GNSS Position Sensor on the network, and if both the GGA & GLL conversions are disabled, no position data is sent by the plugin to OpenCPN.


I think the problem is either an erroneous HDG sentence sent by TwoCan (assuming there is a heading sensor connected to the NMEA 2000 network) or as has been suggested some kind of issue with virtual ports resending data over the serial ports.

[LennartG]

Steven,
thanks for the reply. I'll do some further testing tomorrow, even if I will not be able to leave the dock due to persistent engine problems.


Will try to generate various logs and attach them for further analysis. That the virtual ports are bypassing the filters seems however clear.

One of the more interesting questions is exactly which signals that are required by the autopilot. I assume that it does not require the GPS data, just the steering commands but that remains to bee seen at a later date (unless some can assist with that information)


/ Lennart

[LennartG]

Steven,
went to generate a massive amount of screen copies to analyze back home, really to dissect the signals and sources, and this is what I have:

- The GPS, there is only the USB puck BU-353-S4, transmitting 'GPRMC', 'GPGSA', 'GPGSV' and 'GPGGA'. This seems all normal.

- The autopilot, Garmin GHC20, has both a serial port plus the NMEA2000 port. I need to use both ports as TwoCan (not yet) supports sending signals to the NMEA2000 network. It is randomly, and not to frequent, transmitting 'HCHDM' on the serial port plus 127250 (HDG), very frequent, on NMEA2000. The values are equal and seems correct.

- The TwoCan has only '127250' (HDG), '128267' (DPT) and '130310' (MWT) tickboxes enabled, all the other tickboxes are empty (assume that the two latter are spelling errors, they should say 'DBT' respectively 'MTW').
The debug window displays 'IIHDG', 'IIDBT' and 'IIMTW' only. The HDG sentence however looks a bit odd, the deviation and variation values are really high, I have e.g. the line: '$IIHDG,190.75,187.74,E,187.74,E*73'.
There are no additional sentences in the debug window.

- Regarding the filtering of virtual signals it actually seems ok, now that I have the pictures and a better screen. The colors are a bit messed up at the 'boat screen'

I disabled the autopilot 'HCHDM' as I suspect it is both superflous and may cause conflicts. That and/or the odd 'IIHDG' could be the cause of my problems. Did not try it the other way around as I am at dockside and could not do a 'live test'.

One more note: Looking at the TwoCan 'Network' tab I can only see the autopilot but if I check thru Garmin I see 'Garmin', USBtin' and 'Airmar' (the echo sounder).

Hope I got it right this time

/Lennart

[stevead]

Hi Lennart,

Quite possible that the heading conversion is incorrect

$IIHDG,190.75,187.74,E,187.74,E*73

Would you be able to re-enable the heading on the serial port of your GHC 20 and capture the NMEA 183 sentence so that I could compare the two ?

The calculation performed in the plugin to me seems to be correct, (heading, deviation and variation are all 16bit numbers that are divided by 10000 and converted to degrees from radians. I have a sneaking suspicion that perhaps I may need to subtract the variation & deviation values from the magnetic heading value to generate the correct NMEA 183 HDG sentence. So if the heading is 190.75, then the deviation is 190.75 - 187.74 E resulting in a deviation of 3.01 E ? Does that seem right for your region/area?

Re the typos, quite likely! Although I think the depth mistake is because I originally converted to a DPT sentence (and worded the setting like that) only to later discover that the OpenCPN dashboard only accepted DBT sentences !

Re the Network tab. You need to wait at least two minutes for it to be populated. The NMEA 2000 Heartbeat is sent every 60 seconds, in the first instance if TwoCan has not seen an address claim from a device on the network it sends an address claim request, then the next time around, if devices have responded it sends a product information request. You should be able to see this in the opencpn.log

Thanks for your perseverance.

[LennartG]

Steven,
just trying to help as much as I can.

Please find the attached pictures:
a) The TwoCan debug window
b) The incoming 'HCHDM' (not 'HDG') signal from the serial port. That is the only signal from GHC 20 on the serial port. This picture also shows the 'IIHDG' from TwoCan.

- My knowledge about the calculations required is very limited (to say the least) so I have no idea how to do that, just note that the season sea trials have not yet been carried out so I can not say anything about the accuracy of the magnetic heading. The deviation in the boat location (or really 'Declination') is however about 6.5 degrees.

- Regarding the typos, just something I noted and 'had to' comment ;-)

- The network info was checked after a long coffe break so I'm sure that at least 15 minutes had passed, however this is just a note that I 'had to mention'. Have however not checked the opencpn.log. No big deal.


/Lennart

[stevead]

Hi Lennart,

Bug on my part.

Good news is that in your OpenCPN NMEA Debug Windows screenshot, both the IIHDG & HCHDM NMEA 183 sentences show the same magnetic heading value, so that conversion is OK.

I'm quite sure that the bug is that both the deviation and variation values (which TwoCan has converted to the same value; 187.74) should actually be NULL (meaning either not configured or not valid).

Some simple math, convert 187.64 to radians, multiply by 10000 results in 32767 which is the maximum value of a signed 16 bit value.

In many NMEA 2000 values, the maximum value of a field indicates an invalid or not present value Eg. for a 16bit unsigned or signed value 65535 or 32767 would represent an invalid value.

I'll try and get a fix pushed up to the git repository. A quick one line fix would be just to output a HDM sentence (no variation or deviation values) or a few more lines for a HDG sentence.

I really do need to revise the source code and ensure that there are checks for all of these instances of values not present.

Thanks and kind regards.

[rgleason]

Originally Posted by rgleason

Dear Steven,

Through my interest in the VSR Alternator Regulator and Backstage software, I found this on Rick's website. It might be useful software for CAN that runs on Windoz.

https://offgridsoftwaresolutions.com...an-log-viewer/


"CAN Log Viewer software is a free viewer, player, recorder and converter of CAN (Controller Area Network) logs. It can play your CAN recordings or display live data from our USB and Wi-Fi gateways on a PC screen in real time and highlight changing data."


His website has some good equipment for LiFePo

"CAN Log Viewer is designed to view and analyze live data from NMEA 2000 and J1939 networks, as well as log files recorded by our products and Raymarine chart plotters. This software can configure and update the firmware of our products not eqipped with a MicroSD card, and display historical data from sensors. Works on Microsoft Windows, Linux and Max OS X."


I did not realize that it works on Windows, Linux and OSX!

[rgleason]

Steven,

I got it to build by adjusting your twocan-test configuration which joins the PI and Drivers, such that the "Plugin" files were moved back up to the normal location, thus NSIS was able to then operate from normal directory and thus copy the "data" directories and files to be included in the package. Thank you for getting the ball rolling, and in particular, the additional CMake file that makes it all possible to include the drivers.

After combining the two CMakeLists.txt files all the drivers were building too.

Then there was one little piece that then had to be worked out, which was commands to copy each of the build drivers into a data/drivers folder which then gets included in the package by the final "cpack" command.. You can see the appveyor Console Tab here showing how it built

I think it works pretty well now. I've tried running the plugin, but don't have adequate tools to really test it yet. The appveyor "artifacts Tab" result is here

I first had this plugin building locally for ov42 through ov48 using wxWidgets 3.0.2 so it would be easy to have a version for earlier Opencpn.

I am going to make a PR to your Test repository, it is reasonably clean, but there are a number of changes. I don't think there is a need to consolidate the commits with a rebase.

I believe that this windows configuration can co-exist peacefully with .travis builds and will turn travis builds on on my repos to check.

Let me know what you think. I hope you are happy with it.

[rgleason]

I tried a travis file from petri that he has working well with secure auth. and linux trusty and osx.

I haven't done the authorization part but there are a few problems I think.
https://travis-ci.org/rgleason/twoca...jobs/549230035
https://travis-ci.org/rgleason/twoca...jobs/549230034


I haven't made a PR of this travis change.

[LennartG]

FWIW: Tried to compile TwoCan from within the OpenCPN plugins tree, just to see if it worked after the latest updates made. It did not, but gave this error:

/usr/local/src/OpenCPN/plugins/twocan_pi/src/twocanerror.cpp:27:25: fatal error: twocanerror.h: File or directory does not exist (freely translated!)
compilation terminated.

The file does exist as
/usr/local/src/OpenCPN/plugins/twocan_pi/inc/twocanerror.h

so it seems a path is wrong or missing. Note that the default plugins appears to have compiled just fine, at least no error messages.

Not being a programmer I stopped here, this was just to test as I assume you need compilations tested.

System: Ubuntu 16.04, OpenCPN 5.0, TwoCan just pulled from Github.


/LennartG

[rgleason]

Lennart, thanks. what repository & branch, just to be clear?

This is the experimental one that does compile for window, as standalone https://github.com/rgleason/twocan-test

I believe it should compile for Linux and Osx provided the Cmake files are ok. (and I don't believe the extra dll drivers needed for windows will interfere), but no one has tested, unless it was you.

The travis compiles fail, on this test version, because of src/ *.cpp errors in formatting it appears.
https://travis-ci.org/rgleason/twoca...m=notification

Originally Posted by LennartG

FWIW: Tried to compile TwoCan from within the OpenCPN plugins tree, just to see if it worked after the latest updates made. It did not, but gave this error:

/usr/local/src/OpenCPN/plugins/twocan_pi/src/twocanerror.cpp:27:25: fatal error: twocanerror.h: File or directory does not exist (freely translated!)
compilation terminated.

The file does exist as
/usr/local/src/OpenCPN/plugins/twocan_pi/inc/twocanerror.h




---I think I fixed this error already. you have to add .../inc/etc to the front of several includes in the cpp files. Do a search for the h file includes. Or Try the test version.


so it seems a path is wrong or missing. Note that the default plugins appears to have compiled just fine, at least no error messages.

Not being a programmer I stopped here, this was just to test as I assume you need compilations tested.

System: Ubuntu 16.04, OpenCPN 5.0, TwoCan just pulled from Github.


/LennartG