New Plugin NmeaConvertor

[Hakan]

JF..
The math questions I can't resolve.
I may be curious why you want to "invent the wheel" since the function is already present in Dashboard.
0-360° sounds like you want the true wind direction, relative to north, and not true wind angle, relative to the bow? That's is two different instruments in Dashboard. To calculated the direction you need true heading to be present though.

[Aqua_vitae]

Hakan,

I have just made a new test : without any true wind formula in nmea converter, displaying true wind data in dashboard with forcing AWA to 0 leads to OCPN crash. It could be AWS, with the same result.
I force the AWA to 0 by disconnecting my anemometer and setting up a new line in nmea converter : $WIMWV, 0, R, 10, N, A.
Let me know what do you think of this issue.

Regards, JF.
The divided by 0 is also not handled in dashboard.

[Aqua_vitae]

It is not a question of re-inventing the wheel. This is just because the MWV nmea sentence operates with a 0-360° scope in opposite of WWR of your plugin manual example which operates with a 0-180° scope and L(eft) or R(ight) additionnal field.

[Aqua_vitae]

Of course, most of the time, the anemometer sends not null values for AWS and AWA. But what will happen if one day either AWS or AWA is equal to 0 ?
Regarding of the test I made with forcing AWA to 0, I think OCPN could crashs as I experiment today.

I am currious to know what do the development team think about that.
Of course, this is not a great issue but I would be happy to have contributed to discover it if it is revealed to be an actual issue.

Best regards, JF.

[Hakan]

JF
In Dashboard code I can't see how a AWA=0 can be a trouble? That value is not used as a divisor what I can see. The crash may come from your code in NMEA Converter?

[Aqua_vitae]

Please Hakan,
Have a look at atan2 function : it is said that the 2nd argument should not be null. And what is the second argument .... a kind of sinus AWA ....
Best regards, JF

[Aqua_vitae]

In fact, either using dashboard internal calculation or user's formula in nmea converter, the special case of AWA=0 or AWS=0 should be handled to get TWA. This is just a mathematical reason due to atan fonction. If not handled, an exception rise. And my first question was : how to handle this case in nmea converter, nothing more.
Regards, JF.

[Hakan]

JF..
Thanks for the atan2 clarification. In real the value could theoretically be 0.0 although obviously not likely. But still it would be worth a safe implementation to Dashboard.

[Aqua_vitae]

Hakan,
Thanks for your reply.
In C code, the atan2 function has two arguments and the inside code can manage if one is null and can return an available result.
In nmea converter, the atan function has only one argument. This suppose that the division Y/X (also done In atan2) is calculated before the atan call. That is why an exception is rised if X is null.
A better appraoch In nmea converter should be passing two arguments, one for Y, one for X and managing In the inside code the null.
Best regards, JF.

[Aqua_vitae]

By the way, I would like to suggest you an additionnal option in nmea converter.
When you submit a new formula to calculation, you have two trigger options : every X seconds or when ALL inside datas have changed. I would be happy to find another trigger option : when ONE of the inside data has changed.
For me, it makes more sens than waiting all datas are updated.
(Sorry if my english is not academic enough ...).
Best regards, JF.

[sv.KUJIRA.ch]

Originally Posted by bdbcat

Scud...
NmeaConverter v1.4.13 is now available in master catalog.
Thanks for the input
Dave

with v1.4.15 i have trouble with field length before decimal point if separated with "," not so if separated with ";"
orig: $PPGLL,4706.1420,N,00838.4390,E,141015,A
result with",": $ECGLL,$PPGLL1,$PPGLL2,$PPGL3, ...
$ECGLL,706.1420,N,838.4390,E,1015,A
result with";": $ECGLL;$PPGLL1;$PPGLL2;$PPGL3, ...
$PPGLL;4706.1420;N;00838.4390;E;141015;A

where lays the problem?
Thanks for ideas or fix

[sv.KUJIRA.ch]

p.s.
problem with field length seems to be with ocpn 5.9.2-0
not with NmeaConverter v1.4.15

[RhythmDoctor]

The problems you are describing sound similar to ones I reported (and were fixed) about a year ago. See replies #382-400 in this thread:
https://www.cruisersforum.com/forums...ml#post3812142

Different anemometer models report their data in different ways, so you may have uncovered a different bug. But the fix that Dave implemented works perfectly for my Raymarine ST4000+ under v5.8.4. I have not had time to try out 5.10.0, and hope that the update hasn't broken NMEAconverter.

Going forward, I'd recommend recording an NMEA script of your anemometer's output, manually editing the data to test certain values, then playing the script back to test NMEAcalculator. That will pinpoint the problem much better, and doesn't require disconnecting your hardware or other difficult hacks. And you can post the script here so others can replicate your problem.

[Corsair63]

Originally Posted by sv.KUJIRA.ch

with v1.4.15 i have trouble with field length before decimal point if separated with "," not so if separated with ";"
orig: $PPGLL,4706.1420,N,00838.4390,E,141015,A
result with",": $ECGLL,$PPGLL1,$PPGLL2,$PPGL3, ...
$ECGLL,706.1420,N,838.4390,E,1015,A
result with";": $ECGLL;$PPGLL1;$PPGLL2;$PPGL3, ...
$PPGLL;4706.1420;N;00838.4390;E;141015;A

where lays the problem?
Thanks for ideas or fix

Maybe a stupid question, how is configured your o.s. regarding decimal??

is your with decimal "," or decimal "."?

make a double check and just in case exchange the system to decimal "."
I have had several problems until I realized it and exchange my systems to decimal "." instead ","
because this is a problem with the separators and also in ".CSV" files.

[sv.KUJIRA.ch]

Originally Posted by 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

the answer still lays here (Quote #391)
with windows11, ocpn5.10 and nmeaconverter_pi-1.3.4.0 all works.
with nmeaconverter_pi-1.3.5.0 they limited the fieldlength to 3digits,
but for nmea0183 we need 4digs for lat., 5digs for lng. and 6digits for time.
so it needs adjustment in nmeaconverter_pi.cpp around line 471.
cheers Felix