Plugin: DashBoard

[Hakan]

Originally Posted by Corsair63

Maybe I should be doing something wrong, but not able to show the date in the Dashboard.

should it be possible to add such feature? as another field to show.

There's an instrument in Dashboard called "GNSS clock" based on time in xxGGA or xxRMC.
The date is present in the GNSS system by e.g. RMC and ZDA but there's no "instrument" for that in Dashboard, correct. Everything is of course possible as a future request. Meanwhile you may use something from the PC itself.

[rgleason]

I found an aduino routine that creates the checksum at the end of each sentence. Perhaps it can be repurposed?


https://forum.arduino.cc/t/nmea0183-checksum/559531/2

[rgleason]

Originally Posted by Hakan

Rick..
In Dashboard code here

Beautiful,... the XDR source.

Can this be expanded?
to include things like


WIXDR,H,89,P,HUMIDITY% Relative Humidity?
amount of water vapor present in the air expressed as a percentage of the maximum possible amount of water vapor that the air can hold at a given temperature.


WIXDR,H,??? Absolute Humidity?
actual amount of water vapor present in a given volume of air
Calculation 70% RelHumidity, 90 degrees airtemp, .03374 bar vapor pressure, 0.0014945 grms/m squared

Battery SOC? for example?
WIXDR,G,95.4,BATT%

Dual Frequency Depth for example?
$SDXDR,D,2.85,M,XDHI,D,2.92,M,XDLO,C,23.16,C,WTHI


I found this Nmea0183 XDR spec
Official Calypso XDR Spec
https://github.com/maritime-labs/cal...ent-1478400841

[rgleason]

Absolute Humidity would have to use the G generic Type Field with no (null) Unit field.

WIXDR,G,[some value with known units],HumidityAbsolute Units=lbs/cu.ft, grms/cubic meter or kilograms per cubic meter

I don't think that Absolute humidity is used much in weather instruments, so maybe we should drop it in Watchdog!

Actually it should be very easy to derive Absolute Humidity by calculation if we really need it?
using AirTemp and RHumidity. Maybe that is what should be done in Watchdog?
Dashboard could also have a Relative Humidity instrument and perhaps a derived Absolute Humidty instrument.

[stevead]

Re NMEA 0183 v4.11 XDR sentences, here are a few pages of a presentation I found somewhere that describes the standard transducer names, types and units.

You will note that Absolute Humidity is defined within the standard so no need to define your own.

For state of charge, unless there is an update to the standard, (or perhaps a question directed towards a company such as Victron may provide an answer), my suggestion would be to use the standard transducer name of "BATTERY#x", a type of "G" generic and units of "P" percent.

There is also some good documentation in the last several pages of the Shipmodul Miniplex manual.

[rgleason]

Thank you Steve, this is a great help.

Originally Posted by stevead

Re NMEA 0183 v4.11 XDR sentences, here are a few pages of a presentation I found somewhere that describes the standard transducer names, types and units.

You will note that Absolute Humidity is defined within the standard so no need to define your own.

For state of charge, unless there is an update to the standard, (or perhaps a question directed towards a company such as Victron may provide an answer), my suggestion would be to use the standard transducer name of "BATTERY#x", a type of "G" generic and units of "P" percent.

There is also some good documentation in the last several pages of the Shipmodul Miniplex manual.

[Hakan]

I'm trying to extend Dashboard XDR parsing to transducerName exampled above.
Not less exchange some outside air descriptions by a common; contains "AIR" made capitals.

While on it the "Dual frequency depth" mentioned above with this example.
$SDXDR,D,2.85,M,XDHI,D,2.92,M,XDLO
Present XDR parser don't include water depth. If we would add this can anyone explain how the HI and LO values would be used and prioritized? In Dashboard we have one depth instrument only.

[rgleason]

Hakan, I know there are many thoughts about Dashboard and XDR. Dashboard is a "plugin", albeit "internal". It is really separate from OpenCPN but uses the nmea data stream coming from OpenCPN.

I wonder why the restriction on instruments, since the nmea sentences are all available will will pass through to Dashboard, why not use the complete set? Would this slow OpenCPN down? Make it more confusing for users? What is the problem? Processing overhead for smaller cpu like RPI? As it is Openplotter supports all these instruments via signalk.

[Hakan]

Originally Posted by rgleason

will pass through to Dashboard

If I don't misunderstand that's not correct. Dashboard is just a receiver. Nothing is "passed through"

OCPN, the multiplexer, collects and send all or requested N0183 sentences by the function ".....SendToAllPlugins".
In Dashboard when XDR is received we parse what's needed for the instruments defined there.
The same is valid for other plugins e.g. Watchdog. When XDR is received to Watchdog, from OCPN, he has to parse whats needed for defined watches. So Watchdog and other plugins can use and parse XDR totally independent of Dashboard.

[Rasbats]

Anything useful here?

https://www.eye4software.com/hydroma...-nmea0183-xdr/

[Hakan]

Rasbats.
I've seen that. But is that an example how one manufacturer uses XDR for there own needs?
Is it commonly used in ships using OCPN? And if so would we prioritize between HO and LO?

[rgleason]

Hakan you've expressed more clearly, what I intended.

If I don't misunderstand that's not correct. Dashboard is just a receiver. Nothing is "passed through"

OCPN, the multiplexer, collects and send all or requested N0183 sentences by the function ".....SendToAllPlugins".

[rgleason]

Originally Posted by Rasbats

Anything useful here?

https://www.eye4software.com/hydroma...-nmea0183-xdr/

Yes, thank you. I do have that info and link in my spreadsheet.


I found Steve's post very helpful, The attachment is hugely useful for XDR. "nmea xdr v4.11.pdf "
Why shouldn't this be followed?


Due to Watchdog being in RX and many of the alarms not appearing to work properly,
I've created an Issue TESTING WATCHDOG which has more information about XDR.

[rgleason]

Originally Posted by Hakan

Rasbats.
I've seen that. But is that an example how one manufacturer uses XDR for there own needs?
Is it commonly used in ships using OCPN? And if so would we prioritize between HO and LO?

As they indicate, it is a dual frequency transducer. Probably for fishing? So you would want it to show both low and high (does this refer to frequency or depth?) I think. This is a specialized instrument, but I think you would probably take the one that represents the sea floor.

I think this is pretty specialized and would not expect it in Dashboard, but what about those fancy fisherman multifrequency transponders, do they have a common nmea0183 sentence? Or are they using other communication protocols? ...nmea2K?


In the description about the Hydro XDR Plugin at the bottom they have

• XDLO - Low frequency transducer depth;
• XDHI - High frequency transducer depth;

[Rasbats]

Originally Posted by Hakan

Rasbats.
I've seen that. But is that an example how one manufacturer uses XDR for there own needs?
Is it commonly used in ships using OCPN? And if so would we prioritize between HO and LO?

Think it should be up to the user to decide which frequency to use. No need for priority.