As mentioned in my previous post, noise from the ADXL335 accelerometer readings result in flickering light. And I don't want that.
(Read the entire post to see chart comparisons of the two filtering methods.)
I got the PCBs yesterday and promptly set about assembling one. The really interesting part of that, of course, was whether it was possible to hand-solder the LFCSP ADXL335 accelerometer ("lead frame chip scale package" – who comes up with these names?).
It turned out it was, in fact, possible. The bottom pad is not soldered, of course, and even though I had made the pads longer to be able to reach them with the soldering iron it was still kinda tricky. But it worked. In first attempt, even.
And the little tumbler thingie works perfectly! (I'll post a video.)
But I need to tweak the firmware a bit. The sensor data from the accelerometer has quite a bit of noise and this results in too flickering light. So I will need to implement a filter of some sort. Either a moving-average filter or a simple low-pass filter. And maybe also some way of "snapping" to 0, 0.5 and 1 values in order to get more "clean" colors. Stay tuned…
"Information wants to be free," as we said back in the day when I was young and naïve
and needed the money and a wannabe-hacker... Now, of course, we say, "open-source everything".
So here they are:
Eagle schematic and board files for the RGB Tumbler
Firmware source code
The PBCs have only undergone minor revisions and Gerber files have now been sent off to ITead Studio for fabrication.
Here's a 3D rendering of both sides of the PCB (yes, several of the components were unknown to Eagle3D and I didn't bother creating custom parts). Also, the largs pads for the RGB LED are actually mostly covered by soldermask:
First version of the PCB for the RGB Tumbler is ready. Although usually I do through a couple of revisions before I send it off and get it made.
The PCB ended up somewhat larger that I had originally planned. It is currently 3.6 x 3.6 mm.
Here are pictures of the PCB printed in 1:1 scale and populated with components to verify that everything fits (click for larger images):
I need to move the slide switch a bit up to make room for the 10 µF capacitor. And I will also move the battery holder up a little bit. The NCP1402 voltage booster almost touches it. Apart from that, everything looks pretty good.
Another problem is that I ended up placing several vias directly under thethe battery. This may not be the best thing. Especially since the vias on ITead's PCBs (ITead Studio is where I get my PCBs made) are not always completely covered (even though the Gerber files say they should be covered). I guess I'll just have to cover the vias myself with some tape or something).
Here's the prototype of the RGB Tumbler in all its glory – click to see hi-res image:
The prototype has been assembled and the first version of the firmware (including the no-button, Gauss-Newton calibration) is done. The calibration routine has been converted from Rolfe Schmidt's Arduino sketch to raw AVR Libc.
Here's a video of the prototype being put into calibration mode, calibrated and then turned on in normal mode.
The camera doesn't do the RGB LED credit and the colors aren't reproduced very well – probably because of the high intensity of the LED.
And I have changed the colors a bit since the last few posts. So now a white light on power-on means "if you switch off now the device will go into calibration mode on next power-up". And the blue flashing LED means "switch to next orientation and hold the sensor still". After a reading it will flash twice either green (meaning "reading ok") or red (meaning "bad reading – hold it still, man") and lastly it will keep flashing green meaning "calibration done – cycle power".
When in normal mode, the G readings on each axis are clamped to 0-1 (I'm using the absolute value, so -1 G is the same as +1 G). This is then converted to a PWM duty cycle between 0% and 100%.
Red is the X-axis, green is Y and blue is Z. That's why it lights a solid blue when lying flat on the table: the only acceleration is 1 G on the Z-axis.
As I explained in my last post I need to include an accelerometer calibration routine in the RGB Tumbler. But I don't want to add one or two buttons – it would take up way too much space on the PCB.
So I thought about how I could choose between "normal mode" and "calibration mode" without a keeping a button pressed on power-up and I came up with this:
On power-up, the MCU checks an EEPROM variable to see if it should go into calibration mode. If this variable is not set, the MCU sets the variable, waits one second and then clears the variable again. This means that if the user quickly (within one second) turns the device on and then immediately off, the EEPROM variable is set (because the MCU never gets to clear it before being turned off) and the next power-up will put the device into calibration mode.
For the calibration itself I will rely on delays instead of pushing a button on indicate that the device is in a new position (we need six positions for calibration). So I will flash the LED for a couple of seconds (four) and then take a reading and then repeat the process five more times. So when the LED flashes rapidly the user must change the device orientation and hold it still.
After all six readings have been taken the black magic-based calculations will be done (Gauss-Newton-based, actually but for me it amounts to the same thing) and the resulting calibration values will be stored in the EEPROM.
If this didn't make sense, then read the rest of the post to see flow charts attempting to explain the same thing.
Read the entire post »
I received a bunch of stuff yesterday – including the ADXL335 breakout board and immediately wired it up to see what kind of output I got. Everything worked nicely except the voltage on the X-axis was nearly 300 mV different from the Y-axis (!) when the accelerometer was lying flat on the table (and thus being subjected to 0 G on both X and Y). The Y- and Z-axes looked ok. Weird. And frustrating. Everything I've read about the ADXL335 (including the datasheet) led me to believe that at 0 G, the voltages on all three axes should be pretty much the same.
Anyway, after lots of Googling and scratching my head, I finally stumbled upon Rolfe Schmidt's blog where he has a lot of information about ADXL335 calibration. I don't pretend to understand the math behind Gauss-Newton algorithms but it worked perfectly!
The calibration values I got did indeed suggest that the X and Y axes were horribly miscalibrated. Maybe this particular unit is damaged – who knows. But I'll be sure to include a calibration routine in the MCU software.
Since the RGB Tumbler will be running off a single coin cell I will need to make sure the ATmega microprocessor doesn't use a single microamp more than necessary. And there are several ways of doing that.
Firstly, let's switch off all peripherals that we won't be using. The "Power Reduction Register", or PRR, is the place for that (refer to section 9.11.3 of the datasheet). And also ACSR for disabling the analog comperator:
Read the entire post »
Whenever we're dealing with more than a few miliamps we need to consider power dissipation. And for the LED Driver for the RGB Tumbler project I'm using three 50 mA LEDs connected to a SOIC-16 LED driver. That's at least 150 mA through a fairly small IC so let's look at the numbers.
The problem is always the temperature at the "junction" inside the IC. If this is too high, the IC will stop working. If it is much too high it will melt, burn or explode. And in most cases that is less than desirable.
Read the entire post »
This is what my parts search has yielded so far:
The MCU, LED driver and accelerometer will be powered directly from a 3V coin cell. But for the blue and green LEDs, 3 volts is just not enough since the LEDs require 3.2V forward voltage and the LED driver requires a further 0.4V for the current regulator. So about 4V would be perfect. I've used the NCP1400 DC-DC converter before but it provides only 100 mA and since each LED draws 50 mA I will need more than that. The NCP1402, however, provides up to 200 mA. And even though it exists in a 4.0V version I've been unable to find that in stock anywhere so I'll probably go with a 5V version instead.
Note that with 5V I can't run multiple LEDs in series so I'll either have to make do with a single LED or use parallel LEDs.
This one looks nice: Optek OVSTRGBB1CR8. It's an RGB LED with 50 mA per LED in a PLCC6 package. PLCC are pretty easy to hand-solder even though the leads are bent in under the device. Flux and a tinned tip will do the trick. And it has a generous 2.1 mm pitch.
I use AVR MCUs because that's what I'm familiar with. I will need three PWM channels and three A/D channels. This AVR Quick Reference gives a good overview of the features of the various ATtiny, mega and Xmega devices.
The ATtiny's have either not enough PWM or A/D channels or not enough pins to utilize both PWM and A/D at the same time or they only come in SOIC-14 packages (too big) or QFN-20 (don't wanna). The ATmega168 and -328 however have enough PWM and A/D channels and plenty pins to use both at the same time and come in a TQFP-32 package. And I already have a couple of TQFP '328s laying around so an ATmega 328P-AU it is.
This one was tricky. First off: do I even need an LED driver? Driving the LEDs directly from the MCU ports is not possible because the MCU cannot supply enough current for three 50 mA LEDs (and the MCU is running at too low a voltage in this case). I could have the MCU drive MOSFETs and use current-limiting resistors. But that would waste too much power in the resistors and the whole thing would eat up quite a bit of PCB real estate. So yes: I need a driver.
I spent several hours looking at and dismissing LED drivers because they were BGA or LGA package only or they were for low-current LEDs only (10 or 25 mA) or they had no current regulation at all. This one looked promising: ON Semi NCP5623. It's an I2C controlled three channel 175 mA controller in a TSSOP package. I don't even need to use PWM from the MCU. However, I only found it at Digi-Key where it was "non-stocked" with a minimum quantity of 2500 pcs. I don't think so.
I finally settled on this one: On Semi CAT4109. It doesn't inlcude PWM controller so the MCU will have to do the PWM'ing. Also it needs three resistors instead of only one for setting the current and it exists only in a SOIC-16 package which is kinda bulky. But it will have to do.
For the last critical part I settled on an Analog Devices ADXL335. It is +/- 3G with three analog outputs. The only problem is that it is in a LFCSP-16 package which is intended for reflow soldering only. It may have visible connections on the side of the package. I hope it does because then it should be possible to hand-solder it. I will make sure the pads extend 0.5 to 1 mm beyond the case itself so I can flux-and-tinned-tip solder it. I'll keep my fingers crossed and we'll see. Note that the chip has a pad on the bottom (which is impossible to hand-solder) but according to the datasheet, the "exposed pad is not internally connected but should be soldered for mechanical integrity". Which means that I should be able to get away with not soldering it.
For a new project I thought I'd like to do some RGB LED stuff. And I got the idea of making a small circuit (small enough to be put inside a ping-pong ball) that controlled one (or more) RGB LEDs from its physical orientation. Simply put, acceleration on the X, Y and Z axes would translate to intensity of the red, green and blue LED. And since there is always an acceleration of 1G towards the center of the Earth (also known as "gravity"), the color of the RGB LED would depend on its orientation.
So the system will comprise the following "blocks":
- 3 axis accelerometer
- LED driver. Or maybe the LEDs can be controlled directly from the MCU.
- RGB LED. One or two.
When looking for parts there's a few things to keep in mind:
- Size matters. It must be as small as possible. I only recently started working with SMD components but already I can't imagine having to deal with those clunky, Soviet tractor-like through-hole components. But I still haven't gone all the way into reflow soldering. So I'm looking for primarily SOIC, TSSOP and TQFP packages. QFN packages are actually possible to hand-solder but it's not fun at all and LGA and BGA are pretty much impossible. For many-pin devices, SOIC is actually kinda big with their huge 1.27 mm pitch and 0.5 mm pitch TSSOP would be preferable.
- Power. As little as possible. I plan on running everything off a single 3V coin cell so voltage should be 2.7 to 3 volts and amps should be as few as at all possible.
- Availability. I much prefer to be able to get everything from one, local provider.
So off to the intertubes for some Googling…