Dashboard Plugin Instruments: Engine Gauges?

[CaptTom]

This may have come up before, but I didn't find it in a quick search...

Are there any plans to add engine data to the available instruments in the Dashboard plugin?

This feature is available on most new MFDs. Newer engines, or in my case, old engines with an analog to NMEA 2000 device, put all kinds of useful information on the NMEA 2000 bus.

Just trying to work out in my mind what I'd be able to do with OpenCPN on a dedicated device at the helm, in place of an MFD, and this is something I'd want to have.

[nohal]

Originally Posted by CaptTom

This may have come up before, but I didn't find it in a quick search...

Are there any plans to add engine data to the available instruments in the Dashboard plugin?

This feature is available on most new MFDs. Newer engines, or in my case, old engines with an analog to NMEA 2000 device, put all kinds of useful information on the NMEA 2000 bus.

Just trying to work out in my mind what I'd be able to do with OpenCPN on a dedicated device at the helm, in place of an MFD, and this is something I'd want to have.

No, not with the current dashboard plugin, yes there is something in the pipeline for the next major release.

[CaptTom]

Originally Posted by nohal

No, not with the current dashboard plugin, yes there is something in the pipeline for the next major release.

Sweet, thanks! Can't wait to see it!

[Schnapsy]

Originally Posted by nohal

No, not with the current dashboard plugin, yes there is something in the pipeline for the next major release.

Hello,

Since there is a project in progress, is it, please, possible to integrate a dashboard improvement ?

I noticed that data remains displayed (position, depth, etc.) even if the data connection nmea is interrupted.

In case of interruption of flows nmea, * all * the data displayed on the dashboard disappear or change color or - better - starts to flash or blinking...

This is in my opinion the best way to know that there is a problem.

Already reported in the Flyspray FS # 2391

[RonSouthworth]

Hi,

Disappearing can be a bad thing if some automation is acting on the data especially when under way. Microprocessor devices don't alway stop talking sometimes they keep repeating stuff or send jibberish and "flood" the com channel.

Sounds like what you're looking for is a data quality indication of sorts.

FWIW the GPS icon changes state fairly reliably on loss of signal / poor sat visibility sat data quality. Wonder if you have that enabled. From my experience it is a good indicator when I've lost all my GPS positional data. Maybe something to add to the watchdog plugin ?

[stevead]

In response to this question

This feature is available on most new MFDs. Newer engines, or in my case, old engines with an analog to NMEA 2000 device, put all kinds of useful information on the NMEA 2000 bus.

the following answer was given

No, not with the current dashboard plugin, yes there is something in the pipeline for the next major release.

Can you provide any further details?
Is OpenCPN moving to the SignalK data format?
What changes, if any are being made to the dashboard plugin to support data formats other then NMEA 0183?
Is OpenCPN going to natively support NMEA 2000?

Importantly for me, should I stop any further development of the TwoCan plugin?

Soon to announce the 1.4 release (actively particpating on the NMEA 2000 network) and contemplating the 1.5 release (bi-drectional NMEA0183 <-> NMEA 2000 gateway)

[nohal]

Originally Posted by stevead

In response to this questionthe following answer was given
Can you provide any further details?
Is OpenCPN moving to the SignalK data format?

As another supported format, yes. It will have no influence on NMEA0183 support, except substantial changes in the core of the application invisible to the user and to the plugin developer (unless he wants to).

What changes, if any are being made to the dashboard plugin to support data formats other then NMEA 0183?

None. The current dashboard plugin design is not usable in the longer term future. Too fixed to NMEA0183, which in turn is too deficient in features.

Is OpenCPN going to natively support NMEA 2000?

Unlikely, if you ask me.

Importantly for me, should I stop any further development of the TwoCan plugin?

You should probably not.

Soon to announce the 1.4 release (actively particpating on the NMEA 2000 network) and contemplating the 1.5 release (bi-drectional NMEA0183 <-> NMEA 2000 gateway)

That is not overlapping with what I will do in the nextgen dashboard replacement or in what has to be done to support SignalK, so there is no duplication of effort AFAICT.

Both SignalK support and the nextgen dashboard will not be available before the next major release, at least half a year from now.

[stevead]

Probably leads to more questions than you were expecting.

SignalK support: I presume client side only, consuming data in Signal K format?

If I add support for the various engine & equipment related NMEA 2000 PGN's, how does the plugin forward that to OpenCPN ? Will have I to add Signal K server functionality to the plugin? Can I just send SignalK formatted data in the same way that today I send NMA 0183 sentences ?

Adding support for additional NMEA 2000 PGN's is a no brainer (testing however is problematic as I don't have any NMEA 2000 engine sensors to test against ! In fact I have very little to test against !)

Adding support for Signal K server I am loathe to do for a number of reasons, firstly there is already the Node JS SignalK server available (although it doesn't natively integrate as a plugin with OpenCPN) and secondly it would require significant programming effort (gazillions lines of code in C/C++ whereas I do know that it can be implemented on Windows using .Net in a few hundred lines of code as there are existing classes that make it easy to do the JSON, HTTP server and Web sockets stuff.

(BTW, Any plans to allow AIS data to be sent directly to OpenCPN without the need for me to create NMEA 0183 sentences and encode it in the 6bit format only for it to be decoded by OpenCPN?)

[nohal]

Originally Posted by stevead

SignalK support: I presume client side only, consuming data in Signal K format?

Sure in the initial implementation.
[/QUOTE]
If I add support for the various engine & equipment related NMEA 2000 PGN's, how does the plugin forward that to OpenCPN ? Will have I to add Signal K server functionality to the plugin? Can I just send SignalK formatted data in the same way that today I send NMA 0183 sentences ?
[/QUOTE]
You will not have to add any server functionality, you will simply call an API function as you do for NMEA0183 sentences.

Adding support for Signal K server I am loathe to do for a number of reasons, firstly there is already the Node JS SignalK server available (although it doesn't natively integrate as a plugin with OpenCPN) and secondly it would require significant programming effort (gazillions lines of code in C/C++ whereas I do know that it can be implemented on Windows using .Net in a few hundred lines of code as there are existing classes that make it easy to do the JSON, HTTP server and Web sockets stuff.

There are signalk-server-cpp and Argo, both a better idea than .NET for inclusion in a crossplatform package IMHO. And both needing effort to actually make them usable.

(BTW, Any plans to allow AIS data to be sent directly to OpenCPN without the need for me to create NMEA 0183 sentences and encode it in the 6bit format only for it to be decoded by OpenCPN?)

I do not understand what you mean. What is this "AIS data" for you exactly? Whatever, the answer probably is no, unless it is SignalK.

[CaptTom]

Originally Posted by stevead

Adding support for additional NMEA 2000 PGN's is a no brainer (testing however is problematic as I don't have any NMEA 2000 engine sensors to test against ! In fact I have very little to test against !)

If there's any way I can help, let me know. I have a NoLand RS-11 analog-to-NMEA 2K device, but not sure if there's anything on my network which could capture the data.

As for SignalK, none of my off-the-shelf hardware uses it, so it's all just theory to me. I'm a big fan of open protocols (and dislike the fact that NMEA 2K is proprietary) but until SignalK is widely supported, I'd rather not invest too much in it.

[stevead]

Is it safe for me to assume that the "new" OpenCPN SignalK API will allow me call the API passing some data in a format similar to the following:

{
    "navigation": {
        "meta": {
            "label": "GPS position","units": "deg",    "convertTo": "dms"
            },
            "latitude": 54.484,
            "longitude": -0.61683,
            "$source": "Twocan plugin",
            "timestamp": "2019-03-10T17:24:31.42",
            "pgn": 129025
    }
 }

Regarding AIS, Currently the plugin parses AIS data from the relevant NMEA 2000 PGN's and then has to perform the 6bit encoding to create an NMEA 0183 sentence of the form: !AIVDM,1,1,,A,1>O5liPv1<wqpsrM65m5KTL800S5,0*11 only for OpenCPN to then decode the AIS payload.

If OpenCPN will be able to consume AIS data in the SignalK data format that solves half the problem, otherwise it would be more efficient to be able to submit AIS data directly to OpenCPN , rather than via NMEA 0183 sentences with their inherent 6bit encoding.

To Capt. Tom (and others), If you have access to a Linux PC/Raspberry PI with a CAN adapter, just use the candump utility to log any data on the NMEA 2000 network. If you only have a Windows PC, then the TwoCan plugin together with a supported CAN adapter can be used to log the data.

[nohal]

Originally Posted by stevead

Is it safe for me to assume that the "new" OpenCPN SignalK API will allow me call the API passing some data in a format similar to the following:

{
    "navigation": {
        "meta": {
            "label": "GPS position","units": "deg",    "convertTo": "dms"
            },
            "latitude": 54.484,
            "longitude": -0.61683,
            "$source": "Twocan plugin",
            "timestamp": "2019-03-10T17:24:31.42",
            "pgn": 129025
    }
 }

Yes, normal SignalK delta format.

Regarding AIS, Currently the plugin parses AIS data from the relevant NMEA 2000 PGN's and then has to perform the 6bit encoding to create an NMEA 0183 sentence of the form: !AIVDM,1,1,,A,1>O5liPv1<wqpsrM65m5KTL800S5,0*11 only for OpenCPN to then decode the AIS payload.

If OpenCPN will be able to consume AIS data in the SignalK data format that solves half the problem, otherwise it would be more efficient to be able to submit AIS data directly to OpenCPN , rather than via NMEA 0183 sentences with their inherent 6bit encoding.

We will certainly not invent another format to pass the AIS data. In addition to the NMEA0183 already supported we will support also SignalK.