New Plugin NmeaConvertor

[AboardAdventurer]

Good afternoon gang,

I'm trying to get my Maretron WSO100 weather sensor to input data into the OpenCPN dashboard. I struggled for a bit with the incoming XDR sentence converting over to MDA, but after finally figuring out NMEAConverter I was able to get Air Temp and Barometric Pressure to come online. The problem I'm having is specifically (I think) with NMEAConverter. The pressure is coming in the XDR stream as bars, but really 100 x bars, an example being the data showing today is 98500. OpenCPN needs this to read (apparently) 0.985 to register correctly. I have attempted to insert a mathematical function to chop the 98500 down to 0.985 (divide by 100000), but OpenCPN is truncating the output to 1. I can see it doing this truncation as I divide by 10, then 100, then 1000, etc...it keeps dumbing down the number and both rounding up as well as reducing the decimal feedback. I've attached a screen shot of my specific example. I'm curious how to fix this, as with a reading of 1 from an output of 98500, I don't believe there will be any change in barometric pressure on the dashboard gauge regardless of the change in pressure. It currently reads 1000mbar at an output of 1 on the MDA stream. Any help would be appreciated.

[Hakan]

You're correct that Dashboard-tactics_pi use a value of bar(g) > .8 < 1.1

Hopefully the calculation handle double in the calculations but if only float the 1/100000 will be strange.
A long shot >> try $IIXDR6/100000 or $IIXDR6*10^-5
But if the strange XDR sentence always use five digits a normal pressure, 10130, will be incorrect anyhow.

[AboardAdventurer]

I'm away from the setup for a few days, but I can confirm that the $IIXDR6/100000 does the exact same thing. I'll try the version with the exponent, but I suspect it will also do the same thing. It almost seems like the XDR sentence is pre-configured within either OpenCPN or NMEAConverter to reduce down at that "position" within the sentence. The temperature portion of the code as well as the humidity portion of the code doesn't do it...just the 6th position (as best I can tell from limited testing). I know openCPN supposedly can also accept XDR sentences directly for just humidity, but I have had no success making this work. The only benefit to this would be that I believe the XDR sentence can accept not just 0.8-1.1, but also 800 to 1100. Why does OpenCPN only accept MDA sentences with humidity between 0.8 and 1.1? This seems rather silly to me....a number is a number and it just needs to display it....why not just report whatever is coming in thru the sentence?



AA

[AboardAdventurer]

Tried the code with an exponent and it did the same thing. I came across a thread (of course I can't find it now) describing that the Dashboard plugin sets the decimal count for a particular NMEA incoming sentence fragment by the amount of decimals the incoming data has. I.E, if 0.15 is brought in, than that sentence fragment will always have x.xx available, regardless of the math applied. In my case, I bring in a whole number, no decimals, so it doesn't allow any decimal places. This is extremely frustrating and I'd really like to know what options I've got here...super expensive weather sensor that OpenCPN can barely talk to....doesn't seem right for an otherwise astounding amount of functionality....


AA

[AboardAdventurer]

SOLVED.



The math I required was $IIXDR/100000 because the data coming in was in Pascals (99700 today), but obviously OpenCPN Dashboard requires it to read 0.997 in order for everything to work in hPA. Dividing by 100000 was rendering a 1 as the output which is of course useless.



The trick is to add decimals to the divisor in the quantity you need, in my case 100000.000 allowed the data to correctly display in hpa. I hope this helps somebody out there...banged my head on the wall for days to figure this out and the solution is of course ridiculously stupid!!


Best.



AA

[Hakan]

AA..
Congratulations. Well done. And as usual....Of course! That's one way to tell the compiler this is a float, with decimals, and not a integer, without decimals. On the other hand it's not expected that a average user would know anything about that. So it may be the plugin code would take care of that.

[rooiedirk]

The plugincode does as is. indeed a check for the number of decimals in the input, and uses the same amount in the output.
I could try to add something to format the output. My first idea is then to add something like the printf formating https://www.cprogramming.com/tutoria...t-strings.html
This would be relative simple coding and give a lot of flexibility. Any other ideas??

[Antipole]

Can SKS point me to the latest Mac package for NMEAConverter, please? The manual only has the Windows versions and the thread only a link to an very old package.
Thanks.

[goodwinds]

Just wondering if I should of posted the link here, I originally had on main Opencpn Forum page, however it's more of a NMEA Converter question.

http://www.cruisersforum.com/forums/...on-216079.html

Basically I want to put take the first field value in a MWV sentence, and add 60 degrees to the value and use the new value for OpenCPN Wind display, and output to STNG.

Original thread link has Debug sentences, and screen shot, and of course the processes I've tried/had suggested etc.

Thanks for any advise

[rooiedirk]

Sorry, that won't work. You can not send a sentence with the same identifier as you use for composing it. This would cause an infinite loop.

[rgleason]

You could try blocking that sentence in O
and send it in on a separate virtual port
Using Paul Elliots navmonpc http://www.navmonpc.com/

Nope that won't work you need to use nmeaconverter between navmonpc and O and that is not possible.

Just get it calibrated or fixed.

[Rasbats]

What about using the redundant sentence "VWT"? Will the dashboard still recognise this? Convert from "MWV" to "VWT".

Mike

[Hakan]

Mike..
Both VWR and VWT are parsed in Dashboard as before.

[goodwinds]

Originally Posted by Rasbats

What about using the redundant sentence "VWT"? Will the dashboard still recognise this? Convert from "MWV" to "VWT".

Mike

Interesting thought, then display True wind on O as my apparent wind!!
However, someone smarter than me would need some funky calculation to add 60degrees, and change the L or R in the sentences with the converter.

Example, ST50 NMEA0183 sentence to O is 140 R, while the actual ST50 display shows 170 L (or relative 190 R), so while it might work for wind angles less than 130 degrees, issues may arise when passing through 180, or maybe 0 degrees, the calculation would require R & L manipulation, though interesting idea.

I know the output sentence from the ST50 is wrong, however replacing the instrument and vane just so I can display on O, and use Vane mode on AP seems excessive.

What if the Wind direction on O is still incorrect, Then I block the output sentence of MWV and then could I use the NMEA converter to modify a output sentence in VWT back to AP, so at least the AP could use Vane mode.

I'm not sure what sentences the Evo 1 accepts, especially since its via a Actisence, and ST-STNG converter.

[Hakan]

goodwinds..
What OS do you use for OCPN? If on Win I've small patch to Dashboard if you would like to be a test pilot. I added an option to enter MWV wind angel offset.