Beta Test / Technical

[transmitterdan]

Originally Posted by rgleason

TDan I don't get this. Where do you find this reference? Everything I see says Track made Good, degrees true, or COG. Maybe we are not talking about the same thing? See several posts here


I asked you here:

...and never got a response.


TDan wrote:
Earlier TDan wrote here:
Second post

TDan first statement:

I think Pavel would say no need to do anything
Best

Smile

For RMC there is nothing to do. It is correct as it is.

The RMB correction has already been merged into O master. I see no need to discuss or modify the FAQ any further.

[nohal]

Originally Posted by stevead

Porting TwoCan plugin to Linux to support SocketCAN interface.


wxWidgets version is 3.0.4


g++ version is (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516



Following error when compiling:



Some searches have suggested either missing #include <wx/glcanvas.h> which indeed is present in ospn_plugin.h or compiling against wxWidgets 3.1.x, however I recall when originally developing my Windows version being advised to compile against 3.0.x.


Thoughts ?

All the Linux official builds are done against wx 3.0.something as available in the distributions.
All the Windows and macOS builds for O5 beta are done against wx3.1.2 (Until O4.8.8 they were done against wx3.0)

Are you building against the wx libraries as provided by the distribution (In your case that should be libwxgtk3.0-*gtk3-0v5)? If not, did you compile them with OpenGL support?

Is https://github.com/TwoCanPlugIn/TwoCanPlugIn what you are building? Or did you fix the windows-only stuff already?

[stevead]

Hi Pavel,



Built wxWidgets 3.0.4 from source using --enable-unicode --with-opengl



Using my local clone of https://github.com/TwoCanPlugIn/TwoCanPlugIn



In process of separating Windows and Linux specific code with #idef __WINDOWS__ and #ifdef __LINUX__



and adding an additional class implementing Linux SocketCAN interfaces


other than adding

IF(UNIX)
LIST(APPEND SRC_TWOCAN src/twocansocket.cpp)
LIST(APPEND SRC_TWOCAN inc/twocansocket.h)
ENDIF(UNIX)

to the cmakelists.txt file, is there anything else I am missing ?



For Windows we need to copy the appropriate opencpn.lib to the build directory for the linker. What, if any, is the corresponding addition for linux/g++


Thanks.

[nohal]

Steve...

Originally Posted by stevead

Built wxWidgets 3.0.4 from source using --enable-unicode --with-opengl

Any real reason for doing that and not following the instructions from https://opencpn.org/wiki/dokuwiki/do...ompiling_linux ?

Using my local clone of https://github.com/TwoCanPlugIn/TwoCanPlugIn



In process of separating Windows and Linux specific code with #idef __WINDOWS__ and #ifdef __LINUX__



and adding an additional class implementing Linux SocketCAN interfaces


other than adding

to the cmakelists.txt file, is there anything else I am missing ?

First things that fail on macOS (after adding the missing buildosx subdir and getting rid of "#include <windows.h>")

/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:32:2: error: unknown type name 'LPVOID'
        LPVOID lpMsgBuf;
        ^
/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:41:4: error: use of undeclared identifier 'LPTSTR'
                (LPTSTR)&lpMsgBuf,
                 ^
/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:35:3: error: use of undeclared identifier 'FORMAT_MESSAGE_ALLOCATE_BUFFER'
                FORMAT_MESSAGE_ALLOCATE_BUFFER |
                ^
/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:36:3: error: use of undeclared identifier 'FORMAT_MESSAGE_FROM_SYSTEM'
                FORMAT_MESSAGE_FROM_SYSTEM |
                ^
/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:37:3: error: use of undeclared identifier 'FORMAT_MESSAGE_IGNORE_INSERTS'
                FORMAT_MESSAGE_IGNORE_INSERTS,
                ^
/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:40:14: error: use of undeclared identifier 'LANG_NEUTRAL'
                MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                           ^
/Users/nohal/Documents/source/OpenCPN/plugins/TwoCanPlugIn/src/twocanerror.cpp:40:28: error: use of undeclared identifier 'SUBLANG_DEFAULT'
                MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                                         ^

I did not continue any further for now.

For Windows we need to copy the appropriate opencpn.lib to the build directory for the linker. What, if any, is the corresponding addition for linux/g++

Nothing, the linkers on *nix do not need anything to link against shared libs

[stevead]

Any real reason for doing that and not following the instructions from https://opencpn.org/wiki/dokuwiki/do...ompiling_linux ?

I think my Raspbian distro had a more recent version of wxWidgets, 3.1.2 ?
Either that or I like making things difficult for myself!

First things that fail on macOS (after adding the missing buildosx subdir and getting rid of "#include <windows.h>")

Don’t worry about all that Windows gumpf, I’ve excised all that with #ifdef __WINDOWS__ stuff and replaced Windows specific functions with Linux equivalents, eg FormatMessage with strerror with corresponding #ifdef __LINUX__
Anyway, got through that, now a link error message about relocation and suggesting to recompile with -fPIC.
Will revisit this after the weekend and once some sailing has cleared my frazzled brain.

[transmitterdan]

Originally Posted by stevead

I think my Raspbian distro had a more recent version of wxWidgets, 3.1.2 ?

Either that or I like making things difficult for myself!



Don’t worry about all that Windows gumpf, I’ve excised all that with #ifdef __WINDOWS__ stuff and replaced Windows specific functions with Linux equivalents, eg FormatMessage with strerror with corresponding #ifdef __LINUX__

Anyway, got through that, now a link error message about relocation and suggesting to recompile with -fPIC.

Will revisit this after the weekend and once some sailing has cleared my frazzled brain.

I think almost any .so (shared object library) needs to be compiled for position independent code (-fPIC). If you use CMake tell it you are building a shared library. It should add the proper compiler flags itself.

[rgleason]

Thanks Tehani

Originally Posted by Tehani

:silbido:

I think your conclusions are correct.
RMC in a sentence created only by the GPS (Or position system) based on the data received only by the receiver. There is no waypoint or route information. COG and SOG should appear here.
RMB in a navigation sentence that combines GPS information with the coordinates of the Waypoint. The data it contains are the result of these calculations on the line that joins the position of the ship and the Waypoint. VMG is the right thing to do. VMG = SOG * cos (COG - BRG). It does not make sense to put the SOG in its place.

[rgleason]

Under Dashboard Recognized Nmea0183 List

I've added ZDA and AIVDO.
I'd like confirmation from someone that this is correct!

[Tehani]

Originally Posted by rgleason

Under Dashboard Recognized Nmea0183 List

I've added ZDA and AIVDO.
I'd like confirmation from someone that this is correct!

In ZDA, It can be clearer like this:
5 - Local zone description, 00 to + - 13 hours (- means East longitude)
6 - Local zone minutes description, 00 to +-59 (- means East longitude)

TTM and TLL are sent by the Radar (ARPA / MARPA), not by AIS

[Hakan]

Originally Posted by Tehani

TTM and TLL are sent by the Radar (ARPA / MARPA), not by AIS

Correct, but all code are in the AIS_Decoder and ARPA targets are handled in the same way as an AIS target so the position of the descriptions are in the right place.


Rick...
AIVDO wouldn't be listed as a Dashboard message.
Håkan

[Tehani]

Do you think it would be interesting to process the VDR (Set & Drift) sentence, or calculate its values to present them in the Dashboard?
I also think that this data can be used to correct the APB field 13 "Heading-to-steer to destination waypoint".
At the moment it seems to me that O always inserts the same value as the 12 Bearing field, "Present position to destination".

[Hakan]

Isn't there a plugin called tactics_pi handling things like that? I'm not a racer so I'm not aware of all its features.

https://opencpn.org/OpenCPN/plugins/tactics.html

[Tehani]

Well, if tactics has no influence on that RMB field, I think it's better to leave it empty.
I think it can interfere with HSC (commanded Heading steering), sent as response by AP.
I had to leave incomplete the translation to PGN 127237 for that reason.

[yachtvalhalla]

Originally Posted by rgleason

Under Dashboard Recognized Nmea0183 List

I've added ZDA and AIVDO.
I'd like confirmation from someone that this is correct!

It's hard to see but that should be A!VDO. (exclamation point instead of a capital 'I')

Terry

[nohal]

Originally Posted by yachtvalhalla

It's hard to see but that should be A!VDO. (exclamation point instead of a capital 'I')

Terry

Sure not.