Visit our Popular Forums

Antipole · 26-09-2022, 03:09

Dave's topic OCPN Data Sharing Focus Group has invited input on the desired functionality for interworking. It is not for discussion on how this might be implemented.

One common desire is to synchronise data between multiple instances of OCPN. This is much more realistic than between OCPN and a proprietary device such as a MFD, over which we have no control. Several users have developed multiple displays of a single OCPN instance but that approach is dependent on that single instance. Multiple instances provide more redundancy.

I have developed a 'proof of concept' script for the JavaScript plugin and have successfully moved waypoints and routes between instances of OCPN and demonstrated automatic notification of certain actions such as 'activate route' between the instances. This topic shares what I have learnt and, hopefully, will help develop of the approach. Feedback is welcome.

Basic principles

The JavaScript plugin uses JavaScript structures to represent OCPN objects such as waypoints and routes. My idea is to transfer these structures between instances of OCPN as JSON strings. This is much superior to transferring them using NMEA sentences such as WPT and RTE because all the attributes are transferred. Since the attributes include the GUID, a waypoint or route can be updated. Transferring by WPT or RTE would create a new OCPN object each time!

Achievements so far and limitations

Copy/update waypoints & routes

At present, this has to be initiated by clicking on a button. For waypoints, the script sends all shown waypoints.

A plugin cannot determine whether a route is shown or not, so it presently sends all routes with a name starting with a dot. FS#2842 would solve this. Before sending a route, the script sends all included waypoints which are free-standing.

FS#2888 would allow sending when a waypoint or route is created, modified or deleted.

Navigational actions

When a route is activated, the script automatically sends the route followed by an 'activate' message.
When a route is deactivated, a 'deactivate' message is automatically sent.
When a route is advanced, an 'advance' message is sent.

Apart from creating/updating a route, receiving scripts cannot presently act on these messages, so the script just displays an alert "Would activate route <route name>" or "Would deactivate route" FS#2880 would allow the receiving script to carry out the required action.

Note that in this model there is no concept of a master and slave instance of OpenCPN. An arbitrary number of instances can run the same script. It is perfectly possible to create a waypoint in one instance, have it propagate to all the others, to modify it on any one of them and then have the update propagate to all others, including the originating instance. Similarly, a route could be activated on one, advanced on another and deactivated on a third.

Connecting between instances of OpenCPN

Ideally, this would be by sockets and preferably using TCP to handle flow control and error correction. I have started looking at adding this to the next version of the JavaScript plugin but it seems non-trivial and will be an over-winter project - if I find the time.

Meanwhile I have been transferring messages over NMEA0183 using a private message type. After the message identifier $JSOBJ, fields contain a unique identifier and the type of operation/object. This is followed by the object as a JSON string.

Problem 1 - solved
Sending over NMEA means that scripts will receive back their own transmissions. If they acted on these, you woud get 'howl round' - like when a microphone is too close to a speaker. I have solved this by including a unique identifier in each sent message and keeping a record of the (last ten) sent identifiers. If a received message identifier matches one of the sent ones, the message is ignored.

Problem 2 - solved
JSON strings contain several characters that fall foul of NMEA, such as commas and asterisks. To get around this I use escape sequences such as .c for comma and .. for a real .

Problem 3 - solved
JSON strings can be very long - especially for complex structures such as a route and its included waypoints. This can exceed the length acceptable. I am not sure what that limit is but I have assumed a limit of 256 characters. To address this, the script breaks longer messages into instalments and puts them back together on receipt. In my tests, a fairly simple route could require 30 instalments!

Problem 4 - solved
Transferring all this data could overload OpenCPN and impact other functioning. To solve this, I queue the outgoing messages and send them at one second intervals. This works fine, although it can, of course, introduce a delay for long messages before the object is acted on.

Problem 5 - not solved
I developed the solutions to the above problems by transferring messages between multiple JacaScript consoles in the same instance of OpenCPN. They work very well but I have to inhibit the actual action. So if I send a waypoint, the receiving console just reports "Would create/modify waypoint xyz" as it should not do this to the same instance of OpenCPN.

When I have multiple instances of OpenCPN running on two different computers, messages are sometimes lost. In particular, with a multi-part transmission, the first one or two instalments are not reliably received. This is not a script error as the same message is received OK by consoles running in the same instance of OpenCPN. I have not found any solution to this.