Twocan - a new Plugin

[Canne]

Rick, (quickly seeing) it looks that the problem is with the Cmake-files, it looks like to me that you have a syntax error in twocan-test

INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/Plugin/inc ${CMAKE_SOURCE_DIR}/{Plugin/src ${CMAKE_SOURCE_DIR}/Plugin/img)

Also, why "Plugin"? In failed travis-build we can observe:

-I/Users/travis/build/rgleason/twocan-test/include
-I/Users/travis/build/rgleason/twocan-test/src

(these are given by default) and your definitions, consequently:

-I/Users/travis/build/rgleason/twocan-test/Plugin/inc
-I/Users/travis/build/rgleason/twocan-test/{Plugin/src
-I/Users/travis/build/rgleason/twocan-test/Plugin/img

There is no such sub-directory as Plugin.

Now, for Linux build it would be sufficient to rename the inc-folder as include and it would work.

But for pro-forma, and for other platforms I would define:

INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/include)

This definition has double usage in Linux but it does not matter, it is cleaner. Since you do not have any include files in "src" nor in "img" why declare them as part of the include path?

- - - - -

Notepad++ is a good tool, too - thanks for the link, I did not know about its regular expression search feature.
Petri

[stevead]

Apologies for my tardy reply, sailing with v. limited internet access.

Perhaps poor wording on my part, the "test" repository was merely a proof of concept to "merge" the TwoCan plugin source with the Twocan Windows drivers source. If that was workable then as long as the packaging worked then it would make sense that there would be a singe repository to build both the Linux version and the Windows version (with the drivers).

My aim was to at least get cmake to compile the source (which on my box, it did). The travis and appveyor stuff is beyond my pay scale, so I'll leave that to the experts.

My concern was that if I can successfully use cmake to build both the Windows & Linux versions, then what has happened with travis/appveyor that it cannot successfully build ?

I still do have a concern which is if a new or updated TwoCan Windows driver is built, then the combined build & packaging will mean a Windows user will need to reinstall the plugin. Perhaps I'm making a mountain out of a molehill. My vision would be for the TwoCan Windows Driver install to either automagically detect what physical device the user has installed, or provide a check list box allowing them to select what driver to install, however my NSIS knowledge is sorely lacking.

Re the encoding stuff, there are two unrelated and separate issues. Of concern to me was noticing that on some of Rick's logs, one of the Windows drivers (kvaser) logged errors indicating that the function calls could not be invoked. I can't remember whether that kind of error was an encoding error, incorrect DllExport directive or something else.

The second encoding issue is that of the trademark symbol. OK, so it may not be best practice to include it in a comment, but for me on both Windows & Linux builds it hasn't created a problem before. Where the symbol is present in a string value (such as the plugin description), it is encoded. I thought (possibly mistakenly) that if the source code is saved as UTF-8 then all should be OK ?

Finally to address Canne's question

I was thinking how to speed things up (because I cannot have timestamps in any imaginable way, not on my boat) and I ended up to think NMEA 2000. I saw your ground breaking work to interface O with NMEA 2000 by NMEA 0183 conversion. But actually I want to get NMEA 2000 raw data from some key instruments, and get that at the highest possible data rate.

Hardly ground breaking, just innovating for OpenCPN what others have done for Canboat and OpenSkipper. I don't think there is any need to speed things up. From my observations NMEA 2000 devices typically transmit at rates from 1 - 10Hz, which, believe it or not, OpenCPN seems to handle. In fact you can configure a serial port as an output device and OpenCPN appears to transmit those converted NMEA183 sentences pretty much instantaneously. I guess the question really is "How do you plan on using/visualising the data?".

Note also that as other users have noted, the Canable cantact device works very well, especially using the Candlelight firmware under Linux.

[Canne]

Rick, I did actually a conversion of code constant strings like what I explained above. Before attacking massive edits of the code strings containing special characters you want to unicodify, please read carefully my comments on this commit : https://github.com/canne/dashboard_t...fec7c9e34acfc9

There is a problem I found with wxWidgets wxString class based objects : constant strings are fine, they are C++ code, no wxStrings. But one pass these strings to wxWindows derived objects, like as for the caption text. There, at the reception one needs to do (at least on Windows - the treatment is not same!) a dedicated conversion when assigning the unicode constant into the object's member variable. See the code, it is not a big deal but if you don't do it, your wide string unicode will remain normal character string and contents will not be interpreted correctly! Sigh...

With this, I suggest you to do first the comments only, that's easy. If there are special characters in the string constants, you may need to consider where they are consumed and make some modifications at the reception end as well.

Just wanted to warn you that you don't spend as much time as I did with this one.

You may want to read this: https://docs.wxwidgets.org/3.0/overview_unicode.html

You will understand why macro _T(), is actually totally obsolete since wxWidgets 3.0 onwards Unicode is the default operation mode:

#ifdef UNICODE
#   define wxT(x)  L##x
#else // !Unicode
#   define wxT(x)  x
#endif

But apart of consuming double the memory for nothing, most of the time, it is actually harmless, maybe a bit confusing.

Best regards,

Petri

[Canne]

Thanks, stevead,

for your explanation. I plan to make statistical calculations like spline functions and for that I need a time domain. Since there is none in OpenCPN (it is event driven), I was planning to jump in front of it and capture the data myself at the source. For statistical calculations it does not hurt to have more samples, either! It seems to be possible in ov50 to have timestamps at the reception. If that happens, I will remain behind the OpenCPN, no problem. If not, I ll try that Canable device and hack its driver to be there at the raw data arrival.

Best regards,

Petri

[stevead]

If you are going to do splines in real time then I guess the easiest thing to do is is prepend a NMEA 183 sentence with a V4 tag block, presumably the 'c' option (Unix time with millisecond resolution) as the 'r' option (relative time) is only one second resolution.

No idea what effect v4 tag blocks have on OpenCPN or whether they are passed through a serial port configured as an output device.

If not real time, then the candump utility on Linux will log the raw NMEA 2000 data with timestamps. Then just a matter of parsing the data.

[rgleason]

Boy a lot is going on in this thread.

Re: Canne's very helpful post #105
Thank you for finding those problems caused by my moving the plugin files out of the "plugin" directory and back up one level to where NSIS knows how to use them. I will dig into your details and fix this repository accordingly. I believe it will then work with both travis builds and appveyor.

Unfortunately I will always be learning, probably for the rest of my life, because I don't "know" very much... and I've probably forgotten much of what I once thought I knew! So please be patient with me, and if I get too arrogant, please let me know.


Re: Steven [stevead] Post #107 . Sorry if I was abrupt earlier. Your post shows that there is some hope, if it works acceptably. I note that if a driver changes why couldn't we add a minor version number and re-release the plugin? Or will there be too many changes to the drivers? I too am not facile with nsis but it is useful to know about this idea:

Stevenad wrote:

My vision would be for the TwoCan Windows Driver install to either automatically detect what physical device the user has installed, or provide a check list box allowing them to select what driver to install, however my NSIS knowledge is sorely lacking.

I suppose the driver files could be stored and accessed remotely via internet, as Pavel has done with Climatology's 7mb of 35 years of Noaa data, or they could actually be a part of the package as installed. Since these files are smaller files, I think the later is most appropriate because users don't always have internet!

As far as having automatic sensing and selectors for the driver, I believe that belongs in the program itself, doesn't it, under preferences? (I need to look at how this might happen, while using the plugin, and knowing more, I think....)

Steven I wouldn't underestimate the value of your contribution at all. Hope you've been enjoying the sailing.

Saw this comment by Steven "do splines in real time ...." followed by suggestions for timestamps.

How hard would it be to make O's version of nmea0183 able to make timestamps visible and invisible with some kind of a trigger?

1. The default would be invisible to maintain compatibility.

How hard would it be to make O's version of nmea0183 able to insert timestamps at various points?

1. When received.
2. Other times to be determined.

What source for the timestamp?

1. GPS?
2. Computer?

So now the real question, What are "splines"? I saw another post by a user who asked about Opencpn functionality who wanted to do routing "splines" for his autopilot. I sent that along to Sean for his digestion and possible improvement of pypilot, but heard nothing. Can anyone please explain this further? What is the advantage? What is it for? Is it associated with forecast weather?

[stevead]

Quick observation for Petri.

Added V4 Tags (time presented as milliseconds since 1/1/1970) into NMEA 183 sentences that were converted by the plugin from NMEA 2000 messages. (for simplicity sake I just prepended the tag to depth messages).

OpenCPN doesn't barf, but unfortunately for you, OpenCPN appears to strip the tags when resending the sentence to an output serial port.

Looks like you'll have to find another way to add a time dimension to your data.

[Canne]

Thanks, sad they are stripping it, since at the plugin it is parsed for a second time and I could have extracted it at that time. But if O adds the time in a structure and passes that along the message, that is OK as well. Let's wait for 5.1 to see how it is implemented or if implemented at all. Plan B can simply fork a thread which recover the key data with timestamp through some IPC over the OpenCPN process. I do not need NMEA for 5 or so key data, just data sets and time.

Let's see how it evolves. Thank you for having made this trial!


Petri

[rgleason]

Originally Posted by Canne

Rick, (quickly seeing) it looks that the problem is with the Cmake-files, it looks like to me that you have a syntax error in twocan-test

INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/Plugin/inc ${CMAKE_SOURCE_DIR}/{Plugin/src ${CMAKE_SOURCE_DIR}/Plugin/img)

Also, why "Plugin"? In failed travis-build we can observe:....

I've made some changes following Petri's suggestions and they are working now. Thank you!


Commit: Pi-join-changes has a green check https://github.com/rgleason/twocan-test/commits/master



Travis - both gcc C++ and C++ succeed building

https://travis-ci.org/rgleason/twoca...m=notification


Incidently homebrew has over 300 warnings like this

warning: ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings]
"h c #210101",

Appveyor also succeeds

https://ci.appveyor.com/project/rgle...uilds/25762642

[Canne]

Rick, glad that it worked! For "spline", see this:

https://en.m.wikipedia.org/wiki/Spline_(mathematics)

Think like wind vane measurements as an example on y-axis. Time on x. Fit best curve. Predict the next one, data, when it comes fit again and predict, ... and so on. Associate with other data. Possible only if all data share the same time domain.


I have sent you a private message for the QA site account.

Cheers,

Petri

[Douwe Fokkema]

For the prediction of (semi) linear data from a series of observations the Kalman filter is a very useful method. In radar_pi we use this for finding the trajectories of radar targets to lock them as ARPA targets. We also use it for predicting the GPS position of the radar at the time of observation of the target. Technical references and a coding example see https://github.com/opencpn-radar-pi/...src/Kalman.cpp


Douwe Fokkema

[rgleason]

Douwe, thank you for the valuable reference and suggestion.

[stevead]

Announcing Version 1.5.

Apologies in advance to Rick who is probably going to be apoplectic as this may ruin the work he's tried to do to improve building & packaging of the TwoCan plugin.

Three features in this version;

One major fix that I will call the "Lennart Fix". Probably the only other person that I know of who has used the TwoCan plugin discovered that his boat's heading was almost the reverse of its course over ground, which I gather didn't play very nicely with the autopilot....

Analysing the logs revealed the deviation was 187.74 degrees! Obviously incorrect! A bit of math revealed the cuplrit: (187.74 * Pi/180) * 10000 (its in tenths of thousanths of radians) = 32767 which matched the recorded raw data. Many of you will recognize that 32767 is the maximum value for a signed short! In all of the NMEA 2000 values, the maximum value (be it a signed or unsigned char, short, long, long long) means "Data Not Available", Similarly maximum value less 1 means "Data Out Of Range" and for some reason maximum value less 2 means "NMEA Reserved". So I've added data validation for almost all of the converted PGN's, so if a value is invalid the resulting NMEA 183 sentence will correctly reflect that.

So in this case instead of sending "$IIHDG,300.00,187.74,E,187.74,E", the plugin correctly sends "$IIHDG,300.0,,,,"

As some members of the forum were interested in receiving additional data for tactics such as heel angle, I've added conversion of Parameter Group Number 127257 (Attitude) into a NMEA 183 XDR sentence with heel, pitch and yaw values.

Unfortunately those users were also interested in a time domain, and my experiments with prepending a NMEA 183 v4 Tag with timestamp data revealed that OpenCPN strips these tags, so alas, those users will need to append their own time stamps. Perhaps a feature request for OpenCPN not to strip V4 Tags when resending to an output port.

Finally support for additional log formats. Users may log received NMEA 2000 frames in the Raw TwoCan, Canboat (Kees Verruijt ), Candump (Linux utility), Comma Separated Variable (CSV) and Yacht Devices formats. These additional formats have not been rigourously tested but the intent is to allow logs from the TwoCan plugin to be visualied with other tools.

My next focus, time permitting, will be on the Windows plugin drivers, namely to extend active mode support on at least the Canable Cantact device, either by rewriting to use overlapped serial I/O or to use the candlelight firmware and use native Windows USB I/O. I hope to add another CAN adapter, which has a most "unusual name" to the list of supported adapters.

The usual caveat emptor applies, and please report any bugs.

Currently sailing, so replies to any questions or bug reports may be slightly delayed.

[rgleason]

Originally Posted by stevead

Announcing Version 1.5.
Apologies in advance to Rick who is probably going to be apoplectic as this may ruin the work he's tried to do to improve building & packaging of the TwoCan plugin.

No problem Steve. My version does build cleanly for windows and linux, and there is no need for you to accept my PR. I know how to orchestrate the drivers and the plugin structure such that NSIS completes properly and can do it again if I have time.

[stevead]

Announcing support for an additional adapter.

This may sound very confusing and if one was a large multi-national organisation then no doubt trademark lawyers would become involved issuing cease & desist orders. But I digress....

I found another manufacturer of CAN bus adapters called Rusoku, who manufacture and sell the "Toucan Marine" adapter!

http://www.rusoku.com/products/toucan-marine

It is an inexpensive, nicely packaged device, robustly enclosed in a plastic case complete with USB cable and M-12 5 pin Micro-C connection making it easy to connect to existing NMEA 2000 networks.

For Windows users, I have added a new TwoCan Plugin driver on github under http://github.com/twocanplugin/twocanplugindrivers

After connecting the adapter, check the Windows Device Manager to ensure it has installed correctly. If not, the WinUSb .inf file can be found in the Toucan/drivers folder once you have downloaded the TwoCanPluginDrivers repository from github.

You will also need to copy the CAN Abstraction Layer (CANAL) Dynamic Link Library canal32.dll to your Windows System directory, or to any other directory that is included in your PATH environment variable.

For Linux users (including Raspberry Pi) it requires an installable kernel module to enable SocketCAN support. The Rusoku Toucan SocketCan source code and make file can be downloaded from https://github.com/rusoku

For Raspberry Pi users I found the following link very helpful: https://raspberrypi.stackexchange.co...mpiling-kernel

Once you have compiled the Toucan SocketCAN kernel module, it may be loaded using the insmod command and then use the standard SocketCAN commands. Eg.

sudo ip link set can0 type can bitrate 250000

sudo ip link set up can0

I guess I should add that other than having received a free sample, I have no commercial relationship with Rusoku and receive no financial incentives.