Interoperability between OpenCPN(s) & Devices

[rgleason]

Perhaps for O to O there could just be a plugin that handles navobj.xml and will copy the file from or copy to and also provides backup and better saving/storage of routes outside of navobj.xml. This transfer of the file could be by usb key or network.

This would not work for communication with other chart plotters.

[Tehani]

Originally Posted by bdbcat

Tehani...
"At this time, OpenCPN never acts as a navigation data repeater, and I think it should."


Well, it does, actually. Most MUX ports can be set to I/O mode. If they are so set, then all the dataflow received by any port is echoed to this output port. Filters are available to throttle data, and preclude recursive loopback.



Or maybe I misunderstand the use case?


Dave

As a repeater instrument, I refer to a device for presenting the data received on its screen.

It has nothing to do with the forwarding of sentences.

In the case of received RMB, I think it would be nice if O presented the relevant data (DTW, XTE, VMG ...) and drew the great circle to the waypoint. Just as it does when acting as a navigator.

[bdbcat]

Tehani...


Ahhh. Misunderstanding of the word "repeater".


Carry on.....


Dave

[alaskanviking]

What id like is some sonar & track/route interconnectivity. would love to transfer sonar and sidescan sonar directly from the chartplotter or Sonar box, ALA Reefmaster software instead of having to use SD Cards, but i suspect that is not a possibility because of the equipment venders

So what I'm really talking about is taking the Dinghy out to check out passage depths in advance and sending the Geo referenced Sonar data back to the big boat Opencpn for planning purposes. Wifi would be nice if you had a longer range wifi antenna on the mast, or even do the transfer via wifi/blutooth after you get back to the big boat.

would like the ability to transfer these bathymetric charts back to the chartplotter, again its an SD card thing currently

[rgleason]

Thanks Tehani.

Part of interoperability is Connection of vessels instruments to Opencpn

[bcn]

Just a reminder:
The RTZ plug-in from Rasbats
https://www.cruisersforum.com/forums...ml#post3272644


Using a public standard. For me the way to go. It can even be integrated directly into OpenCPN..


Hubert

[Dockhead]

Originally Posted by rgleason

Thanks Tehani.

Part of interoperability is Connection of vessels instruments to Opencpn

You don't mention Ethernet connections to Navico plotters. That's how I'm connecting my board computer with O to my boat network.


I receive a huge variety of 0183 sentences over that connection, but never tried to SEND 0183 sentences into the network over that connection -- do you know whether it's possible?

[Tehani]

Originally Posted by Dockhead

You don't mention Ethernet connections to Navico plotters. That's how I'm connecting my board computer with O to my boat network.


I receive a huge variety of 0183 sentences over that connection, but never tried to SEND 0183 sentences into the network over that connection -- do you know whether it's possible?

Of course it's possible. No special mention is needed for Navico chartplotters.

You just need to configure a network connection as output.
Then indicate which sentences you want to send to that network.

[Tehani]

Interesting is this recent post that is related to this thread:

https://www.cruisersforum.com/forums...ml#post3493623

I think Ocpn should ignore the content of the GPS / GNSS sentences if the valid data indicator is not 'A' in RMC, or is '0' in GGA field 6. Remember that this GGA will condition the validity of other sentences like GLL.
Used as a multiplexer, I don't find it convenient for Ocpn to forward in this case, although this is already a problem of the final receiver.

[rgleason]

Originally Posted by Dockhead

You don't mention Ethernet connections to Navico plotters. That's how I'm connecting my board computer with O to my boat network.

I receive a huge variety of 0183 sentences over that connection, but never tried to SEND 0183 sentences into the network over that connection -- do you know whether it's possible?

Part of interoperability is Connection of vessels instruments to Opencpn
This is a new page and quite rough. Will add Navico, but Entertaining edits to improve it!


Tehani, also suggested Re: AIVDM, AIVDO and Own Ship GPS data

https://www.cruisersforum.com/forums...ml#post3487406

[rgleason]

antipole2 reports "You could do this with the JavaScript plugin.
I use it for the reverse - sending OpenCPN routes and waypoints out as xxWPL and xxRTE sequences to devices running iNavX." in
Convert incoming xxWPL and xxRTE to waypoints and routes #2353

[rgleason]

For other consideration for interoperability
Network Repeater
Send WP over IP


Navigation Data Backup (navobj.xml)
Saving waypoints, routes, tracks and layers for future use (Or another Opencpn)

[Cowpoos]

I use Raspberry PI, andriod tablet, andriod phone and windows laptop. I would like them to sync routes/waypoints/target alarms/etc automatically and make changes on any device. All my devices have a copy of my maps on them, so not broadcasting map data would save bandwidth. I run Signal K server to broadcast data [via the Pi], so for me running a sync over signal K with Opencpn would be a good way to implement this.

I especially like the idea that a MOB is automatically sync'd, so you could potentially grab any device/phone and hop in the dinghy for a quick rescue. I also like the idea of importing GRIB on to one device and they sync to all aswell, so getting new weather data when in a town on your phone and it automatically syncs to your other devices when back at the boat. There are likely lots of other use cases aswell.

[rgleason]

Antipole (and Rasbats) has made these improvements to the Javascript plugin.

https://www.cruisersforum.com/forums...ml#post3495902

[Antipole]

I am successfully mirroring the OpenCPN active route or waypoint to devices running iNavX. Please see this topic.

In my opinion, the number and variety of devices/applications out there is large and growing. So I think it best to avoid adding functionality for specific others to the OPenCPN core. Rather this should be handled by plugins. As an example, my approach with the JavaScript plugin allows a user to tailor a script to their particular device requirements.

What may needed is developments in the OpenCPN APIs to allow plugins to do the necessary work. As just one example, the API to fetch a list of waypoint GUIDs returns GUIDs for all waypoints and routepoints and there is no way of distinguishing between them, even though OpenCPN can and does so internally. Extracting a list of true waypoints is very fraught.