Sending waypoints/routes over IP

[alctel]

Hi there,

As far as I can tell there is no way to send waypoints or routes over IP? Even if I type the IP connection in the box, it doesn't appear to send anything.

Is there a way you can add this? I ask because I have a 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. I want to use this to create routes to port over to chartplotter as this is way nicer than doing it all on the CP

I saw a thread from 2 years ago about someone asking some similar but it didn't seem to get resolved.

Thanks so much for such a great product

[Neptune's Gear]

IIRC the NSS SImrad wont accept waypoint or route data via wifi. Sorry, the only way is to create it in opencpn and copy it to an SD or USB drive, and plug that into the Simrad. Less than ideal, but the Simrad will not allow file transfer, and navico dont seem interested in fixing it.

[Hakan]

alctel....
Well, there's a way although not really straightforward. I agree there's no way to convince the waypoint/route manager to contact a network port instead of a serial COM port. That would be a feature request using Flyspray but I tested and solved it this way: (I'm on Windows so all refers to that.)
I've one OCPN main instance open, here I call it O-main. I also have a OCPN portable instance open. How to set up a portable instance for simultaneously use with a O-main on Windows is another story. If you don't know pls read wiki or ask me here. I'll call that instance O-port.
I also used a free virtual serial port app set up as a COM1 bridge to COM2.
I had the waypoint to be copied in my O-port. From there I sent the WP to COM1.
In O-main I used two connections, COM2 for incoming messages and a Net-IP-UDP connection for output, see my screen shot below. On the same image you can see what happened in the O-main NMEA debug window. A WP coming in on COM2 and directly reflected out to the IP-ort. (Although in opposite order but that's the same second so windows print can be randomly.)
If your Simrad is not listened to UDP you have to set the IP connection as TCP instead.
As said not the most convenient way and there can for sure be other solutions as well. But this is one way. And I do agree OCPN is great.
Håkan

[alctel]

Thanks for the replies guys - Hakan, I 'll take some time to digest what you said and give that a shot - it looks like the NSS DOES accept waypoints then via UDP?

If all else fails using an SD card isn't that bad - I didn't think of that.

Thanks again!

[barnakiel]

Great or not but I would like to see 'send to IP' (wpts and routes) in OpenCPN one day. It is one of few missing niceties.

Big thanks for the walkaround though - I will try to use your method too.

b.

[rgleason]

Is this worth a writeup to be put under Advanced?
Seems like Hakan has it explained.

[barnakiel]

Originally Posted by Hakan

alctel....
Well, there's a way although not really straightforward. I agree there's no way to convince the waypoint/route manager to contact a network port instead of a serial COM port. That would be a feature request using Flyspray but I tested and solved it this way: (I'm on Windows so all refers to that.)
I've one OCPN main instance open, here I call it O-main. I also have a OCPN portable instance open. How to set up a portable instance for simultaneously use with a O-main on Windows is another story. If you don't know pls read wiki or ask me here. I'll call that instance O-port.
I also used a free virtual serial port app set up as a COM1 bridge to COM2.
I had the waypoint to be copied in my O-port. From there I sent the WP to COM1.

(...)

@ Håkan

Do you think the same could be achieved if you attach both COM 1 (real port) and COM2 (virtual port, bridged) to the same/one instance of OpenCPN?

COM 2 to be created by a virtual port software.

Then define one com as 'out' another as 'in' under OpenCPN?

I mean, is the portable instance absolutely required?

Just an idea.

I will try to test the above hypothesis now. I will try to report back IF this works.

Disclaimer: as is, my gps is linked to my machines via wifi. So I truly dislike unplugging and plugging the optional USB cable for wpt uploads. Let alone this cannot be done from the tablet (our tablet has no OTG).

b.

[rgleason]

NavMonPC would do it.

[barnakiel]

Originally Posted by rgleason

NavMonPC would do it.

Do you mean sending WPTs from OpenCPN to a virtual port on NavMon and let Navmon bridge these over to a net port?

Yes?

You are right this should work too.

But I am not sure NavMon and OpenCPN can tap into the same port at once (?). I need OpenCPN to be on this net port as this is how my nmea data arrives into OpenCPN.

Also, NavMon does not seem to exist on Android and our mobiles are Android based.

b.

[rgleason]

Also, NavMon does not seem to exist on Android and our mobiles are Android based.

Nope, just windows. Sorry didn't think about android, but couldn't NavMonPC be on the PC and still send or receive via wifi?

I think I might need a schematic here...

[Hakan]

b.

Do you think the same could be achieved if you attach both COM 1 (real port) and COM2 (virtual port, bridged) to the same/one instance of OpenCPN?

No, not really. See my screenshot where I have sent ONE WP via COM1 (to "GPS") and it's received by COM2 and directly sent out by UDP and COM1 and received by COM2 and directly sent out by UDP and COM1 and so on......... - like a microphone/speaker feedback.
(The double of each is NMEA debug window stammering, not real transmittance.)
Håkan

[barnakiel]

Originally Posted by Hakan

b.No, not really. See my screenshot where I have sent ONE WP via COM1 (to "GPS") and it's received by COM2 and directly sent out by UDP and COM1 and received by COM2 and directly sent out by UDP and COM1 and so on......... - like a microphone/speaker feedback.
(The double of each is NMEA debug window stammering, not real transmittance.)
Håkan

OK.

Yesterday I did a lot of experimenting but failed to pick up a wpt over wifi.

I think my challenge yesterday was that NavMon uses a separate Client / Server tcp configuartion and it only sends wpts out to the Server part. But I am connecting as a client - my router playing the server part.

Today I will try to get it done over OpenCPN as you did. My nmea router logs all traffic, so I will see if/when a wpt sentence gets there.

So, back to try out more options tonight.

Thanks for all support and feedback. Most appreciated.

b.

[barnakiel]

Originally Posted by Hakan

(...)

(...)
Håkan

People - do as Håkan says.

I tested both method A (two OpenCPN instances - this works) and my pseudosmart and fully faulty method B (one OpenCPN instance - this loops back).

I have also tested NavMon method but it did not work.

Method A allows to send a WPT or a route to another device via IP (ethernet cable or a wifi link). In my case the other device is wired into a router.

I have tested sending from OpenCPN via a wifi nmea router. WPTs get to the other side fine (in our case the other side is a Garmin unit).

I am happy.

I hope OpenCPN developers could add IP to the 'send waypoints' functionality. It should be possible without much ado (? I think).

@ Håkan:

If by any chance you have already experimented with doing the same trick between two wireless devices I would love to hear your feedback on how the IP router should treat an incoming WPT. Is there anything like an 'echo' command that would send the WPT back over the network so that other connected devices could pick it up?

Example: sending wpts from one wireless device to another wireless device over a wifi router.

BIG thanks. You made my day bright today!

Regards,
barnakiel

[Hakan]

barnakiel..
re:"If by any chance you have already experimented with doing the same trick between two wireless devices I would love to hear your feedback on how the IP router should treat an incoming WPT"
I'm not sure I completely understand but I'll try:
I suppose two wireless devices are devices still on the same network segment? (like 192.168.1.xx) In that case it's no problem using protocol UDP. UDP is like a radio broadcast without a specific receiver, everyone is listening as long they're tuned to the same port, like 10110.
The router doesn't care what's broadcast, but some (old?) routers has to be set up to admit UDP on the port(s) involved.
b. was this an answer?
Håkan

[barnakiel]

Originally Posted by Hakan

(...)

I suppose two wireless devices are devices still on the same network segment? (like 192.168.1.xx) In that case it's no problem using protocol UDP. UDP is like a radio broadcast without a specific receiver, everyone is listening as long they're tuned to the same port, like 10110.
The router doesn't care what's broadcast, but some (old?) routers has to be set up to admit UDP on the port(s) involved.
b. was this an answer?

Håkan

Håkan:

Yes, close to this, but not identical.

I am in the following scenario:

The devices:

- 2 x laptops running OpenCPN, both on same 192.168.x.x network,
- 1 x wireless router, AP; creator of the above mentioned network.

The intention: to send WPTs wirelessly between these two laptops.

So: I press send WPTs on one laptop. These WPTs go to the router all right (the router logs them). However, this router does not send them onwards to the other laptop, and so the other OpenCPN does not receive them.

This is due to how my wifi nmea router works: it muxes serial and net ports. So whatever appears on a serial, gets forwarded to a net and vice-versa. However things that appear on the net do not get forwarded back to the same net.

In other words, my router sends serial data to wifi OK and also wifi to serial works OK. What it refuses to do is taking up WPTs from one device on the wifi network and sending them onwards to another device on this network.

I am not sure how to bite this. Maybe the router should 'echo' the WPTs over the net. Or maybe my challenge is using TCP (not UDP). Or perhpas some kind of firewall settings on the router blocks me.

Sorry for dragging this on. I am not at all too good at IP networks. I build things, experiment and then at times the work. At times not.

Very best regards,
barnakiel