Category Archives: Electronics

The pain of (almost-)failure

It seems this project has consisted of one cockup after another…

– First off, I managed to swap the A and B buses on the level translator chips. The “A” bus goes to the disc drive, the “B” bus goes to the FPGA board. Get it the wrong way round, and the FPGA gets zapped with +5V. Cost: a spool of Roadrunner wire, 1/8th of a reel of solder, four tubs of desolder wick, and two days of tedious desoldering and repair work.
– Next, I cocked up the wiring on the disc drive port. Shorted the RD DATA pin with the TRACK0 pin (these are both outputs from the drive to the host). Cost: 20 minutes of signal tracing with the multimeter, a bit more desolder wick (it was just a solder bridge) and a few inches of solder.
– For additional bonus points, I managed to swap the READY/DISKCHANGE and WRITE PROTECT pins at the level translator. I could have just scribbled over the schematic but I figured I might as well fix it… Cost: an hour, a bit of Roadrunner wire, some solder, a craft knife blade, and a few lacerated fingers.
– To finish the whole shooting match off, the disc drive I pulled out of my junk box just happens to have a slightly iffy hub motor. Specifically, in certain orientations (“lying flat on the desk” being one of them), it won’t spin up. Turn it upside down and slam the disc in against the end-stop, and it will. Just. Interestingly once the disc is in place, it works OK. So I’m fine as long as I don’t have to swap the disc. Y’know, I think I might just find another drive…

Next problem: it spins the disc, seeks to a track and so on, but it doesn’t really read or write anything. “Your challenge, should you choose to accept it… make the damn thing work!”

Homebrew SMD/SMT soldering oven

Once again, I’ve started an expensive project.

A few days ago, I was building up an LCD controller board, which involved soldering down a lot of small parts. Worst of all were the flatcable connectors for the LCD — these are made out of a plastic that seems to melt at about 100 Celsius. Not exactly good when your solder needs 175C just to melt, and its recommended working temperature is closer to 300C…

I figured there had to be a better way. I’ve been aware of [Kenneth Maxon’s article in “Encoder”]( for a while, in which he explains how to turn a “toaster oven” (also known as a “mini oven” on this side of the pond) into a fully working soldering oven. An article on the same thing in the November 2007 issue of “Elektor” sealed the deal — I was going to build one of these things.

The first problem was finding a suitable oven. After a ton of Google searches, I came to the conclusion that nobody documented their projects to the degree of mentioning how powerful their SMD oven was, or even how big. There was a note in the Elektor article that an SMD oven should be “around 1500 Watts”, but nothing about the size of the oven cavity (perhaps furnace is a better word) itself.

I eventually settled on a Cookworks oven which set me back nearly £60, has a volume of 25 litres, and four solid-rod steel-cased heating elements providing a total of 1640 Watts of power. So that’s 410 Watts per element, or 820 Watts on the top and bottom of the oven. The built in thermostat tops out at 250C, and the whole thing is put together with screws, not rivets — meaning it should be fairly easy to dismantle, then put back together.

I’m currently waiting for some parts from Farnell (some K-type thermocouples, thermocouple connectors, a syringe of 63/37 solder paste, a box of 22-gauge dispensing needles, and a couple of [Maxim MAX6675]( thermocouple controller chips), so I’ve gone back to the design side of things for a bit.

I’m a bit stuck at the moment, however. I’ve more-or-less sorted out the power supply side of things (rest assured I’m going to need a pretty meaty IEC cable), but the power switching is proving a little troublesome. All the 8-to-16-amp AC relays I’ve seen seem to have a break current of less than an amp at 240V AC. If I understand correctly, that means that they’re useless for switching the heating elements on and off, simply because an attempt to break the circuit would probably weld the contacts. It’s nice to see that the manufacturers are still wording their datasheets very carefully — “Oh yes, it’s a 240V 16A relay, but you can have either 16A *or* 240V, not both at the same time.” Just like transistor manufacturers, really.

I think I’m probably going to end up using a solid-state relay or a triac/opto-triac combination instead of the mechanical relay. I’m just not keen on their well-known tendency to fail shorted. At the very least, I’ll probably need to add some form of failsafe to kill the power if something **really** bad happens… What that failsafe will be, I don’t know. I’d rather not use a crowbar circuit; deliberately dead-shorting the AC line to blow the 10A fuse in the IEC inlet seems really silly to me.

My current plan is to test the oven’s ramp-up speed — that is, how long it takes to go from ambient to the full 250 Celsius — and if it’s too long, find another oven. If the oven does happen to heat up quickly enough (that is, from 25C to 250C in less than 5 minutes) then I’m going to buy the rest of the parts and build myself a temperature controller for the oven. If I ever find a solution to the power switching problem…

Fun with level translators

Hmm, seems I’m blogging more than usual. Is that a good thing or a bad thing? I’m really not sure…

Well anyway, I’ve spent the best part of two days building up a GPS receiver. It’s based on a FasTrax iTrax321 “receiver on a chip” (actually a SiRFStar III chip and support components mounted on a small, thin PCB) and has one real purpose in life — to take a 5V supply and a GPS signal, and spit out an NMEA0138 serial data stream containing navigation data, and a 1PPS (one pulse per second) timing signal for my GPSDO.

Catch is, the SiRF chip is designed to run off of a very low voltage power supply. Like, 1.8V low. Oddly enough the iT321 takes 3.3V and regulates it down… Basically, this means I need an external level translator, a 3.3V regulator (for the iT321’s main power supply) and a 1.8V regulator (to provide a 1.8V reference for the translator). Using the highly scientific method of “buy ten of whatever’s cheapest”, I ended up with a tube of ten TI TXB0104 level translators, and ten each of the 3.3V and 1.8V versions of National Semiconductor’s LP5951 LDO regulators.

The datasheet for the iT321 is pretty concise as to what you need to do to make the chip work. It wants a Vcc between “X” and “Y” volts, the antenna track needs to have a Zo of 50 ohms, and so on. I’ve deviated from the spec a little, however — I wanted something I could build at home, so I stripped the board down to two copper layers, on a 0.8mm FR4 substrate. First power up, the iT321 booted, sent a couple of debug messages across the serial port, then immediately started sending NMEA0183 navigation (GPGGA) reports.

Problem is, the RS232 data was going as far as the iT321 side of the 220-ohm protection resistor (in the signal path of all I/Os that run between the iT321 and the TXB0104), but all the PC on the other end of my debug cable was seeing was… well… noise. A quick buzz with my scope revealed noise on both sides of the the TXB0104. And by noise I mean something that looked distinctly like the TXB0104 going into self-oscillation. A 40MHz sine wave on every line that was connected to a piece of wire, but the one open-circuit output was transmitting the exact data the iT321 was telling it to (the VALID FIX output).

So it seems the TXB010x series (TXB0104, TXB0108 and similar) have issues with driving inductive loads (like, say, a metre of six-core flexible wire). I added a 74LS244 buffer between the TXB0104 and the debug cable, and the noise vanished — in fact, I’ve been sitting here watching the GPS board’s output on Fastrax’s debug app, GPS Workbench. Eight SVs in use, two more being tracked, first fix in 17.8 seconds, and a HDOP of 0.90. No doubt about it, the SiRFStar III is a very nice receiver… I just hope its 1PPS output is as well-implemented as its navigation algorithms.

Plan of action now is to design the GPSDO (which will probably be based on a couple of 74HC dividers and a HCT4066 PLL chip) and then build up that and a Rev D GPS receiver board. Then I just need to build up the frequency counter and Zener diode tester…

EDIT: Before anyone asks, the iT321 is based on the SiRF GSC3LTf — see The specs for the iT321 are here:

Repair Tip: Viewsonic VX922

*Device:* Viewsonic VX922 TFT monitor

*Fault:* Power light blinks green “long on, short off”. Some signs of backlight activity, but display otherwise black.

*Cause:* Defective “Capxon” electrolytic capacitors on AC power board. Possible issues with defective “Teapo” electrolytic capacitors on the controller board.

*Solution:* Replace all electrolytic capacitors on the power supply board with suitable replacements — e.g. Panasonic FC or FM series. Be aware that space is tight, and as such replacements will need to be the same size as or (vertically) shorter than the existing parts. Vertical height available is ca. 18mm (0.75in).

Replacement of capacitors on the controller board may also be necessary, but be advised that due to a lack of thermal relief on the capacitor pads, desoldering (and soldering of replacement parts) will be difficult using any less than a 100W *temperature-controlled* soldering iron. Try replacing just the PSU capacitors first; do not replace the Teapo capacitors on the controller board unless a PSU component swap fails to repair the monitor.

Floppy disc reader/writer project — update 200810/1

A few of you might be aware of my pet project — a floppy disc reader/writer that operates at an insanely low level (it operates on individual magnetic flux transitions). The advantage of this thing being that it’ll be able to read (and write!) just about any disc format that can be read in a standard 3.5″, 5.25″ or 8″ disc drive.

Well the big news is that I’ve got approval to cover the software side of things for my final year university project. I’ve also taken a different route to developing the hardware — I’m going to use an Altera Cyclone II Starter Kit (and a pair of bodge-boards) to build a prototype, then work on pulling it into the CAD software later. Given that the HDL code is basically done, this means I can spend nearly all of my 30 weeks (well, 27 weeks now) getting the software finished.

For anyone who hasn’t seen the C2SK board, it’s basically a rebadged TerASIC DE1 development board. 18 LEDs, four momentary switches, 10 two-position switches, a four-digit seven-segment display, 8MBytes of SDRAM, 4MBytes of flash, 512KBytes of SRAM, an SD card slot (!), VGA out, RS232, audio in and out, a PS/2 keyboard connector and two User I/O connectors… which are good old 40-pin IDC sockets. All for £99 plus VAT from Digikey.

And the default startup program does a neat LED chaser display that has been described as “[airport security attract mode](”. I can’t help but agree, the demo sequence is very show-offy.

Software-wise, I’ve done a few quick tests to do histogram analysis of disc track data, but I’m going to have a crack at some MFM decoding over the next week or so. Chuck G. was kind enough to send me some FM, MFM and GCR samples last year, which I’m ashamed to admit I haven’t had a serious look at yet. I really need to get my hands on a few floppy discs from “strange and unusual” machines. I’m aiming for Amiga and BBC Micro at the moment, but I’ll probably add PC floppies to the mix later on.

But first, I need to get the SDRAM working with the FDDReaderWriter HDL code…

Thoughts on sources of small, cheap Li-ion batteries

I think I’m on a “make it smaller” bent again.

I’ve ended up building a laser tachometer to assist in testing the motor speed controller code (which is going to end up using a PID loop for speed control, more later). After I finished it, I realised that I’d ended up designing what effectively amounted to a reusable test/measurement hardware platform. All I needed was a power source.

Farnell stock a decent range of Li-ion batteries, but it seems all the reasonably high-capacity ones are either horrifically expensive, or just plain too big for the Maplin “T2” plastic cases I’ve grown fond of.

Enter the Hahnel HL-5L, a clone of the Canon NB-5L. Truth be told, I wanted the Jessops NB-5L clone (it’s 1100mAh, the Hahnel is 950mAh), but said battery wasn’t in stock at the time…

The measurements of the battery are:

* 45mm long
* 32mm wide
* 8mm tall

So it’s a perfect fit for the T2, among other things. The near-1Ah capacity also makes them very useful for portable gear. I suspect they’re probably Lithium Polymer rather than Lithium Ion, but they’re much better than the Samsung mobile phone batteries I’ve been using recently…

Connecting them would seem to be the hard part – there are three pins — +, T and -. + and – are the positive and negative power supply (actually +3.7V and 0V, but that’s an academic point). The T pin appears to connect to a 10k thermistor inside the battery pack.

There don’t appear to be any magic-handshake procedures involved in getting these batteries working, unlike most laptop batteries (I bought a few Compaq laptop batteries a while ago and ended up stripping them for cells, and adding a custom safety circuit). Charging should be a piece of cake — no doubt the good old [Maxim MAX1811]( or the newer [MAX1555]( should be suitable. Both are specced to charge Li-ion and Li-polymer packs.

Next step will be to build a connector for this thing – the Ixus cameras that use this battery (860IS and such) use three thin brass (?) spring contacts mounted in a plastic body. I’m probably going to end up using epoxy putty to make the base, and some brass sheet to build the contacts…

Motor speed measurement

If you’re just here for the answer to the question “how fast does the Ptouch motor need to run”, the answer is 3000RPM. Ish.

I’ve confirmed this using two different measuring methods — measuring the timing between noise spikes on the motor’s power lines, and the old reflective-tape-and-laser trick. I didn’t use the motor inside the Ptouch; I actually found a motor in a defunct CD-ROM drive that was the exact same type as the one in the Ptouch. It’s a Mabuchi RF-300C-11440, FWIW. [Rapid Electronics]( stock them as “solar motors” (part number [37-0440](, and there’s a datasheet online too. Oh well, at least spares won’t be a problem 🙂

The spike timing trick is quite nifty, and involves using an oscilloscope to show the voltage across the motor. Then you measure the time between three spikes, halve the frequency (in Hz) and multiply by 60 to get the speed in RPM. It works quite nicely, for the most part. Unless the motor doubles up a spike or misses one altogether. As usual, I’m not the first guy to think of doing this — a certain Roman Black [beat me to it]( I never seem to have any original ideas…

To get a more reliable speed reading, I grabbed a laser pointer and a phototransistor out of my junk box. Then I promptly blew up the laser — seems they rely on the current limiting of the batteries — and the spare was broken (looks like the metal shell had worked loose, breaking the +VE connection). So I bought a 5V “idiot resistant” (that’ll be me then) 1mW laser from Maplins for a tenner and bounced a little spot of coherent red light off a piece of tinfoil I glued to the output pulley. That bit of tinfoil (shiny side up) bounced light into the phototransistor once per revolution. Once again, multiply the frequency (Hz) by 60 to get the speed in RPM.

Once again, I got a figure of 3000RPM. Well, 3030 actually, but what’s 30RPM between friends?

Next plan: make the laser tacho permanent. I’ve got some 5mW lasers on order (which should hopefully turn up in a few days) which are earmarked for other, more interesting projects (and 5mW is a bit much for this sort of thing anyway). This time I’ve bought five, so failed diodes shouldn’t be as much of a problem in future!

Well, that and they’ve got a built-in driver circuit. Only a single-transistor constant-current driver, mind, not like the photodiode-regulated three-transistor monster on the Maplin module.

Reverse-engineering a Brother PT-1000 label printer — Walkthrough

Well, yesterday I nipped down to Maplins and bought myself a Brother PT-1010 label printer, as an upgrade for the PT-1000 I’ve been using for the past few months. This was mainly down to the fact that the ‘1000 was nearly useless for labelling component boxes — mine would never print the micro (mu) symbol, or the ohm symbol. That and the PT-1010 has a 12-character display and shows actual error messages, vs. the 8-character display and single “ERROR” message on the PT-1000 (you have to spend ages working through the flowcharts to find out what’s wrong with it!) Also, I wanted an excuse to rip the PT-1000 apart and figure out how it works (or worked?)

So I checked that the ‘1010 worked, moved the label cartridge from the 1000 (they both use the “TZ” tapes), and swapped the batteries over. Then I ripped the 1000 open and started investigating…

The P-touch system seems to be based on thermal transfer technology. There are actually three tapes in the cartridge, not one:

* The plastic carrier tape — the ink is transferred to the back of this tape, which also forms the front of the label.
* A thermal-transfer ink tape — this carries a thermal ink which is transferred to the carrier tape using a thermal print head. The unused sections of this are discarded.
* The adhesive backing and base — adhesive coated on both sides, one side covered with a protective sheet. This forms the back of the label.

So the idea is, the first two tapes pass in front of the thermal head, then the ink dots that make up the character are transferred from the ink tape to the carrier. The used ink tape is fed onto a takeup spool inside the cartridge, while the carrier tape (with ink dots transferred) is attached to the adhesive backing. Nice and easy, and it works pretty well — the labels will tend to put up with quite a bit of abuse, and the plastic carrier stops anything reaching the ink.

But what about the printer — how does it work?

Well, the PT-1000 uses a Panasonic MN101C77 microcontroller to control the print head. This chip is a mask-ROM device that appears to have either 32K or 48K of ROM, and either 1.5K or 3K of onboard RAM. So obviously there isn’t much space there for character definitions, etc., which explains the slightly ropey print quality.

The LCD seems to be controlled by a glob-top LSI, as seems to be the case with a lot of Chinese-made kit.

Lastly, there’s a ROHM BA6220 motor speed controller, which seems to exist solely to keep the speed of the DC motor (which I’ll get to in a minute) constant under varying load conditions.

So now we move onto the printer mechanism. We can split this into three parts:

* Printing — the thermal head, basically.
* Label feed — the motor, gearing and drive system
* Sensing and detection — the cutter actuation switch, and the three pinswitches that are used for cartridge presence and type detection.

The printing head itself appears to be a 64-dot 12mm thermal print head, manufacturer unknown (possibly Kyocera). There are ten contacts on the flat-cable connector, which is obviously not enough to drive the printing elements individually. So that means there’s a shift register in there. Two pins are used for +9V (actually 7V to 9V according to the legend on the power connector), two for +3.3V, and four for control — strobe, clock, data and latch-pulse.

There are also three pin switches in the cartridge bay. These are used to detect the state (hole/no hole) of the cartridge type points on the bottom of the P-touch cartridges. One of these is used to detect that a cartridge is inserted, while the other two seem to identify the tape size. I only have the 12mm tapes, so I can’t say for certain which pins control what without doing some further tests.

So now we move onto how the head actually works. To start with, I powered up the printer and used a multimeter to find all the ground and power pins. This was fairly easy — the PCB has labelled ground and +3.3V test points. I scanned across all ten pins on the connector, and measured the voltage on each pin. By tracing the tracks on the board, I found a few pairs of pins that were connected to the same points. It turns out there are two battery supply (more likely heater supply, about 7V to 9V) points, two +3.3V supply points, and two grounds. That’s six power pins, which leaves four actual signal lines.

One of my fairly recent acquisitions is a Tektronix TDS2024B digital storage oscilloscope. This nondescript white box can acquire at a sample rate of 2Gsps (two gigasamples per second), across four signal channels. This makes it ideal for reverse engineering digital circuitry, where lots of signals often depend on each other. It’s an absolute godsend for debugging SPI serial buses (which involve four lines — chip select, master-out-slave-in, master-in-slave-out and clock). You can watch an entire bus transaction take place, capture it, zoom in and out, and figure out in a few minutes why that particular transaction failed.

But enough about the scope. Seeing as we only have four actual signal lines (once we eliminate the power feeds), we can put each signal on its own input channel and see everything that’s being sent to the print head at a given point in time.

But to do this, I had to attach about half a dozen wires to the fine-pitch flat-cable connector… less said about that the better. The connector appears to be about 1mm pitch…

So now I’ve got the head wired up to the scope, I powered up the ‘1000 again, filled the print buffer with capital “X” symbols (these are easy to spot in data traces, as you’ll see in a minute) and hit print. The scope was set to trigger on the first clock cycle, and I ended up with this:

OK, that gives you an idea what the P-touch is sending to the head — the scope is triggering off the falling edge of channel 1 (Note the “CH1 (fall) 2.40V” in the bottom right corner of the screen dump). From the trace, it’s pretty obvious that Ch3 (magenta/pink) is some form of clock signal, and Ch4 (green) is data, which leaves Ch1 and Ch2. We can also see that the print data is sent in eight bursts, though we can’t see how many clock cycles there are in a burst. So let’s zoom in a bit:

Hmm. Eight cycles in each burst. That makes sense, seeing as eight bits is a byte. Let’s take a closer look at that trace, turn the cursors on and see how fast data is being clocked into the head…

That’s 1.6us per clock cycle, or about 625kHz. Let’s zoom back out again, and see how much time there is between each burst:

Once again the scope did the hard work — there’s a delay of 10us between data bursts. It looks like the print head is being controlled by some form of onboard serial port (shift register?) on the Panasonic chip.

Now I’m going to turn the cursors off, and set the scope to view 1 again. Note that this is a short video clip of about 6Mbytes in XviD/AVI format, not a static image:


This is the first view again, but shown in real time. You can see the high area of the data bytes move into the centre, then back out again. Think about what an “X” looks like. Two arrowheads next to each other, with symmetry around the centre point. Data is sent line-by-line, and the P-touch prints horizontally. What you just saw was a bunch of “X”es being clocked into the print head as bitmap data.

So now we need a few more measurements:

* The low time and high time for the Ch1 waveform. They aren’t the same, there may be some meaning in that.
* The low time and period for Ch2, and how long it takes from the rising edge of Ch2 to the falling edge of Ch1

Let’s go back to view 1 again, zoom out and move the trace along a bit:

Note that I’ve turned the cursors on, and used them to measure the low time of the Ch1 signal (first image). I’ve also measured the high time (second image). We’re looking at a low time of around 4ms and a high time of around 10ms. That’s a total of 14ms.

Last but not least, we need Ch2’s low time (pulse period) and the Ch2-to-Ch1 delay. This time I’m going to set the scope to trigger off Ch2’s rising edge, in Single Sweep mode:

Reading off the cursor values gives us a low time of 1.4us (first image) and a delay of 11.2us from Ch2 going high to Ch1 going low (second image).

So now we need to do some research. What are these signals? What do they do? What do they mean? Well, it turns out Kyocera have produced a really nice application note on how their thermal print heads work… and the waveforms match the P-touch ones almost exactly. So open up the [application note]( and read through it. Pay close attention to the “Driver IC equivalent logic circuit” and “Sequence of printhead operations” sections.

Let’s take a look at the first image again (the overall view) and #7 (the zoomed-out view):

Compare these with the timing diagram in the Kyocera appnote. See the similarity?

It seems Ch1 (yellow) is our Strobe, Ch2 (cyan/light blue) is our /Latch (not-latch) signal, Ch3 (magenta/pink) is the clock (which we knew before), and Ch4 (green) is the data line (which we guessed from the video trace). From the video, we can also infer that when a high bit is clocked into the register, that heating element will be energised on the next firing cycle (latch pulse followed by low pulse on Strobe).

So if we merge the pinouts we’ve deduced with the scope with the power pins that we found earlier, we get:

1. Vheater. +9V supply from battery pack.
2. Data. Serial data into shift register.
3. Clock. Serial shift clock. Apparently clocks on a high-to-low edge.
4. Latch pulse. Negative-going latch pulse, ~1.6us wide.
5. +3.3V logic supply.
6. Ground.
7. Ground.
8. Strobe. Negative-active strobe pulse used to fire the print heads. Timing critical.
9. +3.3V logic supply.
10. Vheater. +9V supply from battery pack.

You’ll notice that I’ve described the strobe as “timing critical.” The strobe must be low for no longer than the P-touch holds it low (in this case, 4 milliseconds). If it is held low for too long, the print head will burn out. The high time is irrelevant, as in this state the head elements (heaters) are not energised.

It’s also worth paying attention to the time from latch to strobe (there is a time delay from latching the data to it appearing on the thermal printing elements) and the clock rates.

Now I just need to figure out how that blasted motor speed controller works… The motor is wired in reverse, and the drive voltage seems to be around 2.685V according to my DMM. The BA6220 datasheet is pretty sparse though…

And as a final bonus, here’s a picture of my rather scruffy, cramped workbench:

USB-TMC isn’t all it’s cracked up to be

Why can’t anything be as easy as it looks?

I’ve spent the past two days trying to get my Tek TDS2024B to talk to a Linux box via a homebrew USB-TMC driver library. Based on the USB-TMC spec, I’m doing everything by the book — and in fact, I can get the scope to respond to a GET_CAPABILITIES control request. Problem is, as soon as I try and send a command over the Bulk endpoint, it times out.

Urgh. I’m going to spend a few minutes reading through some libusb sample code, then if I still can’t get it going I’ll try and finish reverse-engineering the nasty binary serial protocol the HM8130-3 signal generator uses.