Salt Water and Electronics - 5th Bass Strait Voyage

After quickly recovering from the prior launch and recovery on Friday 22/3/2024, the vessel was ready for another launch 11 days later on Thursday 2/4/2024, the 5th voyage on Bass Strait.

Following the prior launch and recovery on the Friday, the compass had been replaced and recalibrated yielding much better accuracy. The aim was specifically to improve the determination of the True wind Direction, which contributed to the failure as discussed in the last post.

Om that Friday night, the vessel had been recovered high and dry on the beach after it had been washed ashore, through the small surf.

There was little damage, but the sail and its electronics would have been submerged in the breaking waves on beach.

It was considered that there were no electronic problems with the Sail, and so the vessel was launched again on Thursday 2/4/2024.

Launch from Torquay 2/4/2024 at 8:15pm, soon after sunset

It sailed well, in the light to moderate conditions for the next 16 hours, and almost 15 miles down the course, at which point it failed to proceed down the course, and to started to drift back toward the launch place.

The conditions at that point were very calm.

The vessel drifted back to the west for 2 days and returned coincidentally almost back to the launch point. 

As the boat approached the shore it was possible to interrogate it using the LORA telemetry, when it was within around 2km of the headland.

It was possible to confirm that most of the components were operational.

However the wing sail had not responded to regular polling, since the time of failure, 2 days earlier.

This implied that the Wing Sail controller had failed.

The vessel was safely brought to shore by swimming out to retrieve it, to avoid it entering the breakers. 

Safely retrieved, and brought to shore before entering the breakers.

It was noted that wing sail servo was not operational, and was in the neutral position.

This suggests that it is likely that the last action performed by the controller was to partially reboot, and center the servo. If it had failed without involving a reboot, the servo would most likely have been set to one side or the other.

The electronics were switched off, and then switched back on again, and the Wing Sail returned to operation.

Later inspection of the Wing Sail controller revealed evidence of corrosion, despite the epoxy coating.

It appears that the epoxy coating was incomplete, and allowed salt water to come in contact with the electronic components.

It is believed that this was the reason for the failure of the Wing Sail controller.

It seems likely that the voyage 11 days earlier, where the Wing Sail would have been submerged in the sea water may have allowed salt to remain in voids or fissures in the epoxy coating.

Whilst dry, the salt would not have had any effect.

 

It seems likely that on the next voyage, the moist atmosphere would allow the salt to affect the circuitry.

Wing Sail Controller showing corrosion - top view

Wing Sail Controller showing corrosion - side view

To address this problem, the Wing Sail controller will be fully potted in epoxy.

A new PCB mount, incorporating a potting box has been 3D printed.

New Wing Sail Controller, located in 3D printed potting box

The Importance of True Wind Direction for a Sailing Drone

 The Importance of True Wind Direction for a Sailing Drone - 4th Bass Strait Voyage

An opportunity arose on the evening of 22/3/2024 to commence a passage in Bass Strait from Torquay to Western Port. An 80km (50 mile) passage that would be expected to take around 48 hours.

The mission failed within a couple of hours, with the vessel running ashore before midnight of the same evening.

Torquay Fishing Beach 7pm launch

Conditions were calm as the vessel ran downwind to the lee shore.

The vessel was found with minor damage on the beach.

The first question was whether the damage occurred at sea and caused the failure of the mission, or whether the damage occurred when the vessel was beached.

The equipment housing was completely intact and the equipment was fully operational.

Later analysis of the log files contained on the SD Card showed that the failure was due to the sailing algorithms making bad decisions.

Midnight on the beach

Spot GPS Satellite position reports

The sailing algorithm aims to get the vessel to the next waypoint, while remaining within a maximum permissible cross track error (CTE) from the rhumb line. 

It does this by trying to sail the course, using the favoured tack.

If it can't make the waypoint directly, it will sailing until the CTE reaches the Maximum CTE (boundary) permitted for the current waypoint and then change tack.

If it is unable to directly sail for the next waypoint, it is assessing at all times whether it is able to reach the next waypoint directly on the other tack.

The determination of whether it is possible to sail directly to the waypoint on the other tack is a key issue.

Analysis of the logs showed the following:

• The vessel could not quite sail directly to waypoint.
• It gradually reached CTE Max on the leeward side of the course (port side of course) on starboard tack.
• Having reached the boundary, it gybed on to port tack.
• Then it reassessed the course to the waypoint  (if it were to change starboard tack) and decided it was directly sailable.
• So, it gybed back on to starboard tack again, but it wasn't directly sailable, and it was still beyond Max CTE.
• The process repeated.
• The effect was to gybe and gybe again. effectively running downwind, until it beached on the lee shore.

Position Log from SD Card

The key issue was the wrong assessment of whether the waypoint could be directly reached on the other tack.

When racing sailing a full size yacht it can be tricky to assess when to tack to make the next mark without overlaying or underlaying.

The algorithm for assessing whether the waypoint can be reached directly on the other tack is as follows:

• Compare the Bearing to Waypoint (BTW) with the True Wind Direction (TWD) less the minimum sailing angle from the wind, less an additional sailing margin.
• The sailing margin is currently set to 25 degrees. This is effectively a measure of how much to overlay the mark before considering it is sailable.

Correctly estimating the TWD is critical for making correct decisions, and this was the source of the problem.

The determination of TWD is performed approximately as follows:

• True heading of vessel (HDG_T),
• less Apparent Wind Angle (AWA) 
• less correction adjustments to include an approximation for boat speed..

So the main requirements for determining TWD is to measure an accurate vessel heading, and apparent wind angle.

The main problem with Voyager 2.7 was the accuracy of the magnetic heading.

The following plot illustrates the relationship between the vessel heading and the calculated AWD, as it was during the failed mission.

The plot was prepared from data recorded on the SD Card, while the vessel was rotated on a turntable to assist gathering measurements.

It shows that the AWD varied by up to 47 degrees with different headings.

AWD versus Heading as it was for the mission

The compass was upgraded by removing the UFSF Max IMU , and replacing it with the LSM303.

The improvements brought by the new compass, and careful calibration, and minor adjustments to the calculations greatly improved the results.

The resulting plot of AWD versus Heading after the upgrades performed, yielded significant improvements, as seen by the near flat orange line.

The variation of AWD was less the 6 degrees with heading completing three full turns.

AWD versus Heading after upgrades

Then end result should yield a much more accurate AWD and hence estimated TWD.

The next ocean voyage should be telling.

 

Satellite Communications - Part 2

The Teensy 3.6 microcontroller has reached the end of production and the Teensy 4.1 is now the suggested device for projects with large I/O requirements. So the Voyager Controller PCB has been updated to V4.0 and then V4.1 as part of accommodating the Teensy 4.1 with connections for the additional serial port supporting the Astronode device as well as a general update.

The Teensy 4.1 is not pin-compatible with the Teensy 3.6, and also required some software changes. Once the new boards arrived, it required a few days to update, integrate and test the updated libraries, and verify their operation, and verify the new board.

Voyager Controller V4.0 - Integration Testing

The integration of the Astrocast Astronode S+ has gone well.
It now supports periodic upload of telemetry data from the vessel, as well as the ability to receive commands to amend the current mission, by inserting new waypoints in the list, or updating existing waypoints. This includes the currently active waypoint.
The aim is to be able to change the route in response to weather systems.

New Version 4.1 controller installed - ready for on water trials

Flip-top Antenna Deck to access hidden components

The satellite telemetry is currently configured to be recorded every 2 hours and uploaded to the satellite at the next available opportunity.

The satellite telemetry data that is uploaded is as follows:

            Date and Time

            Battery Voltage

            Battery Current

            Wing Sail Battery Voltage

            Average Roll angle

            COG

            COG Average 

            Wing Sail Angle

            SOG Average 

            SOG m/s

            Heading Magnetic

            BTW

            DTW

            CTE (cross track error)

            Max CTE (allowed for this waypoint)

            Deck Temp 

            Equipment Temp

            Barometric Pressure

            Wing Sail Time Since Last Response

            Mission index (way point number)

            Current Position

            Previous waypoint

            Next waypoint

Update January 2024 - bad news with the Satellite Comms:

I've been testing and integrating the Astrocast Astonode S+ devices into the Voyager hardware and software since April 2023.

I have an Astrocast account that I've been operating in trial mode to allow the integration testing to proceed before the account is activated and billing commences.

It looks like there's been a misunderstanding about the monthly fees once billing commences.
I thought it would a few dollars per month, as per their web site (which has now been updated in the last 24 hours after I pointed out the pricing I was expecting.).

The Astocast website previously displayed the following data plans shown in the screenshot below. These prices are very attractive, with no activation fee and with no hidden fee.

The data plans have been removed from one page of the Astrocast website. That's the page I cited during our discussion.
But the data plans with no activation fee and no hidden fee are still present on two other pages:

• Event Portfolio & Service - Astrocast - Taking IoT Further
• Astropreneur Program - Astrocast, Taking IoT Further

It seems that this pricing only applies once a service fee of around CHF 50/month or CHF 500/month is paid, depending on the service contract.
They have directed me to a reseller, Soracom.
I'm currently waiting on a response from Soracom. Let's see how that goes...

Using Astrocast Astronode S+ with Teensy Microcontroller

The Astrocast Arduino library can be found here:

Astrocast/astronode-arduino-library: Arduino library and example for the Astronode S (github.com)

The library provides functions to interact with the Astronode device. Most of the functions return an integer which is interpreted as an enumerated type.

A good response is 24834, meaning ANS_STATUS_SUCCESS.

When using the Astrocast Arduino library with the Teensyduino library, many of the responses are  24835 ANS_STATUS_TIMEOUT, or 1 ANS_STATUS_CRC_NOT_VALID.

Extensive testing was performed using software debugging, an oscilloscope, a logic analyzer and continual comparison with other Arduino compatible devices that did not yield communications errors.

It took a long time to find the actual problem.

The Astrocast Arduino library makes use of the function:

size_t Stream::readBytesUntil(char terminator, char *buffer, size_t length)

This function terminates if:

• "length" characters have been read,
• timeout, or
• terminator character  detected.

The Astrocast library calls this function with a precisely calculated length, but expects to return on finding the terminator character.

Unfortunately, the implementation of this function differs between the Teensyduino library and other Arduino libraries, with the primary functional difference being the handling of the length parameter.

Teensyduino: readBytesUntil

The Teensyduino implementation decrements the length parameter before using it in the "while" loop test.

Arduino: readBytesUntil

The Arduino implementation uses the length parameter without modification.

The Astrocast Arduino library passes in a precisely calculated length parameter, even though it expects it to terminate based on finding the terminator ETX (03).

When used with the Teensyduino library the function terminates due to length and does not find the terminator character, so the result is considered invalid.

Then the next call to the function immediately finds the terminator character and returns; so the next result is considered invalid also.

The solution is simple once understood.

The Astrocast library does not need to pass in the precisely calculated length parameter, so the simplest solution is to increment the length parameter before passing it in, and then it works with both the standard Arduino libraries and the Teensyduino library.

 

Code snippet from Astronode.cpp - unmodified.

Code snippet of modified Astronode.cpp 

Satellite Communications with Voyager - Part 1

 Satellite Communications - Part 1

Its always been the plan to add Satellite Communications to Voyager to allow for telemetry and re-routing whilst at sea.

The decision has been made to use the Astronode S+ from Astrocast.

https://www.astrocast.com/products/astronode-s-plus/

Astronode S+

The Astronode device allows for small telemetry messages to be uploaded from the vessel every few hours and simple commands to be received.

It will operate from 3V3, with an average current draw of less than 1mA while waiting to transmit its messages.

The peak current while transmitting is around 80mA. These power requirements can easily be supported onboard Voyager.

A new controller for Voyager has been designed with the key changes being a change from the Teeny3.6 to Teensy4.1, as well as support for the additional serial connection to the Astronode S+ Sat Comms device.

Prototype Voyager Controller V4.0

Astrocast provide a software library for interacting with the Astronode S+ within the Arduino C++ environment.

Astrocast/astronode-arduino-library: Arduino library and example for the Astronode S (github.com)

I used the Astrocast Arduino Library to exercise the Astronode S+ device using various Arduino compatible devices. These mostly worked ok, but I was having problems with the Teensy devices.

This was a problem because the Teensy device was only one that had to work.

The Teensy devices should have been the most capable of the microcontrollers in use, but they continually returned errors when communicating with the Astronode S+ device using simple 9600Baud serial data.

It took several months of part-time testing and debugging in hardware and software to eventually track down the reason for the communication errors between the Teensy devices and the Astronode devices.

In short, it is due to the Teensy Arduino Stream library, within Teensyduino, having a slight difference in implementation to other Arduino Stream libraries. 
The difference is only highlighted in edge cases, and would rarely become apparent. The Teensyduino Stream library is around 5 years old, and has always had this specific characteristic.
The Astrocast Arduino Library makes use of the Stream library, but it exercises the edge case that highlights the difference between the Teensyduino and other Arduino libraries.

The precise details of the problem with the interaction between the  Astrocast Arduino library and the Teensyduino library are covered in the next post, along with the solution.

 Voyager 2.6 Conclusions

Detailed Analysis - What Happened ?

March 2023 Voyage 

Detailed analysis of the recovered vessel and the log files has yielded the following conclusions:

• At 3 hours out, the vessel could not hold course. This was most likely due to some mechanical  damage to the sail.
• At 8 hours out, the sail stopped responding to regular queries via Bluetooth. This was a sudden electrical failure. The battery was discharging at the normal rate, and remained close to fully charged.
• Data from the wing angle sensor showed that the sail was feathering with the prevailing wind until the last few minutes as it entered the surf.
• It appears that the steering was operational for the whole voyage. After communication with the sail was lost, the wind moved more aft, and the vessel was able to converge toward the rhumb line. with the wind in this quarter the boat could hold course regardless of the state of the sail.
• Later the wind moved further toward a southerly driving the boat toward the lee shore near Blairgowrie.

So it appears that:

• The hull, keel and rudder remined intact and operational at sea.
• The mast was intact and the sail was feathering with the wind while at sea.
• The sail lost the ability to drive at around 3 hours. This was either due to failure of the wing sail servo or mechanical damage to the tail. The servo continued to draw current in accordance with normal patterns so it is likely that it was fine, so mechanical damage to tail seem most likely.
• The sail electronics did fail eventually.
• The tiller was knocked out of place and hit the off-switch when the vessel washed ashore.
• The sail and magnetic disk were rotating right up to when the power was switched off.
• The sail and magnetic disk were not with the vessel when it was found, in dark with torch.
  It is likely that the sail was nearby on the beach or in the shallows, but at the time it was wrongly assumed that the mast and sail were lost at sea many hours earlier.

Next Steps - Stonger more Waterproof Sail

• A new mast and sail are being built. The mast is much stronger than its predecessor, however this now appears unnecessary now that it has become apparent that the mast did not fail at sea.
• The new sail is a lower profile with a longer chord, yielding a similar overall area to its predecessor, which should greatly increase its robustness.
• The new sail is being built using heavier construction than before. with thicker 3D printed components, and larger diameter carbon tubing for the tail boom and counterweight boom.
• The electronic components are being built with the intention of surviving under water for a reasonable length of time.

Voyager Mission 2.6 - Good, but too rough for the sail! - 3rd Bass Strait Voyage

 Voyager Mission 2.6 - Good, but too rough for the sail!

Voyager was launched as version 2.6 from Torquay back beach at around 7:30am 30/3/2023.

The expected conditions were for south westerly winds over the coming few days of 15 to 25 knots, with a 2 to 3 metre south westerly swell.

Some breaking swells could be seen out to sea after the launch.

It was going to be rough.

Voyager 2.6 just prior to Launch at Torquay

It soon became apparent that Voyager was not holding course in the strong south westerly wind and swell. It looked like it was coming back to the rhumb line, but that was just wishful thinking, and it became clear she would wash ashore on the ocean side of Blairgowrie.

Voyager 2.6 only held course for a few hours.

The important question is to find out what has happened.

Typical appearance of the coastline near Blairgowrie (except it was dark at 8:30pm).

Standing on the coast as Voyager approached, it was very pleasing to receive telemetry signals.

This shows that the electronic systems were largely operational.

A new addition to the telemetry was measurement of range and bearing.

This relies on a GPS module that was added to the TFT Telemetry terminal which is used to compare with the reported position from the vessel to calculate range and bearing.

First Telemetry signals could be received at around 1.7km.

The vessel finally washed ashore at around 8:30pm.

It could not be seen visually as it came in, but could be tracked using telemetry, to provide range and bearing.

The shoreline appeared rocky and the seas were rough.

It appeared that the vessel was going to wash against rocks.

The telemetry signal was lost at about the time when the vessel reached the shoreline, and so it was assumed that it had been damaged against the rocks. Access to the area was difficult and dangerous in the dark. 

However, another position signal was received via satellite, and so there was evidence that it may have been intact.

It was eventually tracked down an hour later.

It was relatively intact.

The mast and sail had been lost.

Voyager 2.6 as found on the beach an hour after washing ashore, with the tide receding.

It was found that the electronics were in good order. They had been switched off when the vessel came ashore, and tiller was dislodged, flicking the power switch off.

The main electronics had been switched off when the vessel came ashore

The rudder post was found to be bent, as shown in the image below. This probably occurred as vessel was washed ashore. The rudder post was bent, but there was no damage to the plastic rudder bearings, which is good, given the load they must have endured.

It is likely that the magnetic coupling disk popped off its bolt and knocked the power switch off.

A retaining nut had not been fitted, because the disk appears difficult to remove due to the magnetic coupling with its counter-part.

View of Hull showing bent rudder, probably from being washed ashore

Remaining Mast stub covered in sand, extracted from hull.

General appearance of Mast and Bearings prior to mission.

Partially disassembled remnants of Mast showing overlap of inner tube

The mast was made from a length of 12mm pultruded carbon fibre tube.

A 10mm tube was inserted into to it, and projected down pas the top bearing to increase the strength at that point,

Examination of the mast stub showed that it had failed primarily around the point where the 10mm tube ended.

 

Design and Construction Changes after Voyager 2.5 - Part 2 - Voyager 2.6

September 2022. 

Voyager 2.5 has been rebuilt since ending up on the rocks in May. 

She's been rebuilt to directly address the issues encountered in the last voyage, and is now designated Voyager 2.6.

Most of the issues addressed are related to hardening against water and preventing water ingress.,

Voyager 2.6 ready for the water

Most of the water leaked in through the Wing Angle Sensor housing and ran down the silicone tubing cable duct into the main equipment housing to the main controller board.

The Wing Angle Sensor housing was 3D Printed in ABS plastic.

It leaked a small amount of water over the period of two days.

The sensor housing is still 3D Printed, but it is now filled with epoxy resin.

No water should get into the silicone tubing cable duct, but just in case, it has been partially filled with silicone sealant to ensure no water can pass.

Sensor housing potted in epoxy, and the silicone tube cable duct sealed with silicone sealant 

The aim is keep water out of the main equipment housing, but if water does get in, the next aim is to reduce the chance of water causing problems.

The two PCBs for the wing sail controller and main controller have be redesigned to be potted in epoxy resin to improve resistance to water.

This has been been done by reducing the number of onboard connectors, and moving them off-board as in-line connectors. When connectors are placed in-line within the wiring, they can more easily be sealed. The onboard connectors in the previous design corroded dramatically, are a difficult to seal.

More components have been placed on the PCB to allow the overall height of the assembly to be reduced. This allows the whole controller assembly to lifted higher within the equipment housing to reduce that chance of coming in contact with any water.

New controller boards; potted in epoxy and designed to minimise onboard connectors.

Controller Boards

The previous build of Voyager 2.5 included the use of Plasti Dip aerosol spray as a rubberised sealer for some components such as the wing sail battery assembly.

Water leached through the Plasti Dip applied using the aerosol spray. so this was not to be used again.

Plasti Dip no longer supplies non-aerosol products in Australia, but there are competing rubberised paints that can be used as a dip.

Battery Assembly (light blue) dipped in rubber sealant paint.

Fully assembled Voyager Controller for Voyager 2.6 ready for installation

Design and Construction Changes after Voyager 2.5

Design and Construction Changes after Voyager 2.5 - Part 1

The key points learnt from the voyage of Voyager 2.5 in July 2022 were:

1. Ensure no water can get into the electronic compartments
2. Assume water will get in, but ensure that it won't cause any damage.

Step 1. Ensure no water can get into the electronic compartments

Water leaked into the main electronic compartment.

The equipment compartments (excluding the Wing Angle Sensor housing) were tested by placing under water with a covering depth of about 20mm for 12 hours. 

There was no measurable water leak during this time.

Watertight Components

The Wing Angle Sensor housing was tested separately by placing it under water for 12 hours.

A significant amount of water leaked in.

Leak Testing of the Wing Angle Sensor Housing

It became apparent that the majority of water entering the watertight compartments, entered via the Wing Angle sensor housing, and flowed down the silicone tube to the main compartment.

It is not clear whether the water leaked through the walls of the 3D printed component, or beside the brass tube.

The Wing Angle Sensor did fail whilst at sea, due to water damage.

Design changes:

• Add silicone sealant into the silicone tube to form a plug approximately 10mm from brass tube.
• Pot the Wing Angle Sensor housing with epoxy, and allow the epoxy to flow into the silicone tube, up to the silicone sealant plug.

These steps should ensure that the assembly is completely watertight, and that the Wing Angle Sensor is protected from water.

Telemetry Antenna with Breather Cap could extend down further.

The Telemetry Antenna projects up a tube fitted with a cap to acts as a breather for the main compartment. 

The breather allows the electronics to be exposed to atmospheric pressure. This allows an atmospheric pressure sensor to operate.

It also protects the compartments from over or under pressure during the diurnal heating and cooling cycle. If the compartments were sealed, then water on contact with the compartment seals may be sucked in as the internal temperature drops.

 

There is a risk that some water may have entered the compartments by splashing up the vent cap and then down the antenna tube.

This risk should be mitigated by making a vent cap that extends down, almost the full length of the antenna tube.

Step 2. Assume water will get in, but ensure that it won't cause any damage

All assembled PCBs were finished with spray on lacquer Conformal Coating. Multiple coats were applied.

This was completely ineffective when exposed to salt water.

There was considerable damage and corrosion around power pins on all PCBs.

Voyager Controller showing corrosion damage

Wing Sail Controller showing corrosion damage, but not on the epoxy coated board connector wiring

The power connector and servo connector for the Wing Sail Controller were implemented as in-line cable connectors. They were sealed on the board using epoxy resin with cable tie strain relief.

This was successful. Theses connections did not suffer corrosion damage.

The in-line cable connections can be sealed using self-amalgamating silicone tape. This was successful, but care needs to taken to ensure that the tape seals correctly.

Wing Sail Servo controller showing corrosion

Design changes:

• All PCBs will be dipped or brushed with epoxy resin to completely seal them.
• Where practical, all connectors need to be moved off -board and implemented as in-line cable connectors. This is to allow the entire PCB to be sealed with epoxy.

The in-line cable connectors will be sealed using self-amalgamating silicone tape. This has proven to be effective.

 Voyager 2.5 - Detailed Analysis of Failure 

This article aims to provide a detailed representation and interpretation of each piece of evidence obtained from the voyage and subsequent failure of the Voyager 2.5 within the entrance to Western Port.

Voyager 2.5 was approaching the entrance to Western Port, but stopped sailing near 12th July, 11pm and drifted back out to sea with the tide. This was against the South Westerly wind of around 15 to 20 knots. Rather than drift back into Western Port with the change of tide, she drifted east toward Cape Woolamai, for about 19 hours. 

Then she spontaneously turned left and drift north straight on the rocks near Pyramid Rock.

The whole time she was drifting, the winds remained fairly constant from the South and South West. Despite this, she suddenly changed course and headed for the rocks.

Voyager 2.5 as found at low tide, the next morning

View of Voyager showing the equipment containers still intact

The equipment compartments were intact, but about 50ml of water had leaked in to the main compartment.

The smaller forward compartment containing the satellite tracking equipment remined dry and fully operational.

The electronic components in the main compartment suffered significant electrolytic corrosion around the power circuitry.

The computer includes an SD Card for logging many of the vessels sailing parameters.

Fortunately, the SD card is intact and all log files are accessible.

Path of Voyager after failing to enter Western Port, through to the rocks

Each time the computer boots up, it increments a Boot number.

The mission commenced with Boot #501.

The log files showed that the computer stopped logging data about 18 minutes after the failure occurred.

About 19 hours later, the computer started again with Boot #502 and ran for about 5 minutes.

This coincided with the vessel commencing to drift in shore.

Then the computer rebooted again with Boot #503 and ran for 12 minutes.

It then washed on to a rocky beach. The computer did briefly restart with Boot #504 for a few seconds about 3 hours later.

Detail of movement of Voyager near the time of failure.

Detail of movement of Voyager near the time turn to run ashore

View Log Analyser visualising the vessel state after the failure.

The previous image is taken from the Voyager Log Analyser software. This is part of the Voyager suite of software that is used to visualise the vessel state and sailing parameters.

The wind is coming from the South West, and is confirmed by the AWA in the image.

The vessel is drifting out to sea, as confirmed by the COG in the image.

The vessel is lying beam on to the wind.

The rudder command is trying to turn to port, but the vessel is not responding.

This implies that the steering is ineffective.

This could be due to mechanical damage or electrical damage.

On balance, it is most likely electrical damage, due to water ingress around the Wing Angle Sensor housing.

The following video is a screen recording of the Voyager Log File Analyser.

It shows the first minutes of Boot #502. It shows the moments after the computer has started up and establishes its location. the boat id lying broadside to the wind on the starboard tack. As soon as location is established, then it tries to turn the vessel, and it responds in seconds.

This transition can be seen in the first 20 seconds of this recording.

It is unclear if the vessel can steer properly, but it appears that the vessel does have an intact steering mechanism, and it was responsive to the computer.

The recording also shows that the Wing Angle sensor is probably faulty, constantly showing an apparent wind of -6 degrees, off the bow. If the vessel could steer, it would be constantly trying to bear away from what appears to be a head-on wind.

Detailed log of events

Note: Temperature is measured by the Wing Angle sensor, located within the sensor housing at the base of the mast.

• 11/7/2022 07:27:04 Switch on at Torquay Boot #501
• 12/7/2022 14:53:21 Turn at the Cape Schanck waypoint
• 12/7/2022 16:52:44 Temperature reading drops from 15 to 14 degrees C.
• 12/7/2022 22:50:46 Temperature reading increases from 14 to 15 degrees C, after about 6 hours.
• 12/7/2022 22:52       Approximate time of failure
• 12/7/2022 22:52:09  Steering command is trying turn hard to port, the vessel is not responding.
• 12/7/2022 22:56:46 Temperature reading increases from 15 to 22 degrees C, after about 6 minutes.
• 12/7/2022 23:09:46  Temperature reading increases to 82 degrees C.
• 12/7/2022 23:10:12 End of logging Boot #501

• 13/7/2022 18:04:49 Start logging with Boot #502
  Note: The Steering servo would be commanded to centre as part of boot up.
• 13/7/2022 18:05:13 The rudder is commanded to steer to port.
• 13/7/2022 18:05:16 The vessel has responded and turned 90 degrees to port. No longer lying beam on to the wind. No longer held in hove-to state.
• 13/7/2022 18:10:24 End of logging Boot #502

• 13/7/2022 18:10:35 Start logging with Boot #503
• 13/7/2022 18:23:16 End of logging Boot #503

• 13/7/2022 21:05:39  Boot #504, a few seconds only.

Link for plot of positions reported via satellite:

https://maps.findmespot.com/s/VG5D

Interpretation

It appears that the steering failed.

This could be due to mechanical damage or electrical damage.

On balance, it is most likely electrical damage, due to water ingress around the Wing Angle Sensor housing.

It appears that the temperature sensor within the Wing Angle Sensor started to return faulty data in the minute or two prior to the failure. 

The implication is that the sensor was suffering water damage, in the minute or two prior to failure occurring.

The boat drifted in a hove-to situation for 19 hours after the failure.

For this to occur, the rudder would be turning the vessel to starboard, trying to steer too high to the wind.

It seems likely that the steering failed when the rudder was steering to starboard, and then didn't return.

The vessel left the hove-to position at 6:05pm the next day, at the same time that the computer booted up a second time.

When the computer boots up it initially commands the steering servo to centre the rudder.

It appears the steering may have been partially working, to allow the rudder to move and release the vessel from a hove-to state. She then drifted ashore.

This further reinforces the point that the rudder was mechanically operational while at sea, and the failure was due to electrical faults, due to water ingress.

Further Leak Testing 

Water was found in the equipment compartments, and it must be understood how it got in.

The equipment compartments (excluding the Wing Angle Sensor housing) were tested by placing under water with a covering depth of about 20mm for 12 hours. 

There was no measure water leak during this time.

The Wing Angle Sensor housing was tested separately by placing it under water for 12 hours.

A significant amount of water leaked in.