Notes To Myself: Migrating legacy Microchip C18 projects to MPLAB X + XC8 toolchain, Windows 7

First note to myself: NEVER USE MICROCHIP AGAIN. If I didn’t just need to make “a couple tiny updates” to an already selling, on-the-shelf project I’d just scrap the PIC18 for an EFM32TGxxx part, gcc (shaft of light from the sky, harps playing melodically) and be done with this entire shit-show. Insert whining about the month+ long circlejerk with Microchip Support about the bug in the PICKit3 programmer that is now corrupting the config bits on said product here. Of course, if the code from 5 years ago, even with no changes, still compiled and fit onto the chip it was written for and used to fit on 5 years’ worth of versions ago, and current MCC18 did not insist on dragging in the gargantuan (>4KByte) ‘.code_vfprintf.o’ even if it is not used or referenced anywhere in the code, I wouldn’t even have to bother trying it with the new compiler in the first place….

Soooo…. Install MPLAB X (make tea, a sandwich, possibly a baby or two while waiting for the crunching sounds from your harddrive to finish) and XC8. NB: Licensing is done via a Windows batchfile, completely outside any of the devtools OR their installers. If you have the license file, ignore absolutely anything to do with licensing and install as if you want the “free” version.

License: Run said batchfile. Voodoo happens and it should “Just Work”. (It did. Quite surprised.)

Make XC8 “C18 Compatibility Mode” findable:

The fake “C18” that currently serves as the compatibility layer must first be manually setup in MPLAB X (apparently no autodetect). But first-first, you need to workaround a stupid MPLAB X bug that has been unfixed going on two years now. The bug is you are arbitrarily forbidden from having two toolchains set up whose executables are in the same directory. Unfortunately this is EXACTLY WHAT MICROCHIP’S OWN XC8 COMPILER DOES (of course that directory is already used for XC8 itself, which IS autodetected somehow). So you have to create a fake instance of this directory (symlink or hardlink) with a different name to fool MPLAB X.

NB: The below workaround only works if your filesystem is NTFS. If not, you could also try just copypasta-ing the entire contents somewhere else, and hope this doesn’t break a path dependency somewhere or whatever. I haven’t tried this, but worth a shot.

To do this, you have to first-first-first somehow get a Windows console with Administrator privileges. The way I found that works is to create a batchfile with the contents “cmd <carriage return> pause”, then right-click and “Run As Administrator”. (Using the ‘runas’ command, Windows 7’s answer to sudo, apparently does not work for this as it forces you to know the actual administrator password, and will not accept your user password even if you have administrator privileges.

At the console, cd into the XC8 directory directly above the binaries directory (e.g. “C:\Progra~1(X86)\Microchip\xc8\v1.31\”) and type:

mklink /D _c18bin_ bin

This should result in a message indicating a symbolic link named “_c18bin_” was created.

Now you can actually set up the devtool. Ignore anything on the splash page and go to Tools -> Options -> Embedded -> Build Tools tab. Press “Add…” and enter the fake directory you just created. Specify the location of each build tool (if it exists). NB: For some reason the individual devtool settings ‘disappear’ after specifying them (close and re-open this dialog and “C Compiler” is blank again!). Does this mean it doesn’t need to be specified, or this is another MPLAB X bug and your dev tool will never, ever work? Will soon find out…

Now, try to build project (it will fail).

In “Output -> Configuration Loading Error” tab: “Could not generate makefiles for configuration default.” “XMLBaseMakefileWriter::createRuntimeObjectForMakeRule: null”

In “projectname (Build, Load)” tab: make[1]: *** No rule to make target ‘.build-conf’. Stop.

FIXME: Fix this error…

The Internet, things, and you

Ha ha, apparently proselytizing about the “Internet of Things” is trendy again. Don’t hold your breath kids; until IPv6 is a thing that’s really a thing, enjoy your “small home network of things”, where your game console, thermostat and toaster have 192.168.x.x IP addresses dangling from your cablemodem, and require a 3rd-party cloud service to mediate contact with your neighbor’s toaster*.

Seriously though… if anybody but major datamining companies are going to get remotely enthusiastic about this IoT business, two things need to happen: IPv6 and dirt-cheap low-bandwidth wireless uplinks (think cellphone plan with pay-by-the-byte or 512kb/month dataplans and low/no monthly maintenance fees) so that all the applications (smart stoplights, weather/pollution sensors, whatever) that would benefit from not dangling off someone’s cell plan or cablemodem don’t have to do so. Maybe on the 3rd revival of the IoT hype, about 10 years from now, it’ll really catch on and be actually kind of useful. (See also: “M2M”.)

* The latter shit-uation is due in equal parts to headaches around NAT traversal, service/peer discovery, and the fact that nobody serious (read: businesses) wants to throw in for an open platform when there’s a snowflake’s chance they could parlay their own proprietary stuff into the One True IoT Service. Even with IPv6 and cheap-as-free radio/cell/satellite pipes, the “IoT ecosystem” (I cringe just saying that) won’t be completely free of the need for a centralish service/peer discovery mechanism and (for power-limited systems) somebody acting as mailbox/aggregator/push notifier/whatchamacallit so that the low-power endnodes can talk to one another despite randomly popping onto the network for just a few seconds at a time. Still, a backend you can download and drop on your own cheapo web hosting account if you didn’t want to be tied to said 3rd-party cloud service would be huge in making this, well, A Thing.

Haptic hackery for fun and profit

My day-job employer makes fancy piezoelectric actuators. Not long ago I was asked out of the blue: “Hey, the Haptics Symposium is in less than 2 weeks… It’s in Houston, TX. Want to go?”

“*looks out window at yet more falling snow* Hell yeah.”

“Oh yeah, and we’re going to need some demos so…”

Of course, I had no shortage of regularly scheduled urgent worky stuff to do, so any demos had to be done with some haste. In the end I got not-one-but-two cheesy demos going, one of which didn’t even break during the show! In addition, my newest coworker put together an incredibly sweet haptic texture-rendering demo, but I’m sure he’s writing it up on his own blog as I speak :p

Super cheesy heightfield mouse

One of the fun things about piezoelectric bimorphs is that, unlike coin motors, LRAs and voice coil drivers, they can be deflected statically. So it’s possible to set and hold arbitrary linear positions. With this in mind, I scavenged an old ball mouse from the IT junkpile, removed the PS/2 cable and ball, and hacked it up so that the left mouse button now raises and lowers in response to the brightness of the surface directly beneath it. An arbitrary grayscale image placed under the mouse now becomes a tactile experience, felt rather than seen.

The replacement guts consist of a SHIVR actuator, photodetector, 3x AAA battery holder and a small driver board. The driver board consists of a TI DRV8662 piezo driver and a handful of supporting discretes. The DRV8662 functions as a voltage booster and amplifier, stepping up a 3V-5VDC input to 100V and driving a bipolar output in response to a low-voltage (0-3V or so) input signal. The photosensor and an LED were glued up inside the hole where the ball used to be, and the connection between the sensor and a 100k bias resistor was wired directly to the DRV8662 analog input. The actuator was stood off on a piece of scrap metal to match the height of the button. A mechanical stop feature on the underside of the mouse button was Dremeled a bit to give the actuated button a bit larger range of motion. Last but not least, the top shell was spraypainted black to slightly disguise its origins as an old Microsoft ballmouse from about the Soviet era.

Haptic heightfield mouse demo guts partially assembled, actuator shown

Haptic heightfield mouse demo guts

The purple amplifier board was fabbed using OSH Park sometime prior (for experiments just such as this) and pretty much follows the application example in the DRV8662 datasheet, except for the DC modification as follows: Remove the DC blocking capacitors from the IN+/IN- pins, connect your input signal directly to IN+ and connect a midscale reference to IN-. For a typical 3.3V supply voltage and appropriate setting of the gain selects, a 10k/10k resistor divider between 3.3V and GND is just about right. Note that although the datasheet warns against continuous operation of the DRV8662 to avoid overheating, at such low frequencies it doesn’t so much as get warm to the touch. (Actually, I found it nearly impossible to get the evaluation kit into overtemperature even under continuous, harsh drive conditions.)

DRV8662 circuit with PWM input and modification for DC operation

DRV8662 circuit with PWM input and modification for DC operation

Slightly less-cheesy thumpin’ phablet

Another up-and-coming use for linear actuators lately is to provide inertial haptic effects in handheld gadgets. Most folks are familiar with the kind emanating from the weighted motors used in phones and game controllers, but these are fairly limited: they can only shake “all around” (not in a specified direction), the amplitude and frequency cannot be independently controlled (the only way to get more oomph is to spin it faster), and neither can the phasing of the actuator (let alone between multiple actuators) be controlled. Oh yeah, and the spin-up and spin-down times are on the order of 100-400ms depending on the size of the motor, so forget about any sharp, rapid-onset effects. For these reasons, folks are experimenting with linear actuators, which can provide much more precisely controlled sensations (a good example is the proposed Steam controller, which features two touchpads with a linear voicecoil driver under each.)

A fun thing about the piezo bimorphs is they are extremely lightweight (less than 0.5 grams) – so when adding mass at the end to make an inertial driver, it’s basically all payload: that mass isn’t fighting against the dead weight of magnets or metal shielding components. So I decided to make a demo resembling a big phat phablet*, which could be a flashy quadcore phone or some kind of aesthetically addled game controller. Or, you know, a rounded rectangle hogged out of a piece of Delrin. Hey, rounded corners! This demo featured two actuators, one on each side. I slapped a total of 10g tip mass on each, held in place by a stylin’ dab of epoxy.

Handheld inertial haptic demo in phablet-like form factor

Handheld inertial haptic demo in phablet-like form factor

For this demo I laid out a made-for-purpose PCB (not just carved up what I had already hanging around) and sent it off to Gold Phoenix. It arrived juuuust in time, but that’s another story. The board layout had a total of 3 copies of the same DRV8662 circuit, with a spot for a small PIC12 microcontroller at each to supply the waveforms. (The 3rd circuit was to be for a third, surface-bonded actuator, but I didn’t have time to implement it.) The program on each PIC consisted of a simple arbitrary wavetable generator (a handful of basic waveforms such as sine, square and directional “punch” were generated by a python script and slapped into lookup tables) and a series of calls to the waveform generator function with varying amplitudes, frequencies and waveform index to generate the demo effects. The waveform output itself was driven on a PWM pin and filtered to provide a proper analog input to the driver, and a GPIO pin was used for master-slave synchronization between the PICs.

As before, the static deflection capability of the actuators was (ab)used to produce directional effects, such as making the device lunge toward or away from the user (fast drive stroke followed by a slower position-and-hold return stroke), or wiggle by driving them with out-of-phase square waves. With the 10g of mass, the usable frequency range was from about 30Hz to a few hundred Hz. Above 350Hz or so, the drivers reached their power limit and the output waveforms began to distort, producing significant audible noise in addition to motion. Qualitatively, this frequency range goes from a deep rumble to the sensation that there’s a very pissed-off mosquito trapped under your hand. You can’t feel it over the internet, but you can see the actuators throwing in the video below.

If this had been a real smartphone/etc. with a touchscreen, the actuation could respond to touch activity to produce effects like:

  • Simulate surface texturing, i.e. give different screen areas different feels or make areas feel “pushed in” or “popped out”
  • Simulate sticky and slippery spots on the screen by vibrating the screen at high frequencies to modify stiction
  • Create the sensation of inertia or heaviness in the device, resisting as the user shakes or moves it around
  • Create the feeling of compliance, i.e. make the rigid glass screen feel like rubber and bounce when touched
  • Create the illusion of tackiness, where the screen gets pulled with the user’s finger as they let go, along with a vibratory kiss as it pulls free

Demo Code Details

This was for a day-job project, so I can’t provide the actual sourcecode… but can at least describe a bit of how it works.

The waveform generator is pretty straightforward, with one slight tweak to allow for arbitrary amplitude control. The actual waveform data is stored as raw data at a 256-word-aligned boundary. From the beginning of the table, the current entry is moved to the PWM register, followed by a waitloop for a timer overflow flag and then incrementing the table pointer. One call to the waveform output function outputs one complete cycle. The total duration of waveform output is controlled (at the next level up) by how many times this function is called in succession (i.e. how many complete cycles are output at the configured frequency).

The PIC’s 16-bit timer is used to control timing of waveform traversal. It is a little odd, providing a configurable prescale, postscale and period register (PR) setting. The pre/postscale divide the timer by (1:1, 1:4, 1:16) and (1:1 to 1:16) respectively. The PR configures the ‘top’ or rollover value to any value between 1 and 255. Between these settings, a wide variety of rates are possible. Once again, I used a python script (natch!) to build a lookup table which maps a frequency (2Hz increments) to the pre/post/PR combination which comes closest to it. With the on-chip 32MHz oscillator and 128-point wavetable, the realizable waveform frequencies are from 2Hz to somewhere upward of 1KHz.

Each wavetable entry stores one complete cycle of the waveform at 8-bit resolution, full amplitude (i.e. the waveform goes from 0 at its lowest point to 255 at its highest point; 128 is midscale). To achieve variable amplitude without storing scaled copies of the waveform or performing expensive math, some binary arithmetic is used. I describe the actual algorithm in this forum post. To avoid any audible clicking when switching waveforms, the tables are constructed so that the last point in each wavetable ends at midscale, and only multiples of complete wave cycles are output.

The sine, square and triangle waveforms are pretty straightforward. The ‘punch’ waveform consists of a very short quarter-sinewave drive stroke (from -fullscale to +fullscale) followed a linear ramp back to negative fullscale. As with the others, this waveform is time-shifted so that the midscale crossing of the ramp-down occurs at the last point in the table.

Sinusoidal waveform

Sinusoidal waveform

Punch waveform

Punch waveform, consisting of a rapid drive stroke and slow return stroke. In these waveforms the green trace indicates polarity and the red indicates inflection (not used in the demo code).

The Show

The first day consisted entirely of workshops, no exhibitions. Unfortunately our scheduling didn’t permit getting there early and seeing all of them, but did get to check out a couple. One of these was a sweet haptic texture rendering talk from researchers at UPenn. The math behind their approach will make your eyeballs spin backwards into their sockets a bit, but the results were incredibly realistic. On display were a tablet computer and stylus combo that faithfully recreated the sensation of drawing on sandpaper, cardboard and dozens of other textures on the slick glass surface, and the same algorithm implemented in a force-feedback arm for texturing 3D virtual surfaces. The algorithm and texture database are open source and published online.

The other was probably the most badass-looking Brain-Computer Interface setup known to mankind. You think you’re cute with your little Emotiv headset and its 3 thumbtacks touching your mop? Yeah, this one has 128 saline-soaked electrodes for your mind-reading pleasure. You’ll look like a lunchlady wearing it, but everyone will know how ridiculous you think you look. Actually, the takeaway message I got from the BCI stuff on display was don’t believe the hype. The 128-node BCI demo was impressive in that a fresh-from-the-crowd individual could begin to steer a ball left or right onscreen by thinking (specifically, visualizing moving either their left or right arm) within about 10 minutes, without a lengthy training/calibration period. However, even with this very formal setup, those stories you hear about typing with your mind at normal speed, or guessing which picture you’re thinking about, etc… reality isn’t really there yet. (There is a character input scheme known as a P300 speller that does work, but it’s not nearly as straightforward as thinking about a letter and having it show up in your document. Input speeds are measured in characters per minute – not all that many – and require intense concentration.)

A volunteer is wired up to a Brain-Computer Interface consisting of a skull cap with dozens of electrodes

Serious Brain-Computer Interface

The next several days we were exhibiting. Unfortunately that meant we were stuck in our own booth, and couldn’t go check out the demo sessions. On the bright side, many of the demos were left set up between sessions, so we could at least sneak a peek around during e.g. poster sessions (when the exhibition section was a ghost town) and get some idea what they were about. Oh yeah, this is definitely a University-research-heavy conference, so Arduinos everywhere! In retrospect, probably not the ideal venue to try and hawk raw actuators to (nonexistent) smartphone-company scouts, but highly informative regardless.

That said, there were a few industry folks milling around. A few from names you might expect to see here, and even more from companies you’ve probably heard of, but would not expect to be interested in this stuff. Oh yeah, and a haptics show would not be complete without a scout from the notorious “I” company there. Not the rounded corners one, I mean the other “I” company, that seems to elicit groans from the entire haptics community. A guy from there walked up to our booth, so I tried to ask (ahem, tactfully) what exactly they did/sold, what value they added.

“So what do you guys do? Some kind of… software, right?”
“Oh yeah, there’s a software package… we champion the cause of haptics… and mainly, you know, licensing…”

He wasn’t carrying a clipboard or obvious spy camera, so at least there’s a chance we won’t find vague patents filed against everything in our booth appearing in exactly 18 months’ time.

"I am Patent Trollio! I need IP for my bunghole! I would hate for my portfolio to have a holio..."

“I am Patent Trollio! I need IP for my bunghole! I would hate for my portfolio to have a holio…”

Murphy Factor

No such trip is complete without at least something going wrong. In this case it was a problem with the handheld demo. I had built two boards as a precaution (baking on the leadless DRV8662s is fiddly enough, and there are multiple of them on the design – amazingly, both boards worked on the first try) and ordered a couple small LiPol battery samples. There was no time to charge them in the scramble to code the demo the night before, but no problem, we can just recharge this board with any USB cable, right? So the first morning of the show, I started one running and just left it out. After the first hour or so, it started to make an unhappy clicking sound and soon went silent. So I swapped in the 2nd board and plugged the dead 1st one in to charge. After a while, the 2nd board also started to go, so I switched the now-charged (harhar) first back in. Yyyyeah, not so much. It turns out (in later investigation back at the office) I had swapped two resistors during assembly, and the one that should have been standing in for a 10k thermistor was actually a 100k, causing the charger IC to think it was way out of a safe temperature range and shut down. (Hey, they’re all 0402 and completely unmarked; don’t judge.) Lunch involved a bolt to the nearest Radio Shack and MacGyvering a close-enough LiPol charger. Yeah, that’s a bundle of low-value resistors with their ends twisted together (to limit current to ~1C, or about 50mA for this battery), a rectifier diode to drop the 5V from a hacked-off USB cable down closer to 4.2V, and some alligator clips to strategic points on the board. The Shack’s cheapest/only multimeter was used to check the battery voltage periodically to avoid overcharging. Not exactly pretty, but it worked.




Wait, what? Yes, actually dinosaurs. On the 2nd night there was a banquet held at the Houston Natural History Museum. So, dinner and drinks under the gaping maw of T. rex and a dozen of his closest dead friends. Pretty cool.

Dining with dinos. Bites with trilobites. Ordovician hors d'...Someone please stop me now.

Dining with dinos. Bites with trilobites. Ordovician hors d’…Someone please stop me now.

* Don’t you just love that word – the uneasy intersection of fat flabby phone and a phony wannabe tablet…

Springtime brew

So, I just discovered I’m completely out of Pumpkin Fail (euphemistically, Cinnamon Cream Ale – that I only too late realized I forgot to add the pumpkin to the boil…yeah, don’t ask.). Time for a new brew!

Haven’t decided what to make yet, but at least I know just what to call it…

F*CK SNOW - Seriously, enough of this crap already

(With apologies to Hunger Games fans)

Coming soon to a dominated world near you!

Yep…it’s finally happened!



Notes to myself: Minibog improvements

I’ve been growing some small carnivorous plants (mainly Nepenthes and sundews) in a tank indoors, but a couple years ago, just for fun I started some Sarracenia (pitcher plant) seeds. Well, what do you know, the darned things actually grew. So this spring, when it was clear I wouldn’t be able to keep them in small pots or winter them over in a fishtank anymore, I put together this freestanding outdoor minibog.

For this first attempt, I picked up a pretty standard (you could even say, “bog standard”, harhar) rectangular planter without drainage holes, put a couple inches of gravel in the bottom, stood a couple pieces of 4″ PVC pipe on the ends, then filled it up with sphagnum peat moss. Well, since the planter was much deeper than the plant pots I was sticking in, I put a couple large rocks at the bottom to take up space too. A small overflow hole drilled just below the soil line prevents it turning into a pond.

Minibog with some s. leucophylla, s. flava and a mystery type. The Nepenthes has already been brought inside due to frost hazard.

Minibog with some s. leucophylla, s. flava and a mystery type. The Nepenthes has already been brought inside due to frost hazard.

This first cut worked out all right. The peat stayed plenty wet with only a bit of watering during dry spells, and water wicked into the pitcher pots (through peat-peat contact via the drainage holes) well enough despite being plastic. The PVC pipes, intended to take up space and provide a place to sink a couple 1L pop bottles as an emergency gravity-watering system, turned out to be unnecessary, and mostly a good place to grow mosquitoes.

Notes for next year:

On watering: The scheme with the PVC pipes (besides taking up the extra space in the planter) was that if the water table ever got to the very bottom and I was on vacation (or just forgetting to water the thing, because that’s something I would do), water-filled pop bottles notched at the bottom would slowly release their contents to maintain 1/4″ or so of water at the bottom (enough to keep things moist enough to stay alive, without immediately evaporating). It turns out the gravel alone works just as well for this. But I did like the fact that the pipes gave an easy visual indication of the water level in the minibog, and a quick way to fill ‘er up. So for next year, a mosquitoproof watering hole / level indicator: It turns out that 1.5″ PVC and a pingpong ball are an almost perfect fit: juuuust enough clearance for the ball to float freely, but not enough to let flying pests reach the water. Brilliant!

1.5" PVC pipe and pingpong ball as water level indicator and mosquito excluder.

1.5″ PVC pipe and pingpong ball as water level indicator and mosquito excluder.

On wintering (to move or not to move): So far I’ve been providing winter dormancy for various plants by keeping them in a fishtank in a cold room of the house. Except for one N. purpurea (Home Depot rescue), I’ve got nothing that’s winter-hardy where I live (USDA zone 5). Reading up on the subject, it looks like people are successfully wintering not-so-hardy pitchers here if they are dug into the ground (no freestanding pots) and mulched. So next year I might take this bog and sink it into the ground, for plants that can be wintered outdoors, and make a smaller one that can easily be brought inside for the tropical stuff (I stuck a Nepenthes in the bog for the season, and it seemed to like it). Keep the pingpong ball watering scheme for both. I’m hoping with the infrastructure of a bog underneath, the fishtank will no longer be necessary for maintaining humidity or keeping things wet over the intervals I remember to water them. (That, and it looks like the fishtank is needed for actual fish now.)

More on moving: Another reason to bury this one is this design of planter was apparently not really intended to be full of water: after a couple seasons, it’s really starting to bow out in the middle.

On wildlife: Something(s) just love to go in there and dig little holes everywhere. I can’t really tell whether it’s squirrels, birds or both. Likewise, when I tried starting some live Sphagnum on the top, it was quickly dug out and removed (probably by nesting birds). In the end I had to cover most of the surface with good sized rocks to keep it from looking like a minefield. Sprinkling the surface with cinnamon and cayenne pepper powder had no effect. Next year, possibly some better wildlife protection scheme…

PID control stove hack for better brewing, sous vide, etc.

“Cook all the foods, hack all the things /
Make all the booze, hack all the things”

In beer brewing, the temperature profile during mashing has important implications for the beer’s eventual body and “mouthfeel”. The requirements for partial mash brewing are a bit more relaxed than all-grain, but still matter (the enzymatic reactions occur over the range of ~150-160F, but progress differently depending on the time spent in various portions of that range.) More to the point, manually babysitting this for a large pot of not-yet-beer on a stovetop is a pain in the arse, so the other night I just modded our electric range for external closed-loop temperature control.

The hack is pretty simple and should be straightforward to apply to most electric stoves. The supplies needed are a temperature controller (typically a PID controller), a temperature probe (typically thermocouple or RTD), and a beefy solid-state relay. I’d also highly recommend a jack for the control signal connection so it can be easily unplugged and stashed somewhere when not in use. In my case, I also added a beefy bypass switch that allowed the mod to be done in a reversible and failsafe way.

I am very fortunate to have a wife who puts up with my relentless tweaking around and warranty-voiding :-p She didn’t even flip a shit when she went for breakfast one morning and saw this:

"But honey... I'm making it *better*..."

“But honey… I’m making it *better*…”

Even so, a mod that involved loose ugly equipment and snarls of exposed wiring was probably not going to fly – so this had to be done with no or minimal visible changes.

Electric range guts in brief
Your parents’ (or maybe grandparents’) generation put a man on the Moon, so you might think a modern electric stove is full of microcontrollery precision and closed-loop systems targeting a specific glass temperature (non-contact IR temp sensors being about a buck fifty in quantity now). But nothing could be further from the truth. Typically, any and all temperature regulation is contained in the control knob itself, using a hacky-sounding mechanical assembly known as an infinite switch. It’s basically a bimetallic strip, like in an old thermostat, stuck on top of a variable resistor set by the knob position. The heat from the resistor makes/breaks the circuit at some interval proportional-ish to knob position, but it doesn’t know or care what kind of thermal load is on the burner. More relevant to this application, it also means there is no nice relay controlling everything, ready to have its nice low-voltage control signal hijacked with an Arduino or similar. This mod requires working directly with mains voltage and current, typically 240VAC (for North America at least), and obviously at enough amps to make things glow.

The mod

The stove I have features several burners of various sizes. I targeted the largest one for modification as this is the only one large enough for the brewpot. This burner features three independent elements that can be enabled in increments (inner, inner+middle, or all) to heat things of various sizes. Upon removing the back panel of the stove, I found a wiring diagram folded up and tucked inside behind the control knobs. This provided a good starting point, and also helpfully reported that the burner pulls 3,000W when all 3 elements are engaged, at a resistance of only 19.2 ohms across the 240V mains. Yikes!

Assuming a full 240V (RMS) from the wall, the burner should pull 12.5A (Ohm’s law). For a safety margin and (mainly) the belief that random solid state relays, usually made in China, may tend to be “optimistic” about their current ratings, I bought one rated for 40A, along with a PID temperature controller (Auber Instruments SYL1512A) and a waterproof RTD (resistance temperature detector) probe. PID control mathematically anticipates the future output for a given input, providing more accurate control (e.g. reducing overshoot), especially in an application like this with plenty of thermal inertia. The output of this controller is directly compatible with typical solid state relays, which are controlled by a DC voltage (typically accepting a wide range such as 3-24V). To avoid any possibility of overstressing the elements from rapid cycling, the controller cycle time setting was lengthened to be closer to the cycle times observed from the manual control, about 15 seconds.

A simplified diagram for the 3-element burner, before and after modification, is shown below. The dotted boxes in the top figure represent various internal switches on the control knob. Note that despite being drawn as completely independent switches, they are actually sequenced by the knob in a manner that isn’t entirely clear (and I didn’t care to reverse-engineer with a meter). I felt the most failsafe approach would be to wire the relay in series with the main switch, with a bypass switch in parallel with the relay, rather than bypass the knob switch with the relay. This provides “normal” (relay bypassed) vs. “external control” (bypass switch open) modes, and ensures that the burner can still be used normally if the relay ever fails, either open or short. The knob must still be turned to one of the ON positions to operate in either mode, so a during-the-night relay or controller failure cannot activate the burner unattended.

Wiring diagram

(Top) Original circuit, (Bottom) Modification for external control

In this stove a fat red bus wire delivers mains power to each infinite switch via a 1/4-inch quick connect, making it easy to patch custom circuitry in between.

In this stove a fat red bus wire delivers mains power to each infinite switch via a 1/4-inch quick connect, making it easy to patch custom circuitry in between.

I made a couple splitters to distribute power between the SSR and bypass switch and back to the infinite switch. Quick-connects make connecting it up, well, quick.

I made a couple splitters to distribute power between the SSR and bypass switch and back to the infinite switch. Quick-connects make connecting it up, well, quick.

Passing 3000W is no small potatoes, so external heatsinking on the solid-state relay is needed. For this I bolted the relay to a scrap aluminum plate, drilled a few holes in the stove’s back panel and bolted it to the inside. Thermal grease on all mating surfaces aids heat transfer. The plate acts as a heat spreader, making the entire back panel one big (if not particularly efficient) heatsink. The relay was positioned to fit into a gap between the control knobs and the main electronics assembly (clock / oven control) inside the front panel.

Solid-state relay installed onto inside of rear cover, allowing the entire cover to act as its heatsink.

Solid-state relay installed onto inside of rear cover, allowing the entire cover to act as its heatsink.

The relay and its wiring fits nicely into a gap between the infinite switches and the oven control assembly.

The relay and its wiring fits nicely into a gap between the infinite switches and the oven control assembly.

Rear cover reassembled. You can hardly tell it's been modified.

Rear cover reassembled. You can hardly tell it’s been modified.

Wiring for the bypass switch and relay control input was snaked through small gaps underneath the front panel, and the switch and a phono jack for the relay control were mounted tucked underneath the front panel using J-B Weld. In the end, unless you get up close and squint just right, you probably couldn’t tell the stove didn’t come this way.

Bypass switch wiring routed through a small opening underneath the front panel.

Bypass switch wiring routed through a small opening underneath the front panel.

Hey, I needed some way to hold the switch in position while the epoxy hardened...

Hey, I needed some way to hold the switch in position while the epoxy hardened…

Testing the thermal regulation using a small pot of water. The controller will be put into a nice enclosure soon.

Testing the thermal regulation using a small pot of water. The controller will be put into a nice enclosure soon.

End result. It looks pretty normal when the external controller isn't in use.

End result. It looks pretty normal when the external controller isn’t in use.

Sidenote: The hacks that didn’t get done
While I had the unit open, there was also the remote possibility of fixing a few cringeworthy design flaws, I mean “features”, in the oven portion, which IS microprocessor-controlled. One is that the temperature display actively lies to you: as soon as the oven meets or exceeds your set temperature, it will lock the displayed “actual” temperature to this value regardless of any subsequent, including major, fluctuations in the actual temperature. This is probably done to hide the poor bang-bang thermal regulation from the customer, but can be very annoying if you’re furiously fanning the door to cool it off in a hurry, or need to lower the set temperature for any reason. The other one is that you cannot – I mean you are actively forbidden to – set an oven temperature lower than 175F (a temperature where bacteria cannot thrive). Doubtless this is the work of lawyers trying to stop stupid people from cooking up Montezuma’s Revenge casseroles, but tough noogies if you wanted to dry some herbs or keep some bread warm.

As an embedded programmer by day, I figure oven firmware should be simple enough that this could be a short afternoon reverse engineering, right? Alas, the microcontroller turns out to be an obscure Renesas part with a rather obtuse-looking in-circuit programming protocol (not PIC, AVR or anything else I can easily borrow a programmer for and try to suck the firmware out). I decided I didn’t care enough to try implementing my own reader on the off chance the firmware was left unprotected.

Notes to myself: Lulzbot TAZ n00b guide

A work in progress…

Critical Specs:
Bed size / Build envelope: 298mm (X) * 275mm (Y) * 250mm (Z)
Nozzle diameter: 0.35mm (shipping default; others available)
Filament diameter: The TAZ’s extruder expects 3mm filament. However, not all off-the-shelf filament will be exactly this diameter; the discrepancy could affect print quality in severe cases (see notes later).

The Parts:

-RAMBo – all-in-one Arduino-compatible controller + stepper/heater/etc. driver board (all-in-one variant of RAMPS)
–Marlin – firmware used by RAMPS/RAMBo boards
-Extruder (motor/gearing for filament control, plus hot end)
–Hot End (nozzle, barrel and heater): Budaschnozzle

PC Software:
For open-source 3D printers, this comes typically in 2 parts: a printer interface program and a slicing program. The slicer converts STL to G-code, and the interface is what actually drives the printer (usually includes homing, viewing/adjusting temperatures, and sending the generated G-code to the printer).

Printer controller / interface: TAZ ships with Pronterface, but others are available.

Slicer: TAZ ships with the aptly-named Slic3r, but again, others are available.

Common Problems

Printer “shriek” followed by severe height problems when printing (head crashing into bed or printing in midair) – This is the ONE issue that gave me the most grief. The issue in brief is that the TAZ’s Z-axis (2-motor gantry on high-friction leadscrews) must be driven quite slowly compared to the other two axes, or else the motors will stall. However, most slicers (including the Slic3r configuration that comes with the printer) insist on moving every axis at the maximum possible speed for all non-printing moves (and often even printing moves). In general, this is accomplished by generating G-code specifying arbitrarily high feedrates (F999999 or whatever) and expecting the firmware to limit these moves to a sane speed. For some reason, these limiting values are either missing or incorrectly set on the printer firmware end, so the Z axis motors stall when performing the initial home-raise-position-lower move at the beginning of the print. This results in a number of highly irritating problems such as printing in midair (if it stalls more during the lowering portion), or the nozzle dragging across the bed and shredding the crap out of any films/coatings thereupon (stalled more/entirely during the raise portion), or putting the entire gantry out of whack (if the motors on either side stalled by different amounts – have fun with this one!).

Some more discussion of this issue at .

To fix it: At the time of this writing (10/2013), you have to rebuild and reflash the firmware after tweaking some settings. In brief: Download the appropriate firmware sourcecode for your printer here, along with the Arduino IDE from the same page (they specifically endorse and host v. 1.01, but any recent version should in theory work). Oh yeah, and for you Windoze users, some kind of tool for opening .bzip2 archives. I recommend 7-Zip. (Great utility, but be wary of fake/spam download links from their file host when downloading…) Unzip the firmware files, go into the configuration.h file and uncomment the //#define EEPROM_SETTINGS and //#define EEPROM_CHITCHAT lines. This will let you set maximum speeds using an M code (to be explained later). While you’re in there, may as well sane up the default values too. Scroll up and lower the Z value for DEFAULT_MAX_FEEDRATE (the values are X, Y, Z and Extruder, respectively). The default is 10, which for my printer is too fast. On mine, a value of 5 was slow enough but excited some nasty resonance that caused the whole printer to buzz angrily. In the end I ended up with 4.2, which provided much smoother operation. (YMMV of course.)

Open the Arduino IDE, and from there open “marlin.ino” in the firmware files. Set the board as “Arduino Mega 2560” (Tools -> Board) and the serial port used by your printer (Tools -> Serial Port), press the Upload button and cross your fingers.

Assuming everything worked, you can now use M commands to set speed limits for each axis. Use:

M203 X### Y### Z### E###

to set speeds, and M503 to display the current values (if EEPROM_CHITCHAT is enabled). You can add this code to your slicer’s startup routine to ensure the speeds are not overridden by other users or software settings (most slicers have a place to add custom G-code before and after the slicer output.)

NOTE: Pay careful attention to expected units. The M command expects (by default?) values in mm/min., whereas if you set a default in the firmware as above, this value is expected in mm/sec. Particularly braindead slicers and/or host software might even set your machine into Imperial mode, blech.

Print does not stick to bed / breaks loose – Very common, and semi-related to the curling issue below. The big thing to check is the nozzle height when printing the first layer. It should be basically touching, smooshing the initial layer down nice and flat. The output should not look like a round bead of toothpaste being squeezed out of a tube. Check bed leveling, Z screw and repeatability, etc. Next things are to play around with the bed temperature and possibly extrusion temperature. Ensure the bed is fully up to temp before printing. For parts with low bed contact area or small protrusions that get caught and lifted, you can try various software-generated adulterations (raft or brim) to help with adhesion. These are typically autogenerated by the slicer program at your command. A raft is a solid-fill first layer covering typically a bounding box around the footprint of the print, followed by a sparse layer that allows for breaking the raft off afterward. A brim is a widening of all features on the first layer (as if your print were a bit melty and thrown at the bed with some force) to increase the surface area and move any “peel point” away from your actual part geometry. Brims are good to help stick down thin features that are prone to being lifted during the early print passes. After removal, the thin brim can be easily cut off with an X-Acto knife.

UPDATE: I tried the “lulzjuice” (acetone glue) trick, and it seems to work beautifully – completely solved my adhesion problems! Basically, for printing ABS, dissolve a bit of filament in some acetone, and wipe/brush a thin layer onto the buildplate before printing. Acetone has a low boiling point, so if you have a heated buildplate, do this *before* heating it up to avoid a bubbly mess. The flip side is that unsticking the print (intentionally) can be a little harder – if all else fails, try hitting it with coldspray (or an inverted can of computer duster).

Edges of print peel / curl away from bed while printing – Caused by a combination of poor adhesion to the bed and changing temperature. Check all of the stuff for the previous problem, then see what you can do about controlling the rate of cooling (overall or between layers). Try lowering the extruder temp slightly or raising the bed temp(?), dealing with any sources of cold breezes (enclosing the build area if necessary), or fiddling with software-based thermal controls (delays between layers, etc.).

Fat, floppy, and/or blobby print (edges extending beyond where they “should have been”) – Often a side-effect of the edges peeling upward and pushing the outer surfaces up toward the nozzle (the excess material has nowhere to go but outward…). If there is no peeling problem, most likely too much material is being extruded. See “Filament Diameter Problems” below…

Filament Diameter Problems – Use good, red-handled calipers to measure the filament diameter in several places – it may be a bit fatter or thinner than the nominal dimension, especially extra-cheap or noname-brand stuff. A fraction of a mm difference may not sound like much, but considering that’s being squeezed down from, say, 3mm to 0.35mm, it can become significant! Most slicers have a means for compensating for the filament diameter.

Popping sounds from extruder during print – Trapped humidity in filament (think popcorn) – try gentyl baking or storing in a drybag when not used for extended periods.

Trouble bridging – The extruded filament should be getting “pulled” slightly during print; not “pushed” (i.e. travel rate should slightly exceed the extrusion rate). See “Filament Diameter Problems” or related compensations offered by your slicer.

Hole diameters in printed parts – plastic may “squish out” a bit during extrusion, causing your hole diameters to be slightly narrower than expected. Assuming the amount of extrusion is actually correct (see several of the above), I’ve heard of folks compensating with an Excel table of expected vs. achieved hole size (it might calculate this) – don’t know where to get this though.

Tim Tears It Apart: Sensitech TempTale4(R) data logger

One of these devices appeared in a large shipment of temperature-sensitive raw materials at my work, amid a pile of dry ice chips. While I don’t know the MSRP or actual retail price of this gadget, the shipper packs one in with every order and tacks on $60-70 for it as a line-item; nonreturnable as far as I know.

So, we can’t return it and we can’t read it out, so what do we do?

I think you know what we do :p

TempTale4 Front Panel

TempTale4 Front Panel

The device is aimed at exactly this application – telling if your temperature-sensitive stuff stayed within a defined temperature band during all phases of shipping and handling. With timestamps, you could probably tell exactly which party in the shipment chain screwed the pooch. There is a fancy term for this kind of tracking – cold chain certification.

As far as interfaces go, it doesn’t get much more simple. A button to start logging, a button to stop logging, a simple LCD display, and a couple blanks to enter a shipper’s name and the PO# of the shipment. The current temperature and recording status (started / stopped) is displayed on the LCD. If the temperature went outside the allowed band while recording, an alarm symbol (bell) also appears. A pair of LEDs exposed through the front panel allow the device to be configured and recorded data to be read out to a PC via an optical doohicky (more on this later).

TempTale4 rear cover removed, showing the plastic 'cage' that holds the battery pack in place

TempTale4 rear cover removed, showing the plastic ‘cage’ that holds the battery pack in place

The enclosure is a basic 2-piece sandwich, with the half-thickness (.031″) PCB fixed into the front by 3 screws. A separate plastic ‘cage’ holds the battery pack in place; fingers on the backside clip around the edges of the PCB. The entire weight of the battery pack – and impact loads it imparts during rough shipping – are borne solely by the PCB and ultimately those 3 screw points. They might not anticipate extremely rough shipping for cold-chain cargoes (although a broken logger could be spun as a rough-shipping-detection “feature”).

On the plus side, note the O-ring ensuring a water-resistant seal between the case halves. Any other case openings are covered by the front overlay “sticker”, eliminating any fluid intrusion paths.

Battery cage removed

Battery cage removed

Battery pack removed. That piece of double-stick tape really ties the room together.

Battery pack removed. That piece of double-stick tape really ties the room together.

The battery pack is Zip-tied to the plastic “cage”, although not to the PCB or any part of the case. A piece of foamy double-stick tape helps hold and cushion the battery pack where it sits against the PCB. This and the overlay sticker on the front suggest this device is intended for enforcing low temperatures. High-temperature overlays and even double-stick tape exist, but it’s pretty fancy stuff. This tape isn’t fancy.

The battery pack consists of two series-connected Tadiran lithium primary cells (AA size), with a nominal 7.2V output. Now, in an industry that is constantly pushing toward ever lower voltages to reduce power consumption, this is weird! Especially for a gadget that needs to go a long time without a battery change. A single 3.6V cell will easily power a 1.8-3.3V device, and maintain this output voltage until nearly depleted. Some wild guesses at the reason behind the unusually high voltage:

1) High-current operation at very low temperatures. This shouldn’t be an issue during normal operation (just datalogging should use very little current on average), but if someone wanted to read it out over the optical interface in the Arctic, it may be another story. This may provide extra headroom against the inevitable cold-battery voltage sags that would occur as the transmit LED fires.

2) Voltage-happy LCD? Some LCDs require a higher voltage such as this to operate (usually generated by an onboard charge pump circuit), but these are typically graphical matrix LCDs (many independent rows/columns) – the rows/cols are typically energized one at a time, and to refresh the entire display faster than the eye can perceive flicker, each one is on for only a very short time – higher voltages help them reach their final dark/light state within that time and retain it until the next refresh. I can’t imagine this little segment LCD having such a requirement.

3) They needed 2 batteries to get the milliamp-hours up regadless, and wiring them in series was easier/cheaper (no worries about cell balancing). This is not an ideal way to get more mAh (increasing resistive losses in the series-connected pair, and conversion losses in any regulator, especially linear/LDO), but I suppose it works well-enough, and the price is right.

Bottom side of PCB exposed

Bottom side of PCB exposed

With the battery pack out of the way, we can see the bottom side of the PCB. Not much there! A couple things to note though:

1) A secret button hidden inside the device. As it turns out, this button resets/clears the device for reuse. The entire LCD will blink every segment for a couple minutes, then the device is factory-fresh again (probably).

2) No components apart from the secret button, but a fair number of empty pads (non-stuffed components).

PCB removed - rear of LCD accessible

PCB removed – rear of LCD accessible

Top of PCB. Notable points incude "secret" magnetic switch, accessible programming header, and an overall dearth of actual components.

Top of PCB. Notable points incude “secret” magnetic switch, accessible programming header, and an overall dearth of actual components.

Finally, we get to the topside of the PCB, the actual meat of the device! Erm, wait a minute, where’s all the meat?

The $70 pricetag notwithstanding, it should be becoming clear that this device is cheap-cheap-cheap to make. The bill of materials consists mainly of a few pushbuttons, a small handful of discretes and a glob-top MCU/ASIC. The segment LCD and an EEPROM in the top-left of the photo (a note on the manufacturer’s web site says it could be 2KB or even a whopping 16KB of storage) complete the ensemble. I have to snicker a bit about that after testing a 32GByte uSD card in my own day-job datalogger design the same day, but again, this device is designed to be throwaway cheap, and 640k (ahem, 16k) ought to be enough for anybody – for temperature data, anyway. (The astute reader will see “32K” stamped on the chip; either a clever misdirection or these loggers have grown more spacious than the web site lets on.)

Some notable points:

1) The temperature sensing element appears to be a simple RTD – no thermocouple or even brand-name digital sensor, but probably accurate enough.

2) The glass tube designated S3 is a magnetic reed switch. This almost certainly is used to trigger entry into the download/configure mode, either with a magnetic wand or a magnet built into a monolithic reader device that aligns to the LEDs.

3) The LCD is affixed to the top shell, not the PCB, and contact is made by an elastomer strip (zebra strip). Don’t lose this!

4) The neat row of capacitors at the bottom of the photo (C2, C3, C10 ~ 13) are probably part of a charge pump circuit for the LCD. There goes that theory about the battery voltage.

5) As with the bottom side, note the prevalence of non-stuffed component pads. Aside from a good handful of discretes, there are spots that appear to accept a second RTD temperature sensor and a humidity sensor. Most likely, this same board and ASIC become the “TempTale4 Humidity” with the addition of these components.

6) Besides the holes for extra sensors, pay particular attention to the two – two! – sets of non-stuffed headers (J1, J2). The latter pins directly into the globtop, suggesting the likely possibility of an in-circuit programming header (or even JTAG, holiest of holy grails).

See-thru view of front case, showing button flexures and a small opening in the plastic to bring the temperature sensor closer to the outside environment.

See-thru view of front case, showing button flexures and a small opening in the plastic to bring the temperature sensor closer to the outside environment.

In this final photo, you can see the shell cutouts as they relate to the overlay sticker. The temperature sensor normally sits in the small notch in the middle, leaving only the thin bit of sticker between the sensor and the outside environment.

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.


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.)


$ 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
Characteristic value/descriptor: 00 18

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. 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.


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

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

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.

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” 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!