mardi 19 mai 2015

Automatic tacks/jibes performance analysis

I've recently finalized my R scripts to analyse all our racing data. Unfortunately I can only find the data from 2013, but that already quite a few races!

As an example I'll use some newer data that we got during a recent practice (the same I used to make the videos overlays)

From these NMEA records, I compute the rate of turn of the boat, the standard deviation over the heading for the last minute. Using these two measurements along with the speed over water and apparent wind angle I can detect pretty accurately tacks and jibes.

Using the standard deviation and rate of turn I can see when we started our tack.

Using the speed over water, I assume the tack being done/completed when we reach 90% of the speed we had before, and therefore recover our speed. I use 90% because it's a threshold we reach most of the time, if I used 100% with the wind fluctuations I cannot observe these 'stops' all the time.


The plot above represents from top to bottom: Speed over water, Heading and Apparent wind angle

The vertical bars represents:

  • BLUE : Tack or Jibe detected
  • RED : Beginning of the maneuver
  • GREEN : End of the maneuver
Now the interesting part is to calculate how much distance we lost performing that maneuver.
We can do that by integrating over time the speed loss (which is equivalent to calculating the area of the speed dips on the top plot)



When doing that I can calculate how much distance we lost over the competition due to our maneuvers. This is a very important metric, we can try to optimize our tacks and reduce that value!

What I'm interested to see is the distribution of these values. When running the same algorithm for the whole 2013 NMEA data I recorded this is what we find:


This graph shows that most of our tacks are making us loose between 1-3 boat lengths over the distance we would have done without performing the maneuver. This is very good !

Now you can also see that some of our tacks are really bad... There are some that are performed slowly and makes us loose 6 boat lengths or more... This has to be fixed!

What needs to be fixed is the variability of how we execute these. We should be consistent, perform it with the same team, in an almost exactly same way in order to reduce the tail of the chart above.

Tacking in 2-3 boat lengths is a well known rule of thumb, but we need to work on never get slower than that, because you only need one of these bad tacks to ruin your race!

samedi 16 mai 2015

It's all up and running

Today I performed a couple of tests on the system and I can finally conclude that it all works as intended.

Our single board computer now takes care of multiplexing the data from the GPS and our instruments and broadcast that over a secured WiFi.

When connected to the network and listening to a specific port using a TCP socket I can receive all the information necessary. This allows us to wireless connect tablets, laptops, smartphones.

The application I made for my phone correctly shows me our targets as well as absolute and relative differences. The laptop will be helpful for navigation on long distance races (I kept the RS-232 connection though in order to have backup if the WiFi fails, that makes the two connection redundant)

The hot-spot also serves as a "black-box" for recording all the data. Recent python scripts where added to act as TCP client and save all data to a USB flash drive connected to the box. I plan on using that later for data analysis and performance evaluation, as well as for the videos that were described a couple of days ago.

From conception


To realization

The next updates will be done on the Android application. The plan is to create an algorithm performing sensor fusion in order to calculate a precise distance to the starting line, and estimate precisely if we're early or late to the start.

I'll also restart to work on the application used on-bord for the MAC, make sure everything works correctly and enhance the tracker to allow finding boat and plotting their trajectory in a nicer way.

mercredi 13 mai 2015

Using Boat Instruments and Video to Enhance Sailing Practice Sessions

I recently found a way to incorporate our boat data to videos we shoot. The basic principles are:

- Collect all NEMA messages
- Take a video
- Synchronize the two and create nice gauges

This process is pretty much straight forward, however I faced a couple of issues in the process:

- The synchronization is not always evident, I used our tacks and distance between the tacks in order to find how to synchronize the video.
A better approach would be to film a watch and thus "time-stamp" the video so I can use the NMEA GPS timestamp to then find a sync point.

- The NMEA data understood by most software are GPS ONLY, this is not what I want. I want to have our wind instruments measurements, I want to have our speed over water values and I want to have our upwind and downwind optimal VMG targets.

The first piece of software I created was to take as an input NMEA data and create a CSV file. NMEA information comes at irregular interval, sometimes data is missing and needs to be linearly interpolated.

Now I wanted to have the optimal targets on it, so I have to include them using the velocity prediction calculated for our boats:


Once you have that the remaining action is to synchronize the data with the video, and create overlays

At the end you have a very sweet video that you can use to review your practices, see when you're fast, when you're slow, and what can be improved. Et Voila!


And the youtube video:





vendredi 8 mai 2015

Using Data to 'win' Sailboat races

I've been sailing for quite a few years on the great lakes, doing various buoys and port to port regattas. I decided last year to use the skills I developed at work and bring that to the boat to have an edge on others, so in early 2014, I started developing a system that allowed us to have a clear edge on the competition by using data publicly available, some creative ways of gathering the data and the good tools to analyse it.

We did out best ever Mackinac race that year, and I'm pretty sure it'll be hard to reproduce.

Preparation


I started gathering and observing weather data for that race 7 days ahead, collecting the data ahead of time allows you to see how the foretasted results evolves. If you see that for 7 days in a row, the wind speed and direction are the same for the day of your race, you can assume that the model is pretty stable and results are solid. If you see huge variations from day to day, it's likely that big perturbations are in the area, and the models have a hard time predicting what will happen.

3 Days before the race, I knew what the strategy will be : I wanted to be the leftmost boat of the fleet. I sent a couple of emails to everybody everyday refining our route and strategy but the overall plan did not change. Why? Because fronts were coming from the west and I wanted our boat to be the first catching it while everyone else will be stuck in high pressure system on the east side.

That's a very short story to let you know how I prepared for the race, but what about the other systems I told about in the first chapter? Read next.

Capabilities of our boat

 Our boat was able to:
  • Gather weather forecast from various models as soon as they were published by the NOAA
  • Selectively get a portion of our area of interest to reduce the time it takes to download things
  • Sends Tweets (text and images)
  • Post on Facebook (configured by following our twitter account)
  • Re-estimate the best route with every weather forecast we had
  • Know the position of all the other boats at any time
To do that I created a system made of two parts: A server that was running at home waiting for my commands, an POP/SMTP client used on the boat to send receive messages.

The mode of operation was pretty simple, if I wanted to know the weather forecast, I was sending an email to my server with a specific title like when my server receives the request, it downloads all the necessary files from the NOAA servers, stack them hour per hour, and truncate them to only use the desired area. Thus files sent back to me where around 44kB only and downloadable in a read.

There are systems commercially available for that but the only provide you with GFS models, ours could grab any model, thus we had a better overview of the weather ahead of us.

We could also send tweets like this one :
For that I needed to take a picture, resize it to a very small image to weight no more than 20kB and sent another type of email to my server. Then the server took care of publishing out tweet.

For the positions of the other boats it was also pretty straight forward. But required some hacks, our positions are relayed to the public using the website Yellowbick. They have a pretty nice webpage and JavaScript client that displays boats on a map. 

However we didn't wanted to download the whole page all the time with our cheap satellite connection, this was just impossible. So the server was doing it for us, send an email every time new positions are available, and I used my custom made software to display course, speed, heading... of all our competitors, this was our little spy:


We're also using the forecast and a software that performs optimal routing using dynamic programming. The inputs it needs are: The predicted performance of your boat, the weather forecast and a GPS point to go to. Then what it does it try for many different increment of headings to find the route that takes you the closer to your destination in the shortest amount of time. And provides you with very good information about where to be on the race course:


All of that was running during our race, and it allowed us to finish in second place. Now what second? We didn't win? No because we were a bit too slow at the beginning, but we'll fix that this year with some other data and visualization tools.

Conclusion


We'll use all these tools again next year, we'll improve on our satellite communication to have a more reliable connection, and we'll also train hard to stay on target all the time. The WiFi transponder and App described a year ago will be very useful!

mardi 8 avril 2014

Why and how NMEA over Wifi

NMEA Over Wifi, what is that?

Most racing boats are using sensors and display using of the shelves components provided by a couple of manufacturer. Each of them are using different protocols and are usually obfuscated and incompatible. However the NMEA0183 and NMEA2000 protocols are standards defined to allow multiple components to exchange data together and are widely used as interfaces between specific equipments.
On the racing team I'm sailing with we're equipped with a B&G H1000 system, while this system has it's own proprietary undocumented H1000 protocol, it also capable of outputting NMEA sentences for use with other components.
These are right now all connected to each others using electrical signals carried through wires and respecting the RS-232 electrical levels. This system works well but stays confined into the navigation station area of the boat where we also have our onboard computer.


The representation above shows our instruments installation, I did not detailed the H1000 system but it contains speed on water and wind instruments, magnetic compass and displays. The H1000 NMEA interface uses the proprietary data and converts it to standard NMEA0183 frames.
The drawback is that the H1000 network refresh information with a frequency of about 5 times per second while the NMEA output is only refreshed every 2 seconds or so. We have a much slower rate of information available there.

The new system will introduce a WiFi hotspot in the system, giving us the advantage of allowing the laptop to be still connected to the instruments network but also to have handheld devices connected to the network:

Tables and phones can now see the instrument data and represent information to the sailors of the boat.

While we already have displays for regular information like speed on water, wind information... We can now build our own application and filter/interpret the NMEA data.

The first application of the laptop is to record all data and allow to check that instruments are properly calibrated, it also helps for weather routing, navigations and waypoint management.

The handheld devices will be more specific to each persons in the cockpit. Our custom made app is able to provide to the Tactician, Main Trimmer and Driver information such as:
- Actual performance versus optimal performance (in development)
- Estimated distance to the layline (idea)
- Favourite end of the starting line (idea)
- Distance to the starting line (idea)
- Heading and distance to the next waypoint (idea)
- Timing features for starts (idea)

We can now display any information to these people, assuming that the wind instrument reading are correctly calibrated. We can potentially ditch the laptop and use a tablet for navigation but we may need it still for long races where weather routing and satellite connection is giving an advantage.

WiFi Hotspot

This idea came after we started to develop custom software for the laptop, by discussion after races around the grill we started to imagine what a wireless system could be done and what could it provide. Not knowing anything about that but having couple of engineers in the team we started to experiment with the RaspberryPi. This solution provided us with a hotspot for a cost of around $50 using already existing software.

After a couple of trials and errors I opted for a solution using the IPE operating system and Kplex multiplexer software. The specific OS is a read-only system that will tolerate power failures very well and will prevent from having corrupted memory on the device. This was mandatory for a correct reliability of the WiFi hotspot but still provides the advantages of using a debian based linux operating system. Again with that os we can develop custom software for data filtering or transmission of information.

The Kplex software was a great surprise, instead of implementing myself the program that will read serial port information and stream it though TCP and UDP packets over the WiFi, I found that someone has already done that and used an open source license. Thus we could just save time and efforts by reusing this amazing piece of software.

The hotspot is now used as a testing platform, I'm sending NMEA data recorded 2 years ago during the NOOD series races to feed in my phone application and develop the code needed for correct visualisation of the data. This setup is the simplest and most reliable that I've experimented with to data leaving me more time to focus on the Android development rather than troubleshooting electrical problems.
Second testing platform, much simpler and robust
First testing platform to feed simulated NMEA to the system


Custom Android Application

This application is currently in development as in order to keep this article up to date I prefer to refer to the GitHub development page, so I don't have to update images and documentation on multiple pages :)

Please visit the application specification page for more details

The overall goal is to provide custom information when it's necessary to whom it is necessary, look at what Jim pithill was wearing during the races:
Left arm custom made instruments repeater
Right arm custom made smart watch repeater



Now this is not as advanced as what Richard Kent is developing for the multiple America's cup and Volvo ocean races he works on but this is a good start for an open source project that could benefit the racing community.

lundi 18 novembre 2013

Pi Controlled Garden


Introduction

Here's the thing, I love fresh herbs for my salads, but have a tendency to forget to water them properly... In the summer I keep my little garden on my balcony and it does pretty well, but in the winter it must be kept indoors.

With the winter and it's shorter days coming, two T5 tubes of 28W each were installed to help these little plants. There were happy and thriving:

Original setup with a regular timer
I also wanted to water them automatically, and play with a raspberry pi this rainy weekend, so I started to gather ideas:

Project specifications

The system must: 
- Be autonomous for two weeks (I will leave for two weeks in France for vacations soon)
- Be quite simple and not cumbersome, I do not want a heck of a network and cables running in my kitchen
- Be able to oxygenate the fertilizer solution to provide dissolved oxygen to the roots of the plants
- Run on a PI for the fun of it
- The the system will run on a gallon of water + fertilizer mix controlled by a valve

Oxygenating the solution is important: Oxygen helps the roots to absorbs nutrients, it also helps stirring the solution before pouring it on the soil.

Hardware

Here is the list of the necessary hardware:
- RaspberryPi Rev2 board + SD card
- A samsung smartphone charger for the power supply
- Relay module
- Valve gravity feed 110V
- Small wiring for the board, scavenged from phone lines cables
- 110V electrical cord for the light, valve, air pump
- Transparent aquarium airline tubing + T-splitters
- Black aquarium airline tubing + T-splitters
- Aquarium air pump
- Screws, glue, tape

I used the black airline tubing for the water+fertilizer solution from the tank to the plants. This is important as we do not want any sunlight going throw the solution and algae growing in the tubes and valve... The 1 gallon tank also need to be black or stored in the dark.

Building the system

Raspberrypi and relay module

By looking at the I/O availables for the pi, I selected 3 I/Os that will be used as outputs to control the relays and soldered a cable to connect the two boards.
The selected IO as 14, 15 & 18 on the P2 connector. The same connector provides +5V and GND to power the relay board. Each relay does not consumed much and the PI power supply can take that load. Moreover all relays on the board  are driven by optocouplers, this is nice as each GPIO cannot provide enough current to directly drive a relay.


Wired pi and relay module
In order to make the link between these boards I used a 14 pins IC socket that was cutted in two and solder the wires on the two half sockets. That way the board can easily be connected and disconnected.
Splitted in two, this offers a nice and cheap connector.

Setting up the PI

The first step is to download the Raspbian OS and put it on a SD card. This step takes some time but is quite easy buy following the steps on the elinux beginner guide.

After booting up the pi you can configure the setup of the OS and install a few things. I would recommend these importants steps to configure:
- Maximize the partition to the size of the SD card (gives more room than the original image)
- Enable SSH server (allows to remotely connect to the pi)
- Change password (123456789)
- Reduce the memory shared by the GPU to 16MB (we'll not need the GPU for displaying graphics)

I also installed Apache/MySQL/PHP in order to maybe provide an webinterface to the watering system but haven't found time to code that yet.

The idea then was to use crontab to start scripts that will energize the relays for taking care of my herbs

Scripting

The best way I found to command the GPIO for a PI is a python library called RPi.GPIO. I have very little experience in Python but prefer it than bash scripts ;) This library is very simple to use.

Scripts specifications

The project will be made of 3 scripts:
- One for controlling the light
- One for controlling the air pump
- One for controlling the watering valve

All scripts will be controlled by one configuration file

Each of the scripts will write in a logfile what is beeing executed and at what time.

The scheduling will be done by crontab, that will run one or the other scripts at defined time.

I wanted to avoid a water disaster, but haven't worked on monitoring the system, I would need to read the power given to the valve. However at worst I have a gallon of water in my kitchen which is no so bad :)

Scripts themselves

Here is the code for each of the python scripts, all the files can be found on this github repo.

Basically all files starts with: importing libraries, starting a log file, reading the configuration file and initializing the GPIO of the PI. The following code is the beginning of the lightSTART.py file

import RPi.GPIO as GPIO, time, logging, sys, signal, ConfigParser, os
#setup logging class
dir = os.path.dirname(os.path.abspath(__file__))
logfile = dir + '/logs/info.log'
logging.basicConfig(filename=logfile, level=logging.INFO)
#read configuration file and retrieve light duration
Config = ConfigParser.ConfigParser()
Config.read(dir + '/config.ini')
duration = Config.getint('params','light')
#configure GPIO
GPIO.setwarnings(False)
GPIO.setmode(GPIO.BCM)
LIGHT = 14
GPIO.setup(LIGHT, GPIO.OUT, initial=GPIO.HIGH)

The rest of the code will handle signals that can be sent to the process in case of Ctrl+C is pressed to halt the script, and the start() method that starts the light itself.

def signal_handler(signal, frame):
        msg = 'You pressed Ctrl+C! Lighting STOPPED'
        logging.info(time.asctime(time.localtime()) + ' ' + msg)
        print msg
        GPIO.output(LIGHT, GPIO.HIGH)
        sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)

def start():
        #starting the light and saving the time at which it started
        start = time.time()
        GPIO.output(LIGHT, GPIO.LOW)
        msg = 'Light STARTED'
        logging.info(time.asctime(time.localtime(start)) + ' ' + msg)
        print msg

        #checking how much time has elapsed every hours
        #if time elapsed is more than 8 hours then break
        elapsed = 0
        while True:
                elapsed = (time.time() - start)
                if elapsed > duration:
                        break;
                time.sleep(1)

        #shutting the light down after 8 hours
        GPIO.output(LIGHT, GPIO.HIGH)
        msg = 'Light STOPPED after %d seconds' % elapsed
        logging.info(time.asctime(time.localtime(start)) + ' ' + msg)
        print msg
        

if __name__ == "__main__":
        start()

I chose to use methods instead of creating a flat script so I can load this as a module in other scripts if needed and call the start() method. Basically all scripts are using the same structure, with different GPIO configuration and timings.

I do not really like the while loop running for 8 hours... In that case I'd maybe better do something like a crontab task to start the light and one to stop the light. Or maybe I could do a script called every minute to check what is the current time and decide if the light should be ON or OFF, that way if the power fails and the system reboots, the light will be ON.

My PI is not connected to the network in "regular operation". I use a long cable across my appartment for debugging only. This makes the project fragile against power outages as the clock will be lagged (as long as the outage lasts) for the execution of the crontab. By default Raspbian has no RTC chip, so it tries to :
 - get the time from NTP server at boot and every 3 hours
 - get the time from the fake-hwclock module
- set the time to the fake-hwclock every hour

As the Pi will not have NTP option available, a crontab job is defined to set the fake-hwclock every minute instead of every hour. That way in the case of a power failure the system clock will be delayed only by as much time as the power outage lasts. And not by increments of one hour.

Crontab jobs

There are three crontab jobs, edit them using >sudo crontab -e.
The RPi.GPIO python library needs root access to change the state of the I/Os, moreover the root level is required to set the clock to fake-hwclock, so sudo is necessary.

* * * * * fake-hwclock save
0 6 * * * /home/pi/scripts/lightSTART.py 2>>/home/pi/scripts/logs/cron.log
0 11 * * * /home/pi/scripts/airWaterSTART.py 2>>/home/pi/scripts/logs/cron.log

Redirecting the STDERR output to a file helped me a lot debugging the execution of the scripts, now it could be taken away but I keep this configuration for a while to see how the system runs. It could still be considered a testing phase as the system is less than 24 hours old now.

Installation

For the setup I wanted minimal impact on my kitchen environment so I tried to hide everything in and under the cabinets. In the cabinets I put a 1 gallon water bottle that contains the fertilizer solution and the air pump. The water line and electricity for the pump are running though a small hole at the bottom of the cabinet:

Gallon filled up with clear water in the cabinet.
Air pump in the front. Air and water lines coming from the top of the jar.
Lots of flour for making lots of crepes !
The electronics is secured upside down under the same cabinet, and wires are organized to have a minimal impact on my view :) What I can see when I'm standing up there are only the line for the water/fertilizer and the electrical cord for the valve and the light.

Power strip tapped in from behind the microwave
Relay board (blueish) and Pi module temporarily connected to the network
The circular object on the front is a kitchen workplan light
 The valve gave me some trouble... a few leaks. I used two bronze threaded adapted from 1/16 inch pipe to 1/4 inch pipe. The transparent 1/4 inch pipes are connected to the solenoid gravity feed valve. There were taped black later on to avoid light and algae growing in the pipes and valve.

This setup was good but leaked around the valve and adapters.
The bronze adapters were leaking though the threading, so there were filled with super glue
The valve was leaking due to plastic molding imperfections that were polished off

The valve outlets were polished off, because by default there was an imperfection that let air and water leak. It's probably due to the fact that the valve was made of two plastic pieces melted together and it left and edge.
The little linear edge can be seen on the top of the outlet. This was sanded off.
Watering the plant themselves was done using the black pipe fastened using cable ties on kebab sticks:

Black pipes are bringing the fertilizer solution to the plants.

Update:

The pipes that bring the solution to the plants deliver very inequal amounts of solution, some where not outputing anything...

In order to solve that issue I decided to raise the pressure in the tubes, that way a little difference of output height will not make a big difference to the flows. So the plan was to seal the output, and leave only a tiny opening. This tiny opening will make the pressure raise in the tube and level out the amount of solution delivered per output.

Well it was late in the evening and I wanted to fix that, so how to seal the output and only leave a tiny opening:
Yep, a screw at each output: Regulates the flow as the solution
can only go though the threading to get out of the tube

Voilà!

It was a fun Sunday, I havent done such DIY things since a long time and remembers me my old time.

I'll need to adjust the watering time, any maybe will post a picture when the  plants thriving again!

References

Syntax Highlighting with Blogger Engine: http://www.craftyfella.com/2010/01/syntax-highlighting-with-blogger-engine.html

Others are linked within the page



lundi 27 mai 2013

Bénéteau 36.7: Experiencing with current flows


The issue on the boat:
There is current flowing between the mast and the keel. A little bit of current might be expected: there are sacrificial anodes on the boat, they create a galvanic cell thus a current. However our saildrive is not supposed to be connected electrically to the ground, see this article. So this current is not coming from a galvanic cell on board, it's probably a current leak from one of the wires going up inside the mast.
All the lights on the mast as well as the instruments and the radio are functioning correctly. We checked all the cables and made sure none was electrically connected to the mast. Most of them were not except the shield of the VHF antenna. This coaxial cable shield is connected to the connector, which is connected to a metallic bracket fastened with rivets at the top of the mast: Here is the electrical path, the cable of the VHF antenna.

We measure the current flowing through the keel from the lightning protection cable, this is the only electrical link to our keel. So we placed a amp meter in series with that cable:

The picture above shows a very small current flowing: 3 µA or 0.000003A which is almost nothing, we don't have to worry about a lot of corrosion here. The issue is when we plugged the shore power to the boat, that value jumped to 300-2000µA. Here some concerns can be raised about corrosion as the cord is usually plugged for very long hours.
As the only electrical path identified before is the VHF antenna shielding or ground, we disconnected the antenna: 




When the antenna is disconnected we get very low current: 0.5µA or 0.0000005A: close to nothing.
So to summarize:
  • Boat in the water, VHF antenna connected, shore power disconnected: very little current.
  • Boat in the water, VHF antenna connected, shore power connected: non negligible current.
  • Boat in the water, VHF antenna disconnected, shore power connected: close to nothing.

 So apparently two majors actors in the equation: The shore power and the VHF antenna.
We decided to carry on, keep the VHF antenna connected, let the shore power cord plugged on the boat, and trip open all the circuit breakers, one is in the lazarette, one by the nav station.

 The circuit breaker of the lazarette disconnects two of the tree wires in the cord from the electrical system on board. It disconnects the hot and neutral wires. The ground (used as a safety) stays connected. We measure again the currents and got the same results.
  • Boat in the water, VHF antenna connected, shore power disconnected: very little current.
  • Boat in the water, VHF antenna connected, shore power connected: non negligible current.
  • Boat in the water, VHF antenna disconnected, shore power connected: close to nothing.
Conclusion, we have a grounding issue with the shore. What can be tested: disconnects every power equipment on board one at a time and measure. If there is no difference in the measurements the component we disconnected is not likely to be the cause of our problems. So we started by disconnecting the battery charger:

On the picture above you can see the hot and neutral wires disconnected and taped (the tape prevent accidental shorts and sparks if you forget about it or power up the system again) You can also see on the picture above that the ground is still connected, it should be disconnected (I took the picture at a bad time).
After measurements no changes, so the charger is not likely to be the cause of our issues. We then try to disconnect the ground from the water heater. Besides the fact that we never use it, the water heater is connected to the shore power in case of the crew needs to take warm showers while staying on dock :)

The picture above shows the ground cable (green) disconnected from the water heater, et voila ! The measurements are not fluctuating anymore weather or not the shore cable is connected. I don't say we fixed all the issues, but we isolated one of the major contributors to our current flow.

As we never use the water heater and it was obviously a source of problems we chose to disconnect it completely from the power panel in the nav station. The green wires all disconnected are the grounds of the on-board equipments: Heater, charger, outlets.

Note: Be sure that nothing is connected to the outlets while making that test, this might be a source of problems too on your boat if one of the appliances is leaking current.


The the power panel the heater in completely disconnected and the poles are taped, this reduced a lot the current flowing through the keel while connected to shore power.

Conclusion:
  • We had currents flowing through the ground of the shore power, then thought the heater and somehow back to the electrical ground of the VHF and finally the keel. This electrical path is now broken open and no current can flow.
  • Our approach is maybe a little bit radical, we might test if a diode based galvanic isolator on the shore ground would solve this issue or not.
  • How is the current flowing from the heater to the ground of our VHF? There are no links between the 12V electric system and the heater, and the battery charger was disconnected... Don suggested that the water heater might have been damaged a year ago when the engine overheated. Something might have been damaged inside the water heater or corrosion might have developed and offer a path for the current to flow. The current might flow then though the engine coolant to the engine, then as the engine is connected to the 12V ground this causes an issue with the keel which was connected to the negative pole of the batteries though the VHF antenna.
  • We also plan to isolate the bracket holding the VHF antenna from the mast. There is no need for that, and it cannot hurts to do it. The good of that is that we'll break another electrical path for currents to flow and prevent further damage.

Be careful while opening all these electrical boxes and playing with shore power, this might hurt or kill you...

Please also use a meter when trying to find issues concerning galvanic corrosion on a boat. All the legends that you hear on dock, at the yacht club or in the yard are most of the time based on other sailboat wiring designs and might not apply in your case. Just use a meter and isolate the issues, this is your best bet!

BoatUS provides also a nice article on issues from shore power. Basically what we did above was trying to disconnect the shore ground from the conductive elements of the boat in the water.

Thanks Don for providing the boat and the camera!