(Embedded video)

• Original blog post
• More about the bit-banging USB host
• Forum thread
• Source code

The AVRFID was a quick but rather unique project, back from when I was on a bit of a 125 kHz RFID binge culminating in the design, construction, and installation of a proxcard reader for my garage door. While I was fidgeting around with such things, it occurred to me that you could (using a whole host of dirty tricks) convince a general-purpose 8-bit microcontroller like the AVR to function as a passive RFID tag.

Since then, I received a couple patches:

• Luke Koops improved the FSK modulation for HID tags, so that the resulting waveform is much more regular.
• Cesar Fernandez described the HID card format in more detail, and implemented a parity calculation. The 45-bit code is actually composed of four distinct fields:
  • A 20-bit manufacturer code or header, constant for all HID cards.
  • An 8-bit site code, unique to the particular security installation.
  • A 16-bit unique ID. These are often printed in decimal on the back of the card, and they seem roughly sequential.
  • An odd parity bit, covering the other 44 bits.

I didn’t have my RFID gear handy, so Cesar was kind enough to verify it with his official HID reader. So I stamped a new version number on it. If you’re interested in building your own HID card emulator, there is now a much better chance it will actually work with your reader

• Grab the latest source code from Subversion.

So I cracked it open, naturally. (Hey, I was planning on using it for that crazy project.) And I was shocked to find this:

Bluetooth and USB are both quite complicated, and this project is implementing only tiny fractions of each specification. But I think it’s enough to show that the functionality you actually need in a simple embedded application isn’t that complex- and a lot of the cheap consumer electronics you can get nowadays might actually be more hobbyist-accessable than they appear.

Hanno on the forums found some great $2 Bluetooth dongles on DealExtreme. So I just had to order a few of these and try them out with my work-in-progress software stack. The result:

That’s a Propeller demo board, the $2 dongle (stripped down and attached to a 4-pin header, for convenience) and no other components. The demo here is just scanning for nearby devices, but I also have some basic L2CAP support and I’m working on the SDP server. Currently the stack uses 4 cogs (3 for USB, 1 for Bluetooth) and 12 kB of RAM, but I’m hoping to optimize it.

(Of course, this is only possible because the Bluetooth dongle itself has significantly more RAM and ROM than the Propeller has. Oh, the economies of scale!)

The software is very much a work-in-progress, but you can find it in the Subversion repository, with an MIT-style license.

]]> http://micah.navi.cx/2010/04/embedded-bluetooth-for-2/feed/ 1 http://micah.navi.cx/2010/04/its-alive-bit-banging-full-speed-usb-host-for-the-propeller/ http://micah.navi.cx/2010/04/its-alive-bit-banging-full-speed-usb-host-for-the-propeller/#comments Fri, 02 Apr 2010 04:37:00 +0000 Beth http://micah.navi.cx/?p=1006 I’d like to make a more detailed post about this once the project is a bit further along… but for now just a brief description and a couple teaser photos

This is one of those things that people have said was impossible, and I’ve wanted to try it for a while. I finally found an excuse. I wanted a way to build more cheap wireless networked devices. You can get bluetooth and wifi adapters that are microcontroller-friendly, but it’s a niche market so you’ll pay a lot. I wanted a way to use the $2 bluetooth dongles and $10 wifi adapters you can easily find online or at your local electronics shop. But these devices are all USB, and USB host controllers aren’t yet common on small hobbyist-friendly microcontrollers like the Arduino and Propeller. So, I decided I’d see if it was possible to implement a USB host controller entirely in software on the Parallax Propeller microcontroller.

Turns out that it is. This still needs more development before it’s generally useful, but it’s already showing potential. Of course there’s a long list of caveats on something that pushes the limits of both the Propeller and the USB spec, but none of them should be deal-breakers for most applications.

If you’re interested in helping with or following the project’s development, there’s a thread on the Parallax forums. The latest source code is in my usb-host Subversion repo.

So, that idea is pretty crazy, but it seemed just barely plausible enough that I had been thinking about the component parts of such an amplifier. The most important seemed to be a sensor that could accurately supply feedback on the speaker cone position without loading the speaker or distorting the cone. The first method we considered was a capacitive pickup. Paint the back of the speaker cone with conductive paint, then position two copper plates behind the cone, just barely not touching when the speaker is at its maximum throw. This acts like two capacitors in series, and gives you a capacitance that varies along with the audio frequency, without any mechanical connection to the speaker cone.

We also considered magnetic feedback, using something like an LVDT, but where one coil is the voice coil itself. This would involve modulating some kind of high-frequency carrier into the speaker drive signal, then placing another fixed coil around or behind the voice coil to pick up that signal.

The next method, and I guess the simplest, is optical. This would work a lot like a fiber optic microphone or an optical guitar pickup. You can measure vibration by detecting changes in light intensity caused by changes in distance or angle of some reflective thing that’s vibrating.

Whereas the capacitive and LVDT ideas require a high-frequency modulated signal, that’s optional with the optical method. You can measure absolute intensity, or you can modulate your LED with a high-frequency carrier that can be detected on the receiving end. This modulation can help reject ambient light (including hum from fluorescent lights) but it isn’t required.

So, to see if this project has even a tiny chance of working, I thought I’d prototype the optical sensor by building an optical microphone. The end results were rather mediocre. I’m posting it here only because:

• I was honestly surprised that it worked at all
• It could be useful for other applications, like a drum or bass guitar pickup
• Maybe one of my readers has hints on making it more sensitive and lower noise?

The Circuit

This is a really simple back-of-the-envelope sort of transimpedance amplifier, high-pass filter, and gain stage. Disclaimer: I hate doing math for analog circuits when it’s just a quick hobby project, so I did no math in designing this. Take it with a few shakes of salt. My breadboard was humming pretty badly due to incoming EMI, so I built it dead-bug style in a mini Altoids tin. If you build this, definitely use a suitable amount of shielding.

• Power supply range is about 3-6v, but it seems to work best at 5-6v. (If you listen to the op-amp data sheet, max voltage is 5.5v.)
• The op-amp should be a low-offset, rail-to-rail, high-bandwidth type. I used the OPA2350 because that’s what I had handy.
• The IR LED I used is pretty generic. I’m operating it at fairly high current, because I wanted a strong light source. You might consider using multiple LEDs, though, to make it easier to position the pickup properly.
• The photodiode should be a PIN diode with an IR filter. I used an SFH229.
• Keep the leads short, especially power and photodiode.
• They aren’t on the schematic, but remember some decoupling capacitors. (I used 0.1uF and 22uF)
• I put a bit of black heat shrink tubing around the photodiode as a baffle. This seemed to help.
• I used a stereo 1/8″ audio jack for ground, audio out, and power in. It would be neat to build one with a built-in battery, but this tin was a bit small for that, and the IR LED is kind of power hungry.
• Make sure to ground the Altoids tin! These smaller tins are harder to solder to than the larger tins, but it can be done. Just use a hot setting if your iron has adjustable temperature, and be patient.

Rubber Band Pickup

The first successful test I had of this pickup was with a rubber band. I’d like to try this with a guitar string, but I don’t play

It’s actually pretty forgiving about the positioning of the pickup relative to the rubber band, and it’s very sensitive even when the rubber band is a few inches away. This circuit can pick up very low-frequency vibrations well, so you hear very deep bass notes that you don’t normally notice in a rubber band pluck.

• Optical Microphone: Rubber band test (MP3)

Speaker Surface Pickup

This is the application I originally hoped the optical microphone would work for: picking up sound off the front or back surface of a loudspeaker cone. If I could do this really well, the closed-loop amplifier might have a chance. The results certainly weren’t hi-fi, but I guess I was still surprised it worked at all.

Unlike the rubber band, this test was extremely finicky. I had to position the pickup just right, and I used some Kapton tape to make the surface of the speaker more reflective to IR light. I also had trouble getting a good reflection off the curved surface of the cone, so I stretched a flat section of tape between the center dome and the middle of the cone. This gave good signal strength, but the tape itself also acted as a mechanical filter, giving kind of an odd frequency response to the whole system.

• Optical Microphone: Music test (MP3)

And that is all.

Hopefully this will allow me to have some closure on a completely mediocre mini-project that was nonetheless interesting enough that I couldn’t just forget about it without sharing. If anyone reading is a real electrical engineer, I’d be interested in hearing about what I did wrong.

But what if you just want one weight sensor, not four? The balance board starts to look kind of pricey, and who wants to deal with Bluetooth if you don’t have to?

I’ve had a couple ideas for problems that could be solved by a cheap interface to the weight sensor in a common digital bathroom scale. The kind you can get for $15 or so at the local big-box store. For example, I’ve pondered using a grid of bathroom scales as an input device. You could use it to emulate a DDR pad, and there might be new applications that could benefit from analog weight readouts on each square of the pad.

The other idea is really Scott‘s doing. He has a kegerator, and naturally we’ve been plotting to fill it full of all manner of sensors, actuators, and RFID readers. We’d like to have a continuous measurement of the keg’s weight, both to have some advance warning that it’s getting low, and to detect when an individual glass of beer has been dispensed. It seemed like if we could use the sensor from a digital bathroom scale, the filtered output would probably be accurate enough to detect the difference in weight from just one beer.

I’ve seen other projects to hack a digital scale. For example, this SD Card Bathroom Scale project uses a microcontroller to ‘read’ the LCD by decoding the signals used to drive it. This was a great idea, and he pulled it off quite well. But it requires a lot of wiring, and you’re still limited to the resolution and functionality of the original scale. I wanted to see if there was a simpler and lower-level way to hack a typical bathroom scale. And, for my particular scale at least, there is.

How a digital scale works

Old-skool analog scales (you know, with the needle that moved) were based on some clever gears and levers that converted pressure on the scale into compression of a big spring, then the spring’s compression into rotational motion that could drive a dial. But digital scales don’t really have any moving parts. They are mechanically designed to distribute your weight evenly to a bar or collection of bars which bend very very slightly under the pressure. Those bars are bonded to an electrical element that also flexes very very slightly, changing its electrical resistance. This is a strain gauge.

Inside the scale I hacked, you can see the two load-bearing bars. Each bar has two strain gauge sensors bonded to it. Measuring the difference in strain between the two sensors can tell you how much the bar is flexing.

There are a lot of notable parts here:

• There are two buttons mounted on the scale’s feet. These are connected in parallel. If either one is pressed, the scale will power on.
• The vertical bars on the left and right are load cells, the mechanical parts that are designed to bend slightly. Each one has a tiny PCB with two strain gauge sensors. The two sensors share one common wire, so there are three wires going to each load cell.
• The clip in the bottom-center originally held a lithium coin cell battery.

And on the main PCB:

• A numeric LCD module, bonded to the PCB.
• A microcontroller or ASIC of unknown variety. This is the digital chip that runs the scale- it’s a chip-on-board module which is soldered to the back of the main PCB.
• Analog front-end. This consists of an LMV321 quad op-amp, a few transistors, and a heaping spoonful of passives. This amplifies and conditions the signal from the strain gauge sensors. I’ll talk about this more below.
• Power switching. The analog front-end is very low-power, but to preserve battery life even more, the microcontroller uses a transistor to turn it off entirely when the scale is sleeping.
• Hidden features! There’s a “CAL” header. If you short this header, wake up the scale, then un-short it, the scale will go into a factory calibration mode. The LCD displays some kind of raw reading in this mode, and it continuously updates.

This is the only scale I’ve disassembled, so your mileage may vary. If your scale puts everything on a single IC, there may not be a way to hack it without building your own analog front-end. But if you get lucky (older scales may be more likely to use discrete parts) you may see something like this in the scale you disassemble. The separation of functionality into discrete analog and digital circuits makes this model of scale quite fun and easy to hack!

Reverse Engineering

This section will explain the process I used to figure out how this scale works. You might be able to use some of the same procedures on other types of digital scales.

• Visual inspection: Noticed the op-amp chip, arrangement of the passives, how the strain gauges were connected, power switching.
• Looked up a data sheet for the op-amp chip. Noted the power and output pins.
• Used an oscilloscope to probe each of the four op-amp outputs, looking for a signal that seemed plausible for a microcontroller to measure. This would have to be either a fairly high-amplitude DC analog voltage, or some kind of variable-frequency signal.
• Found this signal. Output D on pin 14 had three different kinds of waveforms: low when the scale is off, high when the scale is on but not actively measuring weight (microcontroller is doing calculations or updating the LCD?). When weighing, this pin is a pulse train whose duty cycle seems proportional to weight.
• Traced this signal back to a pin on the microcontroller.
• At this point, it might have been sufficient to interface to the scale by snooping this signal. But the pulse train is not present all of the time, so I’d have to have extra code to ignore the idle periods. And you’d have to simulate button presses to keep the scale awake. So, I wanted to figure out how to keep the scale in measurement mode all the time.
• First step: Keep the analog front-end powered on. I traced the V+ pin on the op-amp back to a transistor that the microcontroller uses to power on all analog circuitry. I soldered a shorting jumper across this transistor.
• Now when the microcontroller is off, the op-amp output is high rather than low. This means there must be some other signal that the microcontroller is outputting in order to put the analog frontend into measurement mode, or otherwise generate that pulse train.
• Probed around the microcontroller with my oscilloscope, looking for interesting signals on the pins nearby where the op-amp signal enters.
• Found another pulse train which was active only when the scale was in weighing mode. This signal seemed to be at the same frequency as the op-amp output signal. This one is normally low, but has brief high pulses.
• At this point, I thought I had enough information to guess how the circuit worked. Traced where this signal goes, to verify. It is an output from the microcontroller which heads to a transistor in the analog front-end. I didn’t fully reverse engineer this, but I suspect it’s discharging a capacitor that’s used for integrating the analog weight signal.
• Made the modifications discribed below, and hooked the analog front-end input and output up to a Propeller microcontroller. Verified my guesses by performing some experiments with the microcontroller.

Analog Front-end

This documents my understanding of how the analog front-end works in this digital scale. I didn’t reverse engineer the circuit itself, so this is really just a “black box” description based on observing how the circuit behaves.

The circuit’s input is a tiny resistance from four strain gauges. They are arranged as two independent load cells, each with two sensors that act as a differential pair. The front-end amplifies these tiny differences in resistance, and sums them into a single analog signal. For example, if the strain gauges were labeled L1, L2, R1, and R2 (two sensors each for left and right load cells), the analog summation would be:

Total = L1 – L2 + R1 – R2

This total is still an analog signal, and it’s fairly noisy. There would be a lot of different ways to convert this to a digital signal: a standard successive-approximation A/D converter, a voltage to frequency converter, an RC oscillator… This scale uses an approach that’s simple, cheap, and pretty accurate for situations where you’d like to dynamically make tradeoffs between sample rate and accuracy. It uses an integrator and comparator.

In this approach, there is a capacitor which can charge or discharge depending on the state of a signal from the microcontroller. I’ve been calling this the “Reset” signal. When Reset is low, the capacitor slowly charges at a rate which depends on the analog Total above. This is an analog integrator. When Reset is high, the capacitor discharges quickly. This voltage across the capacitor is fed to a comparator, where it’s compared to a reference threshold. If it’s larger than this threshold, you get a logic “1″ out, if it’s smaller you get a logic “0″.

This starts to look a lot like a closed-loop feedback system. In fact, you can even think of it as an electronic equivalent to the old mechanical balance. Instead of balancing two physical weights on a lever, you’re balancing two electric currents which are trying to charge or discharge the integration capacitor. If the capacitor voltage is too high, you need to drain it a bit. If it’s too low, you need to let if fill up. If you keep the capacitor voltage oscillating right around the comparator threshold, it’s just like you’ve balanced a mechanical scale. Now you know how heavy the object you’re weighing is, because you know how much time you need to spend discharging the capacitor to keep it balanced.

I find this symmetry between the mechanical and electrical scale pretty elegant. It’s also practical- your accuracy is limited by electrical or mechanical noise in the circuit, and by your microcontroller’s timing resolution. But you can always integrate over longer periods of time in order to trade sample rate for accuracy. If you keep the capacitor balanced for a whole second, and add up how much time you spent discharging the capacitor over that second, you’ve just calculated the average weight with much more precision than you’d have if you measured the length of a single discharge pulse.

Modding the Scale

After figuring out the analog front-end, I really just wanted a way to use that by itself without worrying about the built-in microcontroller or LCD. This turned out to be really easy:

• Remove the lithium battery and holder
• Solder a jumper wire across the transistor that normally powers off the analog front-end. (This is visible in the photo below, near the red and black power wires.)
• Cut three traces near the microcontroller: Reset signal out, comparator signal in, and button signal in. This separates the microcontroller from the analog circuitry, and it also prevents the microcontroller from waking up. It will stay turned off.
• Solder a 5-pin ribbon cable to the board: Ground, Power (+3v), Buttons (optional), Reset out, Comparator in.

The wires on the left are power and ground. It’s hard to see here, but the traces corresponding to the three wires on the right were cut, between the wires and the chip-on-board assembly. From top to bottom, those wires are comparator, button, and reset. And that’s it! With that simple mod, the scale is ready to connect directly to any 3.3v microcontroller with two free I/O pins. I used a Propeller, but an AVR should work great for this too. If you’re using a 5V microcontroller, you’ll still want a 3v or 3.3v power supply for the scale. You may also want to limit the voltage on the reset output signal too, though I suspect this isn’t actually necessary.

Software

I tested this mod using a PropRPM board and some jumper wires. All of the other stuff on the PropRPM board is unrelated to this project- no external components are necessary to talk to the scale, just two 3.3v I/O pins.

The software is pretty simple. To measure weight, you need to toggle the “Reset” output on and off in order to keep the integration capacitor balanced around a comparator threshold. Pulling Reset high will quickly drain the capacitor, pulling it low lets the capacitor charge at a rate which depends on the total weight on the scale. You can take more accurate measurements by repeating this for more cycles, or take quicker measurements by repeating it for fewer cycles. On the Propeller, I use the system clock to measure the total amount of time that I spend letting the capacitor charge. Here’s a complete program that prints scale measurements to the serial port:

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  PIN_SCALE_OUTPUT = 3    ' Pulse high to discharge
  PIN_SCALE_INPUT = 4     ' Output from integrator

OBJ
  term : "Parallax Serial Terminal"

PUB main
  term.start(115200)
  repeat
    term.Str(String(term#NL))
    term.Dec(measure_raw(500))

PRI measure_raw(period) : raw_weight | timeref
  raw_weight := 0
  repeat period

    ' Reset, and wait for input to go high. This is its idle state.
    OUTA[PIN_SCALE_OUTPUT]~
    DIRA[PIN_SCALE_OUTPUT]~~
    waitpne(0, constant(|< PIN_SCALE_INPUT), INA)

    ' Turn off the 'reset' output. This starts integrating
    ' the pressure. When the analog integrator reaches a threshold,
    ' our input pin goes high. Time this.
    timeref := cnt
    OUTA[PIN_SCALE_OUTPUT]~~
    waitpeq(0, constant(|< PIN_SCALE_INPUT), INA)
    raw_weight += cnt - timeref

And that’s all it takes! I’m looking forward to trying this with a larger grid of scales. A powerful microcontroller like the Propeller should be able to simultaneously sample and filter measurements from several scales. This proof-of-concept looks pretty promising for the kegerator project, too. With an integration time of a second or so, it can easily measure weight accurately enough to count glasses of beer

P.S.  I’m pretty sure I just spent more time writing this blog entry than I spent on the hack itself. How silly is that?

Back Story

This all started when I bought a sewing machine for making fabric RFID tags a little over a year ago, and started using it to make cute plushy objects. Well, as much as I like making plushy objects, I haven’t actually made very many of them since buying the machine. So, my boyfriend has been guilting me into making him a few as gifts for Christmas, birthday, valentine’s day. Naturally, being the great partner I am, this gets me thinking about ways to soup up my sewing machine first

The original machine did bug me in many ways when working on fine detail work. I’m lazy and uncoordinated with a needle, so I tend to sew almost everything by machine, even when the individual stitches all have to be lined up just right. In fact, when sewing the face parts on my meat and crab plushies, I found myself sewing individual stitches by turning the flywheel by hand.

I don’t know whether more expensive sewing machines are any better, but on my cheap Singer Inspiration 4210 the stock motor is nearly unusable at slow speeds. It stalls easily, makes an awful buzzing noise, maintains an uneven speed, and delivers very little torque.

Sensors

My first experiments were to instrument the sewing machine with sensors that I could use to estimate the speed and angle of the main shaft.  I needed some kind of absolute angle reference, plus some way of counting how far the shaft has traveled. For the angle reference, I found a really handy place to mount a photo-interrupter sensor. This cam is part of the mechanism that advances the machine’s feed dogs. It conveniently moves this metal bar back and forth once per revolution of the shaft.

For sensing the shaft speed accurately, my preferred solution would have been a high-resolution encoder wheel attached to the motor or the main shaft. But that would, at the very least, involve making a rotary encoder disc and attaching it somehow to one of the sewing machine’s moving parts. I wanted to avoid messing with the machine’s moving parts as much as possible, so I looked for non-contact solutions. I noticed that, with a little signal conditioning, an IR reflection sensor works pretty well for counting teeth on the machine’s drive belt. After switching motors, I modified this to sense teeth on the motor’s sprocket instead, but the same signal conditioning circuit works in either case. The signal conditioner is an dual op-amp configured as an amplifier, bandpass filter, and comparator with hysteresis.

Lastly, there’s the most important sensor: the foot pedal! I wanted to keep the original foot pedal feel, but use it as a generic input device for the microcontroller. So, I removed all electronic parts other than the variable resistor itself, and connected that to a 1/8″ jack. With a little modification, the jack fit into the same hole that was originally used for the mains cord.

Induction Motors Suck

This is where the project got a bit out of hand and I started making wrong turns. At first, I was hoping it would be possible to implement smooth closed-loop control by using the original motor and a simple triac-based speed controller for the motor. This seemed straightforward enough. But I didn’t have all of the parts on hand to do a normal optotriac + triac based driver circuit. So I went shopping at HSC. No optotriac, but there were some solid state relays. Alas, after I got them home and looked up the data sheets, it turns out they are the zero-crossing switching variety. Useless for speed control. So, back to the drawing board. No optotriacs on hand. Well, I could move the opto-isolation, putting the microcontroller on a line-powered circuit, and opto-isolating the serial port instead. But that sounded really annoying to debug safely, especially for me without an isolation transformer or variac. But that would require a low-voltage power supply on the mains  side of the optoisolator anyway, and if I had to go to that trouble I might as well just use a transistor to switch on the triac…

So I started rummaging through my junk bins again, and I found an old X10 lamp module. This must have a triac in it, I thought. It won’t have an optoisolator, since X10′s cheap circuits never bother with mains isolation. But it might have a power supply and zero-crossing circuit I could use. So I find a handy LM465 schematic online, and I start paring down the circuit into just a bare-bones triac driver, zero crossing detector, and +15V power supply. I got pretty far along on this triac-based speed controller before I switched tactics:

I was experimenting with closed-loop servo control using this triac controller, but the results were pretty uninspiring. With a triac, you can only change speeds as fast as twice your AC power frequency. And a 120 Hz control loop just isn’t tight enough to keep the sewing machine operating smoothly at low speeds. The motor’s lousy torque at these speeds certainly doesn’t help.

I also had lots of trouble with EMI in this design. With all the parts strewn about my desk and electrically isolated but not RF shielded, my microcontroller would randomly reset after the motor ran for a few seconds or so. I first saw this with my trusty Propeller. I tried switching to an AVR Butterfly, half to try and avoid the EMI, half to have its LCD and joystick as a user interface. But, no luck.

I was curious how they solve this problem in industry. Servo motors are pretty common in industrial automation, and surely you must need a fancier way to control the speed of a large motor in order to build a heavy-duty servo. Well, it seems that there are two solutions:

• Just use a DC motor instead of AC. This is more expensive, but it’s simple and until recently it was the only option.
• Variable-frequency drive. You still use an AC motor, but now you use an AC-to-DC power supply plus a DC-to-AC inverter to control the frequency of the motor’s power supply. With an induction motor, this controls the speed.

VFD seems quite cool, and I was really close to attempting to build a simple VFD controller using parts from a dead UPS. But then my better senses caught up with me…

So, I was about to settle for this mediocrity and finish off my triac-based controller with some buttons and mounting hardware from HSC, when I randomly happened upon the perfect DC motor. I didn’t know it was perfect at the time, but I had a hunch. As soon as I got it home and sat it next to the original motor, I knew.

I was pretty lucky. The speed range was good, the sprocket had the same pitch, and it had plenty of torque at low speeds. The only problem: It’s just barely too large to fit inside the sewing machine cabinet. So, I had to improvise the mounting a bit. I ended up slicing off the bottom panel of the sewing machine, bolting its frame to some scrap pressboard, and mounting the motor using a hacky arrangement of pressboard scraps, screws, and zip ties.

I started out building a simple MOSFET speed controller for the motor, since I’d never used a MOSFET to control an inductive load before. But after spending an hour or two trying to squash transients and convince my FETs to switch at a high enough frequency, I figured I’d had enough pain for one week. I had a spare LMD18200 chip with this project’s name on it.

The LMD18200 is an amazingly versatile and robust little chip. I used it for my laser projector project a while back. It was really overkill for that, but it’s about right for this sewing machine’s beefy new motor. I needed a pretty heavy duty motor drive capacitor too, so I ended up mounting the LMD18200, capacitor, and DC-DC converter in a small metal box for safety reasons. If the capacitor fails, I’d prefer not to have burning hot electrolyte and shrapnel all over my face.

Future work?

Enough rambling for now. And I guess I should stop hacking my sewing machine, and start sewing cute things

I did leave plenty of room in this build for later expansion. I’d like to add some kind of user interface for switching sewing modes. Right now I’m using the USB port for that, but a little LCD with a rotary encoder knob would be just swell. I’ve also thought of other ways to automate the sewing machine to make common tasks easier. For example, it would be useful to have a mode that automatically lifts the presser foot between stitches in single-stitch mode. I already found a good place to mount an RC servo motor for that.

And then there’s the idea of building a CNC embroidery machine around this, using Lego Mindstorms to make the cartesian robot…

Links

• More pictures
• Ugly hand-drawn schematics: main board, wiring harness, power box
• Source code for the Parallax Propeller firmware