New Plugin NmeaConvertor

[bdbcat]

RD...


Got this sorted out. The NMEAConverter code did not know what to do with 3 digit input values, like might be seen in your SOG, or indeed in any circular angle variable (0-360).
Soon to be fixed by PR to Rick's production repo, should find its way into production catalog soon thereafter.


If you would like to pre-test by importing the Windows tarball, here it is:


https://dl.cloudsmith.io/public/open...48-MSVC.tar.gz


Dave

[RhythmDoctor]

Thanks, Dave. It works great with my cherry-picked (noise-free) data file which I posted here. With unfiltered NMEA streams (SOG>0) it's not as clear. It's too late here to dig into that, so that will have to wait until later after work tomorrow. I'll report back after I've had time to look into that. Also, I'm 800 miles away from my boat for the next 12 days, so it will be awhile before I can test with real-time data.

I also mentioned that the "calculate using degrees" feature did not work either. I haven't been able to test that yet - its it possible that your three-digit fix has eliminated that issue also? That would simplify my formula significantly.

[rgleason]

@bdbcat New version ready to merge

[RhythmDoctor]

Please don't merge it yet. There are still a couple of kinks in the calculation.

My first example with SOG=0 works OK, but there are problems when the boat is moving.

I've attached a file of the same wind data, but with SOG=001.0 kts instead of 000.0 kts. Note that this is not actual sailing data, and with a wind of only 4.5 kts I needed to make sure that there were no calculation errors caused by sailing on an impossible point of sail (such as SOG>TWS).

Note that when the boat is moving forward at a feasible speed, the TWA should always be higher than the AWA. The attached NMEA data displays reasonable values on most points of sail, but there is an issue when wind angle is around 90. I recognize that a value of exactly 90 degrees might give an infinite arctan operand, but it looks like for very large but non-infinite arctan operands (as generated with AWA of 85.5, 90.5, and 95.5) that the calculation is still breaking. Is there any way to allow arctan values to calculate properly up to operands of around 99999 (i.e., atan(99999))? That will help things for us lazy daysailors who like to set the boat on a broad reach and take a nap. lol (really, I am just kidding about this)

FYI, this is also speculative on my part, so it's possible that the cause of this discontinuity in the calculation is something else. But there does seem to be an issue.

Also, the "calculate using degrees" function still does not work. I tested it with this formula and got clearly incorrect results:

$XXVWT,90-atan(($??VWR3*cos($??VWR1)-$??RMC7)/($??VWR3*sin($??VWR1))),$??VWR2,sqrt(sqr(($??VWR3*sin($??VWR1)))+sqr(($??VWR3*cos($??VWR1)-$??RMC7))),$??VWR4,,,,

[rgleason]

It is merged. So try the new version.

[RhythmDoctor]

Originally Posted by rgleason

It is merged. So try the new version.

I updated to 1.3.5. Same problem - the calculation breaks down when wind angle is around 90 degrees. As SOG increases, the range of angles where the calculation breaks gets larger. Please have another look at this when you get a chance. I'll also continue trying to look at the various intermediate values to nail down exactly what's breaking down, but I won't get to it for a couple days.

[RhythmDoctor]

Below is an NMEA log from playing back the script that I posted before with SOG=001.0 kt. I highlighted some values in red. Note that True Wind Angle gradually goes up to 98.21 degrees, but then abruptly drops by 100 degrees to 03.00 (=103-100), and continues to increase to 11.44 (=111.44-100), then at larger angles starts to report correct values again starting with 116.93.

You can also see this graphically using the dashboard for true and apparent wind. There is still a calculation problem with wind angles around 90-100 degrees.

Is it possible that the calculation is being done correctly, but the output is truncated to xx.xx format? If so, the problem should be easily corrected by setting the format to xxx.xx. Note that the True Wind Speed does not show a similar discontinuity - it continues to be reported correctly, so this seems strong evidence that the bug is with the formatting of the outputted value of the true wind angle. But it does not explain why higher values like 116.93 are reported correctly.

Also, I re-verified that the "calculate using degrees" still does not function at all on v 1.3.5 (as with prior versions).

07:36:14 $GPVWR,171.50,R,4.50,N,,,,*5B<0x0D><0x0A>
07:36:14 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:14 $XXVWT,173.04,R,005.49,N,,,,*40<0x0D><0x0A>
07:36:15 $GPVWR,60.50,R,4.50,N,,,,*6A<0x0D><0x0A>
07:36:15 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:15 $XXVWT,72.75,R,04.10,N,,,,*4B<0x0D><0x0A>
07:36:15 $GPVWR,65.50,R,4.50,N,,,,*6F<0x0D><0x0A>
07:36:15 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:15 $XXVWT,78.06,R,04.19,N,,,,*4C<0x0D><0x0A>
07:36:16 $GPVWR,70.50,R,4.50,N,,,,*6B<0x0D><0x0A>
07:36:16 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:16 $XXVWT,83.25,R,04.27,N,,,,*44<0x0D><0x0A>
07:36:16 $GPVWR,75.50,R,4.50,N,,,,*6E<0x0D><0x0A>
07:36:16 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:16 $XXVWT,88.33,R,04.36,N,,,,*48<0x0D><0x0A>
07:36:17 $GPVWR,80.50,R,4.50,N,,,,*64<0x0D><0x0A>
07:36:17 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:17 $XXVWT,93.32,R,04.45,N,,,,*47<0x0D><0x0A>
07:36:17 $GPVWR,85.50,R,4.50,N,,,,*61<0x0D><0x0A>
07:36:17 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:17 $XXVWT,98.21,R,04.53,N,,,,*49<0x0D><0x0A>
07:36:18 $GPVWR,90.50,R,4.50,N,,,,*65<0x0D><0x0A>
07:36:18 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:18 $XXVWT,03.00,R,04.62,N,,,,*4A<0x0D><0x0A>
07:36:18 $GPVWR,95.50,R,4.50,N,,,,*60<0x0D><0x0A>
07:36:18 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:18 $XXVWT,07.72,R,04.70,N,,,,*48<0x0D><0x0A>
07:36:19 $GPVWR,99.50,R,4.50,N,,,,*6C<0x0D><0x0A>
07:36:19 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:19 $XXVWT,11.44,R,04.77,N,,,,*4D<0x0D><0x0A>
07:36:19 $GPVWR,105.50,R,4.50,N,,,,*58<0x0D><0x0A>
07:36:19 $GPRMC,213200,A,3907.1950,N,07615.2860,W,001.0,105 .5,060823,011.3,W,D*19<0x0D><0x0A>
07:36:19 $XXVWT,116.93,R,004.86,N,,,,*4F<0x0D><0x0A>
07:36:20 $GPVWR,110.00,R,4.50,N,,,,*59<0x0D><0x0A>

[RhythmDoctor]

I hate how Cruisersforum puts a 30 minute deadline on edits! (Not your fault, I realize.)

Regarding my statement "But it does not explain why higher values like 116.93 are reported correctly," I now have a hypothesis of what is going wrong.

Note that the incorrect values of TWA (true wind angle) only occur when AWA (apparent wind angle) has xx.xx format and TWA value should be xxx.xx. If both AWA and TWA are xx.xx, the result is correct, and if both are xxx.xx, the result is correct. The error only happens when AWA is xx.xx and TWA is xxx.xx:

AWA--------Output TWA--------Correct TWA
85.50----------98.21---------------98.21
90.50----------03.00--------------103.00
95.50----------07.72--------------107.72
99.50----------11.44--------------111.44
105.50--------116.93-------------116.93

I suspect the fix for this bug is to report all degree outputs in xxx.xx format, regardless of what the input format is.

Please have a look at this - I think you're really close to solving this problem.

[bdbcat]

RD...
No problem with atan() function.


The code logic to create the output string is a little, well, idiosyncratic. Without a full rewrite on this logic, I simply added some code to ensure that if an output value is >= 100.0, then it needs 3 digits. Duh...


You may try this import, to check the update in your use case before we publish.


https://dl.cloudsmith.io/public/open...48-MSVC.tar.gz


I did not investigate the "calc using degrees" option. The rad() function seems to do the job for your formula, as a reasonable workaround. You may like to post a detailed bug report on Rick's github repo of this plugin, concerning this issue.


Thanks
Dave

[RhythmDoctor]

Hi Dave,

I flew home unexpectedly for the weekend and just tested your latest tweak. It looks great. Thanks!

You are correct, I do not need to do my calculations in degrees, I was just pointing out that it the other fixes did not also fix that feature. You might consider disabling the check box until someone gets the motivation to fix this feature, but that's entirely your choice.

Thanks again. I hope to get out sailing this weekend before flying back to my job, so I really look forward to trying this out. I've been having problems with the calibration of my wind speed transducer, and doing a couple out-and-back sails with apparent wind at 90 degrees will help me to fix that calibration. If I do both directions with 90 degree apparent but don't end up in about the same place, then either wind or current changed or the tranducer needs adjusting. Afterwards I can use the VDR log to experiment with different calibration factors to try. That's one reason why getting this working on a broad reach was so important to me.

[bdbcat]

RD...


I spent some time looking into the apparent failure of the "Calculate using degrees" option.
Tentative conclusion: It works OK, at least for some trivial cases.
Consider this formula:

$XXVWT,$??VWR1-(10.0 * sin(45)),$??VWR2,20.0,$??VWR4,,,,

A pretty simple contrived formula, not useful for anything except testing. As you can see by the formula, the VWT direction should be a constant 7.07 degrees [10.0 * sin(45)] smaller than the VWR direction. And in tests with current Production plugin, it performs exactly as expected.


So, at this moment, I see nothing wrong with the plugin code.


You might like to try building up your formula with some simple expressions, feed it some constant VDR strings, and see what is going on here for your more useful formulae.


Thanks
Dave

[scud]

GM everyone. Today I updated to the new version of this plugin NMEA_converter and I get this message. Uninstalled and reinstalled. No way! Keep getting the same:


"The following libray has encountered errors during startup:
NmeaConverter_pi
The library will be removed. You might want to reinstall it's associated pluging after updating the catalog...."


What can I do to fix the problem? Finally I had found a way to display barometric pressure but now the formula is gone along with the plugin

[scud]

I was able to recover the formula from opencpn .ini file.
I also found the nmea_converter_pi.dll in C:\Program Files (x86)\OpenCPN\pluginsbut it is dated 2019.


OCPN is 5.8.4 and WIN10

[scud]

In the log file I find a strange message but in following startups the check of compatibility disappears


13:00:16.705 MESSAGE plugin_loader.cpp:336 Checking plugin compatibility: C:\Users\SCUD\AppData\Local\opencpn\plugins\nmeaco nverter_pi.dll
13:00:16.705 MESSAGE plugin_loader.cpp:336 Checking plugin compatibility: C:\Users\SCUD\AppData\Local\opencpn\plugins\nmeaco nverter_pi.dll
13:00:16.705 MESSAGE plugin_loader.cpp:1191 Plugin is compatible: true
13:00:16.705 MESSAGE plugin_loader.cpp:1206 PluginLoader: Loading PlugIn: C:\Users\SCUD\AppData\Local\opencpn\plugins\nmeaco nverter_pi.dll
13:00:16.705 MESSAGE plugin_loader.cpp:1206 PluginLoader: Loading PlugIn: C:\Users\SCUD\AppData\Local\opencpn\plugins\nmeaco nverter_pi.dll

[scud]

OK with beta catalog I was able to downgrade to 1.4.4.0 and I'm now back in biz