Saturday, 25 March 2017

Odroid U3 and the emmc memory

Introduction

The Odroid U3 board can, just as all other Odroid boards, use eMMC memory instead of a micro SD card. This type of memory is not only more "cool" but also much faster.  When I bought my board I did order a 8 Gb eMMC module with Ubuntu on it. My recent thinking was to put Openelec on the eMMC instead of the Ubuntu that came with the board.
Back side Odroid U3 with eMMC (red dot) installed, Micro SD card and eMMC adapter


I have downloaded an image from the Odroid forum here.
With the normal procedure I copied the image to the eMMC:

gunzip OpenELEC-Odroid-U2-6.0.1.0.img.gz
sudo dd if=OpenELEC-Odroid-U2-6.0.1.0.img of=/dev/sdh bs=1M
sync
sudo umount /dev/sdh1
sudo umount /dev/sdh2

All good and booting the board with the eMMC and the following messages from uboot:

OK
U-Boot 2010.12-svn (May 12 2014 - 15:05:46) for Exynox4412
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 880MHz
DRAM:  2 GiB
PMIC VERSION : 0x00, CHIP REV : 3
TrustZone Enabled BSP
BL1 version: 20121128
Checking Boot Mode ... EMMC4.41here
REVISION: 2.0
Manufacture ID 0x11 [ 7456MB ] 
NAME: S5P_MSHC4
MMC Device 0: 7456 MB
MMC Device 1: 0 MB
MMC Device 2 not found
*** Warning - using default environment
USB3503 NINT = OUTPUT LOW!
ModeKey Check... run normal_boot 
No ethernet found.
Hit any key to stop autoboot:  1
do_fat_cfgload : cmd = fatload mmc 0:1 0x41000000 boot.ini
reading boot.ini
2697 bytes read in 21 ms (125 KiB/s)
Find boot.ini file. But This file is not odroid4412 config file!
NAME: S5P_MSHC4
NAME: S5P_MSHC4
>>> Load Boot Script from mmc 0:1 <<<
reading boot.scr
** Unable to read file boot.scr **
>>> Load Boot Script from mmc 0:2 <<<
** Unrecognized filesystem type **
>>> Run Default Bootcmd <<<
reading kernel..device 0 Start 2455, Count 16384 
MMC read: dev # 0, block # 2455, count 16384 ... 16384 blocks read: OK
completed
reading RFS..device 0 Count 18839, Start 2048 
MMC read: dev # 0, block # 18839, count 2048 ... 2048 blocks read: OK
completed
Wrong Image Format for bootm command
That didn't work. The same procedure with a micro SD card did result in a booting system.

Somehow is something going wrong with u-boot.
Working micro SD version:
Odroid # version

U-Boot 2015.10 (Feb 29 2016 - 22:54:24 +0000)
armv7a-openelec-linux-gnueabi-gcc-4.9.3 (GCC) 4.9.3
GNU ld (GNU Binutils) 2.25.1
Not work eMMC version from the same image:
Exynos4412 # version


U-Boot 2010.12-svn (May 12 2014 - 15:05:46) for Exynox4412
How can that be, two different versions of u-boot from the same image file?

The old U-boot of 2010.12 is not compatible with the boot.ini file and probably also not with the kernel format / identifier of what ever. It is clearly necessary to use the U-Boot 2015.10 version.

Difference between SD and eMMC


The reason is that the Exynos4412 Prime soc is intended for secure operation. That means that the bootloader and software has to be signed and that a couple of further "hidden" security features are used when an eMMC is available instead of an SD card.
This results in a complicated booting process:
  1. ROM
    The rom loader starts when processor is powered up / has had a hard reset. Based on hardware settings (boot pins and availability of interfaces) is the next step boot loader put in to the L2 cache memory
  2. BL1
    The signed bootloader "BL1.bin" is pulled into the SOC this is a binary blob that comes from Samsung. It is signed with a key / encrypted. This loader fits into the L2 cache is is able to configure the memory of the processor so that the next boot loader actually fits into the memory.
  3. BL2 +  TrustZone
    This loader is basically a signed part of U-boot. This U-boot part is signed by the key of Hardkernel and is therefore an acceptable payload for the BL1 loader.  At this point is also the "TrustZone" configured a kind of security level in the processor to enable things like DRM and payments. From this point U-boot can be loaded.
  4. U-Boot
    This is the normal opensource boot loader that understands eMMC, SD, USB, network and the file systems. This loader puls the kernel into the memory and will start it.
  5. Kernel and initrd
    When this part is loaded and started we have at last a working linux system.
The different boot loader parts are differently stored on the SD card and unfortunately not in the same way on the eMMC card.

The different blocks are on the SD or eMMC as follows organized:
Binary Block offset Part type
name SD eMMC (eMMC only)
Bl1.bin 1 0 1 (boot)
Bl2.bin 31 30 1 (boot)
U-boot.bin 63 62 1 (boot)
Tzsw.bin 2111 2110 1 (boot)
Uboot Env 2500 2500 0 (user)

What stands out s that the eMMC uses a boot/secure part for the bootloader. This part can (normally) not be accessed from the operating system or when the eMMC is used as SD card. This done to be able to guarantee a secure system and to have a un-brick-able configuration. The user cannot change the bootloader and therefore not really brick the board. Only with a special u-boot or a special kernel module is it possible to access the secure partition.

Basically this means that the boot loader is not updated when an image is written to the eMMC card in it's sd adaptor.

How to update u-boot on an eMMC

Hardkernel has an eMMC recovery tool available. This is an image with a special u-boot that updates the secure boot partition of the eMMC with new bootl loaders. This tool can be found on their forum here. I have used image exynos4412_emmc_recovery_from_sd_20140629.zip, but as always your mileage may vary.

This image must be written to an SD card as normal. The procedure is as mentioned on the Odroid forum as follows:
  1. Prepare a microSD card and flash the attached image.
  2. Boot with the microSD without eMMC
  3. Turn on U2/U3 and wait for a few seconds and blue LED will blink.
  4. Plug your eMMC module into U2/U3
  5. Plug micro-USB cable into U2/U3 and connect other side to your PC USB host or ODROID's USB host port. (This is a trigger to start the recovery)
  6. After recovery process (only a few seconds), the blue LED will turn off automatically.
  7. Finish. Install OS on your eMMC with as usual.
When we look at the SD with the image we see the following structure:

hansan@Desk-computer:~$ ls -l /media/hansan/48E0-7CDF/*
-rw-r--r-- 1 hansan hansan 2701 Jun 28  2014 /media/hansan/48E0-7CDF/boot.ini

/media/hansan/48E0-7CDF/update:
total 662
-rw-r--r-- 1 hansan hansan  15360 Mär 18 12:37 bl1.bin
-rw-r--r-- 1 hansan hansan  14592 Mär 18 12:37 bl2.bin
-rw-r--r-- 1 hansan hansan   1392 Jun 28  2014 sd_fusing.sh
-rw-r--r-- 1 hansan hansan 159744 Mär 18 12:37 tzsw.bin
-rw-r--r-- 1 hansan hansan 478121 Mär 18 12:37 u-boot.bin
-rw-r--r-- 1 hansan hansan   2105 Mär 18 12:37 update.sh
hansan@Desk-computer:~$ 

This means that the special u-boot on the SD card is pulling the boot loader parts from the update directory and put those files into the secure boot partition of the eMMC. To make openelec working on an eMMC is it necessary to put the new U-Boot 2015.10 into the boot partition of the eMMC. This can be done by first extracting the boot loader parts for openelec and copy them to a recovery image. That image updates the boot partition and after that is it possible to write the openelec image to the eMMC. This results in a working combination.

My approach to get to the correct version of u-boot was to compile openelec from source.  A different approach would be extracting the parts of the SD-card and save them under the correct names.

I have downloaded the source from here. And followed the instructions:

1. Unpack sources
2. make PROJECT=Odroid DEVICE=$DEVICE image
3. wait for compilation.
4. zcat target/OpenELEC-Odroid-$DEVICE-6.0.2.0.img.gz | dd of=/dev/mmcblk0

    $DEVICE can currently be either U2, XU3 or C1

5. SD card is now complete.
I did need to mangle the download site for the "liberation-fonts-ttf" package. Google on the error messages received during complication can help to fix the issues.  The required files can be found in the image directory.

hansan@Desk-computer:$ ls ./build.OpenELEC-Odroid.U2.arm-6.0.2/image/system/usr/share/bootloader/
bl1  bl2  tzsw  u-boot  update.sh
These four files have to be copied to the SD card with the eMMC recovery image update directory. Don't forget to add the .bin extension to match the "pattern" on the SD card.
With this image is it possible to update the u-boot on the eMMC module to the version need to boot the openelec image from eMMC. It is then not longer needed to use a SD card.
This new image can be backed up  to a file.

hansan@Desk-computer:$ sudo dd if=/dev/sdh of=~/work/Arm_sbc/odroid/openelec/eMMC_openelec_6.0.2.0.img bs=512 count=220501
220501+0 records in
220501+0 records out
112896512 bytes (113 MB, 108 MiB) copied, 6,31194 s, 17,9 MB/s
hansan@Desk-computer:$ 
I have put the updated recovery image here.

By the way it would also be possible to extract the required files from the Odroid OpenElec SD card image. That would remove the need/trouble of compiling the boot loader.



Saturday, 18 March 2017

Fixing the SmartTV

Over the years I have collected a couple of ARM based boards evaluation / experimentation . Some I bought because just I wanted to and others I have bought for a specific purpose that they never fore filled.

I got recently so disappointed with the "SmartTV" part of my Samsung television UE40ES6300. The issues are that the applications are not very convenient (e.g. difficult to search in Youtube), the SmartHub always needs an update when it is inconvenient and in June 2016 was the support for Skype discontinued. The discontinuation of Skype would be enough for a own post.

The combination bad SmartTV, no Skype and Arm board gave me the thought that it would be maybe a solution to install AndroidTV on one of my boards. Such that I can enjoy a more stable experience, have a good working Youtube and Skype again because this all works so nice on my android telephone.

My board of choice for this is an Odroid U3 of Hardkernel.
Odroid U3

This is a board based on a Samsung Exynos4412 processor a quad core Cortex-A9 on 1.7GHz and with 2Gb of memory. Quite a potent processor that is also used for some of Samsugs galaxy telephones and tablets. This processor was discontinued / succeded with a newer version sometime Q2 2014.

I first tried Android TV CM 12.1 which did not do the trick for me.
  • The google play store did not work properly
  • Did not get used to the user interface, (More my problem)
  • To have skype support in your android device you need a "key" which is not available for this device / android combination.
The above made that this did not solve my requirements. With having to give up on Skype there was  no need to use Android. The next step would be a linux based media player (i.e Openelec with Kodi).

Openelec is also available for the Odroid U3 and can be found here on the Odroid forum. This worked for me better than Android, because of my better knowledge of linux. It is for me easier to understand what is happening under the hood than with Android. With Android I am more the stupid user than the "hacker" that can fix the internals.

I do have a couple of issues for which I will make a few blog entries:
  1. The image works very well from an SD card but not from the faster / sexier eMMC memory. The solution of that can be found here.
  2. My above mentioned television is not always detecting the HDMI and CEC interface, depending on who was switched on first. I will need to further look into this.
  3. It would be nice to only supply power to the board when the television is on. But this should not give a corrupt file system when the TV is switched off.



Wednesday, 4 January 2017

Children's countdown timer

Occasionally, our children need some help with the concept of time. According to them, some of those minutes are much shorter than others (think watching TV vs. driving to the Efteling). To help them with this, I have been promising to make something for the past half year. But now it is ready!

After spending about two days on it over a period of six months, here is the result: a children's countdown timer. It shows clearly how much time is left for a certain activity, and also plays a tune when time is up.

The children's timer. Unfortunately, the multiplexing of the leds combines unfavourably with the shutter of the camera. To the naked eye, all leds in the upper-right quadrant are lit.

By turning the knob clockwise, more and more of the leds along the ring are switched on. After not moving the knob for 5 seconds, the timer starts counting down1. One after another, the leds slowly decrease in intensity and switch off. Each led takes 100 seconds, so the full circle uses a full hour. When all leds are off, time is up and a song is played on a piezo buzzer while the leds show a flashy pattern. By turning the knob clockwise past "zero", it is possible to switch between silent mode and audible alarm (non-silent) mode. In non-silent mode, the buzzer also clicks when turning the knob, providing feedback on whether an audible alarm is enabled.

Under the hood

The main parts of the timer are 36 red leds, two 1.5V AA batteries, a 3.3V step-up converter from the parts bin (Sparkfun NCP1400-based), a rotary encoder (from conrad.nl), a piezo buzzer that came with an old computer mainboard, and an Atmel ATtiny2313 for a brain.
A look under the hood. The piezo buzzer, the step-up converter and the AVR are approximately on a straight line from the bottom-left to the centre. All leds are on, and the batteries deliver a current of 6.3mA.
The 36 leds are driven as 3 sets of 12 via charlieplexing, using 12 microcontroller pins. This arrangement uses more pins than multiplexing the leds in a single set, but it allows three leds to be lit at the same time, increasing the average brightness using less current. Without going into details, this has to do with the non-linear response of led vs. current.

Since debugging this kind of setup is very hard, I tried to keep the software as simple as possible. A single "master" timer fires an interrupt 2600 times per second. The main purpose of this is to refresh the "display". The correct leds are switched on or off according to what needs displaying. Four levels of intensity per led, 12 leds, and 2600 interrupts per second lead to a refresh frequency of 55 Hz, which shows no flicker (to the naked eye at least ;-)).


A look at the back side of the board. The other side can be so clean because this one is a bit of a mess.
After updating the display, the routine samples the two input pins connected to the rotary encoder. By filtering over 16 samples, the signals are debounced to get a reliable input. And finally, a software counter divides the master clock to generate a timer "tick" at 5 Hz to be used by the rest of the software for time-keeping.

Events for timer "ticks" and changes of the rotary encoder are communicated to the rest of the software using bit flags. After every interrupt, the main software loop wakes up, and if there is an event, this is handled in the loop.

To play music, a separate timer is connected to the piezo speaker, that generates the notes. The music is stored encoded in the flash image and played at a pace determined by the "tick" events ultimately derived from the master timer.

When the countdown timer is switched off, the oscillators of the microcontroller are disabled and the ATtiny enters a deep sleep mode. Just before this happens, one of the inputs connected to the rotary encoder is set-up such that it will wake up the microcontroller when the signal changes. If the rotary encoder is in a position where one of its inputs bounces between on and off, this could prevent the microcontroller from entering deep sleep. To counter this, the input that wakes the micro is alternated between the two inputs every time sleep mode is enabled. So if the AVR wakes up due to a bouncing pin, it will time out since there is no actual input after the debouncing filter. It then switches to the non-bouncing pin, and enters sleep mode again.

The software is written in C using avr-libc, and compiled by avr-gcc. The current version takes 1748 bytes of flash memory, leaving exactly 300 bytes for possible extensions. The circuit has a header that is compatible with an USBasp to allow in-circuit updating of the software, something that has already proved very useful. Since the circuit normally runs at 3.3V, but the USBasp needs 5V, it is necessary to disconnect the battery before programming, and power the circuit from the programmer itself. In hindsight, I should have added a jumper to make this more convenient and less error-prone, but so far I remembered to remove the batteries when needed.

I put the software on https://github.com/bart-h/avr-timer for those that are curious.

Power usage

Because the contraption runs of a battery, power usage is an important consideration. When switched off, the system itself draws an idle current of 0.5μA after the step-up converter. Assuming a battery capacity of 1Ah, this would correspond to a battery-life of 228 years! Or actually, it means that other things will dominate the battery drain. Before the step-up converter, about 12μA is used, mainly by the converter itself. Initially I was irked to fix this 4% efficiency problem, but then I realised that the battery life would still be 9.5 years. Close enough to infinity for my purposes.  And when the system is fully active, the efficiency increases to about 90%.

When the countdown timer is running and all leds are switched on, the system draws 6.3mA at the battery. Running a countdown of a full hour (starting with all leds on, and ending with all leds off) then uses 3.15mAh. Again assuming a 1Ah battery capacity, this would allow 317 runs, more or less one per day for a full year.

The largest power drain is by the buzzer and its series resistor. When it is driven high, it draws ~30mA. Fortunately, when playing notes, the buzzer is switched on and off constantly, as sound is made by voltage changes, not stable levels. This already halves the average current. In addition, the music contains pauses that set the buzzer to 0V. Because I do not have an integrating power meter, I do not know how much power is actually used when playing music. But because the tune takes no more than 20 seconds, I assume the power usage can be neglected in the overall scheme of things. While turning the knob, the buzzer also toggles to make clicking sounds. Here I took care to switch the buzzer level back to 0V as soon as possible, to conserve power.

Because an real Alkaline AA battery actually has a capacity closer to 2Ah, all calculated lifetime numbers should be doubled as well in reality. But the final proof will be when I have to replace the batteries...


The timer running when it is dark. Because the camera uses a much larger exposure time, all leds that are lit also appear on in the picture.

Tuesday, 22 November 2016

Updating DVD drive firmware

I recently  tried to watch a few DVD's with the drive in my computer. That didn't work so well; towards the end of the "file" was the drive not able to read the frames any more. Maybe this has something to do with the second layer on the disk or something with the security on a DVD.
But anyhow I thought it was maybe a good thing to try to update the firmware  of the DVD drive to see if that helps.

I have, as Linux advertises, a HL-DT-ST DVDRAM GSA-H12N in my linux computer. This is relative old LG made drive with a Pata interface that can read and write DVDs next to CDs.

 Looking for a firmware upgrade showed only a windows utilities for firmware upgrades. The new firmware was packed in "GSAH12N_UL02.exe".  I couldn't get it working under Freedos, because it explicitly needed windows. And with wine I only got an error message / no response at all. But I had not much confidence in wine for this hardware job, which made that I started to do some Google search.
 
This question on launchpad gave me a hint how I could get it working. I did needed to install the mfc42.dll with help of winetricks.

Then I only needed to do the following to update the firmware:

sudo chown -R root ~/.wine
sudo wine GSAH12N_UL02.exe
sudo chown -R $USER:$USER ~/.wine


I did had to add a disk to the drive to make sure that the windows program could find it.

After the reboot is my DVD drive indeed advertising the higher firmware number UL01 is now UL02. However I am still not able to read the complete DVD. That will be the next thing to sort-out.



Saturday, 12 November 2016

Kid's stuff


Just a small update: for our daughter's birthday party, we needed two large puzzles with a toolchest-y theme. The idea being that the kids will search for, and hopefully find, the various pieces and put them together to win a price.

So I took a bit of scrap triplex left from some home improvement job, cut it in half, an traced a bunch of my tools. First in pencil to make sure I got the contours right, and then in black marker. After that, I took the electric jigsaw and cut the pieces. Note 1: when making multiple puzzles, mark pieces on the back to know which puzzle it belongs to. Note 2: be careful when cutting, as an electric jigsaw cuts straight through metal workbench parts...

After that I sanded the edges and my wife added a bit of colour. And finally the kids liked the puzzles, so all in all another successful little project!


The puzzle before cutting it into pieces. I traced a few of my tools in pencil, and then used a permanent marker to make it, well, permanent.

And the other one, as we needed two... Notice the differences.

After cutting and painting number 1...


...and two.

Sunday, 2 October 2016

Finding a use for an obsolete tablet: part 1 - resurrection

Somewhere in the year 2012 I thought buying a cheapish Chinese android based tablet was a good idea. My wife just got her first iPad, and I was curious what sort of tablet €85 would get me. From a tablet point of view this turned out as somewhat of a disappointment, or rather, it would have been a disappointment if I would have expected to get a useable tablet.

Looking at it from the hackable Linux device perspective it was actually quite okay. It came with a 7" 800x480 colour LCD, ethernet, WiFi, serial port, microphone, speakers, camera, two USB ports, 2Gb flash, a micro SD port, and a resistive (i.e. single touch) touchscreen digitiser. On top of that it had a rechargeable battery that would sustain the thing for about two hours. And all this rather underpowered by a 300MHz ARM processor and 128Mb of ram.
The tablet came with this dongle. On this side I hacked a serial port. On the other side, there are two USB2 ports. And on the left side, there is an UTP plug for ethernet.
Unfortunately, I started with trying different versions of Android based firmware. A firmware upgrade consisted of downloading a zip, extracting to SD card, and booting the tablet with the SD in it. Apart from a new android kernel and rootfs, all these firmware updates always included an update for w-boot and u-boot as well. These were the pre-bootloader and main bootloader respectively. At a certain moment I left the SD card in when I hadn't meant to, booted, noticed my mistake, yanked the card out, and corrupted either w-boot or u-boot. As a result, the tablet would not boot anymore, and I had made myself a fancy paperweight.

At the time, I looked into fixing this. The bootloaders are stored in a spi flash chip, while the rest of the software lives in another set of flash chips. So I hooked my buspirate to the spi flash and tried to access it in circuit. This was ultimately unsuccessful: while I could read the flash chip id, the rest of the tablet's circuitry a somehow prevented me from writing or even reliably reading the chip's contents. I decided that I would have to desolder the chip to continue, and that I had more important things to. 
Attempt at in-situ programming of the spi flash chip.

So I put the tablet in its box and more or less forgot about it for a couple of years.

Recently I came across it again while looking for something else. I then saw connection points for a JTAG interface. These I had noticed before, but at the time I did not have anything to interface with JTAG. But now it seemed that, with a firmware update, my buspirate and openocd could be made to do this.

So I soldered a connector to the JTAG interface, hooked it to my buspirate and tried openocd. I quickly found that openocd needs some kind of description of the item on the other side of the JTAG to work. This makes sense as designing such a hardware debug interface, with a very limited number of users, for  "plug and play" would be a serious waste of effort. Unfortunately the tablet was based on a wondermedia WM8505-board that was unknown to openocd.

JTAG header added to tablet. GND is hooked to the spi flash ground pin. And I stuck a description of the pins to the inside of the tablet case, for future reference.
This meant I had to make my own definition file, while discovering how openocd actually works. I could find a single post on a forum of someone who had done the same or similar, but that post did not have much detail. But fortunately, it all proved relatively straightforward. When I connected the board, only a single JTAG tap (something like a client or receiver) was found, so this had to be the processor. And by now I knew that the WM8505 had an ARM926ej-s core, for which openocd already had a definition file. So after some experimenting, I could halt the processor on the tablet, dump/change its registers and other state, and make it do anything I want.

For those in need of this, here is the definition file I cobbled together:
# Barebones openocd definition file for WM8505
#
# not sure if this actually works
jtag_rclk 3000

# WM8505 SoC
jtag newtap WM cpu -irlen 4 -expected-id 0x07926f0f

# CPU
target create CPU arm926ejs -chain-position WM.cpu

# no hard reset, use soft reset
CPU configure -event reset-assert  { jtag arp_init }

# Work area in ram: last 8k from 128M
CPU configure -work-area-phys 0x07ffe000 -work-area-size 0x4000

arm7_9 dcc_downloads enable
arm7_9 fast_memory_access enable

reset_config trst_only
Next step was to load a copy of u-boot via JTAG into the tablet's ram, and run it. From there, I could take control of u-boot via the serial interface, and use that to flash both u-boot and w-boot from the SD card into the spi rom. But first I hit a small snag: the first 6 or so u-boot versions I tried all seemed to work, but then shut down the tablet. Fortunately, the 7th version did give me a prompt, and I could fix the corrupted spi flash. 

(I later discovered that the other u-boot copies were actually fine: what happened was that these checked the state of the power-button. If the button was pressed for about 1 second, the boot process would continue. If not, the tablet would power down. As u-boot is (almost) the first thing to run when the tablet is powered on, this would prevent accidental turning on of the tablet. But in my JTAG case, the power button was always off, so u-boot would power down the tablet.)

After fixing the spi flash, it was also possible again to update the original android firmware in nand flash. However, I had difficulties finding a correct one. For starters I  was and am not 100% sure which exact model of tablet I have. Many variants with minor differences in hardware existed, and firmwares of other models would sort-of work on mine, but with some features (i.e. touchscreen or audio) missing. And most firmware versions originally were on download sites that either no longer exist, or do not have the files anymore. Some of the versions that I could find did boot and show something but I could not get the touchscreen to work.

Success! Notice the low-glare screen on this high quality product.
So I decided to forget about android, and install a plain Debian Linux on the tablet. But that will be the subject of another post.

Monday, 19 September 2016

Bathroom ventilator upgrade/repair

This was intended to be a simple job involving nothing but simple mechanics and a bit of electrical wiring.

Background

The ventilator. Just in case you were wondering...
The ventilator. Just in case you were wondering...
Some years ago we had a new ventilator installed in our bathroom. This was a smart fan with a moisture sensor. So if someone was running the shower, the air would get moist, the fan would switch on and extract the air towards outside. As an extra, the unit also had a set of little flaps (a more to the point word probably exists in English) that automatically open and close when the fan starts or stops, and an indicator light, because everyone needs an indicator light.

From the start this thing had the problem of being quite loud. The other family members very much preferred it to stay off while relaxing in the bath. Over time their wish was gradually granted as the fan got more and more slow and finally stopped turning altogether.

Naturally I took the thing apart and checked the motor. Even when hooking it up to mains directly (and yes, it was a 240V part) it did not run anymore. So I got thinking what to do next.

A simple plan

Since the warranty had already run out by a few weeks (duh), I was free to do what I wanted. I figured I could install a new fan as far away from the bathroom as possible in the exhaust chimney thingy on top of the bathroom's roof. So I bought a simple 240V on/off ventilator of similar wattage as the old fan that fitted in the chimney pipe. I would run the wire through the pipe, hook it up to the ventilator controller, and Bob would be my uncle. Easy.

But Murphy was not to be outdone by Bob. While I was thinking this through, buying the ventilator and planning this job, the old ventilator unit failed completely. The flaps no longer opened and the little indicator light stayed dark when running the shower. 

Circuit debugging

The circuit. Note the triac (next to the lamp), and the yellow filtering cap.
The circuit. Note the triac (next to the lamp),
and the yellow filtering cap.
Since I lost the receipt of the new-bought fan, I could not return it to the shop. What was left was to take a good look at the controller circuit. It was pretty simple. It had a triac to switch the mains, a moisture sensor, two adjustable potmeters, a few transistors, diodes and resistors. The transistors were there to get a lower voltage from the mains (I think) and switch the triac when the moisture sensor's resistance would fall below one of the potentiometers. (The other potmeter controlled the time the fan would run before switching off.)

While I am not the most experienced circuit debugger, I know it involves sticking a multimeter in a live circuit. But since this circuit is directly hooked to mains, I would be competing for a Darwin award that way. So I had to try to figure this out without power.

I knew for a fact that the old fan had failed. I also knew that a non-turning motor can draw 2 to 3 times the current compared to when it runs normally. This could potentially overload the controller, causing something to fail.

The only semiconductor in the "240V on" part of the circuit was the Z0103 triac. Some probing with my multimeter also seemed to suggest it was not 100% happy anymore. So I ordered a replacement and let things rest until the new part arrived.

Replacing the triac made the light come back on and the shutters work again! Success! So I did a little dance, kissed my wife, and connected the new fan motor. Disappointment! It showed the same not-really-turning-over behaviour as the old one did towards its end. Clearly something was still wrong with the controller board.

More circuit debugging

Further poking around identified another component in the 240V part of the system: a 0.22μF filter capacitor. For lack of a better idea I took it off and put it in my little component tester: 33nF, about a factor 7 too low. So I ordered a replacement and put the whole lot aside while waiting for the mail.
After I soldered the new cap in the circuit, the new motor ran smoothly. Hurray! So I finally was ready to start installing the new fan.
It works! Note the piece of paper lifted by the air flow, the new orange capacitor peeking through, and the flange still being attached to the new fan.
It works! Note the piece of paper lifted by the air flow, the new orange
capacitor peeking through, and the flange still being attached to the new fan.
Finale

First step was to remove the old fan from the ventilator housing and change the wiring a bit. While messing with the circuit I had removed the original connectors since they seemed flaky, so everything is now either soldered or attached with screw terminals.

The fan attached to the (upside-down) chimney top. Note the two bolts that just allow the fan to turn.
The fan attached to the (upside-down) chimney top.
Note the two bolts that just allow the fan to turn.
Next step was installing the new fan. In principle the new fan just fitted in the top part of the chimney, except that it had a flange. While very useful for the scenario where I would do what the installation instructions say, I was not planning to do that. Fortunately a plastic flange is no match for me and my hacksaw.

I then drilled two holes through the chimney top and the pipe around the fan, while taking care not to get in the way of the fan blades. Through the holes went two flat head bolts, and on the bolts went two nuts that I secured with a tiny drip of super glue. The top actually has an inner and an outer pipe. The inner one goes inside the chimney, while the outer sits on the outside. The fan is bolted to the inner pipe. The heads of the bolts were flat enough not to stop the top to go inside the chimney pipe. So I ran the wire through the chimney, put the top back on the roof, and went downstairs into the bathroom to hook things up.

Inside, things were straightforward in concept. But trying to get a bunch of wires to fit under the cover, the cover to be against the ceiling, 4 screws to through 4 holes, and somehow have a hand left over to fasten the screws above my head was somewhat tricky to say the least. And of course I had to repeat the exercise because I found I had to tweak the two potmeters a bit after the first test run.

But all is well that ends well. The ventilator works again, and is noticeably more quiet than before. However, in the future I might still add a switch so my wife can enjoy her bath in absolute silence if she is so inclined.

Some more photos



The orignal (non-working) fan. The brown part in the front-right is a bi-metal actuator to open the flaps.
The orignal (non-working) fan. The brown part in the front-right is a bi-metal actuator to open the flaps.


Good cap.
Good cap.

Bad cap.
Bad cap.


Removed the original fan. Note the feed-through for the  new fan's wire fixed in place with some hot glue.
Removed the original fan. Note the feed-through for the
new fan's wire fixed in place with some hot glue.

The new fan in the upside-down chimney top. The wire will run through the chimney pipe and connect to the controller in the orignal casing.
The new fan in the upside-down chimney top. The wire will run
through the chimney pipe and connect to the controller in the orignal casing.


The chimney top back where it belongs. Nothing to see here, folks!
The chimney top back where it belongs. Nothing to see here, folks!