Sending waypoints/routes over IP

[rgleason]

B,
You're doing great. Keep the idea discussion going so the Tracker request is pretty well figured out! Is there some clever way to elimnate the loop back problem using one Opencpn? Either filtering or whatever.
Thanks.
Rick

Opencpn could use two connect  channels perhaps. 
Or some way to tag data going out and then filter it coming in, or  perhaps a filter that eliminates the same sentence within a certain  period.

Yep.

But we need to use a flyspray to get it.

I will have a look at these spryfly things tomorrow and write two requests:

- one for enabling IP as 'send WPT to ...' ,
- one for enabling WPL receipt and display,

I think one more for allowing GGL or RMC to AIS sentence conversion. This has been discussed before too. (To enable a second object to be tracked).

Would be nice to have a bit more advanced nmea multiplexer on OpenCPN  too - if anything future networking will be more advanced rather than  less.
Cheers, b.

[barnakiel]

Originally Posted by rgleason

Is there some clever way to elimnate the loop back problem using one Opencpn?

Yes. The cleverest way is to allow for any interface as 'send to' rather than only COM interfaces.

There is no problem with loopback in OpenCPN. There is problem with net interface not being an option when sending waypoints and routes.

Killing the bridge over the two COMs will kill the loopback. I can test this later. But it is a super lousy way, not a clever way. Because every time it loops, it gets forwarded to the net interface too.

Some devices will take the WPTs as many times as you send them, creating multiple copies of same WPTs. I think stuff is sent every second or so over OpenCPN multiplex.

I have registered with the feature tracker. Waiting for some kind of code email now. Will try to write the requests later tonight.

Cheers,
b.

[muttnik]

Originally Posted by barnakiel

This particular problem I had was indeed kplex not sending back until I implicitly declared loopback on TCP interface.

Hmm...that doesn't sound right. So you have a server X and clients A and B. A sends to X but then B doesn't receive from X?

Or do you mean that you were making one connection A->X and what you wrote from A wasn't being re-read by A?

Sorry to be confused: I don't think this was one of your scenarios above (which were UDP).

Also sorry to wander off-topic but if this is the case it sounds like a (possibly platform-specific) bug in kplex I should fix....

[barnakiel]

Method X ;-)

Try the same as specified by Hakan above, except use 1 OpenCPN only and do not link virtual port A to OpenCPN.

The setup is then:

- OpenCPN connected to a net port,
- virtual COM ports (say A and B), bridged,
- connect port B only to OpenCPN.

Now go into OpenCPN click the waypoints you want transferred and specify "send to COM A" (!!! NOT Com B !!!)

Bingo!

OpenCPN allows you to send WPTs to a virtual COM that is not connected to OpenCPN. And now this port is bridged and we get the WPT echoed back on the virtual COM port that is connected to OpenCPN. The rest of the story is known.

Perhaps someone can test this on their setup. Esp. if Hakan could, as he has the whole setup already in place.

It works for me great and requires only one mod: fire up a bridged pair of virtual COMs before the operation.

Cheers,
b.

[barnakiel]

Originally Posted by muttnik

Hmm...that doesn't sound right. So you have a server X and clients A and B. A sends to X but then B doesn't receive from X?
(...)
Also sorry to wander off-topic but if this is the case it sounds like a (possibly platform-specific) bug in kplex I should fix....

1) This is so and 2) no, there is no a problem with kplex - the manual says clearly loopback must be specified explicitly as no loopback is default on TCP interfaces.

It was not part of the initial thread content but I brought it in as I did not get waypoints displayed on receiving (remote) OpenCPN instance(s). Only later, with exquisite support from Pavel, I learned that OpenCPN will not display incoming WPL sentences no matter what.

But we learned how to get it done from OpenCPN to say a remote GPS.

Look up my "Method X" post abopve which may allow us to apply Hakan's solution while doing everything from one OpenCPN instance, with a virtual bridged COM set.

My OpenCPN install is on Win8.1- I can test again on Win XP SP3 later and on Android. Perhaps someone on Linux could chime in.

Cheers,
b.

[Hakan]

b.

re:- OpenCPN connected to a net port,
- virtual COM ports (say A and B), bridged,
- connect port B only to OpenCPN.

Now go into OpenCPN click the waypoints you want transferred and specify "send to COM A"

Yes - works fine (of course ) WPs and routes are nicely transferred to network and since A is not "seen" by O, no endless feedback. A straight forward solution to test if the IP message can be collected by the Garmin(?) gadget.
If it works and you want to skip OCPN multiplexer and pay a fee there are a couple of virtual serial to IP out there. (The free one used to be limited to one serial bridge only)
Håkan

[rgleason]

b. wrote:

The setup is then:
- OpenCPN connected to a net port,
- virtual COM ports (say A and B), bridged,
- connect port B only to OpenCPN.
Now go into OpenCPN click the waypoints you want transferred and specify "send to COM A" (!!! NOT Com B !!!) Bingo!

Is this correct?
I have to visually see this stuff for some reason!! Rather than words.

     | <----> IP-UDP/TCP Network (nmea data comes in)
     |
OpenCPN              __________
     |--Com B out-->| NavMonPC  |--> Com A out to Chartplotter?
                       Bridge

The "bridge" can be NavMonPC connecting to Virtual ports Com A and Com B . NavMonPC can be on the same computer as OpenCPN, just connecting the two virtual ports.

- Barnakiel, not set up to test this stuff right now. Sorry, but it seems like you and Hakan have it nailed.

[barnakiel]

Originally Posted by rgleason

(...)

The "bridge" can be NavMonPC connecting to Virtual ports Com A and Com B . NavMonPC can be on the same computer as OpenCPN, just connecting the two virtual ports.

(...)

Well.

In theory yes but in practice I tried and NavMon did not do the job well at all. The other software (HDD Software Virtual Serial thingy) did well though.

I have not received any codes from that flyspray thingy. Can't place my suggestions there yet. Maybe morrow.

Cheers,
b.

[barnakiel]

I am posting my setup and some images just in case someone needs WPTs over IP.

My kit was:

- OpenCPN, ver 4.4
- Win 8.1
- HDD Software Virtual Serial bridge

Start the bridged virtual COMs up first.

Connect OpenCPN to one of the COMs and to the net port.

OpenCPN connects to the net interface and to ONE only of the bridged virtual COMs. Send the WPTs to the OTHER virtual COM. NOT to the one that you connected OpenCPN to.

Cheers,
b

[barnakiel]

Originally Posted by rgleason

b. wrote:

I have to visually see this stuff for some reason!! Rather than words.

I will try to make a drawing on paper or else with a paintbrush and post it here tomorrow.

Cheers,
b.

[barnakiel]

Originally Posted by rgleason

I have to visually see this stuff for some reason!! Rather than words.

Hey. I made a drawing. I hope it helps.

See attached.

Big hug,
b.

[barnakiel]

Originally Posted by alctel

(...)

Simrad NSS8 connecting using wifi and everything looks great except that. It's listening for NMEA183 and 2000 strings over IP so I think if there was a way to send strings it would update.

(...)

If it connects to GoFree wifi bridge then the solution we posted should work.

I do not have NSS8 at hand to test it though.

b.

[alctel]

Tried the above, don't think it will work - I think it's an NSS issue, as the nmea debug window looks correct. I'm not sure why it wouldn't update as it's listening for nmea183 strings but as you see below I think i'm sending them correctly

http://imgur.com/a/lLSmC

[barnakiel]

Originally Posted by alctel

Tried the above, don't think it will work - I think it's an NSS issue, as the nmea debug window looks correct. I'm not sure why it wouldn't update as it's listening for nmea183 strings but as you see below I think i'm sending them correctly

Imgur: The most awesome images on the Internet

I am looking at the image. I have also had a look at NSS manual.

The manual says:

- WPTs get transmitted over the SERIAL port,

- WPTs on Ethernet are NOT bridged (but it fails to say if they are utilised), (this is question No1 for Simrad support),

- surprisingly, the list of accepted nmea sentences does NOT mention WPL.

So, we are sending WPL but it is not listed as a valid waypoint sentence in NSS manual.

And NSS does not bridge the WPT sentence in any case. (This does not imply the sentence is used / not used).

I have no idea what sentence NSS uses for WPT transfer then - maybe one of N2K sentences? A good question No2 for Simrad support.

See dumps attached. Pretty self explanatory.

The way we are trying (using WPL nmea 183) via Ethernet, it cannot get done.

You may be able to send WPTs via the N2K link or else using a different (but which?) nmea 183 sentence.

Big hug,
b.

[rgleason]

B. Thanks for the nice drawing! And good followup!

Did tracker register you? It shouldn't take longer than 5 min to send back an email.