Plugin: DashBoard

[rgleason]

SkipperEarly wrote

Would it be possible in the AWA-AWS and the TWA-TWS dial to have the outer figures in the appearance-small style (like it is now) BUT the central speed in appearance-label style? That way the speed could be set larger for better reading.

Just so we can visualize what we have now. I do not understand "appearance-label" style.

[rgleason]

I had sent this to Thomas Rauch earlier (maybe he'll do this, but I don't know).



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]

[Graphic]

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

Now I am thinking the brown and blue should be switched, because
blue= water reference
brown=ground reference.
(Not shown this way in the image though)

It adds data to App & True Angle Instrument.
However I think there is potential for much better graphic representations, perhaps with a double dial and indicators.

[transmitterdan]

Originally Posted by Hakan

dan...
Without deep knowledge but what about a JSON message like how Jon used in OcpnDraw, OD, and Watchdog, WD?
OD and WD exchange messages as well as WD receives AIS messages from OCPN.

But of course no JSON messages are yet prepared in OCPN for the result of the VMG calculation.

Håkan

I think the "simplest" thing would be to have the code that computed VMG send a message to dashboard the same as the NMEA multiplexer does now. JSON format would be ok too. But that would mean the locally computed data would not be available for output on the NMEA multiplex. If we are only worried about dashboard that is not a big penalty IMO.

[Hakan]

Dan...
Or could something like this be used to get it as a common NMEA?
routeman.cpp: 716
// XTE

{
            m_NMEA0183.TalkerID = _T("EC");            
            SENTENCE snt;             
            m_NMEA0183.Xte.IsLoranBlinkOK = NTrue;
            m_NMEA0183.Xte.IsLoranCCycleLockOK = NTrue;            
            m_NMEA0183.Xte.CrossTrackErrorDistance = CurrentXTEToActivePoint;            
            if( XTEDir < 0 ) m_NMEA0183.Xte.DirectionToSteer = Left;
            else
                m_NMEA0183.Xte.DirectionToSteer = Right;            
            m_NMEA0183.Xte.CrossTrackUnits = _T("N");
            m_NMEA0183.Xte.Write( snt );
            g_pMUX->SendNMEAMessage( snt.Sentence );
        }

Håkan

[skipperearly]

Originally Posted by rgleason

SkipperEarly wrote
Just so we can visualize what we have now. I do not understand "appearance-label" style.

Under appearance there are 3 settings, title/label/normal. I understand normal sets outer figures but was hoping the central figures could blinked to label, that way in your example the 18.5knt could be configured larger. But maybe the control doesn't allow this.

Sent from my D5803 using Cruisers Sailing Forum mobile app

[transmitterdan]

Originally Posted by Hakan

Dan...
Or could something like this be used to get it as a common NMEA?
routeman.cpp: 716
// XTE

{
            m_NMEA0183.TalkerID = _T("EC");            
            SENTENCE snt;             
            m_NMEA0183.Xte.IsLoranBlinkOK = NTrue;
            m_NMEA0183.Xte.IsLoranCCycleLockOK = NTrue;            
            m_NMEA0183.Xte.CrossTrackErrorDistance = CurrentXTEToActivePoint;            
            if( XTEDir < 0 ) m_NMEA0183.Xte.DirectionToSteer = Left;
            else
                m_NMEA0183.Xte.DirectionToSteer = Right;            
            m_NMEA0183.Xte.CrossTrackUnits = _T("N");
            m_NMEA0183.Xte.Write( snt );
            g_pMUX->SendNMEAMessage( snt.Sentence );
        }

Håkan

That was my first idea. It probably work. We could probably create a "special" talker ID that the multiplexer would know should be sent to the dashboard but not back out to the NMEA output stream. I think it requires some fiddling with the multiplexer but should not be too bad. I'll do a little experimenting and see how hard it would be to do it this way.

There may be another benefit to this idea. In a case where O computes some navigational parameters that users wanted to appear in the NMEA output stream this would be an effective way to get that functionality.

[rgleason]

Messages to and from OpenCPN. Jon Gough developed a format for each call and response, which was used by Watchdog, ODraw and Weather_routing. These messages (call and response) are available to all plugins. This system required small additions to OpenCPN code.

I have asked Jon if he could join in on this discussion.
You might want to look at
Messaging | Official OpenCPN Homepage

[rgleason]

By the way, does anyone have an answer to my question here
http://www.cruisersforum.com/forums/...er-165211.html

about
FS#725 : NMEA use the actively maintained system's copy of nmea0183/ instead of a local copy

Is Dashboard now using the main Opencpn copy of Nmea? I assume it is an updated version?

[rgleason]

SethDart and/or TransmitterDan

We have had several discussions on the forum trying to clarify the term VMG which has several meanings.
http://www.cruisersforum.com/forums/...on-165382.html

..we need to use familiar terms but make each of them explicit with a 4 letter acronym (Thank you Barnakiel, your suggestions).

• VMGC (or VMGT) Velocity made good to course (or target)
• VMGW Velocity made good to wind

Thank you all for your input.

Can you implement these designations in Dashboard? I will write tom_bigspeedy who is preparing tacticss_pi so that he can use the same consistent terms.
Thankyou.

These changes have been made in these Feature Requests:
FS#2065 : Instr VMG in Active Route Console renamed to "VMGC"
FS#2051 : Instr VMGW (new) Calculate "Speed achieved directly towards, or away from, TWD"
FS#2050 : Instr VMG (existing) Change name to "VMGC" - Also Dial version bug

Also User Documents "Terminology" has been changed.

[jongough]

Rick,
Unfortunately I am overseas at the moment and only have my tablet for email/web, so cannot help for a week or so.

However, If you look at the OD, WD, Weather_Routing and AIS stuff, I used standard JSON messaging, but i made the message a little more 'structured', so that reveivers knew who had sent the message and could respond, if needed, with identifiable responses. Seems like overhead with the current synchronous messaging, but makes sense if thinking about asynchronous messaging.

There only change I made to OCPN code was to put out JSON AIS messages. This was to eliminate the need to parse the NMEA message again. The messaging I used uses the standard 'SetPluginMessage' (I think that is what it is called) API.

Currently all messages are broadcast to all plugins (if they asked for it in their INIT section). It is up to the plugins to work out if they are interested in the message. I think the messaging structure in OCPN needs to be updateda little to provide for more targeted messaging, i.e. subscription, and to allow for asynchronous, non-guaranteed delivery/processing. However, that would be quite a change. It may be worth starting a 'messaging' thread to discuss this whole process and come up with an acceptable minimum set of data items that should be in all 'broadcast' JSON messages.

Jon

Originally Posted by rgleason

Messages to and from OpenCPN. Jon Gough developed a format for each call and response, which was used by Watchdog, ODraw and Weather_routing. These messages (call and response) are available to all plugins. This system required small additions to OpenCPN code.

I have asked Jon if he could join in on this discussion.
You might want to look at
Messaging | Official OpenCPN Homepage

[transmitterdan]

I agree with Jon that if we are going to have an API that supports streams of messages then it needs to be optimized so as to avoid slowing down the program with lots of useless messages going anywhere and everywhere.

Dashboard is in need of a few other things before we tackle the VMG question. Right now there is no way for the user to control the behavior of individual instruments. So it is a lot of work to add code for another instrument even if it is the same as another one except for a change in formula or NMEA message type.

There was an idea about this in the beginning but the code is incomplete stubs that do nothing. In order to make the instruments configurable we need the framework for customizing individual instruments in a persistent way. Then we can let the user decide what parameter an instrument displays and what the name of the instrument will be. Each instrument could implement a context menu that would be specific to that instrument. The user should be able to select the specific data from a list of supported data types and algebraic combinations. That would reduce the number of instruments substantially and eliminate the need to keep changing the plugin every time someone wants to rename something or use a different formula.

[rgleason]

I agree .. API .. optimized so as to avoid slowing down the program

FS#1933 : Plugin Messaging Improvements & Efficiency - AIS so it does not impact program
- I believe Dan VOTED for it. Will others?

Dashboard is in need of a few other things before we tackle the VMG question.

Could also be VMGc and VMGw or if it must be shorter VTC or VTW (another Barnakiel suggestion).

User Configurable Instruments- persistant. [Dan I like it!]

1. add new instruments from a template.
2. user defined instrument name.
3. user selection of nmea data & algebraic combination from limited list.
4. ability to change the formula or NMEA message type?
5. user selection of instrument format choices from a list.
6. user choices implemented via a specific instrument context menu.
7. reduce number of instruments
8. eliminate changes due to naming and change of data/formulas.

Question: Would a user be able to create a second or third instrument with different data, from a given 'template'.

How many templates would there be?

• Analog Dial (several types)
• Digital
• Histogram

Another possible advantage to a template is that the "style" could be improved incrementally and it would apply to all associated instruments?

Another improvement would be to be able to drag the indivual instruments into the format and location that you would like, so that you could have a 2x4 instrument window, or 2x3 with with the left part all an double height analog dial instrument, for example. Kind of a drag the instrument within the window/menu and drop it. (-Same could be done with the Active Route Console afterwards)

Sounds like a long term improvement to me, but a good plan!

[rgleason]

Expose the route data (e.g. VMG, TTG, etc.) to the Dashboard plugin by sending NMEA messages through the INPUT multiplexer. -->...might be some circular conditions... user to ask for NMEA data coming into the multiplexer to be repeated on the outgoing mutiplex.

Perhaps Bdbcat and others should advise regarding what would be the best approach. Maybe there needs to be a stronger messaging framework, then the Dashboard can use that framework for messaging?

Or perhaps just do it incrementally. Use what we have now and then change it?

[rgleason]

Sean's Plugin Sweep Plot is partially implemented, however it offers some histograms for Speed and Course (Wind Speed, Wind Direction and XTE in a future version) and good preference controls.

This plugin consolidates the histogram aspect of Dashboard and could perhaps serve as basis for the next version of Dashboard Histograms, with improvements.

He uses some clever averaging techniques and has 10 and 60 minute choices for speed PDS (position determined speed) and for course PDC (position determined course).

See the brief Sweep Plot plugin page.
Sweep Plot | Official OpenCPN Homepage

I hope the plugin can be improved to show all histogram selections.

[Nick_Currawong]

Hi guys,

I have had some issues the XDR processing within the dashboard , I.e. Only processing sentences which match on transducer name "Airtemp" for example.

I have reworked the XDR section to be based on transducer type , this seems to make more sense to me and also allows for a few more instruments. Also allows developers to call their transducers what they like.

I don't know where I can upload my copy of dashboard_pi.cpp for review/inclusion?

I have posted the changed code in the thread link below;
http://www.cruisersforum.com/forums/...rd-166028.html