Plugin: DashBoard

[rgleason]

First use a nmea sentence checker to verify the checksum. There are several links for this in the wiki. Also it looks like you are missing a value at ,, what is that value? Review the nmea documentation for this sentence and check and understand each variable. Have slow inet so cannot help more.

[transmitterdan]

Originally Posted by juancho38

Hi,

can somebody help with why I don't manage to display STW on dashboard ?
Here is the NMEA sentence (VHW) I receive :

<GREEN>10:40:12 (Serial:COM30) $VWVHW,218.0,T,215.2,M,7.4,N,,13.8,K*4E<0x0D><0x0A>
<BLUE>--> 10:40:12 (UDP:192.168.1.255:10110) $VWVHW,218.0,T,215.2,M,7.4,N,,13.8,K*4E

Many thanks for your help.

The sentence is in error. It has one extra field so when Dashboard (or Tactics) checks the checksum it is looking specifically in field 9. Since field 9 in your sentence is the letter 'K' it is not a valid checksum.

OpenCPN itself does not know how many fields an NMEA sentence should have so it finds the checksum by looking for the '*'. So OpenCPN thinks the sentence is valid because it's checksum is ok. But Dashboard knows the sentence is not properly formatted so it tosses it into the bit bucket.

[juancho38]

Yes !
I did not noticed the double comma.
Many thanks for your help.

[Maelruan]

Originally Posted by rgleason

https://opencpn.org/wiki/dokuwiki/do...nmea_sentences
Look for the Dashboard nmea0183 sentences.

I suspect you have rtlsdr_pi for receiving AIS, confused with nmea sentences for Instruments.

There are many clever programmers who might be able to program the conversion if you can provide the details needed and the base data that needs to be converted.

Thanks RGleason,
I use the very reliable AISRec which pumps in very long range AIS targets in NMEA, rather than rtlsdr_pi. I may have led you astray earlier by referring to rtl_ais.exe included in that pi package, which I mentioned as a possible route to a solution because it can be configured for desired frequencies, and also for tcp and udp targets (an option apparently lacking in 433) where data could be read by an NMEA converter (I'm afraid I'll have to depend on your clever programmers for this step), and hopefully from there to Dashboard.

I may be able to provide files in text of results from the terminal display from both the Fine Offset and AlectoV1 protocols which might meet your request for "base data".

Thanks also to Conachair - it had been the link you mention that led me to rtl_433.exe.

[conachair]

Originally Posted by Maelruan

Thanks also to Conachair - it had been the link you mention that led me to rtl_433.exe.

Thinking a bit more about this.....

This *should* work... probably Might seem a bit long winded but well worth the effort imho.

So you can get data from the weather sensor in a terminal, this won't mean anything to the dashboard unless it is converted into an NMEA sentence which the dashboard recognizes as wind data. One way to do this would be using node-red which is sort of like a visual programming language, someone (me maybe ) could write what's needed then you just copy and paste into your machine. I'm assuming you have a windows machine onboard.
So, there's an extremely useful program called signalk which is writen for boat data in general and extremely powerful and useful, it has node-red built in. http://signalk.org/
A relatively easy way to get this running on a windows machine is to load linux on your windows machine - https://docs.microsoft.com/en-us/win.../install-win10
Then install signalk in there. This all may seem a bit long winded but imho it really is well worth the effort, once signalk is up and running you can do all sorts of tricks with all your data, like save it to a database and view pressure etc as a pretty graph >


Might all seem a little daunting at first but not really that bad and *sooooo* useful!!!

I'm working onsite so only have a linux notebook to play with but do have an rtl dongle so will have a play and see if I can find any weather machines nearby.

[rgleason]

maelruan wrote:
rtlsdr_pi.... I may have led you astray earlier by referring to rtl_ais.exe included in that pi package, which I mentioned as a possible route to a solution because it can be configured for desired frequencies, and also for tcp and udp targets (an option apparently lacking in 433) where data could be read by an NMEA converter.

---I understand your point now.

A plugin that would use rtlsdr usb dongles to receive wind data and convert to nmea0183 format might be very useful. There are presently not many of these available, and it will become more prevalent.

[conachair]

Originally Posted by rgleason

A plugin that would use rtlsdr usb dongles to receive wind data and convert to nmea0183 format might be very useful. There are presently not many of these available, and it will become more prevalent.

Maybe someone will write an app for signalk, it excels at stuff like this. No need to get involved with opencpn and more and more apps are becoming available all the time, just write something to feed signalk with the data then it does the rest, do what you want with it. Quick look calypso wind sensor is supported -
https://www.npmjs.com/package/signalk-windjs-plugin
but nothing for rtl yet.

[stevead]

In response to a few users desiring to display engine data (RPM, Oil Pressure, Water Temperature) with OpenCPN using the TwoCan plugin, I have attempted to modify the dashboard plugin.

I can convert the relevant NMEA 2000 PGN's into their respective NMEA 0183 XDR (transducer) sentences and can feed those into the OpenCPN data stream.

I have extended the dashboard_pi source to parse the additional XDR sentences and have use the existing speedometer gauge style to display (in my case, simulated) engine data.

However the problem is that the dashboard plugin has run out of gauge "identifiers" because of:

enum
{
    OCPN_DBP_STC_LAT = 1 << 0,
    OCPN_DBP_STC_LON = 1 << 1,
    OCPN_DBP_STC_SOG = 1 << 2,
    .....
    OCPN_DBP_STC_HEEL = 1 << 31
}

as I have to add the following:

    OCPN_DBP_STC_MAIN_ENGINE_RPM = 1 << 32,
    OCPN_DBP_STC_MAIN_ENGINE_WATER = 1 << 33,
    ....
    OCPN_DBP_STC_STBD_ENGINE_OIL = 1 << 40

which as you can guess is too large for an int.

If I give the enum a type such as:

enum OCPN_DBP: long long
{
    OCPN_DBP_STC_LAT = 1 << 0,
     OCPN_DBP_STC_LON = 1 << 1,

then it solves my problem but breaks lots of other things such as the various gauge SetData methods where it takes an int argument.

Ideally defining the enum values with something like:

enum
{
    OCPN_DBP_STC_LAT,
    OCPN_DBP_STC_LON,
    OCPN_DBP_STC_SOG,
    .....

solves the problem, but I am not sure what else will break.

Does the dashboard plugin author/maintainer know if these enums are ever used in bitwise operations where the above solution may break other methods ?

Any other thoughts, solutions ?

[rgleason]

Steve
You are not using the right dashboard to do this. Both tom-r's tactics has extended the number of instruments and petri's (canne) dashboard-tactics or DashT plugin have been extensively reworked.

I think you should contact them and see if they will accept a pr. It is my quess that dashT is more appropriate for this.

[stevead]

Thanks Rick for the quick reply.

I've just had a quick look at the Tactic plugin source, and while it does indeed extend the dashboard with different gauges/data displays, it does so by replacing others and still suffers from the same limitation that I have described in my previous post.

In instrument.h, the enum still has the same limitation:

    //OCPN_DBP_STC_RSA = 1 << 16,
     //OCPN_DBP_STC_SAT = 1 << 17,
    //OCPN_DBP_STC_GPS = 1 << 18,
    OCPN_DBP_STC_LEEWAY = 1 << 16,
    OCPN_DBP_STC_CURRDIR = 1 << 17,
    OCPN_DBP_STC_CURRSPD = 1 << 18,
    ...
    //OCPN_DBP_STC_VLW2 = 1 << 27,  // Sum Log
    OCPN_DBP_STC_TWAMARK = 1 << 27,  // TWA to a Waypoint
    OCPN_DBP_STC_MDA = 1 << 28,  // Barometic pressure
    OCPN_DBP_STC_MCOG = 1 << 29,  // Magnetic Course over Ground
    OCPN_DBP_STC_PITCH = 1 << 30, //Pitch
    OCPN_DBP_STC_HEEL = 1 << 31//Heel
}

As can be seen from the above commented out enum values, the Tactics Dashboard is not a superset of the "original" dashboard as it replaces some of the "original" dashboard gauges, with those more suited to tactics and there is still the limit of 32 different data sources that could be displayed by the dashboard.

One horrible solution would be for me to create yet another dashboard plugin for displaying engine data !

[rgleason]

Are you looking at my repository or Tom's?
I believe that both Thomas's tactics and Canne's Dashboard-tactics have been extended to 64 instruments. Perhaps you must pick to correct branch or repository, but it has been extended... in fact I think it is probably more likely to be Petri's repository. We had some discussion about this, so you should check or perhaps ask Canne (petri) about it.

You can lead a horse to the... but

[Schnapsy]

Originally Posted by stevead

Thanks Rick for the quick reply.

I've just had a quick look at the Tactic plugin source, and while it does indeed extend the dashboard with different gauges/data displays, it does so by replacing others and still suffers from the same limitation that I have described in my previous post.

I don't believe...
Here a c/p from dashboard/Tactics...


OCPN_DBP_STC_GPS = 1 << 18,
OCPN_DBP_STC_PLA = 1 << 19, // Cursor latitude
OCPN_DBP_STC_PLO = 1 << 20, // Cursor longitude
OCPN_DBP_STC_CLK = 1 << 21,
OCPN_DBP_STC_MON = 1 << 22,
OCPN_DBP_STC_ATMP = 1 << 23, //AirTemp
OCPN_DBP_STC_TWD = 1 << 24,
OCPN_DBP_STC_TWS2 = 1 << 25,
OCPN_DBP_STC_VLW1 = 1 << 26, // Trip Log
OCPN_DBP_STC_VLW2 = 1 << 27, // Sum Log
OCPN_DBP_STC_MDA = 1 << 28, // Bareometic pressure
OCPN_DBP_STC_MCOG = 1 << 29, // Magnetic Course over Ground
OCPN_DBP_STC_PITCH = 1 << 30, //Pitch
#ifndef _TACTICSPI_H_
OCPN_DBP_STC_HEEL = 1 << 31 //Heel
#else
// >32 sentence capacity identifiers needs 64 bits enumeration
OCPN_DBP_STC_HEEL = 1ULL << 31, //Heel
OCPN_DBP_STC_LEEWAY = 1ULL << 32,
OCPN_DBP_STC_CURRDIR = 1ULL << 33,
OCPN_DBP_STC_CURRSPD = 1ULL << 34,
OCPN_DBP_STC_DTW = 1ULL << 35,
OCPN_DBP_STC_BC = 1ULL << 36,
OCPN_DBP_STC_TWAMARK = 1ULL << 37, // TWA to a Waypoint
OCPN_DBP_STC_POLPERF = 1ULL << 38 // Polar Performance


Hope it helps...

[stevead]

That looks like what I'm looking for.

Where can I find the repository for that dashboard plugin?

[rgleason]

Steve, I do hope it is what you are looking for. I believe Petri (canne) has expanded the instruments to 64, and tom-r has not, in order to keep it in parallel with dashboard.

In github try a search for dashboard-tactics or canne as a user. Tonight I can send you a link if you don't find it. It is a very good plugin incorporating all of thomas r's tactic improvements and all dashboard instruments, with extensive testing of each insteument.

See if canne will accept your pr!

Good luck, let me know if you need the link.

[rgleason]

https://github.com/canne/dashboard_tactics_pi


In looking at the code, all instruments appear to be converted to 64 bit.