Fixing the dryer! Adventures of an amateur technician.

A few weeks ago, the motor of my laundry dryer started stuttering, sometimes making a humming noise, sometimes stopping all together. I’ve only had this/a dryer for a couple of years –it was my mother’s before–, so I thought: all right, I’ll just hang the laundry on a rack like I used to and save the environment while at it!

However, not having talent for/interest in house keeping related stuff, I’d become rather appreciative of the convenience. And annoyingly, the dryer wouldn’t fail completely, but occasionally came back to life, giving me the impression that it ought to be fixable. I was definitely not going to buy a new one.

So I hopped on to the Google and Youtube click wagon: “dryer motor humming not running”. Analysis: bad motor capacitor or motor short. All right then, lets get to it!

First, the motor capacitor. It’s there because the type of motor used –an asynchronous motor– actually requires a three-phase ‘rotating’ current to spin, while we only get a single phase –alternating– current from the power grid. A third phase is faked by shifting the phase of the alternating current, which you can do with a capacitor. I measured the capacitance at 5.5muF. As you can see it says 6muF +/-5%, so it was out of spec, but I didn’t really feel it deviated enough to cause any problems, but oh well, let’s replace it just in case! Next:

Taking apart the motor and checking it for possible locations of a short –the kid in the background is my son doing his home schooling work :)–. Nothing to see. I sprayed some varnish into it in case some of the wiring insulation was damaged and put it back together.

Proof of the pudding: I turned the dryer on. Yes it worked! … but not for long. The motor stopped again. Same issue still.

OK then. What else could it be? Was the motor getting any juice at all when it didn’t run? I should of course have checked/measured that immediately. No, it wasn’t getting any, so next to check was the controller board that drives everything. I guess I hadn’t checked this before, because I was afraid the controller board could be the issue and feared my chances of being able to fix it would be greatly reduced if that turned out to be the culprit. Anyway, there was no escaping it now. Let’s get it out!

The board inside looks like this. It’s apparently a very common controller board, made by Electrolux, and is used in many types and makes of tumble dryer (image of the internet):

Nothing on my board looked burned or damaged. I traced a lot of paths and found out that the little black thing at the arrow is a “triac“, a sort of electronic switch that switches the motor on and off. A new candidate for replacement. I ordered one, waited a few days for it to arrive, soldered it on and….

Yes! the machine was working! …. but not for long. Same issue. The motor would stop after a while. Bummer. Quod nunc?

I decided the only way forward was to do live testing. Yes, live testing a 220V powered device is dangerous. Don’t try this at home kids!

Anyway, when measuring voltages on the triac while switched on, the motor would usually switch on only due to me measuring the voltages on the triac. WTF? I must be getting warmer! So if the triac itself isn’t the issue than it must be something close driving the triac… I noticed that the voltage driving the triac, the voltage between the gate and the input terminal, was 0.48V when the motor was running, but only 0.28V when it wasn’t running, but should have been. Otherwise it was just 0V. First, I attempted to better understand the circuit. It’s not complete, but it looks roughly like this:

It seemed unlikely to me that the microcontroller would be broken or somehow ‘confused’. The “darlington” driver, that is used to convert the logic output of the microcontroller to an actual current is a 7 driver array chip with 16 pins. It costs only 30 cents, but I didn’t feel like trying to replace it! The 47 ohm resistor checked out fine when measured… Now the 1k resistor and 100nF capacitor… I couldn’t measure them, because the triac also has an internal resistance between the gate and A1. They look like they’re just there to protect the triac or the driver from peak voltages or something and if anything, they drag the voltage between gate and A1 down, so I thought, h*ll, let’s take them off and test…

HALLELUJAH!!!! The machine was working like a charm! I did feel a little worried about removing the components so I put back a 2k resistor and a 100nF capacitor. The machine still ran fine!

Very long story short: the dryer is working again and I am annoyingly pleased with myself for having fixed it!!

I am still not entirely sure whether the removed components were damaged or whether the driver chip is failing and changing the resistor value is just enough to make it go, but who cares as long as it runs. Considering the time I spent on it, it’s obviously not economically viable to do a thing like this. A new dryer would have been cheaper, but I learned a lot from this exercise, about single phase asynchronous motors, triacs, darlington drivers and about the whole operation of a condensor tumble dryer like this. Also, I didn’t waste an otherwise perfectly good dryer. At least not for the moment. That feels kind of cool.

Posted in Electronics, Personal | Tagged , , , , , , | Leave a comment

Creating a web based mapping application with flexx

For my private boat navigation software project, I was looking for an easy way to manipulate a map, in particular openseamap, from both client and server side. The idea being that the server side runs on a Raspberry Pi that contains the map data, collects data from GPS, motion sensors and so on and the client side runs in a web browser on a tablet or phone that connects to the Pi through wifi. Obviously the server side should be able to manipulate the map based on the boat’s position. On the other hand the user should be able to determine things like zoom level and other typical client side decisions on the client side.

I have played around with Google AppEngine in the past, but it relies on google infrastructure. Apart from that I don’t like that/any dependency much, it’s also not feasible for my application, because it needs to be able to work offline: no internet at sea, at least, not yet. Not being a web developer, my options were fairly limited then and my guess was that I had to create some PHP or Python server side code, javascript client side code and an AJAX interface for communication between the two. Not something I was looking forward to doing. But that all changed when I found flexx, created by fellow dutchman Almar Klein.

In short, flexx:

  • allows writing Python code for both client and server side code in a web application.
  • takes care of communication between client and server side using an event system that uses websockets, which allows for push events from the server.
  • has an already fairly extensive widget toolkit based on phosphor that can be easily extended further.

Being a big fan of Python, this was exactly what I was looking for! Having previously decided to use leaflet for displaying the map, I set out to create a small demo to control a map from both client and server side. The result has since been integrated with the example set that comes with flexx.

I had some trouble getting used to the event system and the separation between client and server side code. Both client and server side code are written in the same Python module! Flexx automatically transpiles the Python code in a nested class named “JS” to javascript and embeds the generated code in the HTTP page output along with a small javascript library that implements some basic python functionality. However, as I’ve come to expect of Python projects: I got results pretty quickly.

Concluding, Almar Klein is doing a great job with this project by integrating a number of technologies, like transpiling from Python to Javascript and a websocket based event system, into a comprehensive package. This allows developers with only basic knowledge of web development to write actual web applications with highly dynamic and interactive features.

Posted in Coding, Raspberry Pi | Tagged , , , , | 1 Comment

Walking in the Eifel

Very rainy but ghostly beautiful walk during our week’s stay near Monschau.

IMG_20151201_151621 IMG_20151201_153229 IMG_20151201_153351 IMG_20151201_154434 IMG_20151201_154650

Posted in Personal | Tagged , | Leave a comment

Trip to Scheveningen and some pictures

Made a nice sailing trip to Scheveningen last weekend.

Earlier this year, Hiske Kamminga took some nice pictures of Wahine:
00000006

00000008

00000020

Posted in Sailing, Trips, Waarschip | Leave a comment

Sparkfun 9DOF on Raspberry Pi 2

A couple of months ago, I finally set out to get the Sparkfun 9DOF stick working (3D acceleration sensor, gyroscope and magnetic flux sensor/compass: 3 x 3 = 9). I got it from my father for my birthday a couple of years ago. I used my new Raspberry Pi 2 to connect to it.

9DOF in handHere’s the stick

As you can see, it’s quite small and has the following IC’s on it:

  • Acceleration: ADXL345
  • Gyroscope: ITG3200
  • Magnetic: HMC5843

All three can run on a 3.3V power supply and are connected together on an I2C bus. Both the supply line and the bus are broken out to the holes on the left.

Hurdle #1: My raspberry pi has a fan and RTC board connected to it: PiCoolFan. The RTC on this board is the fairly common DS1307. The default I2C address of this chip is 0x68, which happens to be the same as the address of the ITG3200 gyroscope. How unfortunate. Four IC’s on 128 available addresses and we got a collision. Not as unlikely to happen as one would expect though 😉

The ITG3200 has an option to use address 0x69 by pulling up pin 9, however I didn’t feel like soldering on the extremely small pins on this board –it would have been nice if @sparkfun would have added a dip switch for this–. The RTC chip should have a programmable address, but I didn’t –at least not quickly– manage to both do the change and have the linux rtc_ds1307 driver use this alternate address. So I decided to go the long way round by using the Pi’s second I2C bus for connecting to the stick. The second bus is disabled by default, but it can be enabled by adding

dtparam=i2c_arm=on
dtparam=i2c_vc=on

to /boot/config.txt

RPi + 9DOFHere’s the complete setup. As you can see, I first tried to connect to the same I2C bus as the RTC/fan –the wires on the right–, before I discovered the address collision using i2cdetect.

Hurdle #2: Writing some code to get actual orientation and motion values from the sensors.

The code I came up with is here. It contains a C++ wrapper for the linux I2C interface, a class for each chip and small logging program.

Hurdle #3: Calibration. The chips obviously output raw binary data that has to be converted to SI unit values for magnetic field strength, angular velocity and acceleration respectively.  Some preliminary testing yielded these conversion values for this board. I would like to add some adaptive calibration since the sensors, in particular the gyro, seem to be sensitive to temperature or other external influences.

Some I2C command output on the Raspberry Pi:

$ i2cdetect -l
i2c-0    i2c           3f205000.i2c                        I2C adapter
i2c-1    i2c           3f804000.i2c                        I2C adapter

$ i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- 53 -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

$ i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- 6c -- -- -- 
70: -- -- -- -- -- -- -- --

Address 0x68 on bus 1 is the RTC and it displays UU indicating it is in use by the kernel driver as expected!.

Posted in Coding, Electronics, Raspberry Pi | Tagged , , , , , , | Leave a comment

Mining FTW

Not actually for the win… there’s not much to be gained. However I find it fascinating that people are actually building dedicated chips (ASICs) to mine crypto currencies (BitCoin etc.). So after mining litecoin on my AMD Radeon HD7950 GPU for a bit two years ago, I decided to order some mining hardware.  2  Gridseed scrypt (litecoin) miners and 1 Antminer U3 sha256 (bitcoin) miner.

Here’s the setup:Mining rig

The miners are connected to a Raspberry Pi (mini linux computer) through USB and the Raspberry Pi in turn is connected to the internet using a wifi adapter. The Pi has two instances of the cgminer software running. One for the Gridseed miners and one for the Antminer. The Antminer occasionally fails and requires a power cycle in order to get going again, so I wrote a small script that runs on the Pi to monitor the miners and power cycle them using a 10A relay in case they fail. The Gridseed miners produce around 800k scrypt hashes per second and the Antminer around 60G sha256 hashes per second. Fairly impressive when you think my GPU (graphics card), which is pretty much top of the line even today, produced around 450kH/s scrypt or 500MH/s sha256 hashes at several times the power draw. It made me realize how powerful dedicated hardware can be compared to general purpose computing hardware.

At a power draw of about 80W (I haven’t measured it yet) on the socket, this setup approximately returns the cost of the electricity used. However it should be noted that mining is not just greedy digging for gold, but it also secures the crypto coin networks, which might turn out to be a useful thing in itself. After all, a distributed way of transacting value may be the best way in a world where banks are basically “amoral“.

Posted in Electronics | Tagged , , , , , , | Leave a comment

Volvo HQ Alicante

While the Volvo Ocean 65’s were in Scheveningen, we were Spain. A somewhat unfortunate planning and not surprisingly there weren’t too many people around the Volvo Ocean Race HQ in Alicante. Nice to have a look around though 🙂

Volvo HQ Alicante

Posted in Personal, Sailing | Leave a comment

The Sweetest Thing

Amazed and bewildered when looking at our little son 🙂
Mian

Posted in Personal | Tagged | Leave a comment

10K run

Laan van Meerdervoort Loop 2013:

  • Kilometer 5: Dunes
  • Kilometer 8-10: Sandy beach with bft. 7

Otherwise pretty good speed 🙂

lvml_map
splits

 
After the final 3 km through loose sand with ridiculous head winds, uphill to Kijkduin… and picture time!!!

LvML_5en10_0269 border

Posted in Personal | Leave a comment

Daytrips on the Haringvliet

I really love the spacious water of the Haringvliet. After arrival in Hellevoetssluis early may, I made several trips alone and with friends. It’s funny how quickly I remembered the locations of buoys and landmarks from 15 years ago, when I had a 470 in Hellevoetssluis for a couple of years. Stayed overnight a couple of times on one of the many mooring buoys or anchor. By now the water is very nice to swim in. Very relaxing and pleasant 🙂

haringvliet_zomer_2013

One of the first really warm days this year. Summertime, when the living is easy.

Skipper

 

Sunset 1

Sunset 2

Posted in Trips, Waarschip | Tagged , , , , | 2 Comments