Those are just simple, band-sawn parabolic arches. The mirror is attached with velcro. Works awesome. Ly.
I suspended the mirror from the pipe thinking that would keep the focal length constant while allowing simples changes of elevation. Why do I always go straight for the complicatedest solution in the universe?
And data from same:
The highest temp on there is almost 140°C. That's over 280°F. According to my rough calculations, the four steepest upward slopes indicate powers in the range of 20-25 watts. (Some of those dropouts are me messing around with the setup, some are cloud cover. Also, I later discovered that true solar south is like 15 or 20° east of where I've been pointing.)
Two big changes from the last run, other than the already-mentioned one of shortening the excess pipe.
Painted the pipe flat black.
Used a laser pointer to adjust the focus. I mounted a frosted glass square (I happen to have a bunch I bought for just such a use as this) at what I thought would be the focal length. Then I stood back and aimed the laser pointer in a roughly perpendicular way and looked where the point fell. This really needs a System to keep it perpendicular, but anyway I was able to determine that my focus was off by over an inch.
I'm thinking the Mark III will be the last iteration. Pointing in the right direction, and simplifying the pointing a little, may let me add another 10-20 degrees to the peak but that will be about as far as I can go with these simple materials and using an open-air design.
I did one "live" run of data collection from the parabolic mirror squeezer, but after I did it I realized there was a major problem. The pipe was much longer than the mirror width, so it overhung. Too late, I realized that this meant there was unheated oil in there, making the temperature measurement invalid. And I don't even know what direction the error was worse in, since the overhang could also act as cooling fins. Anyway, here's the graph of the results:
It looks very similar to the original run in a hotbox:
One major difference: Check the x-axis. The parabola run is at least 4x steeper.
Anyway, if I get some sun this weekend I should be able to re-run with more accurate results.
I've never been completely happy with my temperature logger. It's a bit fragile in the sense that if anything at all goes wrong, and there's no way to tell that at the time, I lose the entire run. I lost a run Memorial Day weekend.
Instead of storing the measurements on the Arduino, I'd like to instantly beam them onto my computer far inside the safety of the house. That way I can track things realtime as well as be assured that I have them. Coincidentally, for my birthday, I got both another Arduino1 and Making Things Talk.
The book describes a great number of schemes to make microcontrollers talk to each other and to computers. You can use wireless networking, bluetooth, XBee, etc (I have only the vaguest notion what some of these are). Naturally the easiest protocols require the most expensive hardware. I only need one way, slow communication, so I got a simple RF module.
Claim:
It works just like a serial port! Just connect the transmitter to the TX pin and the receiver to the RX pin! It Just Works(tm)!
Reality:
No.
Perhaps my unit was faulty. I found many tutorials and guides across the internets and while results varies, I can't ever really say it worked. I did see data appear for a short time, but mainly what I saw was noise. Or nothing at all, which is even less explicable.
Last night I had a brainwave. Or brainstorm. Something happened to my brain and it resulted in an idea. Why not use a wireless laptop as the go between? The kids have these OLPC dealies. The laptop has a USB port and does WiFi. I have a WiFi router (specifically purchased, used, to work with these laptops). About 30 minutes and 10 lines of Python later, I was reading values from /dev/ttyUSB0 and sending them out over a socket to my desktop to another 15 minutes and 20 lines of Python.
The guts of the entire scheme are already there. But with so much success so fast, I'd like to add features. For instance, instant graphing of values on both ends. A protocol so that the laptop knows if there's been an error and can tell me, out in the field. When I have more than one sensor, I'll need a way to indicate which sensor had what value. It'll be like a complete Science Sensing Station!
1If you are at all interested in robots, sensors, controlling stuff with computers, electronics or just plain messing around, I highly recommend the Arduino. That SparkFun item is all you need, assuming you have a USB port (and possibly a cable). Well....you may also need some external electronics, depending on what you want to do. LEDs, resistors, motors, etc.
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 EAS1. (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.
1Gave 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.
