Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Search this Thread Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Old 19-02-2019, 20:03   #2746
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,932
Re: Feature Requests

Quote:
Originally Posted by Herreshoff View Post
Looking for some guidance/help for creating a plugin for Open CPN. I'm from Zulu Waterways which is a POI style service (zuluwaterways.com). Our API is nearly ready and I would like to give access to open CPN users. I would be interested in someone with the knowhow taking a look at creating the Zulu Plugin for Open CPN based off the API. Any interest would be great.
Nicholas Baillie Jackson
Nicholas...

I will gladly guide you and provide any help you or anybody else might need, but nothing changes on the fact that I will not write it myself for lack of time. Also of course you may use the code from https://bitbucket.org/nohal/ac_pi as whatever you consider relevant for your work.
You do have my contact info as we already were in contact.

Pavel
__________________

nohal is offline   Reply With Quote
Old 20-02-2019, 14:47   #2747
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 56
Re: Feature Requests

Quote:
Originally Posted by nohal View Post
In the long(er) run they will hurt the poor people that might do the mistake to implement them in their systems. But again, as long as you won't break the current stuff, send a pull request implementing more quadruplets in XDR. Inventing new sentences, not standardised by NMEA I personally consider a very bad idea, but if you must, at least follow the PXXX naming standard for vendor extensions.

You always need a "gateway" device to connect pretty much anything to a computer or mobile device.
I propose these extensions of the XDR statement so that OCPN can receive data from engines and fluid tanks to be able to visualize them in the dashboard.
I think it's a little invasive method ...
(I do not know how to send a "pull request", please, explain-me how to do it))

--------------------------------------------------------------------------------
NMEA0183 XDR format adaptation to translate N2K 127488 and 127489 pgn's
(More significative and frequent data extraction)

$YXXDR,T,x.x,R,ENGn,P,x.x,B,BSTn*hh<CR><LF> (1-2 times per second, 127488 PGN translation)
$YXXDR,C,x.x,C,OILn,R,x.x,l,FRTn*hh<CR><LF> (1 time every 2-3 seconds, 127489)

Set of 4 fiels per transducer, the 2nd field is the value (x.x)

Transducer name:
ENGn : Engine instance n
OILn : Oil temperature instance n
BSTn : Boost pressure instance n
FRTn : Fuel rate instance n

From NMEA0183 - Standard For Interfacing document rules:
Transducer Type:
T : Tachometer
C : Temperature
P : Pressure
R : Flow rate

Units Field:
R : RPM
C : Degrees Celsius
B : Bars
l : liters/second (Suggested: liters/hour to reduce significant digits)
-------------------------------------------------------------------------------

Fluid levels:
$YXXDR,V,x.x,M,TNKn*hh<CR><LF>

Transducer name:
TNKn : Tank instance n (To be assigned in dashboard: Identification)

Transducer Type:
V : Volume

Units Field:
M : cubic meters

-------------------------------------------------------------------------------
I think all gateway manufacturers will appreciate it and soon, we will add it to their products. The implementation is not difficult at all...
__________________

Tehani is offline   Reply With Quote
Old 20-02-2019, 14:49   #2748
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,932
Re: Feature Requests

https://help.github.com/articles/cre...-pull-request/
nohal is offline   Reply With Quote
Old 20-02-2019, 23:16   #2749
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 3,227
Re: Feature Requests

There is a general question here: which data should be represented and processed by OpenCPN.
Being a Chart Plotter and Navigation system in my understanding just all the stuff that is needed for navigation and sailing.

A general "glass bridge" or "virtual instruments" approach would does not show up in my list of preferences. More, for me they don't belong into OpenCPN.

I don't care about the water tank or the temperature in the wine cooler for navigation. Or the light switches in the cabin. House bank voltage and temperature. Output of genny and solar. N2K does, as they want to cope with all data on the boat. SK is transport and transparent about the content.

Even engine data are very discussible here.

One might argue that OCPN has its built-in multiplexer and can be ignorant about the content pushed forward. Correct, but then don't expect that all data are getting represented at OpenCPN.

N2K is simple: take an Actisense--> NMEA gateway and you have the data in OpenCPN. More precise approach: create a plug-in for Actisense or its clones processing the N2K dat stream using the CanBoat library.

SK would require either an external gateway (in form of OpenPlotter/RasPi or something equivalent) or a SK client/server implemented as plug-in for OpenCPN.
The actual SK implementations based on Node JS are not acceptable as part of OpenCPN as they would add an important burden in form of packages and versions that are changing all the time. OpenPlotter reports a hard time to follow.
SK is still under some development. Implies permanent dedication to keep up with it.

Coming back to the beginning: the internal data model of OCPN restricts itself to the navigation data, based on those found in NMEA 0183. To implement a flexible abstract data model implies a big task. And has to be pondered in relation to what we would gain.
For example several instances of GPS can be handled already with the priorities of Communications. Using different incoming ports for the different instances.
Not very elegant, but working out of today's box. An OCPN N2K plug-in might deal with this option for example.
Keep it simple, please...
bcn is offline   Reply With Quote
Old 21-02-2019, 01:43   #2750
Moderator
 
Dockhead's Avatar

Cruisers Forum Supporter

Join Date: Mar 2009
Location: The boat: Cowes (Winter), Above 60N (Summer); me: somewhere in the air!
Boat: Cutter-Rigged Moody 54
Posts: 23,514
Re: Feature Requests

How about voice recognition for the Log plugin?


We were discussing it here:



Voice Recognition for Log? - Cruisers & Sailing Forums
__________________
"Parce que je suis heureux en mer, et peut-Ítre pour sauver mon ame. . . "
Dockhead is offline   Reply With Quote
Old 21-02-2019, 02:25   #2751
Registered User

Join Date: Mar 2011
Posts: 38
Re: Feature Requests

Quote:
N2K is simple: take an Actisense--> NMEA gateway and you have the data in OpenCPN. More precise approach: create a plug-in for Actisense or its clones processing the N2K dat stream using the CanBoat library.

Shameless plug: or the TwoCan plugin.
But as has been stated, irresepective of whether the data is delivered to OpenCPN via NMEA 0183, NMEA2000 or SignalK, if there are no instruments on the dashboard plugin for displaying engine data or tank capacity (or anything else for that matter), the question is moot, is it not ?
stevead is offline   Reply With Quote
Old 21-02-2019, 04:10   #2752
Registered User

Join Date: Feb 2019
Location: Cadiz, Spain
Boat: Furia 372 - 11.20m
Posts: 56
Re: Feature Requests

Quote:
Originally Posted by bcn View Post
There is a general question here: which data should be represented and processed by OpenCPN.
Being a Chart Plotter and Navigation system in my understanding just all the stuff that is needed for navigation and sailing.

A general "glass bridge" or "virtual instruments" approach would does not show up in my list of preferences. More, for me they don't belong into OpenCPN.

I don't care about the water tank or the temperature in the wine cooler for navigation. Or the light switches in the cabin. House bank voltage and temperature. Output of genny and solar. N2K does, as they want to cope with all data on the boat. SK is transport and transparent about the content.

Even engine data are very discussible here.
Of course I understand what you say. I am aware of OCPN has always been oriented to navigation, especially sailing.
Do not think that I am a truck driver or a motorist (I do not know how they call these specimens here ...). On the contrary, I am passionate about sailing, and I do not like the waves that these people produce.

You see, my analysis corresponds to the observation of the current plotters of all manufacturers. They have mainly incorporated the engine data and the autopilot management in their instrument panel. And I think it might be a good idea to offer something at that level, because many OCPN supporters are targeting the replacement of those commercial plotters.

NOTE: Please, do not give an example to the Actisense gateway, it has very limited features in connectivity and translation capacity...
Tehani is offline   Reply With Quote
Old 21-02-2019, 04:21   #2753
bcn
Registered User

Join Date: May 2011
Location: underway whenever possible
Boat: Rangeboat 39
Posts: 3,227
Re: Feature Requests

Tehani...

"sailing" here in the generic sense - "navegando", soy "tractorista".

Actisense is the fast lane to get the relevant N2K data into OpenCPN.
A N2K plug-in based on CanBoat would be more capable for sure.
And a physical device to connect to CAN/J1939 we can't avoid in neither case.

Stevead...

yet another plug-in for virtual instruments would be my proposal. Or even better a stand-alone program listening to data multiplexed from OpenCPN for example.

Hubert
bcn is offline   Reply With Quote
Old 21-02-2019, 10:29   #2754
Registered User

Join Date: Nov 2012
Location: Orust Sweden
Boat: Najad 34
Posts: 2,335
Re: Feature Requests

Quote:
Originally Posted by bcn View Post
....
yet another plug-in for virtual instruments would be my proposal. Or even better a stand-alone program listening to data multiplexed from OpenCPN for example.
Hakan is offline   Reply With Quote
Old 21-02-2019, 12:33   #2755
Registered User
 
transmitterdan's Avatar

Join Date: Oct 2011
Boat: Valiant 42
Posts: 4,930
Re: Feature Requests

Yes, a dedicated plug-in for engine data and other non-navigation related data sources (battery voltage, liquid levels, oil pressure, coolant temp, etc.) is the best idea.
transmitterdan is offline   Reply With Quote
Old 21-02-2019, 12:36   #2756
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,932
Re: Feature Requests

Quote:
Originally Posted by transmitterdan View Post
Yes, a dedicated plug-in for engine data and other non-navigation related data sources (battery voltage, liquid levels, oil pressure, coolant temp, etc.) is the best idea.
Which IMHO changes nothing on the fact that building it on NMEA0183, worse a non standard extension of it, is not a good idea
nohal is offline   Reply With Quote
Old 21-02-2019, 14:44   #2757
Registered User

Join Date: Mar 2011
Posts: 38
Re: Feature Requests

OK, So this is where i can solicit some feedback to help prioritise features for the little used (if any) TwoCan plugin:


1. Linux support via SocketCAN (currently setting up my Linux build environment)

2. Finalise support for AIS an DSC PGN's (Difficult as I've little if any sample data to test against)
3. Refactor code to use the Canboat/Openskipper NMEA 2000 PGN xml or json definition files rather than hardcoding the NMEA 2000 PGN definitions in various plug-in functions.

4. Support write operations on the NMEA 2000 network. Means becoming an active device (ISO Address claim, ISO commands, NMEA product Information etc. of which I already have a .NET implementation) and then opens the pandora's box of what NMEA 183 to NMEA 2000 conversions to support.

ls a tad difficult because if the plug-in requests WANTS_NMEA_SENTENCES, OpenCPN returns all sentences, even those that the plug-in itself set.
5. Dashboard with engine and tank instrumentation derived from the NMEA 2000 PGN's
stevead is offline   Reply With Quote
Old 21-02-2019, 18:46   #2758
Registered User
 
rgleason's Avatar

Join Date: Mar 2012
Location: Boston, MA
Boat: 1981 Bristol 32 Sloop
Posts: 12,207
Re: Feature Requests

I tend to agree with bcn about some of these nmea0183 extensions using the XDR, particularly when they are data from sensors that are not associated with OpenCPN's mission.

For example, I would support an XDR message for mast rotation angle since it could be used by Tactics_pi.

I believe the reason we need to be hard nosed about this is that we do not want to overtax the broadcast messaging system that OpenCPN uses.


Added after seeing stevead about TwoCan:

Of course I am no expert about this, but I am interested in keeping OpenCPN useful for its main tasks which are actually quite broad without adding all kinds of additional sensors. Perhaps there is a good way to do this without affecting the operation?
rgleason is offline   Reply With Quote
Old 22-02-2019, 10:17   #2759
Registered User
 
Gypsylyon's Avatar

Join Date: Feb 2019
Location: Swizerland
Boat: Belliure 39
Posts: 4
Re: Feature Requests

I'm very sorry that the developers of OpenCPN think it's not a good idea to implement more information.
In the new version of OpenCPN, where you can save different configurations would have been fantastic, to have a Plugin where you can view the engine data including fuel consumption.
I still think it would be an excellent improvement for OpenCPN.
Gypsylyon is offline   Reply With Quote
Old 22-02-2019, 10:51   #2760
Registered User

Join Date: Nov 2007
Location: Probably in an anchorage or a boatyard..
Boat: Ebbtide 33' steel cutter
Posts: 4,246
Re: Feature Requests

Quote:
Originally Posted by bcn View Post
There is a general question here: which data should be represented and processed by OpenCPN.
Being a Chart Plotter and Navigation system in my understanding just all the stuff that is needed for navigation and sailing.

A general "glass bridge" or "virtual instruments" approach would does not show up in my list of preferences. More, for me they don't belong into OpenCPN.

I don't care about the water tank or the temperature in the wine cooler for navigation. Or the light switches in the cabin. House bank voltage and temperature. Output of genny and solar. N2K does, as they want to cope with all data on the boat. SK is transport and transparent about the content.

Even engine data are very discussible here.
With you to an extent, though as a tablet user in the cockpit some data is useful to have in the dashboard, on Openplotter I tweak signalk engine temperature into a water temperature NMEA message so it can be seen all the time. Battery voltage would be nice as well. All could be taken care of if someone from the clever club gets round to writing a dashboard which can read signalk...
SigK users must be still quite a small group though..
__________________

conachair is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Yet anothr of my stupid requests Little Otter Multihull Sailboats 2 29-06-2008 23:29
Any requests for pics at Strictly Sail Oakland? Redbull addict Monohull Sailboats 0 30-03-2007 18:33
Capt.Jack requests permission to come aboard canatc1 Meets & Greets 8 10-04-2006 16:54



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 12:41.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2019, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.