Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Old 21-07-2013, 11:22   #1456
Registered User

Join Date: May 2008
Location: Chesapeake Bay
Boat: Corbin 39
Posts: 44
Re: Feature Requests

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
__________________

__________________
corbin39sailor is offline   Reply With Quote
Old 27-07-2013, 07:51   #1457
Registered User
 
rgleason's Avatar

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

Seans's Trimplot plugin is an initial and partial response to Taarnofski's request
Feature Requests

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

__________________
rgleason is offline   Reply With Quote
Old 31-07-2013, 18:10   #1458
Registered User

Join Date: May 2012
Posts: 8
More alarm types

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...
__________________
mattj51864 is offline   Reply With Quote
Old 04-08-2013, 15:23   #1459
Registered User
 
pa36651's Avatar

Join Date: Apr 2010
Location: Sweden
Boat: Hanse 342
Posts: 22
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?
__________________
pa36651 is offline   Reply With Quote
Old 05-08-2013, 17:29   #1460
Registered User

Join Date: Oct 2012
Location: Brighton, UK
Boat: Westerly Oceanlord
Posts: 339
Multicast data connections

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...
__________________
muttnik is offline   Reply With Quote
Old 05-08-2013, 17:58   #1461
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,494
Re: Feature Requests

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
__________________
bdbcat is offline   Reply With Quote
Old 05-08-2013, 18:26   #1462
Registered User

Join Date: Oct 2012
Location: Brighton, UK
Boat: Westerly Oceanlord
Posts: 339
Re: Feature Requests

Quote:
Originally Posted by bdbcat View Post
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 :-)

Quote:
Originally Posted by bdbcat View Post
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
__________________
muttnik is offline   Reply With Quote
Old 07-08-2013, 18:06   #1463
Registered User
 
rgleason's Avatar

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

More Alarm Types Request by mattj51864
Feature Requests

Please see Sean's thread New Watchman Plugin
New Watchman Plugin

Matt''s list will be added to this thread too.
__________________
rgleason is offline   Reply With Quote
Old 12-08-2013, 08:59   #1464
Registered User

Join Date: Mar 2013
Location: Le Bono, Brittany, France
Boat: Oceanis 31, Beneteau 9.5m
Posts: 26
NMEA 183 version 4.0 header support

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]=
__________________
dominig is offline   Reply With Quote
Old 12-08-2013, 18:12   #1465
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,494
Re: Feature Requests

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
__________________
bdbcat is offline   Reply With Quote
Old 12-08-2013, 18:16   #1466
Nearly an old salt
 
goboatingnow's Avatar

Cruisers Forum Supporter

Join Date: Jun 2009
Posts: 13,649
Images: 3
Quote:
Originally Posted by muttnik View Post

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.
__________________
Check out my new blog on smart boat technology, networking and gadgets for the connected sailor! - http://smartboats.tumblr.com
goboatingnow is offline   Reply With Quote
Old 13-08-2013, 08:29   #1467
Registered User

Join Date: Mar 2013
Location: Le Bono, Brittany, France
Boat: Oceanis 31, Beneteau 9.5m
Posts: 26
NMEA 4.0 Spec

Quote:
Originally Posted by bdbcat View Post
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 is offline   Reply With Quote
Old 13-08-2013, 08:34   #1468
Registered User

Join Date: Mar 2013
Location: Le Bono, Brittany, France
Boat: Oceanis 31, Beneteau 9.5m
Posts: 26
NMEA 4.0 TAG Spec

Quote:
Originally Posted by bdbcat View Post
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
__________________
dominig is offline   Reply With Quote
Old 13-08-2013, 13:16   #1469
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,494
Re: Feature Requests

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
__________________
bdbcat is offline   Reply With Quote
Old 14-08-2013, 15:58   #1470
Registered User

Join Date: Oct 2012
Location: Brighton, UK
Boat: Westerly Oceanlord
Posts: 339
Re: Feature Requests

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

__________________
muttnik is offline   Reply With Quote
Reply

Thread Tools
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 30-06-2008 00:29
Any requests for pics at Strictly Sail Oakland? Redbull addict Monohull Sailboats 0 30-03-2007 19:33
Capt.Jack requests permission to come aboard canatc1 Meets & Greets 8 10-04-2006 17:54


Our Communities

Our communities encompass many different hobbies and interests, but each one is built on friendly, intelligent membership.

» More about our Communities

Automotive Communities

Our Automotive communities encompass many different makes and models. From U.S. domestics to European Saloons.

» More about our Automotive Communities

Marine Communities

Our Marine websites focus on Cruising and Sailing Vessels, including forums and the largest cruising Wiki project on the web today.

» More about our Marine Communities


Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 16:55.


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

ShowCase vBulletin Plugins by Drive Thru Online, Inc.