Feature Requests

[Sailing Hanse37]

Peter,
seems relatively simple to implement and could be useful. Do i understand it right: panel displays a sort of depth histogram of the past few e.g. minutes (should be configurable of course) ?
After the work on the datavase structure i'll have a look at designing a new panel layout for this sort of display. (since i established a graphic library, specific for the instrument panels, i guess it will take me about 4 hours work)

[Sailing Hanse37]

sorry datavase = database (typo ...)

[petermoree]

Yes you understand it right. When sailing (and specially tacking) in an area with lots of sandbars you will have a clear indication of approaching a steep or a low sloping bank and time your *going about* to an optimum. I use this a lot when tacking among the sandbars here in Holland (and switch to Tsubamis but return to OCPN afterwards).

A steep slope is easier to get off when you run aground ;-))

The settings in Tsunamis are choosable by depth range as well as the distance (backwards distance that is) you can cover with the histogram.


My request for this has been dropped by the current dashboard developper and with the people from PolarCom also.


Peter

[jonasaberg]

• getting a full polar database and auto-correct possibility through recording actual sail data and analysing them

I had some thoughts on this a few years ago. Features that could be good is:
-A turn on/off feature; To only collect data when you think you have a descent trim
or maybe better, collect the data all the time, but have a flag that you can turn on/off for data you want to use for your polars
-A sail config button; Genoa 1,2,3? Which spinnaker? Reefs in the main sail?
-Sea condition. The data will be quite different when going against the wind if there is waves/swell from earlier hard wind that slows the boat down.

• Analysis tool incorporated for NMEA datastream 100% finished

What do you mean by this?

To do:

• 'connect NMEA decode' routine to dial procedures 0% (but easy work)

?? dont understand this either...

Setting up sail polar database 20% (well here is still some work to do)

Do you mean for measure or simulated data?
There are some software's out there (velocity prediction plot programs, vpp - programs) that simulate the velocity...

One is an excel sheet, unfortunately it only runs in Excel2000 if I remember correctly. I think that is in the open domain...

There is another commercial package with open hull & sail data. I can try to find it if this is of interest.

also search for vpp or velocity prediction program - I found at least one source forge project...

Also, I think the IMS certificates are open, at least they used to published in Sweden earlier. From them you can recreate the polars for specific yachts.

Originally Posted by Sailing Hanse37

Recording routine is ok, but analysis for polar has to be done, so finished 20%

It will be interesting to see what you come up with.

[jonasaberg]

you might find this interesting
Timing of the Pre-start Manoeuvre
for an America’s Cup Yacht

http://www.kth.se/polopoly_fs/1.45965!sp_jn.pdf

There are plots of recorded data in it, besides other interesting stuff...

/Jonas

[jonasaberg]

and this...
http://www.polardesigner.org/
a free web based vpp

Sailplanner
a free weather routing prog...get some inspiration maybe? I think some of their ideas are very good - like the ability to place a vpp plot for your boat on the chart at a location/time and have it predict how the yacht can sail then and there based on the grib data. Great for planning.

and maybe a bit off topic...
Sailonline.org - Online Sailing
a sail race game on the net...

All three of these are from the same crowd...

[Scratch]

I am having a difficult time in figuring out exactly how to make OpenCPN work correctly on a Mac. I currently have a usb connected Garmin GPS receiver. I'm not sure if I can even make that work with the Mac so that may be prove to be a seperate problem. Any advice at all will be greatly appreciated.

Thanks,

[Sailing Hanse37]

Hi Jonasaberg,
thxs for the links !!! i will look into these !

You had some questions, and i'll try to answer them:
- collecting data for the sail polar: yes definitely there is a possibility to turn on/off the recording and or analysis. I think it's needed most of all for when you are motoring... If you don't have decent trim, your speed will anyway be too bad as to correct the sail polar. (unless you begin with a fully blank polar, and in that case even the bad -because too slow- data can be used to get the very first polar input (which data of course will be rapidly replaced when you are sailing with a better trim)
- sea condition: well this is a difficult question... Implementation of this is certainly possible and even not difficult, but... at the end you'll get a huge number of polars, each adapted to a different situation... I don't think this comes in handy, so maybe better implementing a % of best condition depending on seastate ?? (actually not yet implemented in the program) I'm open to suggestions on this...
- NMEA analysis: most programs are capable of displaying raw NMEA data. I wanted to get a step further by implementing different extras:
- sentence per sentence decoding to be able to analyse sentences as
they come in. Can be handy to see if you get certain information or
not, and from which instrument it's coming. (also handy for detecting
non standard sentences (and these exist on a bunch of brands !)
- Representation of decoded data: to check whether a certain sentence
contains the needed information.
- Check on errors on the network: i for instance detected a bad bus
termination, by evaluating the percentage of faulty sentences.
- Connect NMEA data: has to do with develoment: the input of the
instrument panels comes from a separate small window with sliders on
it. This is to fully test the graphic system. This small window has to
disappear in the final version. Instead data should come from the NMEA
decoding routine. (routine which decodes the NMEA sentences to
useable data in the program)
- Setting up polar database: this means setting up the database
structure which will be used to store polar data for different polars.
- Setting up the data themselves (so introducing some polars to start
with), is not that difficult for my ship since i have factory delivered
polars. The analysis tool will reproduce afterwards my own polar based
on measured data. I'm curious to compare both

Hopefully this is clear to you ? All extra information you could find can be useful. (I'm not searching this much myself for extra information, as my priority this moment is to have the program fully operational ASAP...

Greetings,
Francis

[Streamsta]

I would like the possibility to import polar diagrams and calculate optimum routes using, GRIBs, polars, tides and currents.

Thanks for a great software!

[skovela]

I would like to have NMEA ouput of COG, position and SOG through autopilot port for displaying them both in the VHF screen and an external repeater display.

Thanks for the excellent OpenCPN.

[HotRod]

Originally Posted by skovela

I would like to have NMEA ouput of COG, position and SOG through autopilot port for displaying them both in the VHF screen and an external repeater display.

Thanks for the excellent OpenCPN.

Why not pull this directly from the GPS? You should not rely on the plotter to function to get such data to your instruments..
Nothing should interfere with GPS and HDG signal to other instruments like Autopilot and navigational repeater displays.
This should work independent of the plotter.

[skovela]

Originally Posted by HotRod

Why not pull this directly from the GPS? You should not rely on the plotter to function to get such data to your instruments..
Nothing should interfere with GPS and HDG signal to other instruments like Autopilot and navigational repeater displays.
This should work independent of the plotter.

I have already that implemented with my GPS12, but I would like to use the laptop for all the functions leaving the Garmin as spare. Currently OpenCPN is taking the GPS signal from a USB dongle and I would like to use that signal for the am purpose.

[Captain Carl]

I just joined the forum, so this is my first post. You have to excuse me if this problem has been adressed before, but I haven't found it. What I am looking for is a way in OCPN to handle NMEA DSC and DSE sentences that my VHF is able to produce. These sentences contain the MMSI and position of boats that transmit this to your MMSI. Using this you can track your buddies very simple, if you can get the data displayed on the screen. I have seen it solved in a multiplexer that converts the NMEA sentences to waypoints ( DSC conversion to waypoints ), but I suppose it would be quite easy to have a similar solution directly in OCPN?

Thanks for a great program!

Captain Carl

[PjotrC]

Originally Posted by Captain Carl

I suppose it would be quite easy to have a similar solution directly in OCPN?

At the suggestion of sea_rescue expressed here a couple of weeks ago I have implemented the GPSGate $FRPOS sentences for buddy tracking. Having done this, I went ahead and implemented the DSC and DSE NMEA sentences, of course in a rather simple version - making it fully compliant with the specification would be a lot of work, perhaps not really needed.

I have a test version running now - it works in the AIS thread, using AIS NMEA stream, showing targets similar to AIS, with specific shapes and descriptions. One difference vs. AIS: GPSGate targets are never marked lost nor removed. To remove them, the user has to close the AIS thread.

If there is some interest in these features, I will gladly package the changes for inclusion in some future version. I would appreciate very much access to some real data for testing.

Piotr

[HotRod]

In OCPN there should be a separate tab for Input and one for Output.
In this tab you should be able to add/delete instruments on different ports, setting instrument baudrate and also marking (weight) as master... E.g. if you have two sources of GPS or Compass/gyro or what ever...
When this have been sorted, it would be easier to sort out the different instruments/sentences in and out...
I know this sounds easy...or, but i guess it will take some time to get around all the different strings... But as every type of instrument is defined by the talker '$xx'XXX there should also be a filter to suppress unwanted strings if e.g. the echo sounder forwards the GPS position (usually with delay).

Personally I don't like the idea to add more programs to handle virtual ports to solve the lack of i/o handeling in OCPN.
More programs = more that can fail + more memory/cpu greed...
Keep it lightweight!