Plugin: DashBoard

[stevead]

Thanks very much Rick,
I had searched this forum and the website (incl developer wiki) but I couldn’t find a reference to the correct plugin. I hadn’t thought of searching github, so thanks for pointing me in the right direction.
Regards...

[Schnapsy]

APP & TRUE WIND ANGLE

Hello,

There is a problem with the color data display of the app & true wind angle dial.

1st problem :
When the character size of the data (speed and angle) is greater than 12 (14 for example), the blue and orange display is no longer displayed, it is a default color display that appears. (picture 1 : DASH_14)

On the other hand, when the size of the characters is less than or equal to 12, the display is distinguished, orange for the apparent wind, blue for the true wind ... (picture 2 : DASH_12)

In which * .cpp file can we fix this ? (from the folder */src of dashboard_pi)

2nd problem
By simultaneously displaying the dial "apparent wind angle" and the dial "app & true wind angle", we see that the needle is much more reactive on the dial "app & true wind angle" and the data are displayed faster.

There may be a damping factor in the "apparent wind angle" dial that has not been taken into account for the other dial.

In which * .cpp file can we fix this ? (from the folder */src of dashboard_pi)

Thank you, in advance...

[Schnapsy]

APP & TRUE WIND ANGLE

I answer to myself hoping that it can help, if possible ...

For the color of the data, it is a question of modifying:

in wind.cpp of dashboard_tactics_pi, line 436 (or line 345 for dashboard_pi)

#ifdef __WXMSW__
if (g_pFontLabel-> GetPointSize () <= 17) {// replace 12 by 17 for example
wxBitmap tbm (width, height, -1);
wxMemoryDC tdc (tbm);

This apparently resolves the 1st question.

On the other hand, the speed of display of the needle (subject of the 2nd question of the previous post) is for the moment not corrected, if someone has an idea I am a taker ...

[rgleason]

SCnapsy,

Can you please identify exactly which version of Dashboard that you are using?
Also thank you for solving one of your reported bugs.


Regarding the second item, what exactly do you want to fix?
Do you want a more reactive apparent wind instrument?

The dampening factor is set in preferences of course.
COG dampening factor.
Speed over ground dampening factor


I don't believe there is a dampening factor for wind, but I don't have time to test it now.
Sorry.

[Schnapsy]

Originally Posted by rgleason

SCnapsy,

Can you please identify exactly which version of Dashboard that you are using?
Also thank you for solving one of your reported bugs.

Regarding the second item, what exactly do you want to fix?
Do you want a more reactive apparent wind instrument?

The dampening factor is set in preferences of course.
COG dampening factor.
Speed over ground dampening factor
I don't believe there is a dampening factor for wind, but I don't have time to test it now.
Sorry.

Hi Rick,

1. Color of the datas
To do this test, I used - on two different PCs - the dashboard_tactics_pi 0.4.1 (without bugs) and the dashboard_pi 1.5.
As the first is the improved copy of the second, it is obvious that this little concern appears on both plugins.

In fact this problem only affects those who have a screen large enough and want to increase the display of the size of the datas of this instrument.
Because i don't need tactics plugin, i keep only the dashboard_pi.dll.

2. Needle speed and data
What I see is not about SOG or COG, which can be set in preferences.

In fact, what I notice is that the APPARENT WIND display needle (and the data) are displayed slower than the needle and the data in the APP & TRUE WIND ANGLE instrument.

A movie would be more talking but I can only put a picture ...

[rgleason]

_2. Needle speed and data_ What I see is not about SOG or COG, which can be set in preferences. In fact, what I notice is that the APPARENT WIND display needle (and the data) are displayed slower than the needle and the data in the APP & TRUE WIND ANGLE instrument.

Both versions?

[Schnapsy]

Originally Posted by rgleason

Both versions?

Yes, in both versions.

Of course, the display of the data and the movement of the needle (that seem to be damped) we see on the dial "APP WIND" are more pleasant and more comfortable than the display - too fast - that we see on the dial APP & TRUE WIND ANGLE...

[rgleason]

Schnapsy, I assume the versions below are the ones you tested.
Perhaps we should add a github "Issue" that references your two items?
Just to be clear, you would like to see the arrow movement ( or dampening if it exists) for the app/true wind angle instrument be more sedate like the App wind instrument.

Dashboard_Tactics v0.4.1 [Canne] (Petri's version)
Note there is a newer v0.5.1 that enables time based recording to Influx DB 2.0.

Issues:
1. Color of the Data - Post #513 to fix the problem
2. Needle speed and data - Post #512 explains the problem

Dashboard v1.5 (OpenCPN included version)
Issues:

1. Color of the Data - Post #513 to fix the problem
2. Needle speed and data - Post #512 explains the problem

[Schnapsy]

Originally Posted by rgleason

Just to be clear, you would like to see the arrow movement ( or dampening if it exists) for the app/true wind angle instrument be more sedate like the App wind instrument.

Yes, that is exactly what is desired.
This is an observation I made while training on some files.

In fact, I'm working on modifying dll files to try to understand (a little) the language used by Opencpn.

And in this case, the simplest and the least "dangerous" for me is to work on the cosmetic aspects, it allows me each time to validate certain personal changes.

Next week, as soon as I have some time, I will try to make the same changes with the version v.0.5.1

[Canne]

Hi Rick and Schnapsy,
Sorry I'm traveling and cannot be of much help for now, but observation

1) is that Schnapsy is compiling from snaspshot of Dashboard from OpenCPN v5.0 repo without Tactics which means that no code has been changed; the result should be the same for out-of-OpenCPNv5.0-box Dashboard and Schapsy's Dashboard. I am not involved in any way in both, only touching code under _TACTICSPI_H_ sections, clearly marked. So, you get also the bugs I have sometimes fixed for Tactics functions (this does not ring a bell, however) ;


Observation 2) is that perhaps the fact that like all OpenCPN, those instruments are event driven, that is they need NMEA statements. The ID_DBP_D_AW and ID_DBP_D_AWA instruments (not sure which one you are using) are subscribing to OCPN_DBP_STC_AWA and OCPN_DBP_STC_AWS containing NMEA statements only, while ID_DBP_D_AWA_TWA is subscribed to OCPN_DBP_STC_AWA | OCPN_DBP_STC_TWA and OCPN_DBP_STC_TWS | OCPN_DBP_STC_AWS containing statements, which means probably that it gets updates more often in your system and is, therefore more "lively";

Observation 3) is that D_DBP_D_AWA_TWA is based on class DashboardInstrument_Wind deriving from DashboardInstrument_Dial, overriding about all its methods. I am not surprised that it behaves differently than ID_DBP_D_AW which is implemented using the base class DashboardInstrument_Dial.


I hope that these observations will help you to move forward, Schnapsy. If it is a bug, please don't open it for me in dashboard_tactic_pi repo, unless you compile and link and find the same bug with both Dashboard and Tactics code included, in which case I thank you in advance for your efforts!


Best regards,
Petri


P.S. to make testing possible between two installations (like yours and mine) I can but recommend to use https://www.kave.fi/Apps/NMEA-Simula...A-Simulator.7z instead of recorded files to pinpoint the issue to a set of certain sentences - here you can set to get, for example one sentence every second for each and then move the value and more precisely measure the response time.

[rgleason]

Petri,
Thank you for getting the subject pi being used, clarified. Perhaps schnapsy should start using your most recent, completely tested version of dash-t first.

[Schnapsy]

Hello Petri,

Thank you for all these detailed explanations.
Petri, I know that Dashboard_tactics is not responsible for this display problem (I wrote it in post # 515).
To be certain, I had installed OpenCPN on another computer, without any plugin (apart from the original ones). And of course, I also noticed this shift. So, dashboard_tactics is not in question, definitely.

By cons, I did not know the origin of the shift in the display of the same data in both dials.
Your explanation in point 2 is very clear, thank you, and I think that's what it's about.

Rick,
Since this problem concerns OpenCPN, do you think it is necessary to open a subject in the flyspray?

If so, I do it by quoting this thread ...

[rgleason]

Schnapsy wrote

To do this test, I used - on two different PCs - the dashboard_tactics_pi 0.4.1 (without bugs) and the dashboard_pi 1.5

Dashboard-tactics is now 0.5.1 and perhaps should be tested for this.

Since it does involve dashboard 1.5 a flyspray should be entered. Please make it as detailed as possible, with petri's analysis and solution.

After this is done, we can add and Issue in github opencpn referencing flyspray.

Thank you both for improving opencpn. Invaluable.

[scud]

I have a problem with Wind History OPENCPN 5.0 on WIN 10)
The relevant window shows a bunch of horizontal lines and at the top left corner displays the actual TWS (tag and value) while at the top right corner displays le letters TWD but showing no actual value.

In the remaining part of the window and grid nothing shows up exception made forhte horizontal lines I mentioned above.

Thanx
CLaudio

[Schnapsy]

Originally Posted by rgleason

Since it does involve dashboard 1.5 a flyspray should be entered. Please make it as detailed as possible, with petri's analysis and solution.

After this is done, we can add and Issue in github opencpn referencing flyspray.

to Rick,

I tested the dashboad_pi.dll obtained from the dashboard_tactics version 0.5.1 and very logically, the display shows the same malfunction.


I added this request in the Flyspray, FS # 2617.
https://opencpn.org/flyspray/index.p...s&task_id=2617

Do not hesitate to complete it if necessary.