Dashboard wind needles doesn't show wind from Port

[ChrisseH]

I have been testing the transmission of NMEA 0183 sentences sent from my PC application (by means of WiFi) to a Windows 10 tablet with OpenCPN with the Dashboard 1.2 as well as the Dashboard Tactics 1.6 plugins. All data sent can be seen on the dashboards' small panels, but the wind angle needles only show wind coming from Starboard. If the wind comes from Port the wind needles point strait up. This behavior is the same for the combined Apparent an True Wind panel as for the separate panels for Apparent Wind and True Wind.

At first I did the mistake that I sent the wind angle info in the MWV sentence with the range of +/-180 degrees, but realized that the angle should actually be converted to show wind between 0...359 degrees. After this change I expected the problem to be resolved, but the wind angle needles are still behaving as before. Note that the numerical wind angle info shown in the corners of the tiny wind panels are showing the correct sign (=minus) when wind comes from Port.

What could be the reason for this behavior?

Br,
Christer

[Hakan]

Christer..
OCPN/Dashboard use the MWV, Wind Speed and Angle, in relation to the vessel's bow/center line, according to this:
https://gpsd.gitlab.io/gpsd/NMEA.htm...peed_and_angle
Note: Wind speed unit: K;Km/h, M;m/s, N or omitted; Knots

If so it use to work.

[bdbcat]

Christer...
Please post a copy of your MWV sentences (and others) as sent by your app to OCPN.


Thanks
Dave

[ChrisseH]

Thanks Hakan and Dave,


Below some C# code from the NmeaOut file my PC application.


So as a conclusion - All other NMEA sentences work well except for the two MWV sentences I have. Also the numerical wind data is transferred, but the wind needles in the OpenCPN plugins are not showing wind from Port.


case "RMC":
sentence = $"$--RMC,{DateTime.UtcNow:HHmmss.ff},A,{dataPackage.Lat itudeString},{dataPackage.LatitudeHemisphere},{dat aPackage.LongitudeString},{dataPackage.LongitudeHe misphere},{dataPackage.SpeedOverGround},{dataPacka ge.CourseOverGround},{dataPackage.DatePC:ddMMyy},{ dataPackage.MagneticVariation},{dataPackage.Magnet icVariationHemisphere}*";
goto WriteSentence;
case "MWV (TWS&TWA)":
Int32 twaa = (int)Math.Round(dataPackage.TrueWindAngle1);
if (twaa < 0)
{
twaa = 360 - twaa;
}
sentence = $"$--MWV,{twaa},T,{dataPackage.TrueWindSpeed1:N2},N,A*" ;
goto WriteSentence;
case "VHW":
sentence = $"$--VHW,{dataPackage.HeadingCorrected},T,{dataPackage. HeadingMagnetic},M,{dataPackage.SpeedKnots},N,{dat aPackage.SpeedKnots * 0.539957},K*";
goto WriteSentence;
case "DBT":
sentence = $"$--DBT,{dataPackage.DepthMeters * 3.2808399:N2},f,{dataPackage.DepthMeters:N2},M,{da taPackage.DepthMeters * 0.54680665:N2},F*";
goto WriteSentence;
case "MTW":
sentence = $"$--MTW,{dataPackage.TemperatureWater:N2},C*";
goto WriteSentence;
case "MWV (AWS&AWA)":
Int32 awaa = (int)Math.Round(dataPackage.ApparentWindAngle1);
if (awaa < 0)
{
awaa = 360 - awaa;
}
sentence = $"$--MWV,{awaa},R,{dataPackage.ApparentWindSpeed1:N2},N ,A*";
goto WriteSentence;
case "HDM":
sentence = $"$--HDM,{dataPackage.HeadingMagnetic},M*";
goto WriteSentence;
case "HDT":
sentence = $"$--HDT,{dataPackage.YawCorrected},T*";
goto WriteSentence;
case "XDR":
sentence = $"$--XDR,A,{dataPackage.Pitch},D,PITCH,A,{dataPackage.R oll},D,ROLL*";
goto WriteSentence;


Please be informed that the PC app is developed so that the user (depending on the receiving equipment or app) can select only a subset of the NMEA sentences available in the code. Note also that the idea here is that the wind information is fully calibrated and corrected for motions and other effects before it is transferred. This is the case also for the other parameters, except for RMC.



Br,
Christer

[bdbcat]

ChrisseH....


Nice code.
Let's see the datastream that actually goes into OpenCPN.


Thanks
Dave

[HeywoodJ]

A complete and total shot in the dark, and no reason I can think of that it would make a difference, but your code has twaa and awaa as Int32. Every sample of MWV I can find (including Hakan's sample above) has the angle value as a float with one decimal place.

Again, can't see any reason that would make a difference, but should be pretty easy to modify the code to send a float and see what happens.

Edit:

On review doesn't this:

if (twaa < 0)
{
twaa = 360 - twaa;
}

result in a value > 360? If the twaa is less than zero then 360 - (negative value) => 360 + value. Shouldn't this be

360 + twaa, then for twaa= -10 you get 350?

[ChrisseH]

Of course, the sign should be +.


Thank you very much!


Have to test this tomorrow in my yacht.


Br,
Christer

[champ8242]

Originally Posted by HeywoodJ

360 + twaa, then for twaa= -10 you get 350?

I guess this depends on where the calculation is done, not?
If I do it in Excel:

360 "-" -10 = -350
360 "+"-10 = -370

Bart

[ChrisseH]

Hi all,


Changed minus to plus in both formulas and tested thereafter the app in my yacht, and everything worked now exactly as it should.


Thank you very much guys for your help!


Br,
Christer