Plugin: DashBoard

[Hakan]

Rick..
True, it can for sure be made more sophisticated but for me those "simple" calculations gave me a "good enough" true wind indication. My use is for example when running by motor and you want to know if there's a reason to switch it off and hoist the sails.
Håkan

[transmitterdan]

Originally Posted by fgd3

That's not correct. While a purist (or a pedant) might argue that because you are sailing on the water true wind should be measured at the water's surface rather than the ground it's just a semantic quibble.

I don't agree that it is just semantics. One use of true wind data is to use a polar diagram to estimate what sail configuration and trim should be used to maximize a course made good. Polars are based on wind speed relative to a boat in water not on ground. It may not seem obvious but they are not the same. If the boat is making progress through the water but over ground it is moving differently the sails don't care about the ground. They care about the wind and the keel which is driven by water.

Another use of true wind data is to compare with Grib predictions. These are relative to ground and so using ground speed/direction is appropriate for that comparison. But the more useful data when sailing is wind relative to water.

Polars take into account leeway but perhaps not drift (but apparent wind takes into account leeway and drift). There is no perfect true wind formula that satisfies every requirement.

[hasse_A]

Originally Posted by Hakan

Hasse..
I'm aware of the discussion above but I use SOG, speed over ground, because I want to know the true wind over ground

I can see a point in using SOG since it is difficult to get good precision in STW depending on mounting, heeling and fouling.

To get the correct wind over ground don't you have to take in account the fact that your wind transducer is not pointing in the direction you are moving according to COG (leeway + current). Am I correct ?

The angle difference between COG and heading would off course be easy to calculate if you have heading info and make use of the WMM plugin.

This would give true wind over ground.

/Hans

[transmitterdan]

I agree that if the speed through water sensor is inaccurate then speed over ground would at least help compute true wind over ground. And true wind over water can't be computed anyway so there is no need to bother trying.

I suppose there is no reason not to have both types of true wind available. I'll think about it a bit and see if Dashboard can be coerced into providing computed true wind of both types. What would we name them to make the meaning clear?

[tom_BigSpeedy]

Originally Posted by hasse_A

I had a look at true wind angle and wind speed.
As I understand it you have to input this info via NMEA sentence to have the meters show them.

A lot of us don't have this info accessible.
Would it not be possible to calculate it from apparent wind speed, wind angle and boat speed ?

These are much more frequently available.

If true angle and speed are not present the dashboard could calculate the values, otherwise use the supplied NMEA data.

/Hans

Hans,

give tactics_pi a try, it can do this calculation. It's based on dashboard_pi, they look the same and you can run both in parallel ...
Thomas

[rgleason]

Thanks Tom, those are very good links and graphics.
Sort of responding to TDan and Hasse

To record a good polar diagram, the effect of drift and set, leeway need to be removed, For example trying recording your track while tacking up or downwind going against or with current! There is a huge difference.

Additionally, use of the polars, when you've got meaningful polars, they will provide more effective guidance (Targets) if the software can also include the effect of current and a meaningful estimation of leeway.

What I am trying to say, is I think it really does make a difference how you record your boat's polars and what values you use HDG/STW or COG/SOG and how you account for Drift/Set and leeway.

[rgleason]

Some earlier ideas for Dashboard (and Tactics)

TransmitterDan
http://www.cruisersforum.com/forums/...ml#post2112580

My 2 cents
http://www.cruisersforum.com/forums/...ml#post2112626

Here is a related Tracker #2087
FS#2087 - Improve and Streamline Creation of Instruments - Improved user control & creation.
Please log into tracker and vote for it.

There is also this Tracker #2273 suggestion about display of additional data. Which has not been considered or discussed much, but duplicates the Console and Active Window.

Perhaps when the dust settles more from 5.0 some of these ideas could be tried out by someone? - perhaps minus the messaging bus in Tracker #1933?

[RonSouthworth]

Originally Posted by rgleason

Some earlier ideas for Dashboard (and Tactics)

TransmitterDan
http://www.cruisersforum.com/forums/...ml#post2112580

My 2 cents
http://www.cruisersforum.com/forums/...ml#post2112626

Here is a related Tracker #2087
FS#2087 - Improve and Streamline Creation of Instruments - Improved user control & creation.
Please log into tracker and vote for it.

There is also this Tracker #2273 suggestion about display of additional data. Which has not been considered or discussed much, but duplicates the Console and Active Window.

Perhaps when the dust settles more from 5.0 some of these ideas could be tried out by someone? - perhaps minus the messaging bus in Tracker #1933?

A couple of early observations....

I would suggest that it is a good idea to let some plugins handle a function.

E.g watchdog have it do all the alarms plots do all the trending of data.

Say you create a wind speed indicator that has a setpoint for when a gust or smoothed averaged value of speed is exceeded it generates an alarm which watchdog then handles. Instead of loosing the data it is stored to disk so you can recall it and manipulate it.

To be honest i think a review of how data is managed stored or not stored is worth considering.

Looking at the raft of features being sought solutions are being considered it reminds me of how SCADA systems have evolved.

A lot of the features talked about are out if the box, the only thing needed is the NMEA protocol stack.

There are a lot of benefits to building a real time database for managing your information.

I was actually considering building a maritime SCADA project for a platform I have used for many years the only down side I could see was it is only available in windows, multi platform support being a casualty a few years ago:


Just some food for thought.

[rgleason]

I'd still like to see this kind of consolidated instrument in Dashboard


True-Apparent Consolidation

Also attached is an idea for True-Apparent, considering that Cog/Sog is ground based like true wind.

A 85 11.5k [d.brown]
T 108 12.1k [blue]



HDG 352 STW 5.0 [d.brown]
COG 348 SOG 5.2 [blue]

The brown and blue dials should be switched, because
blue= water reference
brown=ground reference.

This should improved for much better graphics and legibility


http://www.cruisersforum.com/forums/...ml#post2111915

[RonSouthworth]

Originally Posted by rgleason

I'd still like to see this kind of consolidated instrument in Dashboard


True-Apparent Consolidation

Also attached is an idea for True-Apparent, considering that Cog/Sog is ground based like true wind.

A 85 11.5k [d.brown]
T 108 12.1k [blue]



HDG 352 STW 5.0 [d.brown]
COG 348 SOG 5.2 [blue]

The brown and blue dials should be switched, because
blue= water reference
brown=ground reference.

This should improved for much better graphics and legibility


http://www.cruisersforum.com/forums/...ml#post2111915

Swapping the dial arm colours hopefully is just a matter of a search and replace

[rgleason]

Ron this instrument cluster does not exist yet.

Originally Posted by RonSouthworth

Swapping the dial arm colours hopefully is just a matter of a search and replace

[RonSouthworth]

Originally Posted by rgleason

Ron this instrument cluster does not exist yet.

Future stuff I know mock ups are 90 percent of the effort

[teppokurki]

Originally Posted by RonSouthworth

A couple of early observations....
Looking at the raft of features being sought solutions are being considered it reminds me of how SCADA systems have evolved.

A lot of the features talked about are out if the box, the only thing needed is the NMEA protocol stack.

If you are willing to look beyond OpenCPN you can today leverage a modern SCADA stack with Signal K Server, InfluxDB and for example Grafana.

Signal K Server converts NMEA data to Signal K format, giving each datum a semantic name.

Then you can write this data, essentially key-value pairs with well known keys, to InfluxDB with existing software, no coding effort/skills required.

If you prefer some other backend writing a plugin for your preferred solution is very doable. The conversion to SK stays the same, just the db integration changes. You can share the db specific logic in a cross platform plugin, installable with a single click from the SK server admin UI. There already exists one for Prometheus.

Then you are free to choose your visualisation and alerting component(s).

SK server plays nice with OpenCPN, providing for example conversion from N2K to NMEA0183, so you can get the live data also in OpenCPN.

Full disclosure: I am one of the primary authors of said SK server.

[rgleason]

teppokurki


Thanks for the post, it is interesting, and you suggest


Ixia SCADA: DNP3 over TCP/IP Network Stack


SignalK GitHub SignalK https://github.com/SignalK/signalk-server-node



InfluxDB Github https://github.com/influxdata/influxdb



Grafana Labs Github https://github.com/grafana/grafana


My Reaction: ...In some kind of a soup of alphabets and programs. It is unlikely that any of us are inclined to try to utilize these resources without having some explicit examples that work, along with reasonably complete directions and support, IMHO.
Furthermore, are these programs free and Do they meet the OpenSource requirements?

[teppokurki]

Originally Posted by rgleason

Thanks for the post, it is interesting, and you suggest

No, please see https://en.wikipedia.org/wiki/SCADA

Originally Posted by rgleason

My Reaction: ...In some kind of a soup of alphabets and programs. It is unlikely that any of us are inclined to try to utilize these resources without having some explicit examples that work, along with reasonably complete directions and support, IMHO.

The previous author was actually considering building a maritime SCADA project and my point was that by combining existing software you can get pretty far.

If you start with OpenPlotter you get OpenCPN and Signal K out of the box. Adding InfluxDB and Grafana is not overly complex, all you need to do is follow the installation instructions, but I admit there are no single page instructions for setting everything up.

Originally Posted by rgleason

Furthermore, are these programs free and Do they meet the OpenSource requirements?

Yes, they are free and open source.