Another Ham who was bitten by the Fox Hunting Bug in the early 90's. Participated in numerous National DF championships and likes nothing more than the challenge of finding *any* hidden radio transmitter. Has been involved in HAB experiments since 2010. Goal is to fill his Toyota Hilux so full of DF gear that he has to buy a Landcruiser.... Approximately half way there.
It’s never a good idea to go and place a new boat in the wire and head off into the blue yonder and not expect problems. So to keep things simple I arranged a couple of mates to help and dropped the Nereus into the North Arm of the Port River.
So far so good, it floats ! You’ll have to excuse the state of the pontoon, the local Pelicans have made it their preferred home during the Winter. Once in the water the obligatory “is water coming in” checks were done, it certainly did not have to go back on the trailer.
There was nothing left but to go for it and take things easy. So while cruising slowly towards the Port River the steering and gearbox (ie reverse) were checked, along with lights, bilge pump and the fish finder. Here’s a video of us just pulling away from the pontoon in the obligatory 4 knot zone coming out of the North Arm,.
Once clear of the North Arm we could then head towards Outer Harbour with a bit more power on keeping within the 7 knot limit. During this time we were watching the temperature of the engine and making sure things were going as planned.
Eventually however we were able to open the throttle and put the old girl up onto the plane.
Of course not everything goes to plan and the Log gland decided to spring a leak. It was certainly letting in a reasonable amount of water. A little more grease forced into the gland helped slow things down, but it will certainly need to have the two seals changed when I can find the time to pull it apart.
On the way back up river we managed a couple of high speed runs at wide open throttle (WOT). It was only then we found that the heat exchanger was not quite keeping up and the engine temp started to rise towards 100 degrees Celsius. Simply lifting the throttle and slowing down was enough to drop the temp back to normal. So this will certainly require some further investigation.
Getting out on the water in any boat is a great way to spend an afternoon even better when you can share it with a couple of friends. The trip was certainly successful with only minor issues found and nothing that resulted in us being towed home. We certainly can’t ask for more than that.
At some point I’ll also either capture a video or some photo’s of putting this boat on the trailer. There is a unique catch on the bow that allows the boat to be driven on and caught without having to get out of the boat. The first time we put her back on I was a little preoccupied with not hitting anything so didn’t capture anything. Next time.
To start with I went looking for a very basic graphics library that would allow me to experiment on frame buffer devices. There is certainly no shortage of libraries to choose from. The library that I settled on was the “Lightweight C 2D graphics API agnostic library with parallelism support” written by grz0zrg. It had both PNG and JPG routines that could output to a simple frame buffer device, being written in C was also a winner.
Flicking through the various examples the quickstart.c file seemed to have nearly everything I needed to display a PNG file on my OLED. Not so long ago a fellow AREG club member shot me some icon files for our club website; one of these icons was 512×512 pixels in size which made it an excellent candidate for shrinking to 128×128 pixels and using it on my OLED.
Downloading the library was as easy as;
$ cd ~
$ git clone https://github.com/grz0zrg/fbg
If you don’t have git installed use the relevant apt-get command. The example files can then be found in the following directory;
$ cd ~/fbg/examples
I then copied the quickstart.c file and hacked on it a little, modifying it like so;
int file_exists( const char* filename )
//define file handle
//attempt to open file read only
if( (file = fopen(filename, "r")) )
fclose(file); // release file handle
return 1; // tell someone we found it
return 0; //no one home
int main(int argc, char* argv)
const char* framebuffer_name = "/dev/fb1";
const char* logo_filename = "logo.png";
//check we have a framebuffer to talk to
struct _fbg *fbg = fbg_setup( (char *)framebuffer_name, 0);
if (fbg == NULL)
// make sure logo file exists
if( !file_exists( logo_filename ))
printf("File not found: %s\r\n",logo_filename);
//draw something on the display
struct _fbg_img *logo = fbg_loadPNG(fbg, "logo.png");
fbg_image(fbg, logo, 0, 0);
Which was built with the following command line from within the examples directory;
Hacking upon the Makefile is also not that difficult, I simply added the relevant lines the SRC and OUT sections, then copied the quickstart section and renamed display_logo. There is lots of information about on how to do this on the internet so I’ll not repeat it again unnecessarily.
All I had to do then was place my 128×128 PNG file alongside the display_logo executable (renamed logo.png) and run it… wallah ! I was greeted by the AREG logo on my small OLED display in all of its 128×128 pixel glory; see the image at the top of this post.
So the next trick is to move this to the boot process… So by the looks the plymouth package might be the go, only one way to find out.
After having woken up my small 128×128 OLED display I was wondering how to get it to start automatically each time my rPi booted rather than having to log in and run the commands manually.
It turns out this is rather easy and just required me to edit two files. I’m also glad that these Waveshare OLED displays are effectively compatible with the Freetronics OLED 128×128 graphics display. A big thanks to the Freetronics team for making this driver available for SED1351 chip sets.
So I created the following file with my favourite editor (as root) /etc/modprobe.d/fbtft.conf with the following contents;
options fbtft_device name=freetronicsoled128
What this effectively does is tell the system how to configure the fbtft_device as it boots, much like if we started it with modprobe from the command line i.e used the following command;
So now the system knows how to configure the driver, we need to tell modprobe to load it by placing an entry in the /etc/modules file. So using your favourite editor (as root) edit /etc/modprobe and append the last two lines.
# /etc/modules: kernel modules to load at boot time.
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
It appears that the SPI bus is a little slow to load if it’s called as a dependency of fbtft_device, which is a classic chicken and egg driver problem. So by starting it manually we make sure it’s available by the time the fbtft driver tries to do anything.
The i2c-dev entry in the same file fires up the i2c bus and was already pre-configured in my system by raspi-config way back when. I’m using it in my project, YMMV. All that is left to do is test it, so reboot and login and run the following command;
$dmesg | grep graphics
We should see something like the following;
[6.128978] graphics fb1: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB buffer memory, fps=20, spi0.0 at 20 MHz
That tells us that the little OLED display has registered as /dev/fb1 and that it’s ready to go. You can use the con2fbmap trick in my last post to test it’s working.
Now to work out how to get it to throw up an image on boot…
I recently found myself at the very limits of what you can ask an Arduino Uno to do, both in terms of flash and speed. I’ve used Atmel AVR processors for nearly 20 years so I know them and their foibles very well.
At work a while back we started using various STM32 processors and that has been somewhat enjoyable, I now like throwing floats around instead of having to resort to fixed point maths and excel for algorithm development. I’d heard that you could run up the Arduino framework on the STM32 platforms so was keen to try it.
So I initially went looking for a well supported board and simply struggled to find one. It seemed that this space had come and gone rather rapidly. Further research showed why, the Chinese clones has effectively decimated this market due to price. I was still keen to give it ago so placed an order for two Maple Mini boards with the STM32F103CBT6 processors on them off eBay for the princely sum of A$20 with free freight. Little wonder everyone abandoned ship in mid 2016.
A big thanks has to go to Leaflabs since they have left all of the circuits, boot-loaders & design files in a GitHub repository here (click).
So what did we have to do to get these working ? It wasn’t as trivial as the Arduino Uno that is for certain.
The first step was to get Windows 7 drivers (yes I know it runs out next year) for the Maple Mini, I found some here (click). I basically hit the green button marked “Clone or Download”, saved the file on my local machine. Extracted the files from the archive to a temp directory, then via the System Manager clicked on the “Maple 003” device that appears, told it I wanted to update the drivers from a specific location then pointed it at the temp directory I’d stored the files in previously. It figured it out and installed the ones I needed. What I found amusing is it then appeared under a category called “Atmel Devices” since I’d installed tools based on libdfu for these devices once upon a time ago. YMMV.
Once I had drivers installed I could then fire up PlatformIO in the VSCode editor and attempt to create a new project. I selected the board type “Maple Mini Original” and “Arduino” for the platform and let it do its business. Unfortunately the processor I have and the one on the original maple mini are different, so I had to change a few things in the platformio.ini file; my config is below. This config is based on a PlatformIO blog post written by Vortex314, can’t thank them enough for sharing this information (click).
So what is so special? Firstly there are separate board_build definitions to set the processor and speed for the board. Thankfully the cores between the original board and my Chinese clone are similar enough for this to work. Secondly there’s a heap of additional build flags that will build in a USB serial port. So if you’re used to the USB serial to debug your code this will still work. You can find out a little more about why this is necessary on Roger Clark’s website here (click).
It is interesting that the boot-loader contains only DFU code and that the application needs to have the USB serial built in separately. In the above configuration you may notice that the VID is 0x0483 which is by design, this means the Communications Device Class (CDC) will trigger the ST Serial drivers on a Windows installation if you have them installed. If you don’t you can find them here (click).
So from within the PlatformIO environment we can write our code and build for our target. Here’s my very simple test program that flashes the onboard LED (pin 33) and will send some test data to the USB serial port.
// put your setup code here, to run once:
pinMode( 33, OUTPUT );
static int i = 0;
// put your main code here, to run repeatedly:
digitalWrite( 33, HIGH );
digitalWrite( 33, LOW );
So the last comment I need to make is in the programming of the device. When you hit the upload button from within PlatformIO you’ll see OpenOCD start and then pause with the comment “Searching for DFU device [LEAF:0003]” and if you wait long enough a subsequent message flashes by reading “Couldn’t find the DFU device: [LEAD:0003]” and nothing appears to happen.
Initially I thought my board was dead when it dawned on me… The Arduino uses a separate ATmega8U2 that is capable of resetting the target ATMega328 under software control, the STM32F103Cx is using the internal USB port and does not have this reset function (*face palm*). So when we start the program cycle we need to wait for the “Searching for DFU device” to appear and then manually reset our target to force the boot-loader into DFU mode momentarily where it is then caught and updated. Once done the process carries on as expected and you find you haven’t bricked your device.
Recently I was searching for a small graphic display that I could connect to a Raspberry Pi and fit within a Phoenix DIN enclosure I wanted to use.
There isn’t much space in the front of the enclosure I wanted to use, but a small 128×128 OLED colour display seemed it might fit.
Trawling through eBay I found what I thought to be a suitable unit and simply placed an order. There was very little information on the eBay site to tell me which display I had purchased so I just waited. When the display arrived it turned out to be a Waveshare SKU:14747 with the SED1351 controller.
A little searching around the web and I found an excellent tutorial written by the Freetronics Team for their 128×128 OLED display. It turns out our displays share the same SED1351 controller, so it was the logical place to start with my small display.
First task was to map the OLED pins to my rPi 3B+ 40-pin GPIO connector. On the rear of the display the pins and their desired function were clearly marked, so I mapped the pins like so;
I have also included the rPi pin numbers I used, make sure you plug the display into the right pins if in doubt RTFM. Once it was wired I ran the following commands to make sure the rPi was absolutely up to date;
The latest version of Raspbian Lite I was using (Buster) came with the fbtft frame buffer drivers already installed, so these steps were unnecessary. Since this Raspbian installation was fairly recent I decided that I didn’t need to update the rPi firmware using the rpi-update command like in other tutorials; YMMV.
I had already enabled the SPI bus on my Pi when I was coming to grips with the I2C bus. I found the tutorial at Sparkfun a really good reference and easy to follow. To create the frame buffer for the OLED device I ran the following command;
Fingers crossed we see the following output in our terminal;
fbtft: module is from the staging directory, the quality is unknown, you have been warned.
fbtft_device: module is from the staging directory, the quality is unknown, you have been warned.
spidev spi0.0: spidev spi0.0 125000kHz 8 bits mode=0x00
spidev spi0.1: spidev spi0.1 125000kHz 8 bits mode=0x00
bcm2708_fb soc:fb: soc:fb id=-1 pdata? no
spidev spi0.0: Deleting spi0.0
fbtft_device: GPIOS used by 'freetronicsoled128':
fbtft_device: 'reset' = GPIO24
fbtft_device: 'dc' = GPIO25
spidev spi0.1: spidev spi0.1 125000kHz 8 bits mode=0x00
spi spi0.0: fb_ssd1351 spi0.0 20000kHz 8 bits mode=0x00
fb_ssd1351: module is from the staging directory, the quality is unknown, you have been warned.
graphics fb1: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB buffer memory, fps=20, spi0.0 at 20 MHz
The output here shows us that the SPI bus is OK and that we now have a frame buffer /dev/fb1 that is expecting to find a SED1351 LCD controller. So now it was time to display something so I used following command;
con2fbmap 1 1
And here is what I see;
w00t it works ! Now it’s time to go and find some graphics libraries that can talk to this frame buffer device… and to work out how to display text in boxes that is wider than 80 columns in WordPress…
One of my upcoming “Radio” projects involves MQTT running on a raspberry Pi. I’m more familiar with C than I am with Python so to talk to the MQTT broker I went looking for a C based client.
I eventually settled on the Eclipse Paho MQTT C Client library, however it doesn’t come with an ARM based Linux binary package like you get for all the python peeps. Instead you’ve got to compile this from source, I guess since I’m intending to use C in the first place I should be OK. So back to the command line.
Starting with a bone stock installation of Raspbian Buster Lite I simply used the following commands in a shell;
$ sudo apt-get install git libssl-dev doxygen graphviz
$ cd /tmp
$ git clone https://github.com/eclipse/paho.mqtt.c
$ cd paho.mqtt.c/
$ make html
$ sudo make install
$ cd /tmp
$ rm -rf paho.mqtt.c
I found all of the commands above in the git repository README.md file. One thing I noticed was when compiling the libssl-dev library generated a good many “deprecated” warnings about old TLS ciphers being used (ie TLS 1.1, 1.2, 1.3 and SSL 2.0 & 3.0) so if you’re intending to use these it might be best to dig a little further. In my case this wasn’t important so I’ve filed it away here as a note to self for future reference.
So now it was just a question if the library works, the simplest way to do this was to compile the included examples and see if they work. So back off to the command line we go.
So while testing the heat exchanger and thermostat were working I also found the alternator was not charging the battery. I’d noticed that the volt meter on the dash was not showing more than 12V and then confirmed this with a multimeter across the battery. Sigh one thing always leads to another.
The original alternator has certainly been in the boat for a long while and was in a rather decrepit condition, someone had also taken to the upper arm of the alternator bracket with a grinder to make clearance, a sure sign it was not original.
So the alternator fitted to the Nereus turns out was a Delco 10SI chassis with an external RE55 bosch regulator. I’m quite familiar with this regulator since they were originally designed and made at my current work place here in Australia. This was certainly a long way from being a standard issue Ford alternator.
There are still replacements for these Bosch external alternators around, but they are now well and truly obsolete and getting pricey and hard to get. Even if I know who made them. The Delco alternator frame also could not be pulled apart, it was rusted solid. I tried for a couple of days with heat and Penetrene to get the frame screws that hold the two halves of the unit together to release. Alas they were firmly stuck and right on the verge of stripping, so there was certainly no point in sending it off to be rebuilt.
However one of the attractions of the Ford 250ci inline 6-cylinder engine is the ancillary parts are all based on the Ford 302/351W Windsor (hint: Ford engineers were clever or lazy !?!), so many of the V8 ski boat marine accessories from the 1970’s to mid 1990’s will fit my engine. So a bit of poking around the internet and auto parts stores resulted in me purchasing a Sierra 18-5957 marine alternator from a marine service agency in Queensland that has surplus stock on eBay. It was half the price of a new automotive alternator from a well known German Manufacturer and about the same price as the cheap Chinese knockoffs. Decision made.
Fitting the new marine alternator up when it arrived was a complete doddle (meaning easy), all that I required was a small spacer to pack out the foot on the lower bolt from 51 to 76mm. I had some old GM spacers that were 32mm long, I just cut one down to 25mm long.
Once I had it fitted up I had to pay attention to the clearance between the back of the alternator and the heat exchanger. By putting on a longer belt it meant I could hang the alternator further out from the block. So it was off to the auto parts store for a new belt which happened to be 40mm longer (11A1105) than the one I had already. There are even longer belts available and plenty of room on the control arm to move out further should I need it. I may however try to find a suitable arm to replace the one i have, it looks terrible due to its previous brush with an angle grinder.
Of note when replacing the alternator one has to be careful with the pulley diameters and make sure that the maximum shaft speed of the alternator is not exceeded. You’ve also got to compromise on the lower speed when at idle, otherwise the battery can still go flat. However reading the single small sheet of paper that the Sierra Alternator came with did not specify the maximum rpm. So oh boy I get to make some guesses.
The Sierra alternator came with a 50mm pulley and the standard crank pulley on a Ford 302 Windsor (including mercruisers) is 165mm, meaning at wide open throttle (WOT) the alternator would spin at 4800 x 165 / 50 = 15850 rpm. On my Ford 250ci inline- 6 WOT is 4500rpm and the crank pulley is 176mm, so 4500 * 176 / 50 = 15840 rpm; so roughly about the same.
I’m still not convinced that this is right and have emailed Sea Star Solutions who own Sierra to double check this is ok. There are alternator pulleys with diameters of 59.7mm , 66.7mm & 71.1mm. If these diameters look funny it’s because they are all technically imperial. However I’m more used to working in metric now days.
One benefit of the higher pulley ratio is some addtional output current at and around Idle. So reading the Sierra Alternator spec sheet the alternator at idle is rotating around 700 x 176 / 50 = 2464rpm, which should mean the alternator can deliver nearly 48A to a flat battery. This would make cranking on the anchor winch much less of a problem.
The Sierra 18-5957 alternator has an internal regulator, so all of the external regulator wiring could be removed. There were no wiring instructions in the box, but this is a common aftermarket alternator so there are plenty of instructions on the net.
So the trick with this alternator is to wire the red to a switched +12 wire from the ignition switch. The best place for this on a Ford 250ci is from the coil positive. Which on my moter is the opposide side to the alternator.
The black wire is the sense wire, it is not an earth. The sense wire means it is connected to the positive terminal on the battery. This means the internal regulator can measure the battery terminal voltage independantly of the +B terminal and allow constant current charging of the start battery to occur. It’s worth noting that if you are measuring the battery voltage of the console of your boat make sure it’s not from the ignition switch supply, which is wired to the +B pin of the alternator. Otherwise you’ll find the voltage being displayed abnormally high.
So once this was all done it was time to fire her up and give it a test. Nothing like making a video, hopefully these make sense.
Wooo that 3″ wet exchaust on a inline-6 with no muffer sounds good ! Now I can move onto checking the wiring and perhaps sea trials.
For a while now I’ve been meaning to investigate the Message Queuing Telemetry Transport protocol or MQTT as it’s more commonly known. While the protocol is nearly 20 years old it has become increasingly popular with the Internet of Things (IoT).
The original MQTT code was donated by IBM and Eurotech to the Eclipse Paho project more than 10 years ago now and since then has been extended and massaged into what is known as Mosquitto today. I also like that Eclipse have done a lot of work writing clients for a great many platforms making the developers job just that much easier. A few of my friends have used it professionally so it comes recommended and seems like a good place to start.
So I wanted to experiment with this on a Raspberry Pi (there is a plan more on this later!), so after a bit of googling I found a nice guide written by Adafruit (click) that was the basis of what I used to setup my MQTT stack.
The following is what I needed to do to install Mosquitto on a stock installation of Raspbian Buster Lite. The Mosquitto package is available pre-compiled for ARM in the Debian repo’s so that makes life much easier;
The configuration above is just a basic one for testing. It is by no means secure or ready for production systems, you have been warned. Once the config has been written the following two commands can be used to start Mosquitto and check it is actually running;
$ sudo systemctl start mosquitto.service
$ sudo systemctl status mosquitto.service
There are small apps that can be used to throw data into the MQTT broker and create topics to publish and subscribe data to and from. Once I’ve worked this out for myself I’ll throw something here.
One of the “new to me” things my Nereus has come with is a heat exchanger. The heat exchanger allows the inboard engine to be cooled much like a radiator except the coolant is not cooled by air but by raw sea water instead.
To the side is a picture of the heat exchanger in situ. The upper larger hose is where the coolant enters the heat exchanger and the coolant pump draws water from the bottom. The raw water cunningly runs the other way to ensure maximum heat transfer. So raw water enters at the bottom and exits from just under the top tank.
In all of our previous inboard boats the raw water (sea or fresh) was pumped through the engine block before being discharged into the wet exhaust. Running raw sea water in any engine is not a good idea for two reasons;
Salt can be deposited out of solution when it is heated above +68degC
Salt water is rather corrosive to things like Iron and Aluminium
So in the case of a raw water cooled cast iron engine the coolant galleries will over time get caked in salt deposits or holes develop in the block where you don’t want them to which ultimately leads to premature engine failure. This is not so much of a problem for boats run in fresh water. Having a heat exchanger doesn’t prevent raw water salt deposits from high temps, but at least periodically we can service the heat exchanger and make sure the raw water tubes are kept clear. There are also special solutions that can be purchased to dissolve these deposits, something I’ll be looking at soon.
However not having had a heat exchanger before I had no idea what maintenance was necessary. Thankfully I was able to find a name plate on the heat exchanger which lead me to the manufacturer and model a Savage MK1 Compact built across the pond in New Zealand.
I was also pleased to find they had a local Australian distributor Luxfords in Victoria. It is not often you find distributors that are happy to assist customers with old products, so it was pleasant to say the least when I gave them a ring and received a healthy dose of good ol’ fashioned service. Kudos indeed ! So after my quick phone call I had all of the parts necessary to refurbish my heat exchanger delivered to me in a couple of days.
So the team at Luxfords suggested that I replace the sacrificial anode, an o-ring seal and a couple of washers made from nylon. However firstly I had to get it out of the boat. Here’s a photo of the unit in situ and once extracted, this turned out to be a marathon with some of the bolts requiring patience to get them undone due to restricted access;
So it turns out the heat exchanger is nickel plated copper not stainless as I first guessed, so there has been some form of corrosion on going on that resulted in the tarnished green appearance. Nothing a light slight scrub with steel wool couldn’t remove. It would also appear that the rubber on the clamps that hold the heat exchanger had perished and were split, so once again a phone call to Luxfords and they came to the rescue with the new clamps.
Once the unit was extracted from the boat I was able to find two captive head nuts that then allowed me to separate the bottom cap from the upper tank and main body of the unit.
This was where the fun really began.
One of these captive nuts is found within the header tank that holds the coolant and once removed I found a brass rod that runs between the coolant tank at the top and raw sea water cavity in the bottom. As you can see in the images below it was the lower nut that decided that it would undo.
It was now very clear what the nylon washers were for, one of these washers was supposed to provide the seal between the two cooling systems, meaning the raw sea water and engine coolant.
It was a little horrifying to find that the heat exchanger unit didn’t have one fitted. Gulp.
It may very well have been serviced in the past and it was overlooked, perished or removed. This meant the only seal between these two chambers was bring provided by a metal to metal surface, phew yet another bullet dodged.
So digging further through the spares kit I’d been supplied, I still had a second nylon washer, 3″ o-ring and a sacrificial anode. The o-ring was easy that went on the lower cap and sealed this and the main tube. I was then guessing the second nylon washer went under second captive nut again to seal the raw water chamber at the bottom. That just left the sacrificial anode.
As you can see In the pictures above there wasn’t much of the old sacrificial anode left before things got hairy. The compact heat exchanger requires the anode to be trimmed slightly (approx 15mm) to fit, which was easily done with a junior hacksaw. This was reinstalled with a bit of thread tape to make sure it too didn’t leak. I’ll be pulling this anode out every service interval to inspect, it certainly won’t ever get that short again.
When reassembling I did not forget to include the nylon washer under the captive nut of on the threaded rod that sits inside the tank, I even took a photo to make sure I didn’t forget.
Then it was a simple matter to clean up and reassemble the unit read to go back into the boat. In the photo below you can clearly see the raw water inlet and outet. As a precaution I put a little marine grease on the lower o-ring around the lower cap to ensure it wasn’t pinched by the outer tube when inserted. Below is a picture of the unit awaiting re-installation including its new clamps.
Once back in the boat I need to pressure test the raw water and make sure it does not leak into the coolant tank. Then it will easy to fill the engine with cooland and run the engine to check everything works.
Now it’s time to tackle the alternator and electrical systems.
While changing the oil in my Nereus I was watching the temperature gauge and noticed that the engine temperature would warm up to 95 degrees before the thermostat would open, once open the temperature would drop markedly to 80 degrees before finally settling at 85 degrees. It was quite clear that the thermostat was faulty if not on the way out. There was no way I could leave it like that.
Since this boat has a heat exhanger the thermostat is the same as used in a car so replacement parts shouldn’t be hard to get from the auto parts store. The thermostat is hidden behind the usual cover at the front of the engine;
It also looked like the gasket was not sealing well with evidence of a small leak having occurred at some point. The downside of replacing the thermostat it would require the coolant to be drained, so it’s was also time to also service the heat exchanger and kill two birds with the one stone. Note to self I need to find out what’s required here.
The first surprise upon pulling the bolts out of the old thermostat cover was the bolt on the port side was mild steel and was only being held by three turns, it was a little short. The other starboard side bolt was stainless and much longer (32mm cf 25mm). A quick confirmation with a set of vernier calipers told me the right length was 32mm. Now this engine is from the period where metric and imperial co-existed in Australia. So it was highly likely the bolt as 5/16 imperial and not 8mm metric. So a quick measurement with a thread gauge confirmed it was a 5/16 UNC 1 1/2″ long bolt that also required a split washer, so off to the bolt shop we go I don’t have much in the way of imperial bolts in my workshop.
The thermostat housing was a little pitted, so that was duly rubbed on the concrete with a circular motion to grind away some of the surface material to remove the pits (easier than sandpaper and a sheet of glass if you don’t have it) and all traces of the gasket were removed with a utility knife. The thermostat also came with a new paper gasket, which was duly coated in Hilomar M to ensure a good seal and then re-assembled.
It doesn’t look much different than before, except the keen observer will see the bolts have changed just a little and there’s no sign of that coolant leak. The proof will be that it doesn’t leak.
The last task was to get all of the coolant out of the bilge, so to the pumps… well the bilge pump at least. Before I threw the coolant all over the driveway the outlet was redirected into a bucket and fresh water used to dilute the coolant sufficiently until no more “Green” was observed in the bilge discharge.
Time to move onto the Heat Exchanger before re-filling with coolant.