Sat Comms Antenna Update
![]() |
| Inmarsat PCB Antenna installed within the Equipment Housing |
![]() |
| Inmarsat PCB Antenna installed within the Equipment Housing |
I have previously integrated 2-way satellite IOT communications into the Voyager Sailing Drone design.
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.
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.
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:
| Multiband Antenna included in the Dev Kit |
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.
| 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...
An important performance characteristic of a self-trimming wing-sail assembly is the relationship between trim-tab deflection and the resulting angle of attack (AOA).
Within the normal operating range, this relationship is approximately linear.
A practical method for quantifying this relationship uses the existing control and sensing capabilities of the sailing drone.
The onboard system can both set the trim tab to a defined angle and measure the corresponding equilibrium orientation of the wing sail relative to the wind.
A dedicated calibration procedure was implemented within the control software.
During calibration:
The effective change in AOA produced by the trim tab is calculated as half the difference between these two measurements.
This process is repeated across a series of trim-tab deflections to construct a calibration curve of trim-tab angle vs. resulting AOA.
The illustration below shows a sample measured response of the wing sail to a reversal of trim-tab deflection:
![]() |
| Illustation of the trim tab on opposite sides with the change in wing angle |
![]() |
| Example Run of the Trim Tab Authority test, covering 10 to 17 degrees for the Trim Tab. |
![]() |
| Scatter plot of results with lines of best fit. |
![]() |
| Figure 1. Starboard Tack Beating, Trim Tab rotated CW 15° |
![]() |
| Figure 2. Starboard Tack Reaching, Trim Tab rotated CW 15° |
![]() |
| Figure 3. Starboard Tack Running, Trim Tab rotated CW 15° |
![]() |
| Figure 4. Starboard Tack Running, Trim Tab rotated CCW 15° |
![]() |
| Figure 5. Test Rig set for Starboard Tack Running- CCW Trim Tab |
![]() |
| Figure 6. Test Rig set for Starboard Tack Running- CW Trim Tab |
One objective of testing was to clarify the relationship between trim-tab size and control authority. This was investigated by splitting the trim tab into two equal halves and comparing the aerodynamic response when operating one half versus both halves together.
![]() |
| Test foil with split trim tab allowing testing of a full size and half size trim tab |
![]() |
| Voyager 2.9 wing sail with mast pivot at 16% of chord |
The overall trends observed in testing were consistent with expectations.
The sensitivity of the wing’s angle of attack (AOA) to trim-tab deflection increases as the pivot axis moves aft toward the 25% chord point.
At 25% chord the system became too sensitive for practical use: we aim to operate the wing at an AOA below about 10°, yet a trim-tab change of only 1–2° was enough to drive the wing into stall.
It is important that the wing’s response to trim-tab input is not excessively sensitive.
The trim tab must move by a practical amount during normal operation—large enough to be repeatable and to overcome any mechanical backlash or stiction in the linkage—while still giving fine control over the AOA.
The tests revealed an apparent offset of approximately –3° in the trim-tab calibration.
This could be due to small manufacturing or alignment errors, but is more likely caused by flow-field asymmetries in the test setup.
A useful benchmark is the trim-tab deflection needed to achieve a 10° AOA:
about 7° of tab deflection when the pivot was at 15% chord,
about 5° when the pivot was at 18% chord.
For completeness, we also explored operating with deliberately large trim-tab deflections that drove the wing well past the stall angle, even though such conditions are outside the intended flight envelope.
Overall, a pivot-axis position in the range of about 15–20% chord appears to be well-suited.
Within this range the wing shows stable weathervaning, and the tab response is strong enough to overcome backlash yet not so strong that small tab motions cause abrupt stalling.
The designs of the wing sails used with the Voyager sailing drones have been established by studying other designs, by using a lot of intuition and by judging whether it looks right.
It is time to perform some more rigorous testing to determine the optimum values of some key parameters of a self-trimming wing sail.
I developed a test rig to allow a series of relative measurements to be performed indoors.
The airflow is provided by a large domestic fan.
But tests quickly showed that the airflow from a fan is too turbulent to be useful for performing measurements. So a columnator or flow straightener was developed to improve the quality of the airflow.
This was constructed primarily from rolled up sheets of A4 paper, contained within a wooden frame. It wasn't great, but it was good enough to get useful results.
![]() |
| Fan, flow straightener and the test article. |
![]() |
| Fan and flow straightener |
The airflow in the vicinity of the test article was around 2.8m/s.
This was measured using an Air Velocity Sensor Module, the Renesas FS3000-1015.
![]() |
| Test wing section, Eppler 169 with 400mm chord |
![]() |
| Adjustable pivot point shown at 18% |
![]() |
| View of Trim Tab and scale showing +10 degrees. |
![]() |
| Angle of Attack scale showing |
![]() |
| View of mast mount and load cells providing independent support in the X and Y axes. |
![]() |
| Digital readouts of relative force expressed in grams |
| Course from Torquay, 80km eastward to Western Port |
| Safely ashore at Point Leo after 44 hours |
Conditions were good for a 2-day passage commencing from Torquay Fisherman's Beach on the evening of Monday 28/7/2025.
The weather on the course was initially running, and was predicted to back toward a reach, and continue backing to a beat with moderate winds near the end of the main leg to Western Port.
But it didn't get there, and this time the reason was a software bug.
![]() |
| Ready for Launch at Torquay Fisherman's Beach, 28/7/2025. |
The software bug was introduced in 2021, but had not shown itself in ocean conditions before.
When beating to windward the software limits the upwind course with a minimum upwind angle, forcing the vessel to tack to reach a windward waypoint.
In early 2021, a similar constraint was added for downwind sailing, forcing the vessel to tack downwind to reach a waypoint within the minimal downwind angle. This was to improve downwind performance by avoiding sailing dead-downwind.
This all appeared to be fine, but there was a latent error, that was not recognised until now.
The error was revealed when sailing a running course that requires tacking downwind, and then the wind changes so that the course requires tacking upwind, without a period in between where the course is directly sailable.
Given this specific scenario, the software had an error where it did not allow the vessel to leave the running course. I've named it the "Stuck Running" bug.
This lead the vessel off the course and it did not recover.
The software has now been updated to handle the direct transitions between upwind and downwind courses that are not directly sailable.
On a positive note, everything else with the vessel appeared flawless.
![]() |
| Saildrone Explorer |
![]() |
| Saildrone Surveyor |
![]() |
| Maribot |
![]() |
| Voyager 3 |
![]() |
| Voyager 2.0 with first version of wing sail |
![]() |
| Voyager 2.8 with evolved wing sail with tail |
![]() |
| Voyager 2.9 with Tailless Self-Trimming Wingsail |
![]() |
| Voyager 2.9 with Tailless Self-Trimming Wingsail on the water |
![]() |
| Launch at Flinders Beach, after dawn. |
![]() |
| Voyager successfully exited Western Port Bay into Bass Strait, with northerly wind building to 20 knots. |
| Wing Sail damaged several miles out, approaching Cape Schanck waypoint. |
![]() |
| Recovery from the rocks near Cape Schanck several days later. |