Feature Requests

[rgleason]

I've been watching K Box https://github.com/sarfata/kbox-firmware
and https://www.tindie.com/products/sarf...-boat-gateway/ which is fairly expensive, but there are others
See the Wiki
https://www.vyacht.net/new/feature/2...k-support.html
Marine electronic products from Yacht Devices

[transmitterdan]

My point about hardware is that there are virtually no PCs or MACs with CAN interface hardware. And I can't think of any navigation data that is only available in NMEA2K but not NMEA0183. So given that hardware is required to convert CAN to something a PC can receive why not let that hardware also convert the data to NMEA0183? There are many devices that do that already available. I just don't see the justification for adding NMEA2K message handling to O when that effort would give very limited if any improvement over what O does today. There are many higher priority things O could use IMO. Dashboard needs more modern and user selectable instrument types. Would be nice if instruments had more color and better visual presentation. The instrument system needs a consistent class structure with more user friendly panel layout tools. For example, would be nice to just have various displays and data sources. Let the user connect any data source to any display type. Then there would be lots less for developers to do and endless ways to display data. For example, if we had display types as follows:

History graph
Dial (selectable scale limits)
Digital readout

That would encompass 95% of all instrument display needs. If one connected wind speed to a history display and a dial we would know wind speed now and in the past. Would also be nice to connect multiple data sources to an instrument type. So a dial could display wind direction and also digitally display speed. Same for heading and STW. By making it completely up to the user what data feeds what display type the dashboard could be much simpler in my view.

[rgleason]

For example, would be nice to just have various displays and data sources. Let the user connect any data source to any display type. Then there would be lots less for developers to do and endless ways to display data. For example, if we had display types as follows:

History graph
Dial (selectable scale limits)
Digital readout

[rgleason]

Vote for TDan's Dashboard Suggestion
https://opencpn.org/flyspray/index.p...s&task_id=2327

[kevinvh]

Originally Posted by bdbcat

This thread is reserved for discussion and input of feature requests for upcoming versions of opencpn.

Anything is fair game here, although the goal ought to be to arrive at some consensus of a manageable list which may be implemented in a reasonable time frame.

I'd like to see some back and forth discussion here, and something more than "I want opencpn to ....."

I will be monitoring this thread casually. I will not be arbitrating. I will choose what to work on for the next release based upon some loose metric involving effort of implementation vs affected population. Not everything will get done, obviously.

Looking forward to input.....
Dave

Hi Dave,

I discovered OpenCPN only recently and it has got me hooked. I am particularly interested in Weather Routing and have spent a lot of time testing the latest weather routing plugin on a MacBook Pro.

There is on common feature lacking with OpenCPN - a Window Menu where one can bring up any of the hidden windows that are open - this is a serious problem.

Using Weather Routing the "Weather Routing - WeatherRoutingConfiguration.xml" window overlays the chart and you see very little of the chart. There is no way of hiding or shrinking the window any further to display all of the chart.

Similarly, other windows overlay the chart and cannot be hidden, where as there are even more windows that are hidden behind the chart window and you cannot tell if they are open or not.

Please give us a Window Menu (as with all other Mac applications) that allows us to display whatever window we want on top.

Best regards - Kevin Hiscox

[seandepagnier]

Originally Posted by kevinvh

Hi Dave,

Using Weather Routing the "Weather Routing - WeatherRoutingConfiguration.xml" window overlays the chart and you see very little of the chart. There is no way of hiding or shrinking the window any further to display all of the chart.

Consider clicking the toolbar icon for weather routing to show/hide the weather routing windows.

Similarly, other windows overlay the chart and cannot be hidden, where as there are even more windows that are hidden behind the chart window and you cannot tell if they are open or not.

There are some recent changes to weather routing that are meant to fix this issue on macosx in future versions.

[nohal]

Originally Posted by boat_alexandra

There are some recent changes to weather routing that are meant to fix this issue on macosx in future versions.

I would rather call it "somewhat improve", to actually fix it in a way that would not drive people crazy will take some more effort after we switch to wx3.1/3.2 on macOS.

Pavel

[seandepagnier]

Originally Posted by nohal

SignalK
It makes absolutely no sense to support anything else in the future. If you have some

We need an improved way for plugins to get sensor data so they don't individually parse nmea anymore anyway, and signalk is a logical way to do this.

OpenCPN's NMEA 0183 requirement will of course not exist once we implement SignalK.

We can probably just convert nmea0183 to signalk within opencpn in one place, and internally use signalk everywhere.

Where is your work in progress?

my pypilot_pi plugin uses signalk to configure the autopilot

Originally Posted by bcn

As of today there are at least two solutions for N2K that work out of the box:
- the Actisense N2K-NMEA0183 serial gateways (and its clones)
- OpenPlotter on a RasPi plus a CAN gateway delivering a NMEA0183 stream via Ethernet/WiFi or serial.
With all the limitations of NMEA0183 of course.
Even with SK implemented for OpenCPN there will be always the requirement for some hardware device to connect to N2K.

What, if anything is available in n2k that can't be translated into nmea0183? I believe openplotter has n2k -> signalk conversion builtin, but I have no interest in n2k. I have no hardware that uses it.

This will not be something OpenCPN can provide. Similar to the myriad of COM-USB converters. Most will work, some might give problems...

SignalK:
SK is embracing such a wide range of sensors and data sources that implementing a SK client shall not imply to use all these data within OpenCPN.

It has subscriptions, so any unsupported data or data that isn't needed doesn't have to even be sent to opencpn. When you add the gauge to the dashboard, then opencpn requests the data to be sent.

Right now, as you open and close the status/configuration/control/gains windows in my pypilot plugin, you can see the network load changing. This was not possible with nmea0183.

Being a "ChartPlotter and Navigation" software, a careful selection of the data required for this purpose shall be taken. And this selection shall be flexible.
Data like "Exhaust temperature", "Fuel tank level", "Voltage solar panel", "Humidity in salon" do not add information for navigation.

Using imagination I can find any of that data being useful for navigation.

Consider the solar panel voltage. It can logged based on course angle, sails, and the position of the sun. Over time, a multidimensional map can be computed, and a plugin could then inform you what your solar output will likely be over the route as you tweak it to balance solar output with getting where you want.

Keep it simple and concise.

You can keep it simple by not using sensors.

Everyone has different ideas of what they want, so it's best we just support everything.

SK provides already a big number of plugins on the server and client side, such as Virtual Instruments giving a flexible (glass) dashboard solution running in any of the web browsers.
There is even a plotting app for raster charts being boiled.
Always browser based on the client side.

If you want inefficient limited functionality, then go ahead and run it in the browser.

javascript has ruined the web. I disabled javascript in my browser, now it stopped crashing and I can open 100 tabs which used to be completely impossible. Many sites work better, and much faster without javascript. Mostly javascript is used to mine your data, and waste your cpu, and detect your ad blockers... much better not to have it.

The signalk-node-server is unfortunately implemented in javascript. It's a good start, but not a good long term solution. I implemented a signalk server instead in python which I used for my autopilot.

[nohal]

Originally Posted by boat_alexandra

Where is your work in progress?

In the signalk branch in my repo. 1100+ commits behind master and behind my local WIP. It makes very little to no sense to do something with it now as I already said. Wait for the O5 beta cycle, please.

[wdkester]

Don't know if this is a bug or a feature or both!

Layers

I running a w7 64bit system opencpn 4.8.0

I have only used temporary layers but decided to make a permanent layer of anchorages.

When I look in C:\ProgramData\opencpn\ there is no layers folder as per the help file. I added a folder titled "layers" and it works fine.

Either the documentation needs to be changed or the code.

Also, how about adding an Import button (in addition to the Temporary layer button) so that one does not have to create a folder and copy a file to that folder. The documentation shows an Import button but the program does not.

[rgleason]

I have changed this appropriately for Layers.
https://opencpn.org/wiki/dokuwiki/do...andling_layers

However the title "Handling Layers" is not specific enough in my opinion to be any help in searches about the problem. The user must physically create a directory called "layer" in the right user directory. How should this be titled for searches?

"Layer Directory for Automatic Loading"

[Jon Hacking]

Originally Posted by wdkester

...Also, how about adding an Import button (in addition to the Temporary layer button) so that one does not have to create a folder and copy a file to that folder. The documentation shows an Import button but the program does not.

I would vote for this. It would enhance usability nicely, as the current method is pretty arcane, especially since the ProgramData folder is generally hidden. It takes a Power User to do it currently, which many cruisers are not. We hand out a lot of tracks, & many folks who use them don't really know how, & import the tracks, which messes up their own track history. An "Add Layer" (or equivalent) button that

• creates the Layers folder if it isn't already there, &
• opens up a file dialog to copy GPX files to that folder

would be nice.

[wdkester]

Originally Posted by rgleason

I have changed this appropriately for Layers.
https://opencpn.org/wiki/dokuwiki/do...andling_layers

However the title "Handling Layers" is not specific enough in my opinion to be any help in searches about the problem. The user must physically create a directory called "layer" in the right user directory. How should this be titled for searches?

"Layer Directory for Automatic Loading"

That would help, and at the end of the first paragraph of the Layer section you might add "Layers may be imported temporarily or permanently." And have a link to the that section.

[rgleason]

Thanks wdkester. Is this any better? Can it be improved and made clearer?
https://opencpn.org/wiki/dokuwiki/do...manager:layers

[wdkester]

Originally Posted by rgleason

Thanks wdkester. Is this any better? Can it be improved and made clearer?
https://opencpn.org/wiki/dokuwiki/do...manager:layers

Excellent.

Under "Layer Directory for Automatic Loading of Permanent Layers" the second bullet could read "Layers that are saved in a directory called “layers”(created by the user) in the same location as your config “opencpn.ini” file are automatically loaded on start of OpenCPN. These layers are known as “Permanent Layers”.