New Plugin NmeaConvertor

[LennartG]

Downloaded and compiled 'git://github.com/RooieDirk/NmeaConverter_pi.git' on a test setup, then installed the .deb-file.

When toolbox is opened after program start I receive this message, freely translated from Swedish and as I remember it:

'nmeaconverter_pi.so is not compatible with this version of OpenCPN, please use an updated version'

Still on Ubuntu 16.04 and OpenCPN 4.8.4.

Also tried by installing Ubuntu 18.4 Bionic. OpenCPN installed and the distributed deb-file for nmeaconverter worked ok but OpenCPN are lacking some plugins I need (logbookkonni and statusbar) so I can not upgrade my live system.

Still banging my head. Please!

[transmitterdan]

It could be a number of reasons. It’s possible you built the plugin with a different version of some library and that is why the shared object file will not load. Or it could be the version of the plugin header file.

Have a look in opencpn.log to see if any helpful message appears. In opencpn you can find the log file location under options help.

[LennartG]

Thanks for the reply, I was thinking along the same lines and unfortunately the log file contains no useful messages. Have no clue on the OS for the NmeaConverter deb files on https://github.com/RooieDirk/NmeaConverter_pi/releases

So I started a virtual machine with Ubuntu 18.04.01 Bionic and dowloaded OpenCPN, logbookkonni, statusbar and NmeaConverter from git, this to at least have the same OS when compiling.
I then followed the procedures described at 'https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:developer_manual:developer_gui de:compiling_linux'.

OpenCPN (v. 4.99) and NmeaConverter seems to compile/work OK but:

LogbookKonni gave me:
CMake Error at CMakeLists.txt:48 (INCLUDE):
INCLUDE called with wrong number of arguments. include() only takes one
file.

statusbar gave me, during make:
fatal error: linmath.h: File or directory does not exist
#include "linmath.h"

There seems to be no way the get this working on Ubuntu 18.04 nor can I get the NmeaConverter to work under Ubuntu 16.04

What's next?

[transmitterdan]

I always build plugins on the same system where OpenCPN runs. It’s too cumbersome for me to build plugins on a different OS version.

If you can build on the same computer that runs O just run command from the plugin build folder:

sudo make install

It will install and you won’t need a .deb file.

[LennartG]

Dan, appreciate your comment and I have also tried to compile from source under Ubuntu 16.04. Using the 'real machine' is not doable as it not available right now, hence the virtual machine with the same O/S as on the boat..

The object is 'NmeaConverter' and the result varies depending on method.

Using the method described by RooieDirk:

cmake ..
cmake --build .

gives the result:
CMakeFiles/nmeaconverter_pi.dir/build.make:62: recipe for target ”CMakeFiles/nmeaconverter_pi.dir/src/NmeaConverter_pi.cpp.o” failed

Nothing more happened here whatever I did.

Using the 'standard' compiling commands makes it slightly different:

cmake ../
make

gave the same error as above but, running 'make' a second time passed without errors and generated an 'libnmeaconverter_pi.so' file in the build directory.

The command 'sudo make install' installed the file to '/usr/local/lib/opencpn' while it should go to '/usr/lib/opencpn' (no '/local/'). Just moving the file to '/usr/lib/opencpn' actually worked.

So things seems ok under 16.04, the same version as live on the boat.

Problem solved (?), at least for Ubuntu 16.04. The problems with 18.4 (see #213) remains but I will likely not upgrade unless I have to.

[LennartG]

Played around with NmeaConverter 1.0 self-compiled on Ubuntu 18.4 and OpenCPN 4.8.6 to emulate Echo Sounder Airmar DT800 and found a few oddities. In all of the cases I generated strings to be sent every second thru the PreferenceDlg:

1. If you are using the keyboard to input an NMEA 0183 texstring, e.g. '$DDPT,1.8,0.6', then it fails once you pass the period in '0.6', when OpenCPN hangs.
Also the string '$YXMTW,23.5,C' hangs OpenCPN once you pass the period sign if typed from the keyboard.
Funny thing is that Copy/Paste works just fine on both cases.

2. Adding the string '$SDDBT,,f,1.8,M,,F' works sometimes, but not always, if pasted. If it works, then it is also displayed in the debug window (as NmeaConverter also adds the checksum) but does not, at any time, display any depth values.
Same thing if you omit the transducer correction in '$DDPT,1.8,0.6', using e.g. '$DDPT,1.8,'. It fails in OpenCPN while '$DDPT,1.8,0.0' works just fine. The trailing comma seems to be handled correctly by NmeaConverter, present or not.

So it appears that two adjacent commas are not allowed in OpenCPN or is NmeaConverter fooling the system?

The first problem seems to be isolated to NmeaConverter but I am not sure about number two. That ome might be two separate problems though.

[Hexalent]

I used to use this plugin in previous versions, and I like it.
However, now I don't get it to work.

I am on an RPI (open plotter) and installed the plugin via the nmeaconverter_pi_1.0-1_armhf.deb package.

I am on OpenCPN 4.8.6
The plugin is installed but when I browse to the plugin section in OpenCPN, the program crashes immediately.

The log just says this:
19:17:09 UTC: PlugInManager: Loading PlugIn: /usr/lib/opencpn/libnmeaconverter_pi.so
19:17:09 UTC: /usr/lib/opencpn/libnmeaconverter_pi.so
API Version detected: 108
PlugIn Version detected: 100

[fooelisa]

I have the same problem as Hexalent on a RasPI (NOT open plotter) with nmeaconverter_pi_1.0-1_armhf.deb from the github release, on OpenCPN 4.8.6 Build 2018-08-02. Everything seems to install just fine, but when I browse to the plugin section in the OPenCPN settings, it crashes.

Cheers
Elisa

[rgleason]

Ratsea has added another example to correct his ST60 Wind, converting units.
https://opencpn.org/wiki/dokuwiki/do...ind_speed_data

[transmitterdan]

I have been thinking about adding some functionality to this plugin. There are a couple of things that make it hard to translate some NMEA messages. One problem we have seen is that some NMEA messages do not include the complete angle in the value field. Some wind speed messages send the angle and then a character to indicate positive (starboard) or negative (port) angle. It would be nice to have a way to extract the sign of the angle from the character field.

So I have dabbled around with the idea of adding constants to the plugin. If we assign a value to a named constant then anywhere the named constant appears in a formula will be replaced with the constant numeric value. So by assigning the constant -1 to variable "L" and 1 to variable "R" it is possible to use any fields that contain those letters to get a number that can be used in a formula to give the angle its proper sign.

Another issue that arises is most instruments don't handle negative angles so I added a function called drg() to the math engine. This function works exactly like deg() except that it always bounds the result to positive range 0-360. I always do trig functions in radians so this is a simple conversion from radians to degrees where the result will always be in the range of 0-360.

Here is an example of the opencpn.ini section that adds constant variables to the plugin:

[PlugIns/NmeaConverter]
DoUseCheckSums=1
ObjectCount=0
ConstantCount=2
[PlugIns/NmeaConverter/Constant1]
ConstantName=l
ConstantVal=-1
[PlugIns/NmeaConverter/Constant2]
ConstantName=r
ConstantVal=1

There are no conversion formulas yet in this ini example. When formulas are present ObjectCount will be nonzero and the formula strings will appear in the .ini file.

Now when you use the constant "l" or "L" in a function it will be replaced with the number -1. A simple function that does nothing is int(). So if you have a NMEA sentence with letters L or R in a position (e.g. VWR item 2) you can use int($??VWR2) and the letter L or R will be replaced with -1 or 1.

I have not added code to allow creating constants using the GUI so for now I just edit the opencpn.ini file to create constants.

Is this something that seems useful to the NMEA converter user base? Looking for comments/suggestions.

If you want to build a version that has this feature see:

https://github.com/transmitterdan/Nm...e/UseConstants

[rooiedirk]

Ha nice somebody else is working on the code.

I had to block the build in constant 'e'=2.78...., as that would be inserted as 'E' from east was mend. Same problem will arise for "bpfmnsew" and likely a few others, Therefore maybe make it compulsory to use at least 2 letters for a constant?


Oh and then also pls. a function for relative degrees, so -180 till +180. drgr()?
Dirk

[transmitterdan]

It’s not obvious how we can enforce the number of characters in NMEA text fields. The instruments produce these characters not OpenCPN.
A possible design change might help. For a field that was not converted from $ leading variable names don’t evaluate it with the calc engine. That way text only fields would never conflict with function names because the calc engine would not see them. Or do a little sanity check on each field and if it is pure non-numeric text with no () characters don’t invoke the calc engine on that field.
Maybe we need to implement the function atan2(). The formula atan2(sin(theta),cos(theta)) will always produce the correct signed angle between -Pi to +Pi.
The issue I have seen is that marine instruments seem to not like negative angles so there is a need for a function to produce a correct but always positive angle.
I guess we could have constants that are only applicable to a particular formula. That way we don’t introduce global constants that might have future conflicts. For now I think L and R are safe to replace with -1 and +1 respectively.

[Baikal]

Can you please tell me how to convert pressure readings from the Airmar WX200 weather station into millimeters of mercury?

[LennartG]

Feeling stupid adding a conversion into NmeaConverter
I am trying to convert 'ECHDG' from the autopilot (no 'xxHDG' available) to magnetic heading used by the Dashboard plugin and this simple conversion crashes OpenCPN: '$XXHDM,$ECHDG1,M'

What am I doing wrong?
/LennartG

[rooiedirk]

..HDM and ..HDG do not have the same data.
HDG - Heading - Deviation & Variation

1 2 3 4 5 6 | | | | | | $--HDG,x.x,x.x,a,x.x,a*hh<CR><LF>

Field Number:

1. Magnetic Sensor heading in degrees
2. Magnetic Deviation, degrees
3. Magnetic Deviation direction, E = Easterly, W = Westerly
4. Magnetic Variation degrees
5. Magnetic Variation direction, E = Easterly, W = Westerly
6. Checksum

So you will need something like $XXHDM,$ECHDG1,0.0,E,0.0,E


Dirk