Incremental Backup

• So far, I've lost about 55 lbs. That's 4 or 5 pant sizes, I think, plus now my winter coat doesn't fit anymore. Naturally my workplace has NOW decided to have a Biggest Loser contest. I could have won one of these fabulous prizes! I'm almost tempted to regain it all so I can lose it for the free iPhone. (Actual prize may vary.)


• The PVC piston idea doesn't work. Or rather, it works really well, but not for high temperatures. Maybe a water pumping thing might work, but otherwise it just gets gummed up with melty yuck. Also using insulation for the displacer is contraindicated as a fire hazard. /turns off smoke alarm. Needless to say, the engine was unsalvageable.


• Because of the above, I'm starting a new engine. For various reasons, probably all stupid, I'm thinking of going rhombic. I sat down the other day to quickly figure out the stroke length given stuff like the gear diameter. Just an easy little geometry problem until my face imploded. Also, finding cots (commercial/off-the-shelf) hardware that can be used for a medium-sized Stirling is non-trivial.


• This cool thing is in free beta. I hope that doesn't mean they are going to charge for it later, because then we won't have future classics like Two Regular Guys.


• I got a Moleskine "square" (i.e. graph) paper notebook for Christmas. Coupled with my mechanical drawing pencils, it is really awesome. I should post some pics of what I've been doing with it.


• Read Clock of the Long Now. It was very interesting and enlightening and life-changing and so forth, but they left out sufficient detail for my geekiness: Details on the mechanism. It's a single-function, mechanical, binary computer. Like the Difference Engine only in binary. Should be a snap to implement in Lego. I even started designing it but I just don't have enough time to do more than that.

Stirling Walking Beam

I made a Stirling engine before, but it wasn't "real" in the sense of "having traditional engine parts, like a flywheel and crankshaft". Also, it would be pretty difficult to scale that one up or extract power from it as is. So this is my first regular ENGINE engine. (This is called a "walking beam" engine--many other configurations are possible.)

One reason I built this one was to prove to myself that I really understood how they worked. For that reason, I designed this all myself. Not that there's SO MUCH there. Also, there are tons of videos on YouTube that are identical to mine.

It's be really awesome to scale this up. Like with an oil drum for the displacer cylinder. I'd start that right away, except not only do I not have an oil drum, I'd need access to machine tools to make the power cylinder.

Tips

• With the power piston shaft and displacer piston shaft mounted on the same point, getting distances right is a little tricky. It's a big parallelogram this way. Make them separate next time. Maybe even on a rotating collar so the phase angle between can be modified.
• If the shaft tiepoints have a lot of play in them, the engine works jerkily if at all (because all the motion is taken up in using the play).
• I think I overdid it on the height and underdid it on the width. Could have used a little angle-reducing distance on the piston shaft. Alternatively, shorten the stroke.
• The flywheel is a little heavy. The momentum should carry it through the compression stroke, it shouldn't have to be barely sucked in.

Syringe Stirling

I just realized I've never done a post on Stirling engines. How can that be?? Stirling engines are so, so awesome.

Stirlings are a member of the class called "hot air engines". As a group, hot air engines work by exploiting the expansion and compression of a gas when it is alternately heated and cooled. There's a good explanation/animation here.

(That particular engine is a "true" Stirling because of those green cross-hatches. That's a "regenerator" that vastly improves efficiency. However, most people call all generic hot air engines, regenerator or not, "Stirlings".)

Stirling engines are awesome for a lot of reasons, but one of the best reasons is that you can use any source of heat. This isn't an internal combustion engine that can use only one type of fuel that's later impossible to wean away from. This is an external combustion engine. You could use natural gas or wood or ethanol or solar energy or geothermal energy. In fact, some satellites/probes use Stirlings to convert nuclear energy to electricity. That's right, Stirling engines in spaaaaace.

Anyway, back to Earth and me. Because Stirlings are so simple and efficient, you can make even a really crappy one run fairly well. They are very common first projects in machine tool classes, for instance, whereas building an IC engine from scratch would be...challenging for a beginner. However, I'm not even at the level of machine tool student, so even that option isn't open to me.

Fortunately, lots of people have been coming up with plans for engines that don't require machining. A few years ago, I tried one that used water-based pistons but I couldn't get it to run. I really have no idea what the problem was, probably multiple things. More recently, I found some "plans" for a test tube Stirling. It took me a while to actually get it going, because it turns out that glass syringes are incredibly finely made and also very rare nowadays. I actually had to buy one on ebay as an antique!

I think the functioning is clear enough to explain itself. (Note: This is technically not a Stirling since I have no regenerator, although I could stuff a bit of steel wool in there to fix that.)

After viewing the video again, actually that might not be so clear. Here's what is happening:

1. Candle heats air inside left end of test tube.
2. Air expands, pushing "piston" up.
3. Marbles roll to the left, displacing the air to the right.
4. Air cools down, contracting.
5. Pulling piston down and causing marbles to roll right.
6. Air displaces leftward.
7. GOTO 1

The Etching Calculator [EDIT]

A lot of things, many of them new to me, went into this project. We have "regular" programming, "device" programming, a communication protocol, stepper motor control, motor mounting, power supply design and the mathematics of drawing an optimal line on a pixelated display. Some comments on each.

Mounting

I originally thought this was going to be the hardest part. "The rest is just sitting at my computer desk and either typing or handling tiny pieces of electronics" was my opinion. In fact, I just cut a couple spacers and then improvised mounting plates from....I don't know what that stuff is. It's like countertop covering. In any case, this part took maybe 45 minutes. It helps that one vital component of the mount is masking tape.

Connecting the steppers to the knobs went through some iterations. The motors had gears on the ends, but of course the EAS isn't geared. I tried various ways of coupling one to the other, but wasn't satisfied. (This turned out to be a power supply problem, which I talk about below, but I didn't know that at the time.) In the end I managed to remove the gears--they are just press fit, so you can knock them off with a nailset and a hammer. The shafts of both motors and the EAS were almost all the same size, which in turn was just a tiny bit bigger than the internal diameter of some plastic tubing. I just cut a short length as a sleeve and voila.

Stepper Motor Control

Physical Computing was invaluable. In fact, reading about how to control a stepper was what gave me the original idea of controlling an EAS¹. (The guts of that section are online.) I originally tried to do the entire thing with totally generic components, i.e. plain transistors, but I soon gave that up. I unbent enough to use 2 dual H-bridges. Still generic, but you can't get them at Radio Shack (but what CAN you get at Radio Shack?). This compacts the wiring and anyway the motors need more current than a regular transistor can switch.

If this were a real product, I would definitely build/buy a stepper control board. Finer control isn't an issue, but sweet mother of crap this thing is loud. I think a board can ramp the amperage up and down to give a smoother movement that won't shake the house down.

"Device" Programming

The Arduino libraries include an object-oriented Stepper control library, but it wasn't really suited to what I was doing. The most basic fact it cared about was the RPM. The most basic fact I cared about was how many steps to take. So I wrote my own SingleStepper library. That makes me sound alphanerdy, but seriously, it was just a matter of copying and tweaking the existing library.

Another reason for writing my own was that the Stepper lib left the current on even when the motor wasn't turning. That's great if you need the torque to stay on, but non-great if you have a limited budget of amperage. So my library also turns the power on only long enough to move the motor, then turns it back off.

Communication Protocol

The stock Arduino serial comm library only supports reading a byte at a time. WTF ARDUINO ? Naturally I need to send coordinates larger than 255. The solution is conceptually not too difficult: Send a two-byte int a byte at a time and reassemble on the other end. This actually took a couple days to implement, though, because Python (on the other end of the wire) isn't geared towards working with binary data and then there's the question of negative numbers, twos complement, endianness, etc.

Also, in the case where a lot of coordinates are being generated very quickly, the internal buffer can overflow and the EAS goes haywire. So each coordinate has to be ACKed by the controller before the next is sent.

Line Drawing

Here's another place where I didn't go 100% from my own bootstraps. I actually did start deriving this myself, but soon realized that there were going to be special cases and stuff and I wasn't interested in debugging those. Instead, I just adapted a classic algorithm. I didn't use any of the optimizations on that page, since they are more for a digital display than position control. I did make one optimization of my own, though, which was to not move each motor a single step at a time if I could take 5 steps with one and then 1 with the other.

Theoretically, one could turn both motors on at the same time but at different rates to draw diagonal lines. But even if I had the electric power to do that it's just too hard to attempt.

"Regular" Programming

This is so dead simple that it's really not that interesting, but just for completeness: Generate a series of coordinates (either by hand typing in your own or using some equation) and send them out the serial port.

Actually, I should explain that a bit. I chose to implement this as a display-like device. You give it a coordinate pair X,Y and it moves there. The Arduino handles everything after being handed the values. So for instance the sine wave is being calculated as a series of points in Python on my computer and then sent over to the microcontroller for plotting.

Power Supply

Of these all, the one that I figured out last was the power. The EAS isn't really made with computer control in mind. The controls are surprisingly sticky. At first I thought the coupling between motor and EAS was slipping, but I eventually eliminated that. The power supply I bought is rated up to 1.5A, but only puts out 5V, so the motors only drew about 700mA. Turns out that wasn't quite enough to consistently turn the knobs. By bypassing the power supply, I was able to feed 1A directly to each motor (one at a time) and that was enough.

It may still be a little short, though, because I still get the occasional glitch. But I don't have a wall wart that puts out more than an amp at more than 8V.

Cost

The steppers I got out of a broken inkjet printer. (I really lucked out on that, I later realized. Two other inkjets I disassembled had steppers but they were tiny.) I already had the mounting stuff and the Arduino, as well as wires, resistors, etc. I had to buy the H-bridges, the power supply, a heatsink and some power resistors. That probably adds up to $20 or $25. But I can and will reuse it all, especially the power supply, which was the most expensive single purchase.

Oh yeah, and I had to buy an EAS. But one of my design goals (as well as an instruction from my seven year old) was to not alter it beyond being used by humans afterwards. So I consider that a capital investment as well.

¹Gave me the idea, but I wasn't actually spurred to do anything until I saw the EAS clock. The auto-erase functionality of the clock would be really nice to have, but I'd like to point out that the ability to draw curves is even nicer.

Per request, here's a closeup of a diagonal line. You can't see the "pixels".

That said, you actually can see the "pixels" in some curves. I think that's because of the (mathemetical) stepping involved in going from floating math to integer.

Ambient Orb aka Rainbow Ball

For some reason this "ambient orb" Arduino project blew me away. The basic setup is very easy: red, green and blue LEDs mixed in different amounts. (Putting them inside a diffusing cover helps the mixing.) There are only two catches:

1. LEDs aren't dimmable the way incandescents are, so how do you control mix?
2. Finding LEDs of all three colors in the same output is nearly impossible.

The solution to the first catch is Pulse Width Modulation. Basically, you send tiny bursts of current so it flickers on and off faster than you can see it. The more time it spends on (the "duty cycle") the brighter it seems. Doing this from the Arduino is simply a matter of adjusting a number to say what you want the duty cycle to be in the range 0-255.

For the second catch, I pored over catalogs and websites trying to find matching LEDs. I did find them more than once, but it was always coming out too expensive. I mean, I was blown away by the idea, but not to the tune of $10! (Maybe I should have called this blog "The Cheap Bastard".)

I actually do already have all three colors, but the single blue LED I have is a trillion times brighter than any of the others. Really, it's blinding. I could have just bought a new blue to match the low-level reds and greens I have, but what power are they? Is there any way to figure that out, maybe from power consumption?

Finally I realized I could just use a bunch of reds and greens and also cut the blue's power in half (i.e. never get the PWM duty cycle above 50%) and it comes out all right. Mostly. The blue is still too powerful and swamps the blue-green transition.

Why is the green almost invisible in the video? Is the CCD in the camera less sensitive to green? Is the green really a lot less powerful and my eyes just adjust to it?