Feature Requests

[prroots]

I just had the opportunity to use OpenCPN V2.3.1 for a crossing of the Gulf of Mexico from Galveston, TX to Marathon, FL; about 800 nm overall. I am runnning OpenCPN under Windows 7 (32 bit) on a Dell E1505 laptop. The only thing connected to laptop was a DC-DC power adapter and a BU-353 hockey puck gps. The gps driver was downloaded from USGlobalsat Corporate. Must install driver and then reboot computer. Windows 7 can't find the driver by itself.

This was my first opportunity to use OpenCPN under realistic conditions for more than a day at a time. The program is spectacular and almost perfectly meets my needs. I appreciate the fact that authors have resisted the temptation to bloat the program and with this in mind, I hesitate to suggest unnecessary changes. I do, however, have a few suggestions listed below from highest to lowest priority:

1. The positive-named mark (ie, anchor watch) feature was very helpful the first night while at anchor awaiting our departure from Galveston the following morning. The negative-named mark feature, in which one names the mark with a negative value, could be even more valuable if the allowable negative value allowed was increased. It seems that currently, any value greater than 1000 meters is ignored. When passing through the region of densely populated oil platforms, this would have been very helpful to gain an early warning when approaching a wide expanse of oil platforms.

2. Allow more than one negative-named mark. Sometimes passing through the high density of oil platforms is like threading a needle. If one could put a negative-named mark on both sides of desired course, it would guard against straying too far left or right. I would say having just two would be a terrific enhancement, but 3 or 4 might satisfy other situations.

3. After running the program for many hours the arrow keys tend to stop working. This was easily fixed by exiting and restarting the program. Since tracking was enabled, the program automatically started a new track. I wonder if upon restarting, the option can be added to append to the most recent track or start a new track? I had hoped to have one continuous track for the entire passage. This option could occur when starting the program if tracking was already enabled (preferred) or as a separate option in toolbox.

4. Change the tracking icon such that background color brightens when tracking is enabled and darkens when tracking disabled. I would like to see at a glance the status of tracking. I've since learned that when tracking is enabled, a track shows up bolded in the Route Manager window which helps. One can also enable tracking here. Bug: shouldn't the 'Start Track' button be greyed out when tracking is already enabled? Or even better, maybe it should be replaced with a 'Stop Track' button?

5. I am using the dashboard which, by the way, is very nice. When I activate a route I expected VMG to show a value, but it's just blank? This is not a significant concern, but was just a bit confusing that the option was there, but it didn't work. I sometimes find VMG to be helpful in trying to determine how far off the wind to point given leeway considerations. In the final analysis, I stopped using the dashboard, since filtering is not available. I recommend that it be added.

6. When at anchor, I enable a new track to keep track of position. The toolbox is set to record a new position every 60 seconds. Nothing new appears? This suggests that a certain distance traveled is actually controlling things despite the option selected. If one is able to record new points on a time basis, one will actually see an arc develop at anchor depending, of course, on how much the wind shifts. Once the arc develops one can set the anchor watch pretty exactly to allow for wind shifts, but set to alarm shortly after a drag.

7. Sometimes a track is very important to me. For example, if one eye-ball navigates through a cut and wishes to repeat it later at night, the prior track is very helpful. If the computer crashes, the track could be lost. For this reason, I would like an option that allows the track to be periodically written to disk at a user-selectable interval.

8. I like to keep a -1000 mark available on the screen and move it around as needed (to alarm if headed towards some obstruction). This works well except that the program occasionally crashes when I move it outside the area of visible chart. I do this to force the program to load a new chart, but it doesn't seem to like that.

It's probably normal that people expect certain things to happen based upon other similar programs they've become accustomed to. In my case, I've used Microsoft Streets & Trips for years as my street charting program. It has a feature whereby you can display a user settable view by dragging the mouse while pressing the right mouse button. This is handy when you wish to fill the screen with a very specific area. I realize this conflicts with the current use of the right mouse button which opens up a context menu. This would certainly be a significant change and I mention it just as a point of discussion rather than a suggestion to see if this possibility would be of interest in the future.

Thanks again for a terrific program. Wish everything aboard performed as well
Pete

[Extemporaneous]

Originally Posted by prroots

2. Allow more than one negative-named mark. Sometimes passing through the high density of oil platforms is like threading a needle. If one could put a negative-named mark on both sides of desired course, it would guard against straying too far left or right. I would say having just two would be a terrific enhancement, but 3 or 4 might satisfy other situations.

Thanks again for a terrific program. Wish everything aboard performed as well
Pete

This is certainly a good idea. I was actually going to post in the past but forgot.
Thanks for posting.

Where I found the limitation of only one negative-named mark was anchors in an estuary (almost in the middle). It was fairly narrow and when the tide came in the flow in the estuary would change.

It would be great to set an alarm for both banks of the river.

Cheers,
Extemp.

[yachtvalhalla]

Zooming in now requires a click for each decreasing zoom level.

Can we have a quick zoom .. such as a loupe ... ala 'other' programs?

Terry

[yachtvalhalla]

Presently the Tides and Currents icons are visible at all times on the toolbar.

Not all areas of the world have this information available.

Please allow the toolbar to be uncluttered by making their visibility an optional setting.

Terry

[sinbad7]

Would it be possible to include small photos in a layered 'Drop mark properties'?
Would be very useful for entering photos of lighthouses,landmarks and approaches.
Could be similar to those of Google Earth.

Tore

[PjotrC]

Originally Posted by yachtvalhalla

Zooming in now requires a click for each decreasing zoom level.

Can we have a quick zoom .. such as a loupe ... ala 'other' programs?

It usually works very nice indeed with a regular mouse or touchpad. On a recent trip I had a touchscreen in the cockpit, which interpreted a prolonged press as a right-click (no way to make a prolonged left-click without dragging).

In this setup OCPN compared very favourably to a commercial program (SailCruisser), which had vary small zooming steps, accelerating only after a prolonged left-press).

An alternative would be to mark an area to zoom to, but this again requires another button, another click...

Piotr

[lutusp]

Dear Group:

I have been working with GPSD, the GPS daemon that runs under Linux. OpenCPN supports GPSD version 2.95 (the current version that is automatically included in new Linux installs).

As it turns out, (a) there is a new version of GPSD (3.2) under development, with more features and able to function with more equipment, but (b) OpenCPN doesn't work with it.

This all came about because I have a Raytheon 125 GPS receiver on my boat. The Raytheon 125 (Raymarine Marine Electronics - Raystar 125 GPS Sensor) is a small unit that mounts on a pole and dutifully provides GPS data. This unit emits NMEA sentences with a prefix of "EC" rather than "GP" (the default), and the current GPSD release version doesn't recognize this prefix.

I brought this to the attention of the GPSD developers, who told me that the version under development (3.2) does handle this prefix (as does OpenCPN when it's not using GPSD).

So I looked into this. The good news is that it's true -- the new version of GPSD knows about the "EC" prefix. The bad news is that the new version of GPSD doesn't work with OpenCPN.

I have a need for multiple outputs from the GPS, so I have been trying to get everything to work with GPSD rather than having one program monopolize the GPS output.

I emphasize again that OpenCPN works with this and similar GPS receivers directly, i.e. when not using the GPS daemon. The problem appears to be mostly with the GPS daemon, not OpenCPN. But pretty soon now, the 3.2 version of GPSD will be released and become the default, and that will prevent operation with OpenCPN.

[HotRod]

Originally Posted by lutusp

Dear Group:

This unit emits NMEA sentences with a prefix of "EC" rather than "GP" (the default)

I'm a bit curious now, I got the same "Smart GPS", and I have fitted many of these GPS'es on new systems. I have never seen anyone with the prefix "EC" instead of "GP".

Also looking at the service manual - I am not able to find the EC prefix.

I don't doubt that you get this from yours, but I cannot understand how this happened...
Is it connected directly to your comport or trough a Raymarine plotter, radar, echosounder???
This would explain the "EC" prefix.

Originally Posted by User Manual

Output Sentences: GPGGA, GPGSA, GPGSV, GPGLL, GPRMC, GPDTM, GPGNS, GPVTG, PRAYA

Connect your computer according to the GPS cable diagram:
Yellow (+) and shield (-) is NMEA out.

[lutusp]

> Output Sentences: GPGGA, GPGSA, GPGSV, GPGLL, GPRMC, GPDTM, GPGNS, GPVTG, PRAYA

Yes, that's what the manual says. But here is what the Raytheon 125 actually emits:

$ECGGA,223120,4801.835,N,12244.748,W,2,07,1.0,2.0, M,-17.0,M,2.0,0000,D*20
$ECGLL,4801.835,N,12244.748,W,223120,A,D*48
$ECRMC,223120,A,4801.835,N,12244.748,W,0.1,103.0,1 51106,022.0,E,D*15
$ECVTG,103.0,T,081.0,M,0.1,N,0.2,K,D*3F

This is with the unit configured to produce NMEA output as explained in the manual.

> Also looking at the service manual - I am not able to find the EC prefix.

Yes -- I had the same experience. It turns out that "EC -- ECDIS is a specialized geographical information system intended
to support professional maritime navigation." as explained in this document:

http://gpsd.berlios.de/NMEA.txt

> Is it connected directly to your comport or trough a Raymarine plotter, radar, echosounder???

It's part of a rather complex arrangement in which my autopilot gets the signal first, so yes, that might explain it -- although it seems sort of baroque that the system would rewrite only the talker prefix in the NMEA sentences. But because this is a relatively common wiring arrangement on boats, it seems wise to accommodate it.

As it turns out, many GPS NMEA sentence parsers simply ignore the first two characters, the dashes in this example:

$--GGA,223120,4801.835,N,12244.748,W,2,07,1.0,2.0,M,-17.0,M,2.0,0000,D*20

And process the information-carrying section without regard to the "talker" designator represented by the first two characters. I have no idea why GPSD didn't do this at the outset, but they're moving in that direction now. It seems that OpenCPN also does this, since it has no problem decoding these sentences when it is allowed to collect them directly from the serial port.

Anyway, to reiterate, it seems that the present GPSD release candidate has some sort of problem communicating with OpenCPN. I have told the GPSD developers of this problem also.

EDIT: You can get the GPSD 3.2 release candidate source by issuing this command in Linux:

$ git clone git://git.berlios.de/gpsd

Then install "scons" (Fedora example):

# yum -y install scons

Then enter the downloaded GPSD source directory and type this:

# scons install (as root)

[HotRod]

As you are connected to a unit in the SeaTalk network, this explains it.
Raymarine units rewrite the NMEA output, but I would strongly recommend that you rewire your computer and connect it directly to the NMEA leads from the GPS itself.

This way you have a better backup solution.. Say if the unit that you currently connect to should break down... Well, you would be without GPS on both the Raymarine and your computer.

The GPS uses GPxxx as prefix, not ECxxx.
It's your Raymarine plotter/radar... that outputs ECxxx

[lutusp]

> This way you have a better backup solution.. Say if the unit that you currently connect to should break down... Well, you would be without GPS on both the Raymarine and your computer.

Yes, except that I have two GPS receivers, one built into the SeaTalk network, one external, and the only way to have easy switchable access to both of them is to connect my laptop to the system's NMEA output rather than the direct output from the Raytheon 125. It occurs to me that many people will have made the same choice for the same reason (redundancy).

In any case, IMHO consumers of NMEA sentences should ignore talker designations. Fugawi certainly does. And, it seems, OpenCPN also does.

> The GPS uses GPxxx as prefix, not ECxxx.
> It's your Raymarine plotter/radar... that outputs ECxxx

I think you're right. I haven't thought about it until now, but that seems right. I'm still better off reading the system's NMEA output, not the direct GPS receiver's output, because this allows me to switch GPS receivers at a moment's notice. I realize this may sound paranoid, but if you read the article linked below, you may understand why I am somewhat paranoid about knowing exactly where I am:

06. Aground

I emphasize I'm not blaming GPS for that silly episode.

[HamishB]

Originally Posted by lutusp

In any case, IMHO consumers of NMEA sentences should ignore talker designations. Fugawi certainly does. And, it seems, OpenCPN also does.

fwiw we get unreliable $IIGLL sentences from our autopilot repeater, both in terms of timestamp lag and only 3 digits behind the decimal point for arc-minutes.

thank goodness our hydrographic surveying software doesn't ignore the talker and lets us pick the $GPxxx sentences Only, or we'd have all sorts of noise in our positioning (like we used to before we figured out what the heck was going on and disabled listening to the other talkers).

one size doesn't fit all, so the best we can do is stay flexible and try not to make locked-in assumptions about other people's boats.


thanks,
Hamish

[lutusp]

> one size doesn't fit all, so the best we can do is stay flexible and try not to make locked-in assumptions about other people's boats.

Yes, fair enough. I guess a predefined list of acceptable talkers, or a displayed list of selectable choices for more technically knowledgeable users, might be a better way to go than accepting them all blindly.

[janp391]

On our sailing boat I take the NMEA from the autopilot (Raymarine) to the computer. From the autopilot the Raymarine compass heading also arrive to the computer. On openCPN I then have COG and HDN arrows. If the compass has a deviation error then the COG and HDN differ.
So I agree if I can choose the talker then I can make the choice what information I want to bee displayed on the computer running openCPN

[Chevron]

Dear all,

first of all, thanks for the program, compared to ChartNavigator it is much more intuitive :-)

I am using OCPN with a laptop and an attached USB Touch TFT (10"), wich is mounted in the cockpit. My biggest concern are my "big" fingers. As I am touching the toolbar buttons, I don't always hit the right one.

Is there a chance to "double" the size of the toolbar? In that case I don't need a stylus any longer.

Happy end of season and all the Best from the Baltic Sea
Chris