Monday, 22 June 2026

11th Bass Strait Voyage - Software Bugs and Some Good Luck

11th Bass Strait Voyage - Software Bugs and Some Good Luck

Wednesday 17/6/2026 6:30pm. Launch of Voyager 2.9 on a quick 24 mile / 24 hour voyage across the edge of Bass Strait from Torquay to Rye Ocean Beach. 

The vessel was fairly much the same configuration as the previous Bass Strait voyage, in late 2025.

Final Checks Before Departure to Launch Site



Ready for launch at Torquay 6:30pm 17/6/2026


The vessel made it through the destination, but it took 59 hours, rather 24, and took some large diversions on the way.
This voyage revealed new software issues. 

The image below shows the vessel heading eastward, in a generally northerly wind, slowly drifting toward the boundary. And around a third of the way across, it departed the corridor.

The wind was fading, and the vessel was unable to make way in the light conditions, possibly with tidal influence.
The Voyager OS software does change it behavior to cope with course deviation outside the corridor.
This is defined as Cross Track Error (CTE) exceeding Maximum CTE (MaxCTE). Max CTE being the boundary.

The vessel continued to drift out of the corridor, beyond 150% MaxCTE, where a further behaviour threshold commences.
When the wind returned, it failed to return toward the rhumb line, but continued further off course.
Analysis of the logs revealed that the vessel  had adequate wind power to sail, but was running on port tack and refusing to head toward the rhumb line, despite the fact that it could have, if it tried.
I called this the "stuck running" bug, where it was in running mode, and refused to leave this mode.

Good Luck #1

Eventually, the wind backed to north west, which allowed the vessel to successfully make the centre waypoint, while "stuck running".
Once it returns within 25% of MaxCTE, all flags related to exceeding boundaries are cleared and the sailing algorithm returns to normal.



Voyage from Torquay to Rye Ocean Beach, including excursions


As the vessel continued eastward approaching the destination, the scenario repeated.
The vessel drifted out of the corridor beyond MaxCTE in light conditions, and continued to drift south in the light north-westerly wind.
Eventually, the vessel drifted several miles south, when the wind returned. 
but "stuck running" meant it wouldn't return to course.

Good Luck #2

The wind swung around and came in from the SSW at around 30knots. 
This allowed the vessel to run back to the final waypoints with good speed and good control.
The image below shows the vessel approaching from the south and then heading eastward to the shore.





Landing at Rye Ocean Beach 5:30am 20/6/2026



Software Bugs

"Stuck Running" Bug

Analysis of the code highlighted several issues related recovering from values of CTE greatly exceeding MaxCTE.
The primary bug, the "stuck running" bug, is caused by some specific maneuvering cases not being covered.
When the vessel is running down a course, it is forced to gybe back and forth to avoid sailing closer to dead-downwind than around 30 degrees. 
This is for reasons of speed and more importantly to prevent downwind rolling (which is a problem that afflicts monohulls with self-trimming wing sails).
The downwind tacking behaviour generally consists of tacking downwind from one boundary to other. And in each case when a boundary is reached, the mode changes to running on the other tack.
The "stuck running" bug was complex to unravel, but it in simple terms it was related to a problem where the vessel is outside of the corridor, running on a divergent tack, away from the course, and never meeting the boundary.
This is now believed to be resolved, by ensuring that the gaps in the logic are covered to ensure the vessel tries to return to the course as one of its highest priorities.

"Waypoint Reached" Bug

This was not a problem, but this latest voyage highlighted that it could have been.
A waypoint is considered passed, when the vessel crosses a line perpendicular to the course, that bisects the waypoint circle. The vessel must be within the circle as it crosses the perpendicular line to be considered past the waypoint.
This means the vessel must be within MaxCTE to do that.
A situation may arise where the vessel is outside of MaxCTE as it passes the waypoint.
It may be pointless, fruitless and counterproductive to force the vessel to pass within a distance of MaxCTE, when the vessel is already outside MaxCTE.
Instead, a change has now been made to remove the requirement to be within the MaxCTE distance of a waypoint when crossing the perpendicular line, for it to be considered passed.
Of course, the vessel will always try to pass precisely through each waypoint, but if it is pushed past a waypoint outside of MaxCTE, there is little point trying to go back.




Wednesday, 22 April 2026

Sat Comms Antenna update

 Sat Comms Antenna Update

Testing of the satellite communications has proceeded over the past couple of months in different circumstances. 

Australia is in the Band 255 region for the Skylo NTN service. This band is close to the GPS L-Band.
I've had reasonable success using a passive GPS Patch antenna with the Murata 1SC NTN module
But reliability for telemetry was only adequate. In practice, around 1 message in 3 may be lost.

I purchased a low-cost PCB Antenna intended for use with Inmarsat through AliExpress.
This antenna is intended for the Band 255 L-Band.
This yielded significantly better performance than the passive GPS Patch antenna.
It is larger, but being flat it does not occupy much volume.

Inmarsat PCB Antenna sold through AliExpress for under $10




The SMA Connector is mounted on the top of the board. I moved it to the underside of the board to allow the PCB Antenna to be placed against the top of the interior of the equipment housing, occupying the minimum amount of space.


Inmarsat PCB Antenna installed within the Equipment Housing


On water tests have been limited. But so far results are good, with zero lost messages with reporting every few minutes over several hours.


On water testing - good results so far.






Saturday, 21 February 2026

Satellite Comms - another try

 Satellite Comms - another try

I have previously integrated 2-way satellite IOT communications into the Voyager Sailing Drone design.

Swarm Space 

I started with a modem for Swarm Space. But before I commenced integration they announced to imminent shutdown of the constellation. I did nothing more with this modem.

Astrocast

I purchased the Astronode S+ device from Astronode through Mouser.
The Astronode S+ is a small-footprint, low power and very effective IOT modem. Their constellation consists of a few LEO satellites, so they are visible only a few times per day.

Once integration was completed, Astronode advised me of the "commercial service contract" fee of US$500 per month.
For some reason, the only fees documented on their website for connectivity were the data usage fees ranging from US$1.30 to US $6 per month.  
A fee of $500 per month changes from being a reasonable hobby project to being only a serious commercial enterprise.
As at Feb 2026, it is unclear if Astronode is still a trading entity.

I have been continually monitoring the Satellite IOT market looking for low power, small footprint devices with low cost connectivity and data usage fees.

Monogoto with Murata and Skylo

Then I happened upon a YouTube video by Laurens Slats from Monogoto.
They provide a service marrying together the Murata 1SC NTN modem, with access to geo-stationary satellites via Skylo. The costs are under $10 per month for my usage, so it fine for hobby projects.
Using geo-stationary satellites means that the satellite is always accessible (assuming it is not obscured).

The Murata 1SC is available within an evaluation board.

This costs around US $100 through Monogoto. It is small and low power.


Murata 1SC Development Board


The Murata 1SC Dev Kit does have some design problems which compromise its use when deployed in an operational system:

  • It lacks any mounting holes, and so must be clamped in place.
  • It has level-shifting interface circuity on board, which consume just over 20mA while the board is powered up. The Murata 1SC does go to sleep and consumes very little power, by the persistent 20mA minimum is the largest current sink in the Voyager Sailing drone, with the exception of the steering servo.
  • The Murata 1SC supports 3.3Vdc, but the Dev Kit only support 5Vdc.
  • The main connector looks like a standard 16-pin IDC ribbon cable connector.
    But its not. It has a 2mm pitch, rather than the more standard 2.54mm or 0.1" pitch.

In future, I will update the Voyager Controller board to provided switched 5Vdc to allow for powering off the whole Dev Kit board when idle, to significantly reduce power consumption.


The first step was addressing the main issues of installation on a sailing drone, being the antenna.
The antenna supplied with the kit is a multiband antenna, designed to address the different bands used by the Skylo service around the world.
The multiband antenna is pictured below. It doesn't easily fit with the existing equipment bay, and would need considerable effort to deploy and also handle immersion in sea water.

Multiband Antenna included in the Dev Kit

Australia is in the Band 255 region for the Skylo NTN service. This band is close to the GPS L-Band.

I wanted to see if a standard GPS patch antenna could be used with the Murata 1SC Dev Kit in Australia.

Of course, a standard GPS patch antenna is an active device.  I stripped out the active components and attached an SMA pigtail directly to the antenna element to allow for testing with the Dev Kit.

I tried this process on two different sizes of GPS patch antenna.
The 25mm passive patch antenna works well.
The smaller patch antenna could not establish a connection, and was of no use.


Testing with Passive Patch Antennae.


The Murata 1SC Dev Kit mounted above the main board within the equipment housing, including the 25mm passive patch antenna.



The Murata 1SC Dev Kit lifted up on the hinge to reveal the main board below.


I found the documentation of the AT commands provided by Murata was only a subset of the commands available.
The additional AT commands to aid the development were obtained from here:
we-online.com/components/media/o691492v410 Manual-um-acm-adrastea-i-2615011136000 %28rev1.2%29.pdf

 Testing in the back yard is generally good with mostly reliable communications.

I still need to perform on-water testing to ensure good communications while under sail on the local lake.

 

I have set up dedicated UDP listener software to receive and decode the telemetry packets.
At this stage I’m sending around 60 bytes of data, at regular intervals.

It then checks to see if there are outbound commands queued up, and waiting to be sent.
This allows for commands to be sent to change the mission waypoints or other parameters.
They can only be sent in response to the vessel sending a periodic telemetry update.

On-water testing results to follow...