Hm.
(Click above for unsquished version. Well, unsquished graphic. The design is still too squished.)
If I don’t make a list of everything I need to get, I’ll end up waiting on a parts order before I can finish a prototype, or worse, leaving something off the design entirely.
ICs:
Other:
I’ve kind of dropped connectors for remote wired control, and wireless for a keyfob control. How much do those matter?
Our driveway is on the northwest side of our house, and the sidewalk beside it stays shaded and icy even when the front walk has melted dry.
Put a 2′ diameter mirror on the west edge of the roof to reflect sunlight down onto the sidewalk, with servos to aim. Photosensors could detect whether the sky was clear enough to be worth tracking the sun, or it could just do it anyway. Sweep back and forth along the length of the sidewalk on a one-hour period, to melt and dry the whole thing evenly.
It could use solar declination and time of day to calculate aim totally open-loop, or use photovore behavior to track the sun and then calculate the appropriate angle to aim at the sidewalk, or put sensors beside the walk to run as a remote photovore, or put a camera by the mirror and watch where the bright spot is. Or recognize that I only need it to work in the winter, assume a known solar declination, and write a fixed program for solar tracking and sidewalk sweeping.
Two addenda:
I’m talking about a flat mirror, not a solar death ray. One sunlight is enough to clear the front walk; that’s all I want to add to the driveway walk.
I’m not a mechanical engineer and I can’t quite picture it, but it seems to me that it might be possible to make one motorized photovore to track the sun, one motorized sweeper to move a pointer back and forth aimed at the sidewalk, and attach the mirror to a geared angle-splitter that bisects the angle between the two.
I have a working prototype of the tilt menu system for the LED puck, albeit square instead of round, and missing the select button.
It started a couple of weekends ago at Cort’s house, where we made some breakout boards for two Analog Devices ADXL202 MEMS accelerometers I have. Sparkfun used to have a great-looking breakout board for them, but it had the filter capacitors on board and I really wanted them off-board for easier prototyping and testing different signal bandwidths.
We did iron-on toner transfer etch resist, using Cort’s heat press. We also did toner transfer for the silkscreen-layer labels.
The boards came out very nicely, although the straightness of my hacksaw job leaves something to be desired. Besides indicating the positive directions of the X and Y axes, the silkscreen layer also had labels for the individual header pins; but they didn’t stick at all well going up and down the edges of the copper traces, so I scraped ‘em off. Ditto the pin-1 indicator for the LCC chip.
Here’s the board I’ve assembled, with header pins hand-labelled.
I used the Sparkfun SMT soldering method — slop solder on and wick off as much as you can. It leaves enough between the chip and the traces to make good contact, while eliminating solder bridges.
This was a bit interesting to position while soldering. Because it’s an accelerometer / tilt-sensing chip, I wanted its orientation as closely aligned as possible with the orientation of the carrier board. Absolute position doesn’t matter; but if it were rotated relative to the board, its readings wouldn’t align with the tilt of the project it was part of.
I knew I wanted to hold it securely in place while soldering, rather than tacking down a corner and hoping it was rotated about right while soldering the remaining pins. I thought about using a hemostat, but Cort’s was way too strong and would have crushed the chip. I ended up using a needlenose vise-grip, backing it off far enough to just barely grip the chip. I still worried about crushing it; but I was careful enough, as the accelerometer still works.
The whole idea of tilt-menu-based control comes from reader Kevin Reid‘s suggestion:
Accelerometer-based control!
1. Press single control button.
2. Tilt puck such that the LED indicating the relevant function is lit.
3. Release button.
I don’t know whether that’s the exact mechanism (press/release) I’d like to use, but I love the overall idea. To clarify one point, the top of the puck will be rounded/domed, so tilting the puck will light the LED that’s “on top,” like an air bubble floating inside a liquid-filled dome.
With the accelerometer breakout board completed, I was able to prototype the system.
The Arduino at the bottom is the brains. The accelerometer is at the left end of the breadboard with fairly large signal-filtering capacitors — I sized them for about 50 discrete readings per second, which I think should be more than enough (and is still far fewer than the device is capable of). Note that I’m using the accelerometer’s analog outputs and the Arduino’s A/D inputs; I didn’t feel like measuring pulse length from the ADXL’s digital outputs.
The LED matrix at the right end of the breadboard is kind of ugly, at least to implement on a breadboard (as well as hard to see in this picture). I intend to use an Allegro MicroSystems A6276 16-bit serial-in, parallel-out, constant-current LED driver for the real thing . . . but I can’t find where I put mine, so I just hacked together a row/column drive straight out of the Arduino.
The Arduino code is nothing special, but here it is:
It reads the analog inputs to get the X/Y tilt, translates from the scale of the A/D converters into the size of the LED matrix, and drives the row/column outputs. I added hysteresis that (although simple) does a fantastic job of keeping the LEDs from flicking back and forth when you’re on the fence between two adjacent ones. And I used tristating on the LED matrix drive because it made more sense to me to float unused lines than to flip them to the opposite value.
Here’s what it looks like sitting on a flat surface. One of the four center LEDs is lit — it turns out to be always the same one, as I haven’t calibrated the accelerometer readings for perfect level yet and it lists a bit to one corner. Note that one of the envisioned modes for the puck is a bubble level; and in that mode, I think I’d flash the four center LEDs to indicate when the puck is perfectly level.
Tilted a little bit, a different LED is “uppermost” and lights.
Tilted dramatically, the corner LED is “uppermost” and lights. Note that the amount of tilt required is set by the TILT_MIN
and TILT_MAX
values, so it’s easily adjustable for dome shape and/or user preference.
I indicated early on that I pictured LEDs around the perimeter of the puck angled slightly out for good dispersion, so the square matrix I made this weekend was just for a quick demo. I’m actually thinking of twelve LEDs around the perimeter (analog clock mode!) and four in a square surrounding the center, totalling the 16-LED capacity of the A6276 driver chip. I’m working up some very simple drawings of what it might look like, which I hope to post soon.
Maeve had several of these battery-operated, white LED accent lights, and let me borrow one until the next visit.
It was a good opportunity to test a few ideas about the LED puck. If a commercial product was already on the market, albeit for a different target audience, maybe it’d be good enough and I wouldn’t need to design my own. More likely, I could identify and clarify design differences between their product and my own ideas, which is what turned out to be the case.
First, the LEDs in the commercial puck are pretty directional. When placed on a nightstand pointing at the ceiling, it illuminates about a 2′ diameter area. I’d like the puck to be much more omnidirectional, casting light as evenly as possible throughout a hemispherical area.
Second, it’s not bright enough. Used like a flashlight and pointed directly at a book, it provides more than enough light to read; but pointed upward, the diffusely reflected light isn’t quite enough to read by. I specifically want to be able to read by the light of the puck, and I’d need several more LEDs and somewhat more power to be able to do that.
Third, it’s too bulky, specifically, too thick. I could never carry it in a pocket. I have been carrying it back and forth to work in my laptop satchel, but I realize I’d like the puck (or one version of it) to be small enough to carry with me in a pocket all the time. What’s the point of having cool toys if they’re never with you when you need them?
The light portion of the commercial puck tilts so it can be aimed, and the light portion is actually plenty small to carry around in a pocket. The whole enclosure is larger both to accommodate the tilting action, and because it houses three AAA cells.
The space needed to accommodate a power source concerns me. I’d like to find a flatpack LiPo battery, skinny like a cell phone battery; but I fear that power may be the driving constraint on overall puck size.
For anyone reading who’d like to build their own puck, or anyone amused enough by the idea to humor me, I have a homework assignment for you.
Find something round, (*) about the size that you envision the puck being, and carry it with you for a few days. Post a comment about what you used, its dimensions, where on your person you carried it, how comfortable/convenient it was, and whether you’d carry something that size with you all the time.
* (I envision the puck having a rounded profile like a drop of liquid sitting on a horizontal surface, rather than being an untrimmed cylinder. Rounding off the top would slightly improve the comfort of carrying it in a pocket, but cylinders that I’m able to find are good enough for a first test.)
I’ll start:
Maybe two puck sizes will be needed — the original puck, in the electrical tape container size, and the porta-puck, in the jar lid size.
I went to Radio Shack yesterday for some patch cords and discovered three 3′ MIDI cables for $13. Score! Bought ‘em.
At the checkout counter, they have these cute little motorized bugs for $10.
I was afraid it’d be lame; but I played with it a bit. When its feelers hit something, it backs up and turns. It sure looked like two motors were being used to control the forward / reverse-turn behavior. Turns out I’m the one who’s lame for getting fooled; but we’ll get to that.
$10 was about my threshold for a bug with two motors and two touch-sensitive antennae. It’d take some tricky rewiring or maybe making a new circuit board, but it should be possible to make the bug a lot smarter. Plus I didn’t really care about the microphone and response to loud noise, and I figured that accounted for a lot of the circuit board, which I could disable or remove.
Plus it’s really compact. The body is only an inch wide and about an inch and three-quarters long; that makes it really cute.
Bought one. Took it apart today.
The Hexbug is what I call a faux walker — it doesn’t shift its balance to place its center of mass over alternating feet, and each side’s legs only have a single degree of freedom. It’s incapable of falling over, and it could just as well have treads or wheels. It’s still cute — I’m just being clear that I have no delusions about its level of sophistication. Except how many motors it has.
Each side’s legs are powered by a single rotating shaft, shown below. The linkages in the picture above transfer that motion. The front and rear legs move in sync, and the middle leg moves in the same direction but 180° out of phase.
With the bug upside-down, you can see the rotating shaft coming out of the bug body, with an eccentric knob driving the linkages.
The outer legs’ axles are stationary, so the legs just swing back and forth. The middle leg’s axle is attached to the eccentric peg on the rotating shaft, causing the middle leg to move up and down while turning; this is how it lifts its foot to move without dragging.
Finally, before beginning disassembly, the antennae are coiled springs positioned around stiff wire, with feelers protruding at the ends. When a feeler presses against something, the coil portion of the spring contacts the wire, closing a circuit and telling the bug to reverse and turn. These are actually more nicely done than other wire feelers I’ve seen — they do a really good job of retaining their shape and position.
The orange wing is press-fitted on, although more tightly than I expected. Each of the six side flaps that bend down, plus one on the front, continues in a peg pressed into a mating hole in the body. I put a flat screwdriver between the PCB and the wing and twisted to loosen each peg, being careful not to crush anything on the PCB in the process.
There’s the brain. I haven’t traced the circuit, but I can make a few observations. The solder blobs below and to the right of the grey standoff in the middle of the board are the battery connections, the blobs at the front are obviously the antennae connections, and the blobs in the center of the lower half of the board are the motor leads. Two leads. One motor.
The top of the board looks like it’s audio processing, running from the microphone in the back toward the antennae at the front (since a loud noise and an antenna hit perform the same function) and feeding into the motor drive on the lower half of the board.
Removing the screw from the PCB and pressing in a latching tab at the back end of the bug (I did it with the batteries already removed, but this might not be necessary) allows the bug’s body to split open, revealing the motor and drivetrain. Motor. One motor.
Look. It’s one motor.
Duh.
The motor leads aren’t very long, so the upper half of the bug is tucked under the front end of the lower half of the bug in this pic.
When the motor is turning “forward” and the white gear at the top of this picture (right-side legs) is moving with its upper teeth going forward, the coil spring at the center is being turned in the direction that makes it “unwind” and expand in length. This forces the cam at the bottom of this picture (left-side legs) to turn with.
When the white gear at the top is moving with its upper teeth going backward, the coil spring is being turned in the direction that winds it tighter, making it contract. This releases pressure against the bottom cam and causes the spring to slip against it instead of forcing the cam to turn.
So now I don’t know what to do with this dumb bug.
OR
The last one is actually kind of intriguing. Right now, when it hits an obstacle, it backs up enough to do about 90° of clockwise turn, regardless of which antenna made contact. So “reprogram” (rewire) the bug to discern which antenna was hit and turn 90° CW or 270° CW accordingly. Because it rotates about its left legs rather than its center, 270° CW is not the same as 90° CCW would be, but it’s as close as we can get.
With a tiny microcontroller on board, it could get more sophisticated yet, turning at other angles, and even doing quick reverses during normal forward travel in order to move in forward curves.
Thoughts?
At the end of October, I attended a national, annual conference on computing in higher education, and they always have a huge vendor expo with lots of swag being given away. These days, my interest really boils down to free t-shirts and what I refer to as LED trinkets (anything flashy); but a couple of other things turned out to be irresistible. So I brought them home and took them apart to see what makes them go.
Orion, whoever they are and whatever they sell, snagged me as I was walking past and offered me this “demo on USB.”
I responded truthfully that I was fascinated . . . although I didn’t point out that I was fascinated merely by the idea of demo-on-USB, and really unfascinated by whoever they are and whatever they sell.
Inside, the only components are LEDs and their current-limiting resistors, a pushbutton switch, and a Cypress CY7C63803 USB peripheral controller chip. From the datasheet, this thing is an 8-bit microcontroller with integrated USB support, in-system reprogrammability, and 14 (total, configurable) I/O pins in a 16-pin SOIC package.
It’s targeted for use in mice, keyboards, gaming peripherals, barcode scanners, etc., and it strikes me as a really slick little device. It’s available at Digi-Key in single quantities for about $1.45 — seems like there may be some kind of opportunity there, if the development system isn’t prohibitively expensive.
So . . . it seemed unlikely that an 8-bit microcontroller would have an entire software demo on it, which led me to question exactly what the dongle did. I assume it was made to demo on Windows; and even if I had a Windows machine, there’s no way I’d plug this thing in and get pwned.
Instead, I did what any self-respecting geek would do and hooked it to my Linux box, with tail -f /var/log/messages
running.
Nov 4 18:17:06 dell2600 kernel: usb 4-2: new low speed USB device using uhci_hcd and address 10
Nov 4 18:17:06 dell2600 kernel: usb 4-2: configuration #1 chosen from 1 choice
Nov 4 18:17:06 dell2600 kernel: input: Cypress Semiconductor, Inc. enCoReII Keyboard RDK as /class/input/input9
Nov 4 18:17:06 dell2600 kernel: input: USB HID v1.11 Keyboard [Cypress Semiconductor, Inc. enCoReII Keyboard RDK] on usb-0000:00:1d.3-2
Nov 4 18:17:06 dell2600 kernel: input: Cypress Semiconductor, Inc. enCoReII Keyboard RDK as /class/input/input10
Nov 4 18:17:06 dell2600 kernel: input: USB HID v1.11 Device [Cypress Semiconductor, Inc. enCoReII Keyboard RDK] on usb-0000:00:1d.3-2
It was automatically detected as a keyboard-class device. Okay. And its little blue LEDs were glowing, glowing, hypnotizing me, luring me . . . press the button . . . it can’t be that bad . . . press the button . . .
rwww.orionondemand.com
Huh. Typed that right into my terminal, as if it were a keyboard.
Looks like it’s trying to go to a URL, but I don’t know what’s up with the “r” in front. I tried “keying” it into vi after hitting Ctrl-v to capture escape codes; I redirected it into od -c as well. Nothing. Just the “r.”
I have to assume on Windows, it does something else — that there’s a keycode my Linux doesn’t recognize that starts up the default browser, or that there’s additional USB functionality sending through another driver that Linux doesn’t support by default. But how it works, in general, is now easy enough to see.
I didn’t even see these at the show, but after we got back, my boss gave me his.
It’s apparently a picture holder; but in the lower right corner, there’s a little sign that flashes on and off every couple of seconds saying “Confirmed.” (I have yet to figure out what is confirmed, but maybe it’s part of the vendor’s current marketing campaign. Brilliant, that, if you can’t associate the keyword with the company without having seen their literature first.)
My first impression was that there was an EL backlight going on and off. But the glass looked like an LCD . . . and why would they put in a whole color LCD just to display a static graphic saying “Confirmed???” It turns out there’s no backlight, and the LCD is being used as a shutter to hide and reveal a paper graphic.
Here’s what it looks like after prising it out of the frame and opening the clear plastic case. The circuit board has two transistors, and the power source is a narrow strip solar cell hidden along the lower edge of the enclosure.
It occurred to me that perhaps the solar cell could be part of the timer oscillator — when light shines through the LCD, the cell builds up enough charge on a capacitor to darken the LCD, which in turn discharges the capacitor and restarting the cycle. Not so, as far as I can tell; the LCD continues flashing with the solar cell out of the case and exposed directly to continuous bright light.
Rather, I assume that the circuit is a simple two-transistor oscillator . . . and that’s about as far as I care to take my analysis. The PCB’s pretty intelligible if anyone wants to trace it out, but I already know enough to satisfy my curiosity: solar cell rather than battery, and LCD shutter rather than backlight.
An ice storm was predicted for today; and in anticipation, the university shut down. Even faculty and staff don’t go in for a full shutdown.
Temperatures must have been quite a bit higher than expected; because although there’s some ice on trees, all the freezing rain that hit the ground stayed wet and is draining away.
So here I am at home, waiting for more limbs from my neighbors’ tree to fall on my garage, and catching up on some electronics.
Cort and I went to Pittsburg this past weekend to help Maeve clean up more of Slim’s stuff. The focus this time turned out to be books, but we each plundered other areas as well.
I adore these vintage resistor storage cases. The drawers are about 1/2″ high — you don’t need much more than that to store resistors — and they’re totally dreamy. (Um, yup, I’m a geek. )
Cort and I found this on a shelf in Slim’s garage:
It’s an Engler Instrument Company hour meter model 10N, and I think it’s absolutely gorgeous.
It wants to be built into a rich walnut case for something. (I’m not an active steampunker, but I definitely admire real and faux antique gear with wood and brass and glass and gleaming chrome and flicking needles with paper scales behind them.)
Give it 110VAC and it counts hours. The case is riveted shut, so there’s no resetting it. Still, it wouldn’t be that hard to run it long enough to reset — only about 35 months. (I’m going to need a good reason to do that, though . . .)
I’m not sure which cabinet this came from, but Maeve had taken a whole drawer full of Slim’s microcomputer and microcontroller development gear out to the garage. Cort and I picked through it, boxed it all up, and brought it home.
Some of the detail that follows is as much an inventory for Cort and me so we know what we have and where it’s packed, as it is intended to be of general interest.
Lots and lots of microcontrollers and related chips: Two sticks of TL064 op-amps, three sticks of PIC16C55s, three of PIC16C56es, two of PIC16C57s and two UV EPROMable chips, two sticks of PIC16C71s, a stick of ISD 4004-16MP 16-minute audio recording chips, a stick of ADCs, a bunch of miscellaneous Mozer Digitalker chips, an XC68HC705K15, and a couple of MC68HC811E2INs.
Circuit Cellar RTC52 and RTCIO kits, unassembled. I was never a subscriber, but these appear to have been the foundation of many Circuit Cellar control and automation projects; see for example this touch-tone remote-controllable home automation system from 1991.
A PICBASIC development kit.
Various microcontroller development boards, at least two of each, and heavily biased toward Motorola.
An M68HC705KICS programming board, adorably fitted in a box with cutouts for the power leads and ribbon cable, so it never has to leave its nest.
A RAM board and two MP-09A CPU boards from a Southwest Technical Products Corporation 6800/6809 computer, circa 1978. I would really like to find a good home for these with a SWTPC collector. I think there’s a related chassis in storage as well, which I’ll dig out next time.
Couple of LCD screens in “widescreen” format.
A very funky, battery-powered speed synthesizer board. Cort said Slim picked this up somewhere (probably at the Dayton Hamvention) and the two of them (particularly Cort) poked at it for a long time figuring it out. They were able to get it to make noise, and it has both recorded phrases and a phoneme generator, but they never found any documentation about the dictionary and weren’t willing to spend the time to catalog it by trying every address. Cort also said it draws half an amp.
And a very large, datacenter-style pushbutton switch. Sweet!
Cost: Realistically, I see this thing climbing into the $15-30 range for materials. That’s more than I’d pay to buy a puck from ThinkGeek, but not more than I’d pay to construct one myself that I helped design. Anyone else?
Battery: Seems like we’d get a lot better power density (translating to smaller size and longer runtimes) if we used an RC-style LiPo battery, I’m thinking about the size of a matchbook or so. This’ll be more expensive; but I’m concerned that fitting in 2-3 AAA or AA cells will make the puck bulky that it’s not cool anymore. How do you feel about having to buy a special battery for it?
Charge circuit: I can find a charge-control chip and use the datasheet’s sample implementation as well as the next guy; but that’s really just a starting point, and I understand there are often subtleties involved in getting the best real-world performance. Does anyone have a lot of charging circuit design experience, or know someone who does, who’d be willing to design that portion and contribute it to an open-source hardware, community-developed project? We might want to look at LadyAda’s WaveBubble or the Chumby design for reference.
Voltage-boost circuit: Depending on what battery, microcontroller, and LEDs are used, we may need to boost the battery voltage. Same questions as on the charge circuit.
Surface-mount components: I don’t think there’s room to use through-hole technology. I’m envisioning at least the microcontroller, LED driver, and optional real-time clock chips being SMT. LEDs need to be through-hole, in my opinion, both for rated brightness and so they can be aimed slightly away from the center for better light dispersion. Will a few SMT components be enough to keep anyone from building this who would otherwise be interested?
Enclosure: My first thought was pouring this thing in resin, but I’d really like to be able to take it apart and service / enhance it. I’m now leaning toward a two-piece milled enclosure (probably lexan) that would sandwich the PCB edges in rubber for shock control and hold together with recessed screws underneath. Add an appropriate O-ring and the whole thing could probably be made watertight — which in my book counts as another feature. Thoughts?