Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rating: Thread Rating: 4 votes, 5.00 average. Display Modes
Old 14-08-2013, 19:24   #1471

Cruisers Forum Supporter

Join Date: Apr 2006
Posts: 12,106
Re: Feature Requests

"Broadcasting is inherently bandwidth consuming , but the CPU overhead isn't affected much. "
Dave, the impact of one packet maybe trivial given the speed of today's CPUs. However, I have (some time ago) actually spec'd and installed NICs that had dedicated processor onboard, so that they could handle packets without interrupting and slowing down the primary CPUs in a server. AFAIK the situation hasn't changed, every packet is one more task that interrupts the CPU, which has to stop, juggle priorities, toss out the trash, go back to what it was doing. And no matter how fast it does all that, it is still something to slow down the CPU. All that trivial junk eventually adds up, so putting it on a system when it isn't needed is simply poor form, at best. And of course, every extra packet adds to the odds of collisions and slowing down the entire net. Bad form again.

But of course, bad form, sloppy code, excess and waste, that's all pretty much the gold standard for programming these days, isn't it? (sigh)
__________________

__________________
hellosailor is offline   Reply With Quote
Old 14-08-2013, 20:43   #1472
Marine Service Provider
 
bdbcat's Avatar

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

HelloSailor....

Not my quote, but anyway.....

Since we are talking philosophy.....

Moving to your quote:
"so putting it on a system when it isn't needed is simply poor form, at best"

Ahh, but sometimes it is needed for legacy system support. So we enable it. Poor form, IMHO, happens when designers render obsolete entire classes of equipment and interfaces because they are thought to be not modern (enough). Who speaks for the users in this case?

We almost never have the opportunity to completely discard an existing interface in this business. But this need not preclude the coexistence of an older functional interface with a new, more modern concept.

ipv4/v6 is the poster child for this idea. ipv4 will live for decades more, and may never really die. Way too much installed equipment. We should also give the designers of ipv4 some credit. It was state of the art at its time, and it still works.

And so does broadcast NMEA.

My 2 cents...
Dave

p.s. I will agree to incinerate every network hub and replace with a switch/router in my domain, so at least directed TCP traffic doesn't hit every NIC in the domain for no good reason. How's that?....
__________________

__________________
bdbcat is offline   Reply With Quote
Old 16-08-2013, 05:20   #1473
Registered User

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

Just to be clear, I wasn't at all suggesting replacing broadcast, just adding multicast as another option. Fact is that other things which OpenCPN needs to talk to often support it, but almost nothing (except proprietary stuff we don't have the specs for) supports multicast which makes broadcast the hands-down winner as a feature. Having said that, it's a vicious circle. We're stuck with an inferior data distribution mechanism because early implementers of NMEA-0183-over-IP wrote some cheap 'n' dirty code and everyone has followed suit because it's all about compatibility. Obviously, like a poor algorithm (hmm...now if only I was clever enough to do sub and superscripts I could chuck some big-O notation in here :-) it doesn't practically matter for small n.

My hope was that as probably the single most popular piece of open source navigation software, if OpenCPN supported NMEA-0183 over multicast IP, other small/open source developers would follow suit.

Wouldn't it be nice to have an actual standard to code against, as opposed to some de-facto hacks to put a serial line protocol over IP? Obviously discounting IEC 61162 or anything published by the NMEA which we couldn't legally use for open source even if we were to pay for it.
__________________
muttnik is offline   Reply With Quote
Old 16-08-2013, 06:04   #1474
Registered User
 
rgleason's Avatar

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

This is totally above my head, because I don't understand all of it, but are you suggesting that bdcat and others spend time developing a new standard that others may to follow, when Opencpn is "open" and supported by volunteers. There are many projects that could be done and not enough resources. Is this something that really needs doing? How will it help us all use Opencpn? If it will make Opencpn markedly better please explain why. Also, since you know so much about it, maybe you could help?

Thanks.

PS: If you've already helped, please don't get angry at me! Just trying to understand why we need it.
__________________
rgleason is offline   Reply With Quote
Old 16-08-2013, 07:17   #1475
Registered User

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

You don't need it: I think I stressed that. In fact if any OCPN mac or linux users really want to use multicast (over IPv4 or IPv6) they could just use kplex as a shim layer (this is my minor open source contribution in this area). There was no intended suggestion that bdbcat or opencpn developers develop a new standard. The negative aspect of a lack of standard was an (additional) observation. I would certainly love to contribute to development of such a standard, but unless I change my name to "Eric Raymond" or something, I might lack the credibility to get it adopted by anyone.

I'd contribute code to opencpn but am a little concerned that my lack of proficiency with C++ and lack of familiarity with wxWdigets might not make me suitably qualified.

Multicast was really only a suggestion of how OCPN might, as a fine and popular piece of software, steer the de-facto implementation conventions in a better way. Certainly wasn't a "demand" and I apologise if it was misinterpreted as such.
__________________
muttnik is offline   Reply With Quote
Old 16-08-2013, 10:51   #1476
Marine Service Provider
 
bdbcat's Avatar

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

muttnik....

Thanks for the comments. Really.

Couple of things:
1. OCPN currently is getting about 3000 downloads per week, so we have at least some leverage in the ECS space.

2. Even if you don't feel up to working directly with the C++ code, architectural and design direction help would be greatly appreciated. As you know, this is where the hard stuff is anyway when designing interfaces.

So, if you would like to start a thread with some design notes for a new multi-cast NMEA protocol, I'd contribute to it. And we could get the code written somehow. And maybe we could hack gpsd to conform, and then submit that patch upstream to gpsd project, and get somewhere useful.

Think about it

Thanks
Dave
__________________
bdbcat is offline   Reply With Quote
Old 16-08-2013, 13:34   #1477
Registered User

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

Thanks Dave:

FS#1063 with patch which compiles on linux to show the general idea for basic multicast support but needs brushing up for windows portability by someone who actually knows what they're doing with C++ and WX.

I'll save starting a thread on the bigger question an open standard for nav data transmission over IP until I've come up with enough concrete ideas for a starting point for everyone to shoot down in flames. May be a couple of months but if you don't think it's a stupid idea I'll give it a whirl
__________________
muttnik is offline   Reply With Quote
Old 22-08-2013, 15:30   #1478
Registered User

Join Date: May 2012
Posts: 3
Feature Requests

Hi.

Measure lines

Dont know if this has been meantioned before. Did a search, but nothing came up.

Would be very handy for planning to have the possibility to set up more than one or several individual measure lines. In same easy way as today from right click or F4. Deleting either by selected or all.

OCPN is a very nice and easy to work with programm.
__________________
radni is offline   Reply With Quote
Old 24-08-2013, 01:57   #1479
Registered User

Join Date: Dec 2012
Location: Australia
Boat: Bav 47 Ocean
Posts: 19
Re: Feature Requests

G'day,

firstly, congratulations on your excellent product!

in my short (but intense) experience with OCPN while sailing the whole east coast of Oz i came across a few issues...

First is the inability of a raymarine SPX autopilot to go into "Track Mode" on the NMEA data supplied by OCPN - is there something i can do to make it work?

Second is another wishlist item - to be able to have user-defined waypoint names - it seems that NMEA 2000 and Actisense don't like non-numeric (alpha) characters in waypoint names.

the others are bugs that i'm still trapping... and will report once i can recreate them.

thanks again.
cheers,
Ian
__________________
SUNSHINESAILOR is offline   Reply With Quote
Old 24-08-2013, 05:13   #1480
Registered User

Join Date: Jan 2010
Location: Thunder Bay, On
Boat: C&C Landfall 38
Posts: 17
Re: Feature Requests

Quote:
Originally Posted by SUNSHINESAILOR View Post
G'day,

.............. First is the inability of a raymarine SPX autopilot to go into "Track Mode" on the NMEA data supplied by OCPN - is there something i can do to make it work?.................

thanks again.
cheers,
Ian
Hi Ian
I have an SPX10 autopilot and had the same issue. The SPX track feature requires magnetic variation. My RMC sentence was missing the magnetic variation field because my GPS (BU353 puck) does not output variation.
Installing the WMM plugin added variation to the RMC sentence and solved the problem.
Hope this helps.

Brian
__________________
brianalex is offline   Reply With Quote
Old 24-08-2013, 05:38   #1481
Registered User

Join Date: Dec 2012
Location: Australia
Boat: Bav 47 Ocean
Posts: 19
Re: Feature Requests

thanks Brian,

when I get back to the boat i will load WMM.

Do you have a P70 AP control head? Have you had any issues when set to TRUE compass headings?

cheers,

Ian
__________________
SUNSHINESAILOR is offline   Reply With Quote
Old 24-08-2013, 06:49   #1482
Registered User

Join Date: Jan 2010
Location: Thunder Bay, On
Boat: C&C Landfall 38
Posts: 17
Re: Feature Requests

Quote:
Originally Posted by SUNSHINESAILOR View Post
thanks Brian,

when I get back to the boat i will load WMM.

Do you have a P70 AP control head? Have you had any issues when set to TRUE compass headings?

cheers,

Ian
No. I have the ST70 head and I'm believe it is set to TRUE. No problems here.

Brian

p.s. I almost never use the tracking feature as I find the correction back to course is too abrupt (about 30 degrees) for me.
__________________
brianalex is offline   Reply With Quote
Old 30-08-2013, 06:23   #1483
Registered User

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

Quote:
Originally Posted by bdbcat View Post
<Rant>
[...]
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.
[...]
</Rant>
I'm guessing the NMEA might counter that ocpn's fault (and my own code makes the same mistake) is in treating <CR><LF> as a delimiter rather than a terminator. Treat "!"/"$" as the start of a sentence, <CR><LF> as the end and discard everything between end and start and you're fine. Of course as open source developers who couldn't legally use the spec even if we bought it, we can't be expected to know the subtleties of the wording

For lots of other reasons I still think TAG blocks are worth a rant :-)
__________________
muttnik is offline   Reply With Quote
Old 14-09-2013, 08:15   #1484
Registered User
 
titaantje's Avatar

Join Date: Jan 2012
Location: Netherlands
Boat: North Beach 24
Posts: 23
OpenCPN running on smartphone

Probably this is a competely off-topic request.
I would be very happy with OpenCPN on my smartphone.
I have OpenCPN running on my (linux) laptop inside the cabin.
During heavy weather circumstances I can't keep moving inside and outside the cabin.
In the cockpit the OpenCPN-app on my (waterproof) smartphone, preferable with AIS data (over IP, WIFI), would be very helpful.

titaantje
__________________
titaantje is offline   Reply With Quote
Old 14-09-2013, 15:27   #1485
Registered User

Join Date: May 2010
Posts: 521
Re: OpenCPN running on smartphone

Try VNC it allows you to see and control a computer remotely. Works with andoid Windows.Don't kknow about linux
__________________

__________________
dlymn 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 14:46.


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.