Tag Archives: electronics

Repairing a floppy disc drive

Why on earth would anyone want to repair a floppy disc drive? It’s quite a while since most of us bade them good riddance and started using USB sticks and Flash memory cards. However, I still use floppies from time to time, mostly with my trusty BBC Micro which still sits in the corner of the workshop.

Recently I was asked to recover some documents from some old 5.25″ BBC Micro floppy discs. The documents themselves were in an unusual format, about which more another time, but the first step was to simply get the data off the discs. The discs were 80-track ones, and I have a pair of Chinon FZ-506 80-track drives for the Beeb.

Img_6556

Out of all the various Beeb drives I’ve had over the years, I’ve kept these two because they’re housed in a compact casing with a mains power supply, and they have handy 40/80 track switches on the front, not hidden round the back. One drive has always been a bit reluctant to start spinning, but for occasional workshop use that wasn’t a problem. I’d got in to the habit of just opening and shutting the door a little which would kick the motor into action. However, when it came to intensive use backing up these old discs, which needed both drives, the failure to start became a real pain. I didn’t have a spare drive, and finding another one (especially in Poland) isn’t easy these days.

My curiosity got the better of me and I decided to open up the drive and find out what was wrong with it. It wasn’t hard to take apart and I soon had the motor revealed. Here’s a photo of it sliced into its component parts.

Img_6340

It’s a ‘pancake’ motor, so called because it’s (nearly) flat. The shiny silver bit on the left is the turntable which drives the disc, and it sits in a bearing. The next layer is the circuit board containing the windings and controller circuitry, and below that is the rotor which is a multi-pole magnet on a steel disc.

The motor is controlled by a Mitsubishi M51785P motor controller chip. The chip’s data sheet revealed that the motor has three phases, each of which has a coil to drive the rotor round and a hall effect sensor for feedback. This particular one is arranged with two coils per phase, but occupying 6/7 of a revolution, so the motor goes more slowly than the chip is driving it. At least, I think that’s what’s going on. Here’s a closeup of the circuit board. You can see the six coils, and the coloured wires I soldered on to measure things while the motor was running. Because of the way it’s built, it’s impossible to access most of the circuit board while the motor is assembled.

Img_6338

The controller chip seemed to be doing all the right things: its oscillator was running, and the outputs to the coils were doing sensible things. The coils themselves were all undamaged and measured the same resistance as each other. But I noticed something odd about the hall effect sensors. There are three of them, HG1, HG2 and HG3. I noticed accidentally that if I shorted together the two wires taking the output of HG1 to the controller, the motor still ran but sounded very rough. Not surprising. The same happened if I shorted the output from HG3. But shorting the output from HG2 had no effect at all. Aha! Only HG1 and HG3 seemed to be having any effect on the motor. I swapped HG1 and HG2 just to see what would happen, and the fault moved to HG1. That proved to me that I had a faulty sensor, not a faulty chip.

Where to get a replacement sensor, though? This drive was made some time in the late 1980s, and I couldn’t find hall effect sensors in today’s electronics catalogues which would fit mechanically and electrically. I had a rummage around the workshop and found a scrap 3.5″ floppy drive. A squint at the circuit board revealed a suspiciously hall-effect-looking device of the right shape and size nestled next to the spindle rotor, used for index sensing. Well, it had to be worth a try. I extracted it and fitted it to the 5.25″ drive in place of the faulty one.

Success! The motor now ran more smoothly, and shorting each of the hall sensors in turn had roughly equal effects, so they were now all working. Best of all, the motor started reliably every time. Interestingly it wasn’t as quiet as the other drive, but I suspect the scavenged hall sensor is optimised for magnetic fields from the side rather than the front, given how it was mounted, so it’s probably not perfect.

The last job was to realign the head slightly, because this drive was a bit fussy about reading some discs. I found a disc that it struggled with but that the other drive would read every time, and tweaked the position of the head stepper motor each way a little until this drive read that disc reliably. You can see in this photo that the stepper motor has elongated mounting holes, so it’s possible to loosen its screws (there’s another one just out of shot to the right) and turn the motor a few degrees to adjust the position of the head.

Img_6344

After all this work, the drive read all the discs I asked of it without any problems. I hope it’ll be OK for the next decade or two.

Denon DVD-1720 DVD player power supply schematic and repair

A couple of weeks ago, my wife and I wanted to watch a movie. I went to put the DVD in the player, and was disappointed to find that the machine was dark and didn’t respond to any of its buttons. It was broken.

Img_6385

It’s hard to say that a DVD player is really worth fixing. This one, a Denon DVD-1720, is about 7 years old, and wasn’t expensive when it was new. However, I was curious to know why it had stopped working, and that alone was reason enough to delve inside.

Considering its low cost (I think it cost about £100 when new) it was very neatly constructed. Removing a few screws allows the top to come off (careful of sharp edges) and the plastic front panel just unclips with a bit of gentle persuasion, revealing the guts.

Img_6383

Before we go any further, I have to insert a health warning. Dealing with DVD player power supplies has health risks. There are dangerous voltages present inside. If you don’t have the right equipment or don’t know what you’re doing, you can get a nasty surprise, a terminally broken DVD player, a serious injury or be electrocuted. None of those are fun, especially the one which results in death.

Almost all the electronics are on one big motherboard, apart from a few buttons and lights at the front and the fiddly digital stuff to do with the actual DVD reading, which sits on the green board on pillars in the middle. Undoing the screws from the green board, a few on the motherboard, all the ones on the back of the machine, and unplugging three connectors, makes it possible to wiggle the board free. It’s a bit of a squeeze and the board is fragile, so don’t blame me if you break it.

Img_6380

The power supply is at the rear right corner. Denon have kindly marked in white the area with dangerous voltages in it.

Img_6381

There’s not much to it. It’s clearly a switch-mode flyback converter. The transformer is much too small to be an ordinary mains transformer, and there are no inductors on the secondary side. I did the obvious checks – the fuse wasn’t blown, and the three big pale blue safety resistors measured OK. All the diodes dioded too. Time to put my reverse engineering hat on and dig deeper.

The PCB is nicely marked with the component identifiers on both sides:

Img_6378

so it wasn’t too hard to draw out the circuit diagram.

denon-power-supply-s

It’s a pretty elegant design, using only three transistors. The circuit appears to be a blocking oscillator centred around Q1001 and the transformer. At startup, Q1001 is allowed to conduct, and current starts to flow in the transformer primary. At a certain current, the transformer’s core will saturate so the current can’t increase any more. The voltage induced by the changing core flux in the feedback winding at the bottom of the transformer will suddenly drop, creating a pulse which, fed via C1029 to the gate of Q1001, switches it off. At that point the energy stored in the transformer core has to go somewhere, and it finds its way out through the secondary rectifiers into the outputs. The basic scheme is very similar to the Joule Thief, a simple blocking oscillator for driving LEDs from batteries.

The two transistors Q1003 and Q1008 seem to be involved in regulating the supply. Q1003 can cut off the gate drive to Q1001 in response to three things: the current in R1001 getting too high, the optocoupler IC1001 conducting too much (which indicates that the output voltage is too high) or Q1008 stopping conducting. The latter seems to be a way of shutting down the supply if its output voltages get low, or it might be a cunning standby mechanism involving some more stuff on the secondary side which I haven’t investigated. C1032 seems to be there to make sure that the power supply starts up.

I powered the bare motherboard from an isolating transformer (don’t try this at home, folks, unless you know what one of those is and how to use it) and measured some things. There was precisely no activity going on at all, apart from 300V on the reservoir capacitor C1004 and Q1001’s drain, as expected. I first laid the blame on the little electrolytic C1032, since they’re the most unreliable components in any modern electronics, but tacking another 10uF across it didn’t help. Holding my breath and briefly shorting C1032 didn’t bring anything to life, either.

Then I measured some of the DC conditions. Everything around Q1008 was OK, with R1096 and R1034 merrily feeding electrons into Q1003’s base and keeping Q1001 switched off. High-value resistors are the next most suspicious components in a circuit like this, especially when they’re teeny-tiny ones. I checked around the 1.8 megohm R1005 and R1006 which pull up Q1001’s gate. Clearly it couldn’t work without them. Lo and behold, my 10 megohm input meter showed 250V at the junction of R1005 and R1006. That can’t be right – the voltage should be more like 150V, since the resistors are the same value and basically connected straight across the 300V supply. I pulled R1006 out of its hiding place and measured it – it was open-circuit. Gotcha!

Soldering in a replacement 1.8 megohm resistor for R1006 brought the whole thing back to life. The secondaries seemed to have sensible voltages on them (3.3V and 12V at a glance) so I reassembled it far enough to test. It lit up, accepted a disk and played it. Success!

It’s a credit to Denon’s neat design that there were no screws left over when I put it back together. The whole machine is now back in action for the sake of a 2p resistor.

Herrmans H-Track Standlight Modification

In a previous article, I took apart a Herrmans H-Track dynamo rear light. I wasn’t happy with how the standlight behaved: it stayed on for a very long time. Even after an hour, some glow was still visible. This is more irritating than helpful because it attracts attention to the bike when it’s parked, and many times has caused people to helpfully call, “You’ve left your light on” to me when I’ve locked up my bike.

I also saw recently a poster at a railway station telling cyclists, in no uncertain terms, to switch off their lights when wheeling their bikes on station platforms – apparently there’s a real risk of causing trouble. Train drivers are highly attuned to spotting red lights, and so having extra ones on wayward bicycles is a safety problem.

For these reasons I wanted to get some sort of control over the standlight. The German StVZO regulations (section 67, Technische Anforderung 4) say that the standlight should stay on for at least 4 minutes, so I made that my target. Most such problems these days seem to get solved with an Arduino, but that’s really boring. I wanted to do it the old-fashioned analogue way. After a bit of playing around, I came up with a little circuit which automatically switches off the standlight after 4-6 minutes, and also has a button to switch it off manually. It only uses seven components. Here’s the schematic diagram.

Offer_schematic

It’s a simple monostable multivibrator made of two transistors. When the dynamo is generating power, capacitor C100 charges up via resistor R100 and diode D100. It only charges to about 5V because there’s a 5V-ish zener diode in the main light. The voltage on C100, and thus Q101’s gate, keeps Q101 switched on so the LEDs light up. Because Q101 is conducting, there’s very little voltage on its drain, so Q100 is switched off. Meanwhile, in the original electronics of the light, the standlight capacitor is charging up so that the LEDs still get a power supply when the dynamo stops.

When the dynamo does stop generating, C100 no longer receives any charge but instead starts discharging through R102. Because C100 and R102 are both large, and Q101’s gate has a very high resistance, this takes several minutes. But eventually the voltage on C100 drops low enough (about 1.5V) so that Q101 starts to turn off. As it does so, the voltage on Q101’s drain starts to increase, which gradually switches Q100 on. Once Q100 starts conducting, C100 also discharges through R101, so the whole process accelerates. Q100 and Q101 thus form a sort of Schmitt trigger, which switches off Q101, and therefore the LEDs, fairly quickly at the end of a timing period of a few minutes.

The button S100 is there so that it’s possible to manually discharge C100 and switch the light off, for example when parking the bike. Note that this doesn’t discharge the standlight capacitor so, next time the bike starts moving, the standlight will already be at least partially charged. This is handy.

None of the components are critical. D100 can be any small-signal silicon diode, and Q100/Q101 are just logic-level N-channel MOSFETs.

I built the circuit on a little piece of matrix board. It fitted easily into spare space in the light.IMG_6309

Here are the connections to the original light PCB. The green wire goes to the LED cathodes. You can make out where I’ve rather untidily cut the original PCB track to the LED cathodes. I had to cut it in two places because it was used as a ‘through route’ from the rectifiers to the rest of the electronics. The resulting gap is bridged by the bit of white mod wire soldered to D3.

IMG_6308Fitting in the button, S100, was a bit more tricky. I ended up using a miniature PCB-mounting button and gluing it in into the back of the case using epoxy resin. The button protrudes through a little hole but is doesn’t stick out. I’m hoping that will protect it from damage but still make it easy to use.

IMG_6264

The brown button is visible at the top left of this photo. When the light is mounted on the bike, it’s still accessible.IMG_6310I’ve been using the modified light for a few days now and I’m pleased with it. The light itself is very bright, so being able to switch it off when I stop to buy bread is properly handy.

Herrmans H-Track rear light teardown and schematic

I’m in the process of fitting dynamo lights to my wife’s bike and to mine. For our rear lights, I chose a light I hadn’t seen before: the Herrmans H-Track. It’s relatively cheap but seems to have good reviews. It meets all the relevant standards, if you care about that sort of thing. A quick test on the bench showed that it was nice and bright, and the illuminated ring round the outside is eye-catching.

Img_6207

The standlight works quite well but stays lit for a long time (around 15 minutes, I’d estimate), gradually dimming until it gives up. That’s not as nice as the B+M DTopLight I have on another bike, which stays lit for the requisite four minutes then switches off. I was curious to see if it was possible to improve it, so I took it apart.

The light is glued together but there are little gaps between the two halves at the bottom, which make it relatively easy to lever apart without damaging it. Here’s what’s inside.

Img_6208

A little PCB with not much visible – three LEDs and a capacitor. It’s nicely made, with a fibreglass PCB, but there’s no waterproofing or other sealing. The rest of the components are surface-mounted on the other side of the board. I noted in passing that neither of the wires is connected to the mounting screws, which is handy for lighting systems like the Solidlights 1203DR which need both wires to the rear light to be isolated from the frame. Here’s a closeup of the PCB.

Img_6210

Not a lot to it, really. You get what you pay for. For the curious, here’s the circuit diagram I traced out. It’s clear that the H-Track doesn’t have any protection against overvoltage, so you’re in trouble if your front light comes disconnected.

taillight

What about improving the standlight behaviour? Well, I’ve worked out a modification for that but haven’t tried it out in a real light yet. Watch this space.

Orange Livebox 2.0, port forwarding and NAT loopback

For several years, I’ve been running a small server (a Sheevaplug, as it happens) connected to my home broadband connection. It’s not running anything public, but it’s simply handy to have somewhere I can log in to and do things with from anywhere on the internet. It used to be connected via Virgin Media’s cable broadband service, using an Apple Time Capsule as a router, and a dynamic DNS service to handle the name lookup, and it all worked just fine. I could access my server from computers both inside and outside the house.

Recently I moved house, and the new place has broadband provided by Telekomunikacja Polska masquerading as Orange. Their broadband deal comes with its own router which also provides the VoIP phone service as well as having something to do with the TV. It’s a Livebox 2.0. It would probably be possible to set up a different router to do the same job, but the thought of getting the VoIP stuff to work is too awful to contemplate.

livebox-2

The Livebox 2.0 is a fairly flexible box, and I managed to set it up to forward traffic on one port to my server. The server has a little script which updates its dynamic DNS entry, and that did exactly what it said on the tin. I could log in to the server from elsewhere on the internet. But could I connect to the server’s public IP address from inside the house? No way. The router just reported ‘no route to host’. This was annoying. I have various things set up on my laptop which assume they’ll be able to connect to my server, and to have those not work when I’m at home would be a real pain.

The problem seemed to be that the Livebox didn’t want to route traffic from the internal network, where my laptop was, to its external IP address. Reading Wikipedia on NAT, it turns out that this is a feature called NAT loopback. I didn’t even know it was possible for routers not to support it, but I learn something every day. The Orange Livebox 2.0 won’t do it (and yes, I played exhaustively with all the security/firewalling/port forwarding options).

This called for a workaround. My server has a DNS entry with a dynamic DNS provider. Let’s call it server.dyn.com (it’s not, actually). This resolves to whatever the external IP address of my router happens to be – let’s say 203.0.113.1. From inside my home network, the router makes a mess of handling traffic to 203.0.113.1 so I can’t contact it. However, I have control of DNS on the home network: it’s one of the services on my Sheevaplug. I know that ‘spoofing’ DNS entries is bad practice, but I’m going to do it anyway. I can add entries to my local DNS server which make server.dyn.com look up to 192.168.1.10, the local address of the server. The laptop won’t know the difference, but it’ll be able to contact the server. And outside the home network, there’s no chance of anyone, including me, accidentally contacting my DNS server because there’s no way for traffic to get to it. Here’s a picture.

Img_6117s

I use bind9 as my internal DNS server. I added a section to /etc/bind/named.conf.local:

zone "dyn.com" {
  type master;
  file "/etc/bind/db.dyn.com";
};

and then created another file /etc/bind/db.dyn.com:

$ORIGIN .
$TTL 604800 ; 1 week
dyn.com IN SOA localhost. root.localhost. (
  2009060801 ; serial
  604800 ; refresh (1 week)
  86400 ; retry (1 day)
  2419200 ; expire (4 weeks)
  604800 ; minimum (1 week)
  )
  NS sheevaplug
$ORIGIN dyn.com
example A 192.168.1.10

It worked! At home, example.dyn.com resolves to 192.168.1.10, and out on the internet, it resolves to 203.0.113.1. I think it’s far from perfect – the timing settings on my dyn.com record probably need to be made shorter, so that the laptop doesn’t hang on to them when I leave home, and this setup means that all other subdomains of dyn.com don’t work, but it’s good enough for me for now. Maybe it’ll be helpful for you too.

Installing balloonboard.org Debian Linux build on a Raspberry Pi

I’ve just successfully got Debian Linux running on a Raspberry Pi, having built it entirely from the balloonboard.org distribution. Why might you want to do this? Well, I did it because it gives me a small, clean Debian Linux installation which I can then customise. Here’s how I did it.

Get the software:

svn checkout svn://balloonboard.org/balloon/branches/menuconfig2
make menuconfig
  • Mode Expert mode
  • Balloon Board Raspberry Pi board
  • Choose which buildroot version to build -> Feb 2013
  • Select kernel version 3.8 (rpi)
  • Select Build boot image
  • Select Build kernel modules
  • Select Build initrd kernel
  • Select Build Raspberry Pi boot patition image
  • Select Build Debian Root Filesystem

Now type make and it should all build.

Create yourself an SD card with two partitions on it: one smallish FAT partition for the boot files, and a big ext4 one for the root filesystem. Don’t forget to format them.

Into the FAT partition copy the contents of build/kernel/rpi-initrd-boot. Into the ext4 partition untar the file build/rootfs/debianrootstrap.modules.tgz.

Now put the SD card into your Pi and switch it on. This should boot into a ‘recovery kernel’ which has a minimal root filesystem in its initial ramdisk, just enough to sort out the ‘proper’ root filesystem. I used the console serial port to work with it. The HDMI and USB ports might also work but I haven’t tried them. It should come up with a login prompt. Log in as root, password rootme.

Now to configure the root filesystem:

mount /dev/mmcblk0p2 /mnt/root
chroot /mnt/root

Finish the Debian installation (this has to be done now because some aspects of it need to run on the ARM processor, so it’s not easy to have your PC do it). It will ask you questions about time zones and things:

/var/lib/dpkg/info/dash.preinst install
dpkg --configure -a

Set a password for the root account so you can log in

passwd root

and add the serial port to the list of secure ports which are considered safe for root logins:

echo /dev/ttyAMA0 >> /etc/securetty

And shut things down

halt

That last step will probably produce an error message, but it doesn’t matter as long as it’s written everything to the SD card.

Now put the SD card back in your PC, and copy the contents of build/kernel/rpi-boot into the FAT partition. That contains the real kernel which will mount the newly-minted root filesystem. Put it back into the Pi and boot. It will ask you to change the root password at first login.

It worked for me, though I had to ‘ifdown eth0’ and ‘ifup eth0’ again to get Ethernet to work. From that point on I was able to install Debian packages normally.

How to get the second Raspberry Pi I2C bus to work

One of the useful interfaces on the Raspberry Pi is the I2C bus. Originally invented by Philips in the 1970s for controlling functions inside consumer electronics, especially TVs, it’s still very handy for connecting up lowish-speed peripherals to computers. Some of the most popular are real time clocks like the MCP7940, amongst many others, and general purpose input-output chips like the venerable PCF8574. One of its convenient features is that it only involves two wires: SCL (clock) and SDA (data).

pi2c

The Raspberry Pi originally exposed one I2C bus on its GPIO connector, P1. It had another I2C bus dedicated to the camera connector, S5. However, with revision 2 of the Raspberry Pi, another connector was added. This was P5, squeezed in next to P1, and it also carried the second I2C bus, making it easier to get at and use. However, for some reason the two I2C buses got swapped over between revision 1 and revision 2. And to add a further layer of complication, the camera connector and P5 are wired to different GPIO pins on the processor, even though they are both logically the same bus. I’ve tried to summarise the situation in the table below.

Revision 1 Revision 2
GPIO0 SDA0 P1 pin 3 SDA0 S5 pin 13
GPIO1 SCL0 P1 pin 5 SCL0 S5 pin 14
GPIO2 SDA1 S5 pin 13 SDA1 P5 pin 3
GPIO3 SCL1 S5 pin 14 SCL1 P5 pin 4
GPIO28 SDA0 P1 pin 3
GPIO29 SCL0 P1 pin 5

Working on the CUED MDP project recently, I had a need to get the both I2C buses working on a revision 2 Raspberry Pi. There was no problem with the one on P5: typing

i2cdetect -y 1

showed the devices I had connected to it. But

i2cdetect -y 0

showed nothing at all, and examining pins 3 and 5 of P1 showed no activity. Disappointing. After a bit of digging, it seemed to me that the standard Raspberry Pi Linux kernel configures the processor to use GPIO 0 and 1 as I2C bus 0, and GPIO 2 and 3 as I2C bus 1. I wanted the bus on P1 to work, so I needed GPIO 28 and 29 to be my bus 0.

The BCM2835 processor on the Raspberry Pi, like most modern integrated processors, can have its pins programmed to do various different functions. In this case I needed to disable I2C on GPIO 0 and 1 and enable it on GPIO 28 and 29. To do this I enlisted the help of Mike McCauley’s BCM2835 library. It makes reprogramming the GPIOs fairly straightforward.

To install the library on your Raspberry Pi, make sure it’s connected to the internet, then:

wget http://www.airspayce.com/mikem/bcm2835/bcm2835-1.26.tar.gz
tar xzvf bcm2835-1.26.tar.gz
cd bcm2835-1.26
./configure
make
sudo make check
sudo make install

By the time you read this, there might be a new version of the library, so check on Mike’s site to see what you’re getting.

The C code to set up the bus looks like this:

#include <bcm2835.h> 

#define BCM2835_GPIO_FSEL_INPT 0 
#define BCM2835_GPIO_FSEL_ALT0 4 

main() {
    bcm2835_init(); 
    bcm2835_gpio_fsel(0, BCM2835_GPIO_FSEL_INPT); 
    bcm2835_gpio_fsel(1, BCM2835_GPIO_FSEL_INPT); 
    bcm2835_gpio_fsel(28, BCM2835_GPIO_FSEL_INPT); 
    bcm2835_gpio_fsel(29, BCM2835_GPIO_FSEL_INPT); 

    bcm2835_gpio_fsel(28, BCM2835_GPIO_FSEL_ALT0); 
    bcm2835_gpio_set_pud(28, BCM2835_GPIO_PUD_UP); 
    bcm2835_gpio_fsel(29, BCM2835_GPIO_FSEL_ALT0); 
    bcm2835_gpio_set_pud(29, BCM2835_GPIO_PUD_UP); 
}

It initialises the library, sets GPIO 0 and 1 as normal inputs (thus disabling their I2C function) and enables GPIO 28 and 29 as alternate function 0 (I2C bus), with pullup enabled. To build it, cut and paste the code into a file. I called it i2c0.c. Then compile it:

cc i2c0.c -o i2c0 -lbcm2835

and run it:

sudo ./i2c0

Now I2C bus 0 will be active on P1. Well, it worked for me. Once the code is compiled, of course, you can just run ‘i2c0’ after booting the Pi.

I realise that in future this will probably be made obsolete by changing the device tree sent to the Linux kernel at boot time, but for now it’s useful!

Avometer 8 BLR121 15V battery replacement

The Avometer 8 multimeter has lots of useful ranges, including a special high-resistance range which can measure resistances of up to 20 megohms. This is handy, but it needs a special 15 volt battery. The battery it’s designed for is a BLR121, which was once fairly common but is now dying out. The BLR121 is just about still available but it’s expensive, and since the meter is likely to last a long time I wanted a battery which would also last, and be easy to replace when necessary.

DSCN8944

An old solder reel, a bit of copper pipe, and five common-or-garden lithium coin cells is all it took. The coin cells are CR2032, which are 20mm in diameter, and they fit just neatly inside the solder reel. I cut down the reel to form a tube about 35mm long. The stack of five cells is about 16mm long, so I filled the remaining space with a bit of copper pipe cut to about 22mm long. This is what the assembly looked like:

DSCN8946 DSCN8945

It fitted just neatly into the battery compartment of the meter. The spring contacts are very convenient because you can fit more or less any shape between them!

DSCN8947It works perfectly, and it’s cheap. The CR2032 cells are available for less than 50p each if you shop around, and they have a capacity of around 200mAh. The BLR121 replacements I’ve seen have a capacity of only 40mAh, so the lithium replacement should last about five times longer. Not bad.

Here’s a gratuitous picture of the Avo in use checking the power supply of a BBC Micro.

DSCN8951

 

Avometer 8 repair

The Avometer 8 is a British electronics icon. For probably half a century it was the standard high-quality multimeter, found in every factory, workshop and laboratory. Though an analogue meter seems like an anachronism in today’s digital world, it’s still useful for some tasks, and there are decades’ worth of service manuals and test procedures which still call for measurements to be made using an Avo. They only stopped making them in 2008 because some parts were no longer available.

DSC_0570

This one was given to me by a colleague who got it as part of a deal when he bought a secondhand broken TV. I’m not making this up, I promise. It (the meter, not the TV) was made in 1964 according to the serial number. It really didn’t work when I got it. It read about 30% low on all ranges, the pointer kept sticking, and it hardly ever returned to the same zero point on the scale. I was on the point of scrapping it, but decided to save it because it’s got stickers on it from the lab I used when I did my degree, and I was encouraged by advice from the people of the UK Vintage Radio forum. I opened it up:

DSC_0566

It’s clear that everything is hand-built, and should be quite serviceable. The problems with this meter seemed to be in the movement itself – the sensitive, fragile coil suspended by precision bearings in a big magnet – rather than the electronics. The movement is so delicate that I was worried about wrecking it rather than fixing it! However, it’s only held in with two screws, so I could take it out and see what needed doing.

DSC_0568

In the picture above, the movement has been taken out and is standing on top of the rest of the meter. With the benefit of a little advice, and a very handy article from the Amateur Radio Relay League in February 1943 called ‘Rejuvenating Old Meters‘, I set to work.

The gap in the magnet in which the coil is suspended was full of tiny iron filings. They’re not supposed to be there. They get in the way, causing the coil and thus the pointer to stick, and they short-circuit the magnetic field, reducing the sensitivity of the meter. I cleaned them out in the recommended way using a little piece of Blu-tack.

The bearings suspending the armature were way out of adjustment: it rattled and caught on the centre pole-piece of the magnet, again making it stick. I adjusted the bearings, centring the hairsprings and the coil in the gap and just taking up the slack so it could move freely. The bearings in the Avo are sprung, so the armature is never quite rigid, but there should be no rattle in it.

Things were looking up, but there was still a problem. The movement wasn’t balanced, so the position of the pointer was very sensitive to which way up the meter was held. The pointer assembly has three little arms, one opposite the pointer and two perpendicular to it, to which it’s possible to add weights to balance the pointer. It’s a very delicate operation. You have to hold your breath while doing it, since the slightest draught sends the pointer swinging wildly. This picture, reproduced from the Rejuvenating Old Meters article, shows how the balancing is done. First, the meter is set to zero while lying horizontally. Then it’s turned to stand vertically. The tail weight is adjusted with the pointer horizontal, and the side weights are adjusted with it vertical.

meterbalance

I used paint applied in droplets with a tiny screwdriver to add weight. You can see it in this closeup of the movement.

DSC_0558

It doesn’t take much – the balance is incredibly sensitive.

Now to test it. The bare movement is supposed to take 37.5μA for full scale deflection. With a power supply and a resistor, I gave it a current of 37.5μA and it worked! I couldn’t tell whether it was exactly right because the naked movement is so sensitive to draughts that the pointer was never quite steady, but it was close enough for me.

I reassembled the meter, sticking the glass (yes, real glass!) back into the case as I went, and was delighted to find that it was now working – no sticking, it returned to zero every time, and was fairly accurate. It read about 1% low, though. That’s within its specification but I thought it could do better. Fortunately the Avo designers made the meter adjustable to fix such errors. There’s a shunt on the magnet which can adjust the magnetic field a little to compensate for the slight loss of magnetism as it ages. It’s the piece of metal with the slot in it, held by one screw, in this photo of the top of the movement.

DSC_0565

A couple of millimetres to the left was all it took, and the Avo now reads correctly to within 0.5%. Not a bad result, considering the only tools required were a screwdriver, a bit of Blu-tack, and some paint. Try that with a faulty digital multimeter!