Feature Requests

[corbin39sailor]

Hello,

I am using OpenCPN 3.2 on a Fujitsu q550 tablet in my pilot house and mirroring it onto a Nexus 7 tablet in my cockpit. Everything works great but the tool bar buttons are much too small to use with a 7" finger touch screen. Is there a way to make the tool bar buttons larger (mostly the +, -, and follow boat).

Thanks, Bill

[rgleason]

Seans's Trimplot plugin is an initial and partial response to Taarnofski's request
http://www.cruisersforum.com/forums/...ml#post1161795

These should be entered into Flyspray so they are not forgotten! Taarnofski?

[mattj51864]

I've been using OpenCPN for a few years now and really like the program. It is however weak in a few areas and one of these is alarms. I was able to find some discussion on this in previous posts so I don't believe I'm the only one that feels the need...

Here's my list in order of priority to me:

1) XTE alarm - When sailing with a wind vane, it would be nice to have an alarm go off if you started to wander off course due to a wind change. An XTE alarm would alert you so you could make changes to sails and wind vane direction to get back on course. It might also be the first warning you get if your autopilot quits...

2) Waypoint arrival alarm - Similar to above but will alert you when you need to make a course change. Not as important when using an autopilot, but very important if using something like a wind vane.

3) Watch alarm - A timer (length determined by user) that is reset whenever you interact with the program. If you should doze off while on watch, it will wake you up after a set amount of time. Press a button or click to reset timer at any time. It would be nice to have a warning appear before the alarm sounds, i.e. a dialog box would appear and flash for 30 seconds (user settable) or so before the beeping started to keep from waking everyone up if you forget to click...

4) Boundary Lines / alarms - In Nobeltec I could mark boundary areas that would set an alarm off if crossed. I used them to mark shorelines / obstructions that might be encountered. Very useful when single handing at night when you might dose off... if lines are set at reasonable distance from dangers, gives you notice if you wander too close.

5) Depth alarm - good for both while at anchor and while exploring those uncharted inlets. Useful for detecting anchor drag or if you missed a shallow spot when checking out an anchorage.

6) Weather alarms - many boats have weather stations connected with NMEA output. Wind speed might be nice as a reminder to reef the sails... though I admit, this is usually obvious unless you're sleeping and have less experienced crew on watch... Another would be rapid change in barometric pressure.

7) Alarm clock - alarms set to specific times to signal watch changes or other events.

There are plenty of other alarms that might be nice as well. With all the NMEA data that can be available on a boat these days alarms for engine monitoring (oil pressure, temperature), low voltage, high voltage, high water... I don't have any of these data sources on my boat yet, but maybe someday...

[pa36651]

Hi,

I use the instrument panel showing the speed with digits. Is it possible to add a setting for the number of decimals used, and also add a damping?

[muttnik]

All sensible folk know that broadcast is evil and sooo 20th century, yet lots of "NMEA over IP" software implemented it for data receipt and distribution just because others did and no-one was doing it "properly" with multicast, so what was the point of implementing a connection nothing else could use?

If a popular piece of software like OpenCPN implements multicast data connections, others are bound to follow, allowing us all to bin broadcast use.

If only there was an OPEN standard for this...

[bdbcat]

muttnik...

OK, teach us more.
Why is broadcast "bad" on a local network?

And what was wrong with the 20th century, anyway?
I remember Netscape...

Dave

[muttnik]

Originally Posted by bdbcat

Why is broadcast "bad" on a local network?

Broadcast causes every node on the subnet to interrupt its cpu to process a packet it possibly isn't interested in (the OS will then discard it if nothing is listening for it). Admittedly not really a big deal for low volume traffic on a "network" consisting of a laptop, a router, an ipad and a phone when all but one of those things are producers or consumers of boat data. But it's still, y'know...*wrong* :-). It becomes very wrong with high volume data where lots of network interrupts can unnecessarily hit performance of systems not interested in those data. With multicast, only those nodes running software which asks to join a particular group will see packets sent to that group. The CPU won't get interrupted to process packets sent to groups nothing on the host is interested in (except in the unlikely event that it has signed up to another group which happens to map onto the same *ethernet* multicast address and the IP stack needs to discard it, but let's gloss over that...).

broadcast is so wrong it isn't even in IPv6 :-)

Originally Posted by bdbcat

And what was wrong with the 20th century, anyway?
I remember Netscape...

I was rather fond of it myself, especially the 90s. My next feature request will probably be for an OpenCPN presence in GopherSpace

[rgleason]

More Alarm Types Request by mattj51864
http://www.cruisersforum.com/forums/...ml#post1298909

Please see Sean's thread New Watchman Plugin
http://www.cruisersforum.com/forums/...-102928-6.html

Matt''s list will be added to this thread too.

[dominig]

NMEA 183 version 4.0 introduced a Tag Block which should be ignored by compliant NMEA parser.
For example the multiplexer Miniplex-2 send such tags on the USB interface.
\s:MX21-1*43\$GPRMC,135935.00,A,4738.18939,N,00257.82764,W ,0.035,117.97,050713,,,D*73
While OpenCPN (3.3 version Beta) mark the sentences in green in the NMEA windows the GPS indicator (top right) remains Red showing no signal.
Commecial SW now support that type of header and support is OpenCPN would help.

A longer example file is attached here :
FS#1035 : Nmea 4.0 stream with TAG block do not work tranparently.[0]=&sev[0]=&due[0]=&cat[0]=&status[0]=open&percent[0]=&reported[0]=

[bdbcat]

dominig...

Do you have a link to an official NMEA 4.0 specification?
I can find very little hard information, other than the notion that it is optionally transmitted by ShipModule multiplexers.

What other hardware/software supports receiving and processing of NMEA 4.0 Tag Blocks?

Dave

[goboatingnow]

Originally Posted by muttnik

Broadcast causes every node on the subnet to interrupt its cpu to process a packet it possibly isn't interested in (the OS will then discard it if nothing is listening for it). Admittedly not really a big deal for low volume traffic on a "network" consisting of a laptop, a router, an ipad and a phone when all but one of those things are producers or consumers of boat data. But it's still, y'know...*wrong* :-). It becomes very wrong with high volume data where lots of network interrupts can unnecessarily hit performance of systems not interested in those data. With multicast, only those nodes running software which asks to join a particular group will see packets sent to that group. The CPU won't get interrupted to process packets sent to groups nothing on the host is interested in (except in the unlikely event that it has signed up to another group which happens to map onto the same *ethernet* multicast address and the IP stack needs to discard it, but let's gloss over that...).

broadcast is so wrong it isn't even in IPv6 :-)

I was rather fond of it myself, especially the 90s. My next feature request will probably be for an OpenCPN presence in GopherSpace

Given that most CPUs handle Ethernet traffic in a software stack , interrupting the CPU isn't a big factor , especially with reasonable ring buffers. Broadcasting is inherently bandwidth consuming , but the CPU overhead isn't affected much.

[dominig]

Originally Posted by bdbcat

dominig...

Do you have a link to an official NMEA 4.0 specification?
I can find very little hard information, other than the notion that it is optionally transmitted by ShipModule multiplexers.

What other hardware/software supports receiving and processing of NMEA 4.0 Tag Blocks?

Dave

Dave,

You will find a spec following that link (see chapter 7 pages 27)
http://www.ssi.tu-harburg.de/doc/web...vember2008.pdf

It seems that the main player (such as MaxSea) have implemented the support of the Tag Block. To be honest it's quite easy to just ignore them by a bit of code as it's a simple "/ " which must follow a new line.

Dominig

[dominig]

Originally Posted by bdbcat

dominig...

Do you have a link to an official NMEA 4.0 specification?

Dave

Dave

Interresting: The NMEA spec are not free and linked to licence restriction but the erratum are not

You will find here the description of the final Tag Block published by the NMEA and free of access in this erratum:
http://www.nmea.org/Assets/0183_erra...lock_final.pdf

Dominig

[bdbcat]

dominig....

Thanks.
Yes, easy to implement.

<Rant>
But I'm being fussy here to make a point about incremental interface design.

NMEA 4.0 introduces features that not only enhance functionality of the interface (that's good), but break immediately many (most?) of the fully compliant NMEA 3.x implementations in the field. And that's bad.

If you send an NMEA 4.0 string to a navigational device built prior to 4.0, which was working just fine at 3.x, it probably will not be recognised. And it may legitimately discard the entire sentences as an incorrectly formatted string, according to NMEA 3.2. And those devices are still being sold.

A bit like coming up with a brand new, non-polluting gas pump fill nozzle that does not fit my favorite car which is only 5 years old. In the real world, as actually implemented, making the new fill hose smaller was OK, but making it larger would have been "bad design".

So, I say it is poor incremental design.
But I guess we have gotten accustomed to this kind of upgrade in the computer business. PS-2 keyboards migrating to USB interface is a good example. A new motherboard completely broke my favorite keyboard, but we accept this as progress.

</Rant>

All this is not your fault, and I appreciate your bringing this to the table. We will get the feature implemented at the soonest opportunity.

Thanks
Dave

[muttnik]

Originally Posted by goboatingnow

Given that most CPUs handle Ethernet traffic in a software stack , interrupting the CPU isn't a big factor , especially with reasonable ring buffers. Broadcasting is inherently bandwidth consuming , but the CPU overhead isn't affected much.

Much as I hate to disagree in a public forum...I think you may have got the wrong end of the stick with this. Unless you are running some perverse OS which keeps its network cards in promiscuous mode permanently. or I've misinterpreted you completely in which case apologies.

An ethernet card wlll nudge the cpu to run its driver when it has some work for it to do (give or take some interrupt coalescing). Broadcast packets need to be processed in software. Multicast packets for a group the card is not subscribed to don't.

The overhead of nmea broadcast traffic bridged from a 4800 baud serial link is trivial, so it's not a big deal for most open CPN users. It can be a huge deal for, say, financial market data applications (as anyone who dealt with trading floor broadcast storms in the 90s will know :-).

But unnecessary processing is always just kinda wrong to those who see laziness as a virtue.