New Plugin NmeaConvertor

[transmitterdan]

Originally Posted by RhythmDoctor

Seatalk - vYacht dialect:

$XXVWT,90-deg(atan(($GPVWR3*cos(rad($GPVWR1))-$GPRMC7)/$GPVWR3*sin(rad($GPVWR1)))),$GPVWR2,sqrt(sqr($GPVW R3*sin(rad($GPVWR1)))+sqr($GPVWR3*cos(rad($GPVWR1) )-$GPRMC7)),$GPVWR4,,,,<return>

ZZZ’s dialect (Simrad?):

$XXMWV,90-deg(atan(($WIMWV3*cos(rad($WIMWV1))-$GPRMC7)/$WIMWV3*sin(rad($WIMWV1)))),T,sqrt(sqr($WIMWV3*sin (rad($WIMWV1)))+sqr($WIMWV3*cos(rad($WIMWV1))-$GPRMC7)),N,A

It is possible to replace the sender ID (GP or WI) with ?? which means any sender ID will be accepted. Then maybe you don't need so many different versions of the formulas.

[RhythmDoctor]

Originally Posted by transmitterdan

It is possible to replace the sender ID (GP or WI) with ?? which means any sender ID will be accepted. Then maybe you don't need so many different versions of the formulas.

I don't think using a wildcard for the talker ID accomplishes much. One dialect uses ??MWV? inputs, the other uses ??VWR? inputs. And MWV and VWR work totally differently: MWV provides wind angles from 0-360, and VWR provides wind angles from 0-180 with an additional parameter of L or R. This is why, in a later post, I warned that my sentence for $XXMWV probably will not work when tested. I would delete it, but CF doesn't allow editing after a short time.

I would very much like to have an equation that converts between the two (I need it to create MWD from VWR), but cannot figure out how to do it without a conditional operator like "if($GPVWR2="L",180+....)". Are such conditional operators supported in the function library?

Maybe I'm just not seeing something here. Can you suggest some NMEA sentences that would use the proposed wildcards and convert between MWV and VWR?

[rgleason]

Rhythm Dr
Is there any chance of getting a good VDR file for testing?
I would add it to the wiki, along with your version.

Do you want me to send you a new PW for the wiki?

[transmitterdan]

The VDR file on Paul Elliot’s web site works with RythmDrs equations as long as you use ?? for the talker ID.

[rgleason]

Thanks tdan.

[transmitterdan]

Originally Posted by RhythmDoctor

I don't think using a wildcard for the talker ID accomplishes much. One dialect uses ??MWV? inputs, the other uses ??VWR? inputs. And MWV and VWR work totally differently: MWV provides wind angles from 0-360, and VWR provides wind angles from 0-180 with an additional parameter of L or R. This is why, in a later post, I warned that my sentence for $XXMWV probably will not work when tested. I would delete it, but CF doesn't allow editing after a short time.

I would very much like to have an equation that converts between the two (I need it to create MWD from VWR), but cannot figure out how to do it without a conditional operator like "if($GPVWR2="L",180+....)". Are such conditional operators supported in the function library?

Maybe I'm just not seeing something here. Can you suggest some NMEA sentences that would use the proposed wildcards and convert between MWV and VWR?

Wildcards won’t convert the MWV into VWR. But the talker ID isn’t important and should probably be ?? as a good practice. All MWV or VWR sentences should be the same regardless of talker ID.

I wish there was an if ternary operator like C:

(Val==“L” ? 1 : -1)

This would evaluate to 1 for “L” and -1 for anything else.

[rgleason]

Basic comments transcribed here
https://opencpn.org/wiki/dokuwiki/do..._rhythm_doctor

[RhythmDoctor]

Originally Posted by transmitterdan

Wildcards won’t convert the MWV into VWR. But the talker ID isn’t important and should probably be ?? as a good practice. All MWV or VWR sentences should be the same regardless of talker ID.

I wish there was an if ternary operator like C:

(Val==“L” ? 1 : -1)

This would evaluate to 1 for “L” and -1 for anything else.

Now I get what you were suggesting - sorry, sometimes I'm dense. I fully agree that providing example sentences for both $??MWV and $??VWR/$??VWT (as well as ?? talker ID for all input variables) would make the Wiki much easier to use for those who want to just copy/paste the sentences into the Preferences Dialog. The only reason I can think of to not use wildcards is if you have more than one talker providing the same data, and want to filter some of them out.

[RhythmDoctor]

Originally Posted by rgleason

Basic comments transcribed here
https://opencpn.org/wiki/dokuwiki/do..._rhythm_doctor

I will make some changes soon. I need to remove my suggested equation for $XXMWV, because it was not tested and will certainly fail for reasons I explained in a prior post.

I have succeeded at using wildcards for my sentence for $XXVWT, and will put this in the Wiki:

$XXVWT,90-deg(atan(($??VWR3*cos(rad($??VWR1))-$??RMC7)/$??VWR3*sin(rad($??VWR1)))),$??VWR2,sqrt(sqr($??VW R3*sin(rad($??VWR1)))+sqr($??VWR3*cos(rad($??VWR1) )-$??RMC7)),$??VWR4,,,,<return>

However, my attempt to use wildcards for converting water temperature from C to F crashes OpenCPN every time. Someone please test it and see if you get the same problem:

$XXMTW,9/5*$??MTW1+32,F

[rooiedirk]

$XXMTW,9/5*$??MTW1+32,F

Your problem here is that jou are sending a new sentece $XXMTW, and then using this just send sentence again to construct again a new one.

If you are sending a new sentece after receiving data then this will result in an endless loop.
Choosing for sending every xx seconds will give unpredicteble results as it is not clear what sentence will be used for data, the original one or the last new constructed.

[rgleason]

Originally Posted by rooiedirk

Your problem here is that jou are sending a new sentece $XXMTW, and then using this just send sentence again to construct again a new one.

If you are sending a new sentece after receiving data then this will result in an endless loop.
Choosing for sending every xx seconds will give unpredicteble results as it is not clear what sentence will be used for data, the original one or the last new constructed.

Dirk, so how would you suggest fixing it to avoid the endless loop?
I guess the nmea data stream goes through OpenCPN first, then to NmeaConverter?
Is there a way to "intercept" the incoming nmea data stream before it reaches OpenCPN, so that we can make some changes and then send it in to OpenCPN?


I suppose I am asking for a standalone program, such as NavMonPC which can create virtual ports to send to OpenCPN, and will also do tasks such as NmeaConverter?

[rooiedirk]

I'm afraid it is not easy doable. Remove the wildcards will prevent the endless loop, but then still OpenCPN (dashboard) doesn't make any difference for the talkerID, so it will use both. (However the one coming from the nmeaconverter is slightly later, so it might just 'seem' to work)

[conachair]

Originally Posted by rgleason

I suppose I am asking for a standalone program, such as NavMonPC which can create virtual ports to send to OpenCPN, and will also do tasks such as NmeaConverter?

Node red could do that for you.

[rgleason]

Intercept Nmea before going to OpenCPN, modify it with Nmeaconverter, and send it to Opencpn, to avoid the infinite loop.

Node red could do that for you.

1. Node Red - Good, Yes for RPI, Linux.
2. Run two instances of OpenCPN with defined input and output filters, also using NmeaConverter? Complicated.
3. Make NmeaConverter a part of OpenCPN at the Connection filter level?
4. Make an OpenCPN Connections checkbox "Send to NmeaConverter first", then NmeaConverter modifies the nmea stream and sends it to OpenCPN.
5. For Windows users: Extend NavMonPC to include Nmeaconverter features. (This is a long shot, as Paul has finished development.)
6. Other approaches?


Dirk, can we set incoming filters in Opencpn (somehow) to eliminate the unwanted sentence? or even choose to send it to nmeaconverter first?

[conachair]

Originally Posted by rgleason

1. Node Red - Good, Yes for RPI, Linux.

And windows, https://nodered.org/docs/platforms/windows

5 -10 minutes to install if that. *Really* useful for messing with opencpn/nmea as you can just cut and paste messages to send over UDP, see whats coming out of opencpn or with a little javaacript mess around with the messages.