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