Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Search this Thread Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Old 18-01-2018, 06:20   #2536
Registered User
 
rgleason's Avatar

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

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
__________________

rgleason is offline   Reply With Quote
Old 19-01-2018, 05:55   #2537
Registered User
 
transmitterdan's Avatar

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

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.
__________________

transmitterdan is offline   Reply With Quote
Old 19-01-2018, 16:35   #2538
Registered User
 
rgleason's Avatar

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

Quote:
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 is offline   Reply With Quote
Old 21-01-2018, 12:57   #2539
Registered User
 
rgleason's Avatar

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

Vote for TDan's Dashboard Suggestion
https://opencpn.org/flyspray/index.p...s&task_id=2327
rgleason is offline   Reply With Quote
Old 23-01-2018, 15:11   #2540
Senior Cruiser

Cruisers Forum Supporter

Join Date: Jan 2018
Location: Gold Coast, Australia
Boat: Lagoon 500
Posts: 82
Re: Feature Requests

Quote:
Originally Posted by bdbcat View Post
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
kevinvh is offline   Reply With Quote
Old 23-01-2018, 15:38   #2541
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 3,246
Re: Feature Requests

Quote:
Originally Posted by kevinvh View Post
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.
Quote:
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.
boat_alexandra is offline   Reply With Quote
Old 23-01-2018, 15:43   #2542
Registered User

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

Quote:
Originally Posted by boat_alexandra View Post
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
nohal is offline   Reply With Quote
Old 23-01-2018, 16:18   #2543
Registered User
 
boat_alexandra's Avatar

Join Date: Aug 2009
Location: chesapeake bay
Boat: bristol 27
Posts: 3,246
Re: Feature Requests

Quote:
Originally Posted by nohal View Post
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.

Quote:
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

Quote:
Originally Posted by bcn View Post
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.
Quote:
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.
Quote:

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.
Quote:
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.

Quote:
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.
boat_alexandra is offline   Reply With Quote
Old 23-01-2018, 16:40   #2544
Registered User

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

Quote:
Originally Posted by boat_alexandra View Post
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.
nohal is offline   Reply With Quote
Old 05-02-2018, 08:57   #2545
Registered User

Join Date: Jan 2007
Location: Minneapolis
Boat: Irwin 37 CC
Posts: 665
Re: Feature Requests

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.
__________________
David Kester
Pegasus IV
wdkester is offline   Reply With Quote
Old 05-02-2018, 14:38   #2546
Registered User
 
rgleason's Avatar

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

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"
rgleason is offline   Reply With Quote
Old 05-02-2018, 22:18   #2547
Registered User
 
Jon Hacking's Avatar

Join Date: Sep 2010
Location: Currently cruising Southern Indonesia, heading for peninsular Malaysia
Boat: Wauquiez 45' (now 48') catamaran
Posts: 565
Send a message via Skype™ to Jon Hacking
Re: Feature Requests

Quote:
Originally Posted by wdkester View Post
...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.
__________________
-- Jon Hacking s/v Ocelot
Jon Hacking is offline   Reply With Quote
Old 06-02-2018, 06:58   #2548
Registered User

Join Date: Jan 2007
Location: Minneapolis
Boat: Irwin 37 CC
Posts: 665
Re: Feature Requests

Quote:
Originally Posted by rgleason View Post
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.
__________________
David Kester
Pegasus IV
wdkester is offline   Reply With Quote
Old 06-02-2018, 09:34   #2549
Registered User
 
rgleason's Avatar

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

Thanks wdkester. Is this any better? Can it be improved and made clearer?
https://opencpn.org/wiki/dokuwiki/do...manager:layers
rgleason is offline   Reply With Quote
Old 07-02-2018, 06:33   #2550
Registered User

Join Date: Jan 2007
Location: Minneapolis
Boat: Irwin 37 CC
Posts: 665
Re: Feature Requests

Quote:
Originally Posted by rgleason View Post
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”.
__________________

__________________
David Kester
Pegasus IV
wdkester 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 22:56.


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

ShowCase vBulletin Plugins by Drive Thru Online, Inc.