Initially, I looked at using the features of OCPN 3.1+ to retransmit NMEA data received by OCPN using IP addresses. This worked well, passing the data wirelessly through the router to another laptop running OCPN in the cockpit. However this requires twice the power so it would be better to have the NMEA going straight into the router and being distributed from there.
At this point I was directed to kplex by its author, Keith Young. Now kplex looked to be able to do exactly what I wanted, and much more, but had so far only been compiled to run on Linux (Intel), OSX and the Pi. It was, however, written as a POSIX compliant program so any platform running a suitably compliant OS should also run the program. My main router, the RT-N16, with its Tomato firmware is exactly that as the underlying OS is Linux. So, I set about looking into a cross-compile environment because the hardware that runs the RT-N16 is a Broadcom MIPSEL based processor.
At this point things get messy as sorting out how to create a MIPSEL cross compile environment on the Linux image of my laptop took a while. Although I got one working, there were still some false starts to get it configured properly to compile kplex, its probably 20 years since I did this stuff. Eventually those were worked through and I got a program that compiled and ran when transferred to the router, hurrah! Except Keith pointed out that the segmentation violations I saw when some invocations were a bit wrong shouldnt happen and shutting the program down required a 'kill -9'. Now anyone with a bit of UNIX recognises that -9 is a bit like taking out a mafia contract on your program, there is extreme prejudice involved, which shouldnt be necessary for a well behaved program. Keith was fantastic in trying to offer notated versions of his code to track down what was happening but to no avail, subsequent events show that kplex was not in error - my compile environment was the problem. Nonetheless, I had a working program.
Next job was to make it useful. The first diagram shows the wired connections to my laptop and the way the data flowing through the connections is used. Getting the GPS and AIS inputs configured was relatively easy, but first you do need to get the USB connections recognised. Fortunately the serial-USB converters I have are FTDI and Prolific, both of which have drivers available within Tomato. The 'shibby' variant of Tomato provides both drivers including the current version of the FTDI driver. These are not made part of the OS at boot time but must be added in using 'modprobe -a ftdi_sio pl2303'. Once this command is run and the USB cables connected, the two adapters are given USB port numbers and can be addressed by programs running on the router.
Now we are cooking: configuring kplex and OCPN took several trials. What seems to work well is combining the GPS and AIS data streams using kplex to multiplex those onto port 10110 of the router. Then configuring OCPN to use the router IP address and port, 192.168.20.10:10110, as a data connection in the same way as a directly attached COM port.
Getting the output portion of the data stream to the autopilot was less obvious. Any attempt to combine inputs and outputs using kplex and OCPN talking to the same port on the router led to OCPN freezing its data stream until the output connection was disabled. What worked was setting up OCPN with a connection on the laptop to a unique port, 192.168.20.118:10111. Then using kplex as a TCP client listening for data from that port on the laptop. So the autopilot output data stream is a separate connection in OCPN talking to a kplex client on the router, though the kplex client then outputs the received data down the same USB connection as the GPS input. At present OCPN closes the output connection data stream when the 'options' dialog is open, the lack of data can cause kplex to close the client down unless it uses the 'persist' option available from version 1. The two kplex invocations are shown below:
<!-- This one does the inputs -->
kplex -o mode=background
<!-- This one does the output -->
kplex -o mode=background
The message filtering required for the output could be done by either kplex or OCPN, I've chosen to use OCPN. The only messages output are ECRMB, ECRMC and ECAPB. These are all generated by OCPN containing position, waypoint and route information ensuring that only OCPN derived routes are followed. This stops any transfer of 'goto' data deriving from the GPS 'talker' on the NMEA system, the Furuno GP32, to the autopilot. The wiring of my boat forces the Furuno to autopilot connection to be indirect, this could be bridged by using kplex to send data out by defining input and output stream in the same instance with appropriate filters.
The configuration described here, rather long windedly, is shown in the second diagram of this piece. All this has now been working reliably for about a month, running kplex in parallel with the routers main function of making internet connections available to all on board.
Even better I recently found another method of compiling kplex which makes it behave as it should :) This makes use of 'tomatoware' running on the router, a utility I found through Tomato's forums on linksysinfo. Its author, a lovely bloke called Lance, helped me out with compile options (-zmuldefs -static) to make kplex standalone with all its function self contained. So now I think I have a version of kplex that should run on any MIPSEL device using Linux based firmware.
There is, of course, a gotcha to all this good stuff. Sadly the mobile dongle support in Tomato, remember that ??, doesnt like having other serial devices around when it tries to reconnect. This will happen from time to time as you move around and change cells or just as the signal fades in and out. I'm still trying to work out whats going on here, but in the interim the Ericsson box is plugged into the WAN port on the router and the SIM card is in the Ericsson box