Feature Requests

[hellosailor]

"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)

[bdbcat]

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?....

[muttnik]

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.

[rgleason]

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.

[muttnik]

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.

[bdbcat]

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

[muttnik]

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

[radni]

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.

[SUNSHINESAILOR]

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

[brianalex]

Originally Posted by SUNSHINESAILOR

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

[SUNSHINESAILOR]

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

[brianalex]

Originally Posted by SUNSHINESAILOR

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.

[muttnik]

Originally Posted by bdbcat

<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 :-)

[titaantje]

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

[dlymn]

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