Plugin: DashBoard

[rgleason]

Thank you Schnapsy and Petri

https://github.com/OpenCPN/OpenCPN/issues/1464

[scud]

Hello
nobody has the same issue with Wind History?
As you can see all data regarding wind are properly displayed exception made for Wind History

[Canne]

Hi Schnapsy,

Back in the harbor and my boat's Raymarine ST60 SeaTalk (dead slow) available for some testing: I was able to reproduce your issue #2 with AWA/AWS instrument with DashT while testing future v0.5.2! You know, I have not changed wind.cpp or dial.cpp in any particular way apart the fancy wind direction arrows, nor I have changed the way NMEA sentences are parsed and distributed if no true wind calculations are involved. So its comparable with Dashboard. According to me, there is no damping code anywhere here.

I recorded a video from a part of the screen and with a framegrabber SW analyzed the jumping which is very visible and I got this max. delta (from a 10s video):

Which gives 0.85 seconds before the AWA instruments catches up with its neighbor. That's very visible, indeed.

The AWA sentence delivered by my (dead slow) ST60 arrives in average 1.8 second interval, worst case well over 2 seconds as provided by OpenCPN to the plugin and then further distributed to the instruments (see below for detailed statistics).

The data is provided at that moment to the instrument object through its SetData() method. If the this happens after the Draw() method is called, it is too late, since the arrow, for example is redrawn each time in this method and if the correct data is not there, it is not there.

What might be the update interval of your AWA/AWS data containing sentences?

While an excellent tool for debugging, the NMEA recorder does its playback in a monotonic rate since it does not record / use timestamps in the data file. Therefore it is perhaps too fast to detect this type of issues.

The obvious remedy is to increase the frequency of the incoming data from the ridiculous 0.5 Hz (in my case). But since this is not possible without changing the instrument, I attempted to reduce the quite important jitter caused by the NMEA event-driven distribution system of OpenCPN.

How? I bypassed entirely the OpenCPN (previously it was reading directly the USB) and got all my wind data from Signal K server's "delta" TCP port 8375: that's a thread against a thread, a socket against a socket, fast and furious! I managed to reduce the jitter considerably and the SetData() gets called more accurately. I got a video with much more better synchronized needles to a human eye and with a worst case like this:

That's 0,33 seconds. Pretty good!

You can see that even in this case, the AWS data was already good, it was just the AWA that was behind (that's two different calls to the instrument).

I published a paper (with images here), a pdf copy with no images: Three-way_timestamps_win10.pdf, if you are interested.

Best regards,
Petri

[Canne]

Originally Posted by scud

Hello
nobody has the same issue with Wind History?
As you can see all data regarding wind are properly displayed exception made for Wind History

Hi Scud,

You are not showing the True Wind Dir. & Speed dial instrument. It is probably also showing zero movement, meaning that your instruments are not providing TWD data. Or they cannot provide it to you since you are moored.

I can see that you have a Tactics plug-in, why not use it? It can calculate you the TWD using either the STW (preferred by some racers) or SOG. But since your speedo shows zero, it will still show you an empty wind history - one needs to have a speed value >0.0 before the TWD can be calculated - either SOG or STW.

Best regards,
Petri

[scud]

Originally Posted by Canne

Hi Scud,

You are not showing the True Wind Dir. & Speed dial instrument. It is probably also showing zero movement, meaning that your instruments are not providing TWD data. Or they cannot provide it to you since you are moored.

I can see that you have a Tactics plug-in, why not use it? It can calculate you the TWD using either the STW (preferred by some racers) or SOG. But since your speedo shows zero, it will still show you an empty wind history - one needs to have a speed value >0.0 before the TWD can be calculated - either SOG or STW.

Best regards,
Petri

Hello Petri, thanks for your answer.
Take my word for it that the TWD and TWS as well as the TWA gets properly displayed in the other instruments of the dashboard. Eventually next week end I can post a snapshot showing that in detail. As for SOG I confirm it was 0 since I was comfortably sitting in my mooring.

Anyway what puzzles me in the WH graph is that TWS is properly displayed on top left corner.
TWD shows 00 on top right side of hte graph.
The vertical axis shows _._ instead of the scale values and no curve is recorded or displayed.

As for the Tactics plug-in that is another chapter. My intention is to report what looks like a a bug in the WH /Dashboard plug-in.
I certainly can live without WH and I have all the other dashboard instruments working like a charm. WH gets handy when I am anchored in a storm or in a night watch hoping for the wind to give up a little

[Schnapsy]

Originally Posted by Canne

Hi Schnapsy,
(...)

What might be the update interval of your AWA/AWS data containing sentences?

(...)

Hello Petri,

Thank you for all these explanations, although I must admit that I am a little lost.
It's a bit too technical for me ...

To answer your question :

What might be the update of your AWA / AWS data containing sentences ?

The LCJ CV7 anemometer manufacturer's sheet shows a 2 Hz ouput rate (with a 30 Hz measurement).

I must also indicate that I test the computation of the real wind of 2 ways (alternatives, on 2 different pc):

- With the NmeaConverter_pi plugin and the following formula:

XXMWV $, $ IIMWV1 + acos ((sqr ($ IIMWV3) + sqr ($ GPRMC7) + sqr ($ IIMWV3) -2 * $ * $ GPRMC7 IIMWV3 * cos ($ IIMWV1 3.14159265 * / 180) -sqr ($ GPRMC7) ) / (2 * sqrt (sqr ($ GPRMC7) + sqr ($ IIMWV3) -2 * $ GPRMC7 * cos ($ IIMWV1 3.14159265 * / 180)) * $ IIMWV3)), T, sqrt (sqr ($ GPRMC7) + SQR ($ IIMWV3) -2 * $ * $ GPRMC7 IIMWV3 * cos ($ IIMWV1 3.14159265 * / 180)), N, A

- Or (on another PC), with a modification of the dashboard_pi.cpp given by Hakan (which I thank again) and indicated here:

http://www.cruisersforum.com/forums/...31.html number # 457:

// Calculate true wind speed and angle.if (m_NMEA0183.Rmc.SpeedOverGroundKnots <999 ||! wxIsNaN (m_NMEA0183.Vtg.SpeedKnots)){double AWSpeed;double SOG;double c_TWS;double c_TWS_kn;double c_TWA;AWSpeed ​​= m_NMEA0183.Mwv.WindSpeed ​​* m_wSpeedFactor / 1.94384; // In Knots, form it to m / sSOG = m_NMEA0183.Rmc.SpeedOverGroundKnots / 1.94384; // In Knots, form it to m / sif (m_NMEA0183.Rmc.SpeedOverGroundKnots> = 999) SOG = m_NMEA0183.Vtg.SpeedKnots / 1.94384;c_TWS = sqrt (pow (SOG, 2) + pow (AWSpeed, 2) - 2 * SOG * AWSpeed ​​* cos (m_awaangle * 3.141592654 / 180));c_TWS_kn = c_TWS * 1.94384; // To knotsSendSentenceToAllInstruments (OCPN_DBP_STC_TWS,toUsrSpeed_Plugin (c_TWS_kn, g_iDashWindSpeedUnit),getUsrSpeedUnit_Plugin (g_iDashWindSpeedUnit));SendSentenceToAllInstrumen ts (OCPN_DBP_STC_TWS2,toUsrSpeed_Plugin (c_TWS_kn, g_iDashWindSpeedUnit),getUsrSpeedUnit_Plugin (g_iDashWindSpeedUnit));c_TWA = (m_awaangle + 180) * acos ((pow (AWSpeed, 2) + pow (c_TWS, 2) - pow (SOG, 2)) / (2 * c_TWS * AWSpeed)) / 3.141592654;if (c_TWA> 180) c_TWA = 180 - (c_TWA - 180);SendSentenceToAllInstruments (OCPN_DBP_STC_TWA, c_TWA, m_awaunit);// int test = 1;}


I do not know if the output frequency of my anemometer affects the speed of calculation and display of the actual wind (TWS and TWA) by OpenCPN (either with Hakan's formula or that of the NmeaConverter).

In any case, thank you to interest you in this concern ...
Best Regards,
Alain

[Canne]

Hi Alain,

Sorry to increase the confusion level
Anyway, this dive into your use case helped me to improve and verify the accuracy and predictability of the data transmission to the wind instruments in derived, DashT solution.

Originally Posted by Schnapsy

The LCJ CV7 anemometer manufacturer's sheet shows a 2 Hz ouput rate (with a 30 Hz measurement).

Well, that's much better than my miserable 0.5Hz... and since it goes directly to the dial you are rightfully complaining about its AWA needle slowly jumping around.

Originally Posted by Schnapsy

I must also indicate that I test the computation of the real wind of 2 ways (alternatives, on 2 different pc):<snip></snip>I do not know if the output frequency of my anemometer affects the speed of calculation and display of the actual wind (TWS and TWA) by OpenCPN (either with Hakan's formula or that of the NmeaConverter).

It appears that your are deriving the true wind data from RMC sentences: without knowing the origin of these sentences it still might be that they arrive with higher frequency than the AWA information containing sentences alone (2Hz) - in this case, the combined TWA/AWA instrument will get more frequent data updates by SetData() calls.

Let's wait and see what your bug report will bring out.

Best regards,

Petri

[Canne]

Hi Scud,

Originally Posted by scud

Take my word for it that the TWD and TWS as well as the TWA gets properly displayed in the other instruments of the dashboard. Eventually next week end I can post a snapshot showing that in detail. As for SOG I confirm it was 0 since I was comfortably sitting in my mooring.

Don't bother to do that, I believe you! What would be more useful is a short NMEA recording with the recorder you have got and post it here by adding the .pdf in the file extension (forum limitation). I am sure that some original Dashboard users could analyze/play your data in their systems. I would be interested to play it in the latest Tactics plug-in, it has an awesome wind history instrument, completely rewritten.


Back to your observations:

Originally Posted by scud

Anyway what puzzles me in the WH graph is that TWS is properly displayed on top left corner.
TWD shows 00 on top right side of hte graph.
The vertical axis shows _._ instead of the scale values and no curve is recorded or displayed.

I looked at the original Dashboard code in O repository here. WindSpeed is always shown by in line 560, without condition:

 WindSpeed=wxString::Format(_T("TWS %3.1f %s "),
                                     m_WindSpd, m_WindSpeedUnit.c_str());

While TWD displaying has a condition in line 503:

if(!m_IsRunning)
    WindAngle=_T("TWD ---");
else {
    dir=m_WindDir;
    while(dir > 360) dir-=360;
    while(dir <0 ) dir+=360;
    WindAngle=wxString::Format(_T("TWD %3.0f"), dir)+DEGREE_SIGN;   }

Why wouldn't you be "running"? Line 142 says:

//start working after we collected 5 records each,
// as start values for the smoothed curves
if (m_SpdRecCnt > 5 && m_DirRecCnt > 5) {
   m_IsRunning=true;
   ...

Both speed and and direction must have at least five samples received before the history starts. Since TWS looks quite stable, I would concentrate to see why the TWD - if received by the other TWD instruments never arrive - or arrive less than five times - to this instrument's SetData() entry, at line 96 ?

if (st == OCPN_DBP_STC_TWD || st == OCPN_DBP_STC_TWS) {
   if (st == OCPN_DBP_STC_TWD) {
      m_WindDir = data;
      if (m_DirRecCnt <= 5){
         m_DirStartVal += data;
         m_DirRecCnt++;
       }
   }

Originally Posted by scud

WH gets handy when I am anchored in a storm or in a night watch hoping for the wind to give up a little

I endorse this use case, of course! It brings back many memories of dark nights when this functionality would have been welcome!


Best regards,


Petri

[rgleason]

Canne, your great understanding and explanations are much appreciated. I will of course play any uploaded nmea0183 file in dash_T, dashboard and tactics and report.
If there is any difficulty uploading these notes from the wiki may help.
https://opencpn.org/wiki/dokuwiki/do...ruiser_s_forum

[rgleason]

@Petri

I ran across these Dashboard Issues and Tracker items which relate to timing and clock:

https://github.com/OpenCPN/OpenCPN/issues/1408

https://opencpn.org/flyspray/index.p...s&task_id=2568

no VMG, HDG, COG on Dashboard (plus other issues) - Page 3 - Cruisers & Sailing Forums

Correct error reported in FS#2568 #1410
Not yet merged into Opencpn Dashboard.

How would these relate to improvements made in Tactics_pi, Dashboard_Tactics, and other PR to Dashboard (if at all)

Perhaps I should close some of these issues?

[scud]

Originally Posted by Canne

Hi Scud,

Don't bother to do that, I believe you! What would be more useful is a short NMEA recording with the recorder you have got and post it here by adding the .pdf in the file extension (forum limitation). I am sure that some original Dashboard users could analyze/play your data in their systems. I would be interested to play it in the latest Tactics plug-in, it has an awesome wind history instrument, completely rewritten.


Back to your observations:


I looked at the original Dashboard code in O repository here. WindSpeed is always shown by in line 560, without condition:

 WindSpeed=wxString::Format(_T("TWS %3.1f %s "),
                                     m_WindSpd, m_WindSpeedUnit.c_str());

While TWD displaying has a condition in line 503:

if(!m_IsRunning)
    WindAngle=_T("TWD ---");
else {
    dir=m_WindDir;
    while(dir > 360) dir-=360;
    while(dir <0 ) dir+=360;
    WindAngle=wxString::Format(_T("TWD %3.0f"), dir)+DEGREE_SIGN;   }

Why wouldn't you be "running"? Line 142 says:

//start working after we collected 5 records each,
// as start values for the smoothed curves
if (m_SpdRecCnt > 5 && m_DirRecCnt > 5) {
   m_IsRunning=true;
   ...

Both speed and and direction must have at least five samples received before the history starts. Since TWS looks quite stable, I would concentrate to see why the TWD - if received by the other TWD instruments never arrive - or arrive less than five times - to this instrument's SetData() entry, at line 96 ?

if (st == OCPN_DBP_STC_TWD || st == OCPN_DBP_STC_TWS) {
   if (st == OCPN_DBP_STC_TWD) {
      m_WindDir = data;
      if (m_DirRecCnt <= 5){
         m_DirStartVal += data;
         m_DirRecCnt++;
       }
   }

I endorse this use case, of course! It brings back many memories of dark nights when this functionality would have been welcome!


Best regards,


Petri

Thanks Petri
at home and playing an NMEA data file I downloaded then it works.
I ll have to check on the boat my actual NMEA stream.

[Canne]

Originally Posted by rgleason

I ran across these Dashboard Issues and Tracker items which relate to timing and clock:<snip></snip>Perhaps I should close some of these issues?

Seeing Dan's explanation about the root cause being the OpenCPN generated RMC sentence I would get the O fix first done for it and the close the Dashboard ones which are duplicates anyway. If the fix is to not distribute OpenCPN generated RMCs to plug-ins anymore, they would lose the VMG-to-the-next-WP information in that sentence (remember, the non-Tactics "VMG"?) as a secondary effect. Since I am not authoring either of the modules and do not plan to do so, this is only my personal opinion, since you asked for it

[transmitterdan]

Originally Posted by Canne

Seeing Dan's explanation about the root cause being the OpenCPN generated RMC sentence I would get the O fix first done for it and the close the Dashboard ones which are duplicates anyway. If the fix is to not distribute OpenCPN generated RMCs to plug-ins anymore, they would lose the VMG-to-the-next-WP information in that sentence (remember, the non-Tactics "VMG"?) as a secondary effect. Since I am not authoring either of the modules and do not plan to do so, this is only my personal opinion, since you asked for it

I looked into this a bit. It is not hard to have OpenCPN distribute RMC with valid GPS time if it is available. If GPS time is not available then it could use the CPU system time. Is that a reasonable compromise?

I can't think of a case where following a route is even sensible without valid GPS data input. I suppose a route could be started and then GPS data goes away.

[Canne]

Originally Posted by transmitterdan

...have OpenCPN distribute RMC with valid GPS time if it is available. If GPS time is not available then it could use the CPU system time. Is that a reasonable compromise?...

Hi Dan,
+1 for this solution from me! BTW, your PR to O for it did not pass. Was it because the build for trusty failed? Apparently there was a timeout on travis (this happens more and more often. In the end people see only the red cross and think "oh, it has failed..." ).
Best regards,
Petri

[transmitterdan]

I have not made a PR for this issue yet.

The build failure issue is something to do with the CI system. I have tested all my PRs on real Linux systems with no problems.