A new feature: “Tim Tears It Apart”!

So, as you might have guessed, I’m an electronics engineer, and I like to tear things apart – especially gadgets. I don’t usually post about it, because a) someone else has probably already posted a teardown of that gadget, and b) I’m lazy as balls.

But then I realized a good teardown is not all about the pretty pictures, but reverse-engineering the mind and intentions of the original designer. After about a deca*cough* some time in the industry, at the age where I tell kids to get off my lawn*cough* pull up their damn pants, I’m getting a pretty decent feel for not just how a gadget works, but why it works the way it does – i.e. the budgetary constraints, schedule pressures and technical constraints behind specific design decisions. So maybe it is worth posting those teardowns after all :p

I can’t guarantee it’ll be a frequent feature, but there are a few torn-apart gadgets I could throw my 2 cents in on.

Notes to myself: Test a Bluetooth Low Energy device on Raspberry Pi, the quick way

Testing if the new nRF8001-based Mosquino BLE shield I built actually works.
With the unmodified library and example code, it purports itself to the a Nordic heartrate monitor.

mq-shield-ble

Much of the below based on Michael Saunby’s blog post on checking out a TI SensorTag.

Install bluez and hcitool (plus any dependencies). As of today, current version available from a stock raspbian is 4.99-2. NOTE: “gksu synaptic” from the console to get a working graphical package manager, if you’re into that sort of thing. (“Gtk-WARNING **: cannot open display: :0” probably means you used sudo instead of gksu; bad dog.)

Then…

$ sudo hcitool hci0 up
$ sudo hcitool lescan

If all goes well, output like:

LE Scan …
DF:32:3A:73:A3:1C Nordic HRM V1.0
DF:32:3A:73:A3:1C (unknown)

If that’s your device, congratulations, it’s working!

Connecting to it…

$ gatttool -b DF:32:3A:73:A3:1C –interactive
[ ][DF:32:3A:73:A3:1C][LE]> connect
[CON][DF:32:3A:73:A3:1C][LE]> char-read-hnd 0x01
[CON][DF:32:3A:73:A3:1C][LE]>
Characteristic value/descriptor: 00 18
[CON][DF:32:3A:73:A3:1C][LE]>

Don’t ask me how to find out the handles your device supports or what the resulting data means; that’s an exploration for another day…

Bonus trick: make the computer beep everytime it gets an advertising packet:

$ sudo stdbuf -oL hcitool -i hci0 lescan | while read; do beep -l 20 -f 1000; done

Good for range testing (I have not tested it).

AllElectronics “Mystery Infrared Device” with LIRC

NOTE: This device is no longer sold; rescuing this information before it disappears from various caches.

Description of the device from AllElectronics:
Our best guess is this is an infrared receiver/ transmitter for use with televisions or other remote-controlled equipment. Made for OnCommand™, it consists of a small black box, 2″ x 1.95″ x 0.6″ with a dark-red plastic IR window on one side. Inside is a small pc board with four clear LEDs and a module that looks like an IR receiver. There is a 3.5mm phone jack and a 6′ 6-conductor phone cord with a modular phone plug.
CAT# IR-13

Various information on modification for use with a PC: (pulled from cache of AllElectronics product review page)

Reviewer: Seth Marks from CRYSTAL LAKE, IL US
This circuit can be used with one minor modification to make a serial IR receiver for use with LIRC. http://lnx.manoweb.com/lirc/?partType=section&partName=circuit Connect the following: White Wire to DCD (Pin 1), Red Wire to RTS (Pin 7), Blue Wire – GND (Pin 5) The only modification you must perform is to add a pullup resistor between the output pin on the IR transmittor (connected to the white wire) and “In” on the 78l05 (the pin on the main IC closest to the red wire). Seems to work great.

Note: I (Tim) have personally used these instructions and can confirm that they work. With the white/data wire tied to DCD as above, make sure to select “DCD Device” rather than “Rx Device” in the (Win)LIRC serial receiver settings.

Reviewer: Mike from SAN ANTONIO, TX US
Just received this module and started playing around with it. This is what i figured out for the wiring. Yellow and Blue- ground, Red and Green- positive(around 9-12VDC), White- IR out, Black- IR in, 3.5mm jack- External IR emitter If you jumper the white and black together whatever is received from the ir receiver is transmitted out the four IR emitters on the board.(IR amplifier)Or plug in an IR emitter to the jack and controll hard to reach equipment.I have thought up many ways of using these modules.

Refraction Fail

Poor promotional poster placement

Poor promotional poster placement

Fun expression of the day: “flip a coil”

There is supposedly an Afrikaans expression that translates as “flipping a coil” or “flipping the cone”, etc. Kind of a more evocative equivalent to “shitting a brick”. It refers to the act of turning one’s underwear inside-out to dump out the results of having shit one’s pants, e.g. due to extreme rage or surprise. The imagery of course is of the canonical cartoon representation of a pile of poop as a conical coil, bearing an uncanny resemblance to the top of a soft-serve ice cream.

“Johnson is totally gonna flip a cone when the paternity test results come back.”

I wonder if this is somehow the origin of similar English expressions such as “flip out” or “flip your shit”.

Rez Trance Vibrator mystery LEDs, and how to control them

ASCII Trance Vibrator with the LEDs populated

ASCII Trance Vibrator with the LEDs populated

So, a friend of a friend recently managed to buy the original Rez, complete with new-in-box Trance Vibrator. But the peripheral didn’t work – it would be detected, but otherwise not do anything. Knowing I had produced a compatible open source version of this hardware, she brought it over for a look. The motor was seized up, probably due to not having spun in over a decade, and easily fixed with a drop of sewing machine oil. But while I had it open, I decided to resolve a longstanding mystery about the device. You know I’m a sucker for LEDs.

Mystery LEDs

Looking at the PCB reveals footprints for 3 non-placed LEDs and associated current limiting resistors. Facing them on the front side of the case are 3 rectangular pockets of an appropriate size to receive such LEDs, but no openings exposing them to the outside world. (Similar walled structures are used around LEDs in close proximity in other gadgets to block light from the neighboring LEDs.) It’s possible such openings were originally intended to be drilled later… or the mold design was hurriedly changed to remove them, but the pockets themselves remained.

So I stuck some 3mm LEDs there to see what would happen. I assume they were probably meant to be Red/Green/Blue, but I just used the colors I had on hand, along with a trio of 1k 0805 surface-mount resistors.

I don’t have Rez or a PS2, so I fired it up with the test utility I wrote for the Drmn’ Trance Vibrator project. The LEDs light in a changing pattern in response to changes in motor drive level. I wasn’t sure if it was intrinsically tied to motor intensity or some other data, so a quick test was in order. A faithful implementation of the ASCII vibrator’s USB protocol includes some redundant data, which could be omitted without affecting device operation, so I suspected the smoking gun would lie in these extra bytes.

Sure enough, the LEDs can be set arbitrarily via a byte in the USB packet, independently of motor control. The low byte of wIndex, specifically the 3 LSBs, directly set the LED states. The LSB controls “A1” and the next two control “A2” and “A3”, respectively. Although the LEDs can be controlled independently of the motor, the official Rez game always sets the low byte of wIndex equal to the low nibble of the motor power level it is commanding. Observing a USB packet dump of a level playthrough reveals no attempt to drive the LEDs independently. (Since that feature never made it into the released Trance Vibrator itself, it’s not surprising that the game’s developers didn’t agonize over what they could do with it. I’m a little surprised the game passes any data for that byte at all.)

LED control is all-or-nothing. At this point I suspected the high byte of wIndex (always sent as 0x03) might control intensity, but fuzzing around with this value or the others (e.g. the bRequest of 0x00) has no effect.

Here is a quick Python script demonstrating blinking the trance vibe LEDs.

And a video of them in action:

But why were the LEDs removed?
The first answer that may spring to mind is cost cutting… but it doesn’t make too much sense at first, because LEDs are pretty cheap. Or are they? Simply poking them out of holes the front of the enclosure would wreck the watertightness of the enclosure without some kind of gaskets, sealants, or clear windows to cover the openings. Even though the game’s creator says the device was not intended to be sexual, if you put humans near something that vibrates, the first thing they will do is stick it on their fun bits. No. Exceptions. Having openings in an ultimately line-powered device meant to be used that close to the body might have opened them up to regulatory headaches, e.g. medical-grade power supply isolation, and might just not have been a good idea overall.

Tickle_me_elmo

Oh boy… that tickles!

The most logical reason for the removal of the LEDs, though, is that they just wouldn’t really work. Unless you are a contortionist, there are very few ways one could use this device as intended and still have them in your line of sight. I suppose it’s possible they were meant to work as a very early Ambilight-type system if played in a darkened room, but you’d still need some pretty bright LEDs and a pretty small room. It also wouldn’t work from a shirt or pants pocket, or with the protective cover on.

The rest of the circuit

Operationally, the circuit inside is actually pretty close to Drmn’ Trance Vibe, although approached in a very circuitous way. Both generate a PWM signal that controls a transistor to modulate the motor speed. In the ASCII vibrator though, rather than directly generate the PWM signal from the microcontroller, it instead outputs an 8-bit value via I/O pins to a crude DAC (R-2R ladder), which feeds into an opamp (buffer?) and eventually a TL5001 discrete PWM generator. This drives a transistor, which may in turn drive another identical transistor to drive the motor. I have no idea what the 3rd large transistor, next to the PWM generator, is for – I didn’t feel like digging to that level of detail on borrowed hardware that I had to return in working condition :-)

There is a non-stuffed mystery jumper near the large inductor at center, which receives (or would) its output from a similarly non-stuffed diode, and leads to an I/O pin on the microcontroller. In my quick testing, this appeared to be an analog signal which remained at or near ground through all normal operation. I suspect it connects to the overcurrent signal on the PWM generator, and would cause the CPU to halt the motor if tripped, but don’t bet the farm on this. It doesn’t appear to invoke a bootloader, diagnostic mode or anything similarly interesting.

Here are hi-res pics of the PCB, if anyone is interested:

Top of ASCII Trance Vibrator PCB

Top of ASCII Trance Vibrator PCB

Bottom of ASCII Trance Vibrator PCB

Bottom of ASCII Trance Vibrator PCB

Solar seed warmer to get a jump on spring

Spring is coming… here is a tiny little hacklet from the bench of Tim.

I live in New England. I don’t mind it here, but the growing season is a bit short. So here is a scheme to give outdoor direct-seeding a little head start.

Seeds for many food plants, such as melons and peppers, will not germinate until temperatures rise above a certain point consistently. They could in theory be started indoors, but I’ve never had good luck with this in a prison-windowed New England house: even if I remember to water the seedlings consistently (hint: I don’t), regardless of how well I position them in my best south-facing window, they still end up weak and spindly for lack of sunlight. If they don’t outright die when hardened off and transplanted, they seem to go into some kind of shock and stop growing for several critical weeks. I’ve found direct-seeding outdoors is a lot more reliable overall. The tradeoff is that by the time it gets warm enough long enough to trigger germination, they will not set fruit until the tail end of the growing season. What a pain!

The previous homeowner was nice enough to leave behind some things, including some solar garden lights. A quick tweak to them makes them into seed warmers.

Solar garden light converted into a nighttime seed warmer

Solar garden light converted into a nighttime seed warmer

String of low-valued resistors insulated with black heatshrink

String of low-valued resistors insulated with black heatshrink

Assembled view of the seed warmer element

Assembled view of the seed warmer element

Ingredients:
1 old solar garden light
Heat shrink tubing
A few low-value resistors (5-10 ohms)
Small bit of copper tubing

Process:
Sould be pretty self-explanatory from the pictures.
solder one to a few of the resistors in series to achieve the desired length. Connect to each end of the resistor string with some thin insulated wire. Heat shrink this assembly so that the wires exit on the same side (the heat shrink will prevent the bodies of the resistors from wearing through against the tubing and shorting out). Cut a piece of copper tubing to a sufficient length that this can be stuffed inside. For best results, the assembly should be a snug fit inside the tubing to ensure good thermal contact. Finally, seal the ends of the tubing with RTv or similar watertight material, and optionally coat the copper with something to prevent corrosion.

Remove the LED from the solar light, and wire the heating tube in its place. DONE!

Now, when you plant a hill of outdoor seeds, drive the heating tube into the center of the hill, and place the solar light off to the side a bit (so it is not shading the hill). The sun will help keep them warm during the day, and the heater will take over during the cold nights.

Notes:
How much heating will you get? Short answer is “it depends”. In theory, you can measure the voltage output by the light unit and use Ohm’s Law to calculate the power dissipated over your chosen resistors (power in Watts = I*V = V^2 / R). Depending on the design of your solar lights, the output voltage may not be remotely constant or easily characterized, and the circuit inside may have its own current-sourcing limit, reducing your total output. The actual amount of heating you get may be pretty modest. You will not (and should not) find the tube uncomfortably warm to the touch during operation. Fortunately, dirt is a pretty good insulator.

Some plants just plain don’t like to grow in the cold, even if you can trick them into germinating early. For better results, combine with a coldframe to keep the aboveground bit a little warmer too.

So, it appears MakerBot have gone full evil now…

We shuddered when it was announced that MakerBot were taking the next version of their RepRap-based printer design closed-source. We crossed our fingers when the CEO responded to the flap saying they’d be “as open as possible“. We watched with popcorn the various flaps about Thingiverse, legal mumbojumbo, attribution and moral rights.

But now this. MakerBot has been awarded a patent on the conveyor belt. (Specifically, use of a conveyor belt “with a 3D printer”.)

I don’t know about you, but I can’t possibly think of any device for converting a computer file to a tangible work product that uses rollers to clear its work product from the work area to make room for subsequent work product. Certainly no such analogous device exists, or else 3D printers wouldn’t have such a clever and unique name.

While I am here, to forestall successful patent attempts on other obvious means of clearing work product from a work area, I hereby disclose the following novel invention:

1) A work producing system and method comprising a work producing machine, a means of executing stored instructions (sometimes called a “computer”), a set of instructions (sometimes called a “program”, or “software”) that instructs the work producing machine to produce a work product responsive to a description (sometimes called a “file”) describing the work product, a means of conveying said description to said system, and a means of conveying said instructions to said machine. (The system description may optionally include such novel and non-obvious components as RAM, a CPU, wires, wifi, power from the power company, etc.)

2) The claims in Claim 1 where the work-producing machine further includes a method of clearing prior work products from its work area.

3) The claims in Claim 2 where the work-clearing means includes a pushing means to push the old work products from the work area.

4) The claims in Claim 2 where the work-clearing means includes a pulling means to pull the old work products from the work area.

5) The claims in Claim 2 where the work-clearing means includes a scraping means to scrape the old work products from the work area.

6) The claims in Claim 2 where the work-clearing means includes a gravitational means to remove the old work products from the work area. An example of such a means is a tilting means which tilts the work surface, a rotational means which rotates the work surface to a nonhorizontal position, or an antigravity device which causes a local gravity inversion in the vicinity of the work surface.

7) The claims in Claim 2 where the work-clearing means includes a vibrational means to shake loose the old work products.

8) The claims in Claim 2 where the work-clearing means includes additional work surfaces which can be exchanged with the work surface on which work products have previously been produced, and a means of exchanging said work surfaces. (The unused work surface may, for example, be physically exchanged with the used work surface of the same machine, or exist in a second work-producing machine which takes over work production jobs while the first work surface is full.)

9) The claims in Claims 3-7 inclusive, where zero or more said means are combined in such a way as to improve the reliability of clearing work products from the work area.

10) The claims in Claim 9 where the pushing means further comprises a solid object configured to move across the work area, thereby pushing work product out of the work area. Compare “broom”, “push bar”, “squeegee”, “bulldozer”. Since patent examiners have the imagination of a goldfish, I should point out at this time that moving the work surface with respect to the pushing device is the same as moving the pushing device with respect to the work surface.

11) The claims in Claim 9 where the pulling means further includes a magnet. Magnets are magical. (Computer-controlled electromagnets are even more magical because computers are magical and electricity is magical.)

12) The claims in Claim 9 where the pulling means further comprises a suction mechanism and a means of moving said mechanism into contact with the work product and to a location outside the work area. (Compare: “vacuum pick and place”)

13) The claims in Claim 9 where the combined pushing and pulling means further comprises a robot arm and a means of moving said mechanism into contact with the work product and to a location outside the work area. (Compare: Industrial pastry sorting robots). Since I may have been unfair toward goldfish in Claim 10, I should point out that the non-difference between moving the work surface vs. the pushing device also exists for a *pulling* device. Or basically any other device or combination of such devices.

14) “Pushing”, “bumping”, “kicking”, “nudging”, etc. are the same thing. Just throwing it out there.

15) The claims in Claim 2 where the work-producing machine is configured to produce works which are of a 3-dimensional nature.

16) The claims in Claim 15 where Claims 3-14 are restated here by reference.

17) The claims in Claim 16 where the system further includes a means of collecting the removed work products (sometimes called a “bin” or “bucket”).

CNC milling custom 40DP timing belt “gears”/pulleys

Woo, it’s been a long time since I messed with pick & place stuff. Bad Tim.

An irritation I have been having is making everything work using reliably sourceable, off-the-shelf parts (not lucky eBay/surplus finds). In particular I’ve found small “tin can” stepper motors are hard to source in small quantities repeatably, and once you do, finding timing belt pulleys to fit the shaft of the motor you’ve just scored is a fresh new challenge. In a previous iteration, I use some steel tubing and superglue to shim a motor shaft up to size(ish), but here is an alternate approach: my “pick & place” machine is just my CNC machine with a vacuum head bolted on, so why not just cut some pulleys on a CNC machine?

14-Tooth 40DP Pulley

14-Tooth 40DP Pulley, carve on a CNC mill using a 1/32″ bit

For reference, here is the existing head in action.

This last attempt used the “40DP” type small timing belts/pulleys* since they seemed to be readily available here. Despite the massive main pulley and tiny one on the motor, the gear ratio works out to only about 5.2:1. This is adequate for a typical 1.8deg/step stepper (~0.35 degrees/step final head resolution), but pretty coarse for a 7.5deg/step tin-can motor. This is the smallest ‘proper’ stepper I can find in hobbyist quantity and pricing, and it seems to work well. The shaft diameter is 4mm. (Sidenote: A note on the product’s page indicates it now comes with a flatted shaft. You may wish to augment the below to take advantage of this.)

Here is what I did to make a 40DP pulley to work with the new motor. Similar process ought to work for other pulley profiles and sizes.

Thingiverse user drofarts has put together a set of parametric pulley design files in OpenSCAD format. These are CAD files, but more like a text scripting language than a traditional CAD package. You need to install OpenSCAD to use these files if you don’t have it already. Open the desired file and tweak parameters as needed, such as the desired profile, number of teeth, shaft diameter, etc. Use Design -> Compile and Render to see what you’re going to get. For best results in the next step, set the ‘no_of_nuts’ parameter to zero to simplify the output. When satisfied, use Design -> Export as STL… to save the file.

OpenSCAD pulley output

If you were planning to make it on a 3D printer, you’re pretty much done! You can output .stl directly. I don’t have one and will be carving it on a CNC mill, so an extra step is necessary. Basically, you’re going to want to carve the 3D model down to a simplified, 2D representation of just the pulley profile, and do any CNC/toolpath-specific monkeying in your favorite CNC software. For this, OpenSCAD’s ‘projection’ feature can be used. I created a separate scad file that simply imports the .stl from the first step and presents a 2D projection of the pulley profile only.


projection(cut=true) translate([0,0,-8.5]) import("C:/data/projects/pickplace/head/pulleys/Pulley_T-MXL-XL-HTD-GT2_N-tooth.stl");

Change the path and filename to the file you generated, of course. The negative Z ‘translate’ parameter lowers the part partially below the ‘floor’ (zero), which, combined with the ‘cut=true’ projection parameter, causes the bottom part of the pulley (large flanged base with setscrew holes we can’t cut on the CNC) to be excluded from the projection. You may need to modify this parameter depending on the height of the pulley you generated.

OpenSCAD pulley output (sliced)

Then save this using Design -> Export as DXF.

I cut this pulley from a piece of flat Delrin stock using a 1/32″ (0.03125 inch / 0.79375mm) router bit. A larger bit may not be able to get in between the teeth for 40DP profile. In my CNC software (CamBam) I added a bottom shoulder by outside pocketing the pulley profile to 1/4″ depth, then carving the rest of the way through the stock at a slightly larger diameter. If needed, a top shoulder can be added by gluing a washer to the top of the newly created pulley.

But does it work?

Yes :-) Below are some comparison images of the homemade pulley vs. a commercially available one. The latter is fine except that it doesn’t come in the shaft diameter I need.

Homemade pulley (right) and commercially available pulley (left)

The quality of the pulley-belt meshing between the two is comparable. The tooth depth on the homemade one could stand to be a bit deeper, but I haven’t noticed a difference in performance so far.

New pulley on motor

New pulley mounted on the new 4mm motor’s shaft. Perfect fit!

* I can’t seem to find any source/documentation on what the various timing belt “standards” are, or what makes one different/better than another. Also, that source seems to have gone out of business. Suggestions for either of these resources welcome.

Fun with cheap TV-tuner dongles and Software Defined Radio (SDR)

So, last week I joined the bandwagon of exploring software-defined radio (SDR) via one of those super-cheap Chinese TV tuner USB sticks. In a nutshell, the idea of SDR is that, rather than the traditional approach of building dedicated radio receiver hardware for each possible RF band and modulation type (here’s your AM radio, here’s your FM radio, here’s your TV receiver…), each of which can only do one thing, we can simply make an extremely *wide* bandwidth receiver frontend that captures ALL the signals, shovel the raw waveform into a computer, and emulate all the desired radio receiver frontends and tuning in software via digital filtering. New type of radio scheme just got invented? You don’t have to buy/build a new radio receiver, just download this update! Historically, this ‘universal receiver’ has been somewhat hairy and expensive to build. The most well-known (and open-source!) is probably the Universal Software Radio Peripheral, most commonly associated with the gnuradio project. Recently though, Antti Palosaari and other clever folks discovered that a $20 USB TV tuner can be pressed into service as a ‘universal enough’ receiver for many purposes.

There are many ‘flavors’ of the sticks that work for this. These sticks consist of two parts (as far as you’re concerned): a frontend tuner chip, and the Realtek RTL2832U demodulator chip. The latter also includes the USB interface. RTL2832U-based sticks are popular because, while it is officially intended to output TV/FM signal data, it is easy to put this IC into a mode where it dumps the raw tuner output directly to the USB port at high speed. This allows user software to bend, fold, mutilate and decode arbitrary radio signals as it sees fit.

The ‘tuner’ part of this stick is somewhat interchangeable; they all do pretty much the same thing (although some are better or worse at the job for our purposes). A large list of tuners, and the products they appear in, is being maintained here. The Elonics E4000 tuner is regarded as the ‘best’ as it can tune over a wider range (64-1700MHz, with a small coverage gap in the middle) compared to the others. Note however, because of the ‘interchangeable’ nature of the tuners, the stick you receive is not at all guaranteed to contain the tuner you wanted – it will most likely contain whichever flavor was cheapest in China at the time this batch was manufactured. The Realtek IC is much less likely to be substituted with another part since all the USB drivers (or at least USB VID/PID codes) would have to be rewritten.

Case in point; the one I bought was the ezcap DVB-T/DAB/FM stick; upon cracking it open I found an FC0013 tuner rather than the E4000 others have reported.

Some Software

Several SDR software packages (other than, of course, gnuradio) have now been written or updated to accept data from the RTL2832U, and present it in a user-friendly manner. These consist generally of a frequency/tuning setting, spectral plot, waterfall plot (sort of a stripchart of the time-varying spectrum over the last 30 seconds or so), and various options for demodulating a user-specified portion of the spectrum (usually to the form of audio played back on the speakers).
Some that I have tested so far are:

Gqrx SDR receiver – For Linux; supports several common modulations including AM, FM (wide/narrow), and SSB. At the time of this writing, you have to pull an experimental source tree and compile it yourself to get the (very recently added) support for RTL dongles. Luckily, this (for me at least) went painlessly following this tutorial (Gqrx portion begins on page 2; warning: annoying float-over ads); it just takes a while.

HDSDR – For Windows; supports even more modulations (AM, FM, ECSS, single sideband (lower, upper), CW, DRM) and allows the filter bandwidth to be adjusted in most cases. This program is freeware, but not open-source.

SDR# (SDR-Sharp) – For Windows; supported modulations include AM, FM (narrow/wide), single (lower/upper) and dual sideband, CW (lower, upper). This is my personal favorite so far, as the filter bandwidth can be arbitrarily set and easily fine-tuned by simply clicking and dragging the filter envelope shown on the waterfall plot. Tuning can also be accomplished by dragging the spectrum plot as a ‘radio dial’ besides the usual typing/mousewheeling in the Frequency field.

Note that the RTL support in these programs (and in some cases the programs themselves) are very new; they may be much evolved from the anecdotes above by the time you read this.

Some Oddities

Heat issues
When my shiny new tuner stick arrived I wasted no time building gqrx and firing it up. I was rather dismayed to find that the tuner frequency set in the software seemed to have absolutely no correlation to the frequency actually tuned (confirmed by finding some local FM radio stations and comparing their spoken station identifications to the frequency displayed). Same story on other software. It turns out that these chips run pretty warm, and mine arrived on about the hottest day of the year – after a few minutes of being plugged in, the stick was overheating and the tuner IC was no longer responding to commands. This has been mostly solved by removal of the stick’s plastic case and cooler overall temperatures. It seems others have seen the same problem on similar sticks; this user (original Romanian) (English translation) solved it by cutting a hole in the case and bonding a small heatsink to the IC.

Aliasing and other ghosts
With the overheating issue sorted, I confirmed some ‘known’ FM radio stations were where they belonged… but noticed strong FM stations also popping up at truly bizarre locations on the dial. It turns out these sticks are prone to showing you aliased signals and other forms of ‘ghost’ signals. Aliasing occurs when a high-frequency signal is undersampled. As I understand it, these sticks ‘demodulate’ a signal by multiplying the incoming signal with a reference frequency (the ‘local oscillator’, or LO), causing it to be frequency-shifted down to something more manageable. (In most SDR software, the ‘center frequency’ adjustment for tuning adjusts the LO.) Poor filtering of strong signals can cause accidental demodulation of those signals even at far-away local oscillator frequencies, probably most noticeable at integer multiples of the signal’s carrier. The result is that a spurious alias of that signal will show up, ‘folded over’ to an unexpected frequency.

A sure giveaway that you are looking at an alias and not the real signal is that it moves in the ‘wrong’ direction if the tuner center frequency is altered slightly. That is, while authentic signals should appear at a consistent frequency regardless of small tuning changes, an alias will appear to change frequencies as the tuner center frequency (LO) is adjusted.

I have also noticed other ‘ghost’ signals repeated at multiple frequencies, but without the giveaway folding. I don’t have an explanation for these. However, the false-frequency copies seem to vary widely in amplitude, to the extent of appearing and disappearing, as the LO is adjusted.

NOTE: Specific alias/ghost behavior may be (and probably is) tuner IC specific; your results may vary depending on the type of tuner in your particular stick.

I/Q imbalance (DC Offset)
Another issue common to these cheap TV sticks is an imbalance between the I and Q components (we’ll get to that in a minute) of the returned signal. This typically manifests as a continuous false ‘signal’ peak always at the center (LO) frequency.

Primer on some digital RF basics (e.g. what is all this ‘I/Q’ stuff?)

This paper from Agilent is a good overview of how these tuner sticks and similar digital radios are implemented under-the-hood, as well as covering many basic digital modulation schemes and how to identify them.

What’s Out There?
Oh, the fun you can have. So far I have read the entire neighborhood’s pager messages, eavesdropped on bored rent-a-cops’ walkie-talkie chatter, gotten weather reports, and found many more things I can’t even begin to identify. Here is a quick link-dump for some specific cool stuff people have managed to find, and how to do it yourself.

Read pager messages
Plot the courses of aircraft via their radio identification messages
Acquiring GPS (scroll down a bit)
Receive weather satellite images

I might try to cobble together a visual identification guide (or links to same, if this already exists) as a Part 2.

PS. Action shot of sniffing pager data out of the air in my hometown. Click for fullsize:

Screenshot of capturing pager data using the SDR-Sharp and PDW software

Screenshot of capturing pager data using the SDR-Sharp and PDW software

Notes to myself: Using EnergyMicro EFM32 with GCC open-source toolchain

The EFMs can be used with many different toolchains after installing EnergyMicro’s “Simplicity Studio” package, which includes board/chip support packages and some code examples.

EnergyMicro’s application note AN0023 has an overall good overview of setting up an Eclipse + GCC (CodeSourcery) toolchain. Nevertheless, in attempting to replicate this process on my Win7 system (work PC; not my first choice of OS) I ran into a few particular time-wasting issues. The appnote recommends to find and install specific (“old” / current at the time of writing) versions and see it work, then take the risk of updating versions – I just installed the current version of everything (including Eclipse). This might be part of my problems. Installing toolchain components to a slightly unexpected location (i.e. not on the C:\ drive, let alone “C:\progra~1”) may add a bit of uncertainty too.

Some quick notes / “problemlet” observations:
The Simplicity Studio code examples install to one of your OS/version-specific “home” folders, regardless of where you told it to install the application proper. On Win7 there are many variations of a “home” folder; they get installed to the Windows “%appdata%” path (which expands to something like C:\Users\yourname\AppData\Roaming). Assuming you’ve performed the necessary voodoo to bring back some kind of ‘Run’ dialog / command line in Win7, you should be able to type %appdata% at the prompt and thereby obtain the actual path it expands to on your flavor.

During installation of Simplicity Studio you are prompted to install the SEGGER J-Link (JTAG / debug client emulator) drivers. In my case, I was prompted to install them about 30 times (wtf?). After the first installation appeared to succeed, I canceled out of the numerous repeat prompts (holding down ESC key works well for this) without any apparent ill effects.

Otherwise, installation and setup of Simplicity, Eclipse and the various other bits went pretty smoothly, up until…

Problem #1: Broken handling of PATH in Eclipse (Juno)
Attempting to build the ‘blink’ example, eclipse barfs out the following error:
program “cs-make” not found in path
So, dig down to Windows Environment Variables, confirm the path to the build tools has been correctly added…sure enough, there it is. Open a command prompt (defaults to C:\Users\myusername) and type cs-make … Windows can find it too, apparently. Just for fun, copy the CodeSourcery build tools’ path from the system path variable to the *user* path variable, close and re-open Eclipse… same problem. Finally, digging deep in the Eclipse build setup (Project -> Settings -> C/C++ Build -> Environment and manually adding the $path$ variable to the Eclipse-specific environment variables shows that it appears to have taken the “user” environment path, and injected several Java-related paths, apparently overwriting the first several path entries (including the one for the build tools). Manually adding the OS-provided “path” variable here (it expands to a plain text string once added) and hand-adding the build tool path (in my case, “d:\CodeSourcery\Sourcery_CodeBench_Lite_for_ARM_EABI\bin”) is ugly, but it works and I don’t have a better idea.

Problem #2: Install Path Assumptions; Wide Open Spaces
As mentioned earlier, I installed Eclipse and the build tools to my dedicated non-installed-by-the-IT-department-by-default apps partition, D:\. Apparently that is a minor nono – the Makefiles in the Simplicity Studio examples have a hard-coded expectation that you installed everything in “C:\Program Files\” (or your OS-flavor equivalent). After hacking around in the blink example’s makefile a bit to remove all traces of this assumption, I ran into the 2nd problem:

cs-make: *** [build/system_efm32lg.o] Error 1

This incredibly helpful error message from cs-make means that a failure occurred in some upstream tool. Clicking on the ‘Console’ tab at the bottom of the Eclipse window discloses the actual problem:

11:37:58 **** Build of configuration Default for project blink ****
cs-make all
“Building file: ../../../../../Device/EnergyMicro/EFM32LG/Source/system_efm32lg.c”
“D:/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI /bin/arm-none-eabi-gcc”
(…etc, etc…)
The system cannot find the path specified.
cs-make: *** [build/system_efm32lg.o] Error 1

Note the two, yes two, superfluous and unwanted spaces in the middle of the GCC path string, between “Sourcery_CodeBench_Lite_for_ARM_EABI” and “/bin/arm-none-eabi-gcc”. I have absolutely no idea where those are coming from (they aren’t in any of the strings used to build this path string in the Makefile), or whether this is a specific bug of cs-make, Windows ports of make, or make in general. Lacking any kind of better idea, I “solved” this by wrapping every possible piece of data that may be used to generate a path with the makefile ‘strip’ directive (discovered via yet more googling in circles, yay), e.g. a string definition blah becomes $(strip blah), and $(QUOTE)$(TOOLDIR)/bin/arm-none-eabi-gcc$(QUOTE) becomes $(QUOTE)$(strip $(TOOLDIR))$(strip /bin/arm-none-eabi-gcc)$(QUOTE), etc. Note that it appears any piece of string variable which has already been ‘strip’ped must again be re-‘strip’ped when using it to build another string (e.g. in the above, I’ve already defined TOOLDIR = $(strip $(WINDOWSCS)) , and WINDOWSCS = $(strip D:/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI) , to no apparent effect.

Once every susceptible substring in the Makefile has been flushed out and dealt with (this may take a few builds), eclipse builds the project without failures and produces a .bin file. Whee!

Now, the next step is to actually download this fresh new executable to the target board and run it. As I understand it, this requires cooperation of several tools. GDB (GNU Debugger) is used to (besides debug) interact with the vendor-specific JTAG device and actually burn code onto a device. There is also some sort of TCP/IP loopback server (gdbproxy? J-Link apparently performs this function) in the mix somehow.

Aside: This is where everything seemed to sh*t the bed when I tried to set up a similar Eclipse+GCC toolchain for msp430 microcontrollers – building went smoothly, but the whole matryoshka of uneasy agreements between gdb, gdbproxy, and the proprietary binary-blob (.dll) JTAG tool could only be jostled into working occasionally, with a lot of gdb-related process-killing and potentially rebooting between build attempts.

Sure enough, the next problem occurs here.

‘Launching blink Default’ encountered a problem

Error creating session
Cannot run program “arm-none-eabi-gdb”: Launching failed
Cannot run program “arm-none-eabi-gdb”: Launching failed
Cannot run program “arm-none-eabi-gdb”: Launching failed

As a quick sanity-check, typing arm-none-eabi-gdb at a command prompt successfully launches GDB, so this is probably more Eclipse-specific path BS. Since I don’t have infinite time to burn on this, another hacky ‘solution’: manually ‘Browse’-ing to and thus hardcoding the path to arm-none-eabi-gdb in Eclipse’s debug configuration dialog, under (green ‘bug’ button dropdown arrow) -> Debug Configurations -> Debugger. This done, launching debug dumps a healthy amount of gibberish (raw GDB commands and responses) to the console, along with several errors/warnings from gdb and several inexplicable red lines of text (that do not, outwardly, appear to be error messages, but rather echoes of send commands), but the gdb stream seems to suggest that bytes were successfully pushed to the dev board.

Success! I think. I guess. Maybe.
Switching over to the “Segger J-Link GDB Server” program (remember, the appnote says to start this before Eclipse and leave it running) shows GDB “Connected to 127.0.0.1” along with another green mark, which it did not before. Good sign, I suppose.

…OK, maybe not. Attempting to set a breakpoint and run the application does nothing. Attempting to restart the “Debug” process from the beginning just causes Eclipse to hang. With some dicking about (close Eclipse, manually kill all *gdb processes in Windows task manager, restart) I can get as far as “Starting target CPU…” and “4 KB downloaded” appearing in J-Link, but no apparent activity on the target board. But, uploading the freshly built ‘blink.bin’ binary using the ‘energyAware Commander’ DOES work! So, at least the compiler / build environment is sane. Something is going wonky between Eclipse/J-Link/GDB/board. If “Show log window” and “Verify download” are enabled in J-Link GDB Server, download lines have “Verify failed” after them.

After a reboot and starting over with the recommended versions of Eclipse (2.7.3 / Indigo) and its plugins… it works! Then switching back to the current version… it works! It is possible the PC and/or board were just in a wonky state and fixed by a good old-fashioned powercycle. Aaaanyway, downloading code to the development board thru Eclipse seems to be OK now.

Last little niggles:

  • Upon starting a debug session, a large page shows up with the following in bright red scary text: No source available for “__cs3_interrupt_vector_em() “. This is not any kind of error message, really. It just means that the interrupt vector table(?) (which it wants to show you for some reason) has no source code available to show you. (You are instead given the option to view an assembler dump.)
  • The “EmbSys Registers” tab shown in the appnote screen shots does not appear. Solution: This tab is not enabled by default – enable it using Window->Show View->Other->Debug->EmbSys Registers
  • . Once this is done, the tab will appear with a note to set your chip. Now go into Window -> Preferences -> C/C++ -> Debug -> EmbSys Register Viewer and select the appropriate architecture/vendor/chip. For the EFM32LG-STK3600 (Leopard Gecko Starter Kit), this is ARM3, EnergyMicro, and EFM32LG990F256, respectively. Close out of there and the EmbSys tab should contain a list of viewable registers in a folder hierarchy by association (e.g. those associated with the ADC, WDT, etc.).

  • Unresolvable symbol errors: On my setup, several error messages appear under “problems” when debugging is started: “Symbol ‘cmuClock_CORE’ could not be resolved” and “Type ‘uint32_t’ could not be resolved”, for example. They don’t seem to be hurting anything (and I have not found/ looked for any fix for this), but I’d bet real money that this is a stupid paths problem again.
  • Well, Future Tim, there you have it. Working EFM32 debugging on an open-source toolchain!

The IOC, Trademark Law and You

Yes, it’s true! With the London Olympic Games and Paralympic Games Act 2006 (UK), and similar laws pushed through in other countries as a condition of hosting a certain large quadrennial event (US- Amateur Sports Act of 1978; Canada- Olympic and Paralympics Marks Act), any infringing use of IOC ‘properties’ (similar to, but stronger than, trademarks) such as combinations of the words ‘summer/games’, ‘summer/2012’, the interlocked rings, etc., are a criminal (not civil) matter.

The following Venn diagram explains in more detail.

Buying Parts

Solved: Can’t connect to high (>10) Windows COM ports / cleaning out unused COM ports

Problem: Windows, and many Windows apps that use serial (COM) ports, have various problems accessing “high” numbered COM ports. I cannot find an authoritative or quantatative definition of “high” (and it may depend on your app), but I have seen apps start failing after COM8, COM9, COM15… anything in the 20s is asking for trouble. If you are a developer and routinely plug in different “serial” devices (including USB gadgets with virtual COM support, Bluetooth dongles, Arduinos etc.) Windows will happily assign a new port number to each one until something breaks and you go hunting for this post.

Depending on the application, the “s**t-the-bed” breakover often depends on a hardcoded number (e.g. only supports up to COM8), or going to double digits, etc.

Solution1: Some apps may let you enter the COM port number in a special way (UNC path) that lets higher-number COM ports be used, e.g: \\.\COM25
(that is, precede the port name with a double backslash, dot, and then another backslash). If the app uses backslashes as an escape character, try doubling the backslashes, e.g. \\\\.\\COM37

Why this form? Why only some applications? Why does the number where this form becomes necessary differ between applications? (avrdude.exe requires it for COM10 and higher; pyserial will work without it up to at least COM15 or so, but not COM25. Of course, this all may just depend on the phase of the moon and your results may vary.) Beats the hell outta me. If anyone knows what this is all about, please post in the comments!

Solution2: Clean out those rusty, dusty old unused COM port numbers (you know, for that silly dongle you plugged in exactly once years ago and never touched again) so you can recover those “working” low COM port numbers for new devices. Trouble is Windows will not show it in Device Manager unless the device is plugged in, which is a problem if the thing got lost or broke long ago. To see the hidden allocations and remove them:

1. Open a command prompt as Administrator. (Start->Run, type cmd ). Or, right-click Start->Programs->Accessories->Command Prompt and choose “Run as administrator”

2. At the command prompt type set devmgr_show_nonpresent_devices=1

3. At the command prompt type start devmgmt.msc to start Device Manager. For this to work you MUST start it from this command prompt – don’t mouseclick your way into it or try to use an already open copy.

4. When device manager opens, select View -> Show hidden devices

Now when you expand the COM ports section, every COM port ever allocated will be shown (all the ones for nonexistent devices will be grayed out). Now you can right-click all the defunct ones and uninstall them.

NOTE: Without the magic incantations above, you will still have a View -> Show hidden devices option, but it won’t actually show the nonexistent COM port eating devices.

Solved: SL4A force close when calling recognizeSpeech

Problem: SL4A crashes upon the first call to recognizeSpeech() : com.googlecode.android_scripting stopped unexpectedly (Force Close).

The corresponding Android log via adb shell #logcat:

D/AndroidRuntime( 2785): Shutting down VM
W/dalvikvm( 2785): threadid=1: thread exiting with uncaught exception (group=0x4
0018560)
I/ActivityManager( 1429): Starting: Intent { act=android.speech.action.RECOGNIZE
_SPEECH } from pid 2785
E/AndroidRuntime( 2785): FATAL EXCEPTION: main
E/AndroidRuntime( 2785): java.lang.RuntimeException: Unable to start activity Co
mponentInfo{com.googlecode.android_scripting/com.googlecode.android_scripting.ac
tivity.FutureActivity}: android.content.ActivityNotFoundException: No Activity f
ound to handle Intent { act=android.speech.action.RECOGNIZE_SPEECH }
E/AndroidRuntime( 2785): at android.app.ActivityThread.performLaunchActiv
ity(ActivityThread.java:1768)

(etc.)

Solution: Install Google’s free Voice Search app from the app marketplace. This app provides the activity android.speech.action.RECOGNIZE_SPEECH.

Computer-controlled RGB LED Buckyball

Everyone and his brother has built LED cubes before, and while they are unmitigatedly awesome, I wanted to try something a little different. As far as I can tell, nobody has made an LED buckyball before!

Completed ball running some cheesy visualizations

And of course, the requirements for such a large, sparse shape are a little different. In a typical LED cube design, the leads of the LEDs themselves form the structural members and support base of the cube – the lead lengths more-or-less set the size and density of the cube, and since it sits on a large surface area, there’s plenty of room to bring out plenty of signals and drive them from a single many-pinned microcontroller (usually via Charlieplexing). In a large, sparse hollow sphere, the wiring for Charlieplexed LEDs would get unwieldly pretty fast. So instead, I used a bussed approach where each LED sits with its own tiny microcontroller on a serial bus, with a unique address programmed into each one. Such addressable “smart pixel” LED nodes have been around for a while and available off-the-shelf, but for various reasons (outlined below), I opted to design my own open source (GPL) version, dubbed das Blinkenlichten, and used these for the project. These nodes sit on a 3-wire (power, data, gnd) bus and speak over a self-clocking bit protocol. The ball contains 90 such nodes; one for each of the 60 junctions of the buckyball, plus 30 more in the “long” beams of the ball (more on that later too).


Sidebar: Addressable RGB LED nodes
Addressable “smart pixels” or RGB LED nodes have been around for a while; in the hobbyist community, BlinkM is probably the most well-known. However, at close to $13 a pop, a deployment of any significant number of these adds up very fast. In addition, the code was/is very much proprietary – not only closed source with dire warning against reverse-engineering, but only allowed for noncommercial applications at that. As of late 2004, there was really not much in the way of very inexpensive nodes or open-source designs to pick up and build on one’s own. Add to that patent issues surrounding many of these products (including pretty much all I2C-based designs), and the situation for open blinky hardware was bleak indeed. So I rolled my own that was dirt-cheap, minimal wire count and GPL’ed. By happy coincidence, it also avoids all the RGB LED control patents that I am aware of. Luckily, as of late 2011 there are many more inexpensive, open-source and even microcontrollerless (shift-register based) blinkies available in single or strips, so go nuts!

Buckyballs:
In real life, buckyballs are spherical molecules composed entirely of carbon. The LED ball models the most well-known of these molecules, carbon-60 (buckminsterfullerene), consisting of 60 carbon atoms. These atoms are arranged such that their bonds form 12 polygons and 20 hexagons, with one carbon atom at each vertex. The stitching, and often coloring, of soccer balls (footballs outside the US) mimics this structure.

Construction details:
I wanted the ball to consist of basically nothing but light – i.e. a bare minimum of visible wiring, electronics or any other opaque portions. Thus the light from the tiny LEDs would have to be well diffused throughout the entire structure. Playing around, I found that hot-glue sticks make almost perfect LED diffusers, and wasted no time cleaning out the local art&craft store’s supply for the ball’s structural elements. In retrospect, this was not the ideal solution: despite anything you might hear about the buckyball being a magically strong shape, it’s still not enough to hold the weight of 90 hot-glue sticks and electronics without sagging into more of a pear shape. In the end I had to add some internal “guy wires” (monofilament fishing line) to help it hold a spherical shape. As you can see, it’s still not perfect, so I’ll have some adjusting to do!

The ball consists of 12 pentagonal sections totaling 60 sticks, and 20 hexagonal sections formed by connecting 3 sticks between each neighboring trio of pentagons.

To create the physical ball, I needed some kind of scaffolding to hold the ball in shape during various stages of (in)completion, and ideally serve as a construction guide. For this, I bought a cheap inflatable soccer ball on eBay, blew it up, and assembled the ball around it in pieces. The markings on this ball (a promotional item for a foul-tasting yet inexplicitly popular domestic beer) are not 100% faithful to a real C60 molecule; the pentagonal sections are a bit small, resulting in the spokes between them (forming the hexagons) being a bit longer than the pentagon segments. I’ll just refer to these as the “long” sticks from now on.

First, I assembled all the Blinkenlichten boards with a 5mm LED. Each board is about 10mm square and can sit flush against the end of a glue stick with only the solder tabs sticking out. Each of the 60 sticks forming the pentagons are end-lit, with the LED node installed by drilling a hole in one end the diameter of the LED and shoving it in. The remaining 30 “long” sticks (to form the hexagonal sections) have a hole drilled in its middle and the LED inserted perpendicular to the stick. I’ve found that using a drill bit a tiny bit smaller than the LED itself works well: the drilling action heats up the stick enough to partially melt the inner walls of the hole; quickly shoving in the LED after this allows the walls to stretch slightly to accommodate it, then glues it tightly in place.

Template for cutting pentagon sticks to size/shape

"Long" (hexagonal) sticks with the LED perpendicular

I first built the required number of pentagonal sections, with the length of each side matching that printed on the soccer ball. To do this, I made two simple templates in Inkscape and printed them out. One consists of two lines intersecting at 108 degrees (the interior angle of a pentagon), indicating the length to cut each stick to and the angle to cut the end at so that the 5 sticks will sit flush against each other when assembled. The other is a template for laying up the pentagon itself. A box cutter knife made short work of cutting the sticks to the right size and shape. With all the sticks cut to shape, I used more hot glue (for its intended purpose this time) to assemble the sticks into pentagons, being sure to fill in any gaps where the sticks mated.

Stack of assembled pentagons

With all 12 pentagons assembled, I wired their power, data and ground terminals together using 3 runs of color-coded magnet wire. I made a complete ring with each – although this was not strictly necessary, it provides two parallel current paths between any two points around the pentagon. Not a bad idea since the ones nearest where the power/data cable will plug in will be passing a lot of current. To avoid any surprises later, I quickly clipped the Arduino (running a simple test loop) to each assembled pentagon to make sure they were working. Finally, I tacked the wires together and onto the backside of each pentagon with hot glue. While I had the magnet wire handy, I took this opportunity to solder lengths of wire to each of the 30 “long” sticks as well.

Testing the pre-assembled segments to avoid surprises later

With the pentagons assembled and wired, I began assembling them onto on the inflated beach ball, adding the “long” sticks in between as needed. For this I just kind of winged it to avoid tolerance stack-up, marking and cutting one stick at a time for a good fit. After cutting to length, I cut a V-shaped notch in both ends of each stick so that they would mesh well with the pentagon corners they attached to. These were similarly glued into place, squeezing in extra hot glue to fill in any voids.

Sections being assembled on the beachball

Ball structurally completed, but not wired up

Finally! The buckyball looks like a buckyball. The beach ball was deflated and removed. By this stage each pentagon was already bussed together, so wiring consisted of using all the pre-wired “long” sticks to bridge neighboring pentagons together, folding or trimming any excess magnet wire and tacking it to the back of each stick (i.e. the inside surface of the ball.) After a final electrical test with the whole ball assembled, I sealed in all the LED boards and solder points with (you guessed it) more hot glue, made a hanger out of metal rod and cut two pieces of plexiglass to serve as the top and bottom supports for the rod. Bends in the hanging rod prevent the ball from sliding free of the rod or stretching out of shape.

Making endcaps for the top/bottom, which will support its weight when the hanging rod is passed through.

Completed ball running some cheesy visualizations

Electronics & Programming:
After some brief forays writing effects code in Processing and C (to run directly on the Arduino), I decided to write the visual effects script in Python for the most flexibility. The effects script outputs serial data to an Arduino (for the blog cred, yo), which serves as the bridge between the PC and the RGB LED array. Commands are sent as 3-byte packets to the Arduino consisting of a sync byte (0x55) followed by the Blinkenlichten address and command bytes. The Arduino clocks these out to the ball in the native Blinkenlichten single-wire format (not to be confused with Dallas 1-Wire(R) Protocol). See the Blinkenlichten page(s) for a full description of this protocol, but it basically consists of bits encoded as the ratio of ON-time to OFF-time on the wire (if the high “half” of the bit is longer than the low half, it is decoded as a 1 and vice versa), endcapped by a START (high for longer than the maximum bit ON-time) and END (low for longer than the maximum bit OFF-time) condition. Special commands exist for address discovery, address grouping, low-power mode and a couple other handy features.

Obviously, with 90 tiny microcontrollers and 270 unique LED dice potentially drawing power at the same time, there’s no way an Arduino / USB port can supply sufficient power on its own. A small perfboard mates the Arduino (running off the USB supply) to a 5V/4A wall wart for power to the ball electronics. The USB and wall-wart power are *not* bridged together (although the grounds are). Even at 4A (claimed) output capability, the wall wart struggles to keep the ball lit at full tilt – currently (hah!) it takes on a reddish hue if all the LEDs are going near full brightness, because the power supply output drops below the 4V or so it takes to light the blue LEDs. Also, the “3-wire” cable through my window now consists of 5 strands of rainbow wire (power and ground doubled up) because it was getting a tad warm with only one power and one ground strand.

Arduino supplies the data, while a 5V/4A wall-wart (black cable) supplies the power. The flat rainbow wire, is the perfect shape for sneaking around a closed window and to the ball outside.

When I assembled the Blinkenlichten nodes, I just programmed them serially and threw the finished ones in a box. Needless to say, by the time nodes were pulled from this box and the ball assembled, the node IDs are in no particular order. To make things easier on myself, I numbered all the locations in a logical way by writing them on the beachball with marker, then map the “human-readable” number to the actual node ID at that location in software. If you noticed various numbers scrawled on the beachball, this is what they are for (red: pentagon locations, black: “long” stick locations, green: actual node ID at that spot, in hexadecimal).

As of this writing, the effects script has only a tiny handful of effects I could throw together quickly – one pays homage the well-known “snake” games of yore, a couple others simulate paint splotches or crystal growth in various ways, and one just fades the primary colors in and out. Obviously, many of these require the software to have knowledge of the physical structure and relationships of the LED array. For this, the script includes a “neighbor table” consisting of a 2D list of each (human-readable) node number’s immediate neighbors. A couple more tables identify other relationships, such as which nodes are in the same pentagon or hexagon section. The script makes (or will make ;-) extensive use of das Blinkenlichten’s address-grouping features to run high-speed complementary effects on different logical groups with a minimum of bus traffic.

Downloads:
Blinkenlichten schematics/PCB, firmware and Arduino library – see the Blinkenlichten page
Buckyball effects script and Arduino serial-to-blinken script

Fixing an Acer AL2216W LCD Monitor (Delta DAC-19M010 power supply, bad caps)

There are several dozen of this model of monitor at my work since last year or so; the other day I found one on top of the dead electronics plunder pile recycling bin, looking brand new. Googling the model # and terms such as “problems” or “repair” or “won’t turn on” revealed pages of discussion on the badcaps.net forums: it seems this model of monitor is yet another victim of the bad capacitor plague that somehow continues to sweep the electronics world. Upon opening the monitor, this suspicion was confirmed by several visibly bulging capacitors in the low-voltage section of the power supply.

Probable Symptoms:

  • Monitor won’t turn on, no apparent power, black screen
  • Blinking power LED
  • Turns on but shuts itself off without warning*

Note: This power supply board (or very similar model) appears to be used in a variety of monitors from different manufacturers. Depending on which one you have, your symptoms may differ to what I have observed on the AL2216W. In particular, the monitor may simply not turn on (too-low logic voltage or software-controlled shutdown), may blink its power LED to indicate a fault, or may turn on for a few seconds and switch off again. In my case, the monitor showed absolutely no external signs of life (power LED dark and no response to the power switch), but a very brief flash of the backlight could be seen just as the unit was unplugged, confirming it did indeed have power but “chose” not to switch on (likely as a safety feature).

Obligatory Butt Covering Warnings

This is a wall-powered electronic gadget. Opening it and poking around inside carries a small, but non-zero, risk of electric shock even when unplugged. (There is a 100K bleeder resistor across the mains filter cap, but this could fail.) For your safety, wait at least one full minute after unplug to go near the supply board, and use a screwdriver with an insulated handle to short across the leads of the filter cap to be sure it is discharged. If you see a fat spark and blinding flash of light, the safety bleeder resistor has probably failed, and you might want to reconsider poking around in here.

(Opening it and poking around inside while it’s plugged in carries a guarantee of electric shock, just FYI.)

Disassembly

This is fairly straightforward. Pop off the plastic cover hiding the screws that attach the base. Unscrew them and any other visible screws, then carefully pry at the seam where the two halves of the monitor “shell” come together. Once inside, more screws. Note that to get the final metal shields off, the backlight connectors and the ribbon cable to the button panel must be disconnected, then the scew-in posts for the video connectors and two screws concealed in the mains cord socket must be removed.

What’s inside?

Surprisingly little, it turns out. There is one large power supply board (made by Delta Electronics, Inc.) and a much smaller display controller board (marked A220Z1-Z01-H-S6) with only two highly-integrated Realtek ICs and some discrete components. My educated guess is that the controller boards are very unlikely to fail, so start by looking at the Delta board.

Fault Finding

By all accounts, bad capacitors are usually the underlying cause of these problems. Due either to being under-rated or a sordid tale of corporate espionage (see Wikipedia link above), the capacitors will gradually vaporize their electrolyte (and sometimes not so gradually, with a bang) until they can no longer perform their capacitorly duties, causing the monitor to go haywire.

First, inspect all the electrolytic (“tin-can”) capacitors for visible problems. Their tops normally have a score pattern on them, but should otherwise be flat. They should not bulge upward, even a little. Visible bulging, ruptured tops or signs of leakage (e.g. brown goo around the top or seams) are sure signs they need replacing. Note that failed or failing caps will not always show visible signs.

On the Delta DAC-19M010 board, things are divided up into 3 logical sections: the bottom half is a switching power supply that steps your 120/240V wall power down to a 13.8V and 5V rail. Roughly speaking, everything to the left of the large center transformer is its primary (high-voltage) side, and everything to the right is the low-voltage secondary side (the high side may also be marked off by cutouts and/or a line on the underside of the board). The upper half of the board (more or less) is the backlight inverter, with another large transformer to step this low voltage up to the 1kV or so needed to feed the CCFL backlights.

I’m sure you noticed the large, high voltage cap on the high side, right near where the power cord plugs in. You did short it, right? This is the one that can make your skeleton glow even if the monitor is unplugged. Luckily, consensus from the internet is that this filter cap on the primary side rarely fails, so unless it is showing visible signs you can probably leave it alone.

There are seven electrolytic caps on the low-voltage side, all of which should be replaced if you even slightly suspect a capacitor problem. (Technically, the topmost one connects to the backlight inverter, but you should change it anyway.) On my monitor, the 13.8V rail read a tad high (14.x) and the 5V rail showed only 4.1V. There is likely an undervoltage lockout circuit on the controller that prevents operation at this voltage, although there may have been significant voltage ripple due to the bad caps that was resetting or otherwise fouling up the logic directly.

Collateral Damage

With the caps replaced, it’s a good idea to check for any obvious collateral damage. There are several surface-mount fuses (denoted Fxxx) on the bottom of the board which might have been affected (zero-ohm resistors may have been stuffed in place of some fuses; check these too). After you triple-check that the mains filter cap is discharged, also check the through-hole fusible resistor to the immediate left (high voltage side) of the switching transformer. There is also a surface-mount fuse on the controller board near the power entry connector.

Cap List

Here are suitable replacement parts currently available on Digikey. Be careful when removing the old ones, as some of them are near very brittle powdered-core inductors and tacked down with some kind of glue. Note, one of the parts below has a higher voltage rating than the original (this is OK).

Quantity Part# Value Lead Spacing Height
2x 565-1546-ND (220u/25V) 3.50mm 11.5mm
1x 338-2342-ND (2200u/10V) 5.00mm 21.00mm
3x 493-1065-ND (1000uF/25V) 5.00mm 20.00mm
1x 565-1550-ND (470uF / 25V) 3.50mm 20.00mm

* Note, if the screen’s backlight cuts out (often after a couple seconds) but the monitor appears to remain powered, the fault is most likely in the backlights or backlight inverter section of the power supply board, not the low-voltage section. You can confirm whether the entire system or only the backlight has shut off by holding a strong flashlight directly against the screen while a valid video signal is present – if you can see the image around the edges of the flashlight, the low-voltage supply and controller board are probably OK. Replacing C204 MAY solve it, but otherwise, fixing backlight issues is a whole different animal, which I don’t cover here. You MAY be able to identify a single dud tube by unplugging one at a time (WITH THE MONITOR UNPLUGGED!!!) and testing the monitor, but this is not 100% reliable (some inverter circuits will detect a single “open” (e.g. unplugged) tube and shut down anyway).

Slam Stick: dissected!

Woot! It sounds like a gadget I designed will be featured in next month’s EDN magazine (Prying Eyes column). This must be some kind of ironic career turning point: I landed a job by reverse-engineering other peoples’ stuff; now people reverse-engineer my stuff.

UVLO, Comparators with hysteresis (now with 20% more equations!)

The Mosquino board is intended to operate from very low-power sources, such as RF, vibration energy harvesting and small thermal gradients (e.g. body heat). Although the ATMega and the rest of the circuit can be put to sleep at < <1uA once they have reached legal operating voltage, many semiconductor circuits fail this test with too-low or slowly rising power supplies. For example, the datasheet for the MCP1703 voltage regulator shown claims a quiescent current of a couple uA (in regulation), but it actually peaks out at over 100uA just below its regulation voltage, and that's not considering any other circuitry living downstream. So, as a key part of this balanced breakfast, this is a simple UVLO (undervoltage lockout) circuit that will hopefully become standard in the next Mosquino rev. It should be guaranteed to draw <10uA over the full (0.0 ~ 11V) range, and in practice probably much lower.

The active ingredient is simply a micropower comparator with a fixed reference and some positive feedback added to generate hysteresis. While deceptively simple, the math to cleanly resolve the desired on/off thresholds into a set of resistor values gets a little icky, so this post is mostly a note to myself so I never have to derive it again :-) (Yeah, I hate math and chose a career as an electronic engineer. Go figure.)

Operation

Two voltage thresholds, a “turn-on” threshold (Vh) and a lower “turn-off” threshold (Vl), determined by 3 resistor values, are defined by the user. (A reference voltage lower than either of these, Vref, is either provided by the user or comes for free with your comparator.) When a trickle of power is available, the input voltage charges up from zero until the higher, turn-on, thresold is reached, and this is then connected to the rest of the circuit (CPU, etc.). The circuit will be Doing Stuff, in some cases drawing more power than what’s coming in. In this case, the voltage at the input cap will begin to fall as power is consumed. The circuit gets cut off when the input voltage reaches the lower, turn-off threshold.

The feedback resistor, R3, is effectively placed in parallel with either R1 or R2 depending on the comparator’s state, which has the effect of pulling the compared voltage (+ terminal of the comparator) up or down slightly. This makes the divided Vcc appear lower than it really is until the comparator turns on, and higher than it really is until the comparator turns off again (see the equivalent circuits above).

Choosing these thresholds

The thresholds should be chosen such that the chosen power supply can actually (and reliably) charge up to the turn-on threshold, ideally in a reasonable amount of time. The turn-off threshold should be low enough (far enough from the turn-on threshold) that the turn-on current surge and any startup tasks don’t drag the supply all the way down to it and immediately turn your circuit off again. Needless to say, both should be within the circuit’s legal operating voltage range.

Setting the resistor values

R1 and R2 are a voltage divider; their ratio sets the comparison voltage between 0 and Vcc. For our purposes let’s also consider R3 this way, so we are really computing a relative relationship between R1, R2 and R3 that makes your Vh and Vl work. An approximately infinite number of actual resistances would work as long as the ratios between them are correct; we can worry about actual resistance values later. To make things simple we’ll define R3 = 1 and compute R1 and R2 relative to it. Here’s the math you need to do so (you can read the derivation below if interested).

  • Define R3 = 1.
  • Choose R1: R1 = (Vh/Vl) – 1
  • Choose R2: R2 = (Vref * R1) / (R1*Vl + Vl – Vref*R1 – Vref)

You should now have values (probably small decimal numbers < 1) for R1 and R2. Now let's choose real values for them. For a low-power application, you want to use large resistor values to minimize wasted current through them. But, the comparator's + input pin will have some amount of leakage / bias current, so this limits how large of resistors you can use (bias current sunk or sourced by the pin will affect its voltage and thus the overall setpoint accuracy). For decent accuracy, you want the current into the node containing the input pin to be at least 10x (ideally 100x) of the leakage current. For the LTC1540, the bias current is around 1nA, which is about as close to sweet f-all as you can get. In practice, the contribution of R3 in this application will be the weakest (highest resistance value) of the three by far, and so R1/R2 will be much lower. You can probably choose a value for R3 on the order of 15-30M ohms. In fact, a quick survey at Digikey says these are your only readily available standard values in that range; you might have to put two 15Ms in series. Beyond that point, you have to start worrying about truly silly stuff like the resistance of the PCB itself (especially on a humid day) goofing up your setpoints, so again, don't go too crazy. Now, multiply your ratio values for R1 and R2 by that value, and choose the closest standard value that is available for each. Optional, but recommended: Check the actual Vh and Vl you will get from choosing the standard values:

Notes for the LTC1540-based circuit above:

The part is guaranteed to operate correctly down to 2V, and in most cases will behave well below that. In my tests, it operated great down to about 1.4V. Below that, a spurious HIGH pulse on the output occurs from about 0.8 ~ 1.4V. For best results in the UVLO circuit shown above, be sure the FET it drives has a threshold voltage of at least 2V to guarantee the false signal will not be seen downstream.

If that part is not available, a couple parts with similar specs exist (e.g. MAX9117-9210 series), but they are not pin-compatible.

The Maths:


Not Dead

Really! Just busy with some real-life stuff, namely wedding related and home renovations. I haven’t forgotten about this pick & place stuff! Lately I’ve been spending most of my project time on getting Mosquino toward an official 1.0 release. The rev2 boards just came in, so once all the parts are in I should have one ready to test soon. Here they are!

As usual, click for fullsize. Clockwise from the bottom-left are a bistable display shield, microSD shield, low power boost board (as low as 0.6V to 3.3V), Peltier shield (thermal to electricity, ~20mV to 4.1V), vibration energy harvesting shield, a stackable LiPol / thinfilm battery power shield, and of course the Mosquino mainboard itself. You may have seen early versions of some of these on the Mosquino page already, but these implement bug fixes and the latest/finalized Mosquino pinout. Can’t wait to get playing with these!

(And no, purple is not the official / final color – The PCBs were made via Laen’s sweet batch PCB service; he likes to experiment with the colors from time to time. It’s not a ripoff of Lilypad…although the Peltier board can potentially harvest from typical bodyheat gradients (>=2degC), which is an interesting development for wearable computing projects to say the least!)