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…
Ok. Everything has been assembled and mounted. I mounted the control unit inside the stock. Power comes from the gun battery. The wires from the photo interrupter to the control unit run inside the handguard and upper receiver. I have drilled through the aluminium endblocks of the handguard and I'm using three pin RC servo type plugs and sockets to connect the silencer with the IR photo transistor and LED to the gun (I need to unplug it in order to unscrew it) and also inside the stock so I can easily disassemble the gun.
And it works pretty darn good, actually!
I have received the PCBs and assembled the first one. Everything expect connections to external components, that is.
Here's a picture. It looks pretty much like the rendering. And I know: some of the soldering joints could have been made better but bear in mind that this is my first SMD soldering attempt so I'm actually pretty pleased with the result.
Here is a 3D model of the board created with Eagle3D (here's a tutorial and here's some information about getting it to work on Mac OS X):
Pretty much at least. I've added an EEPROM variable for storing the magazine capacity and I've added support for programming the magazine capacity and for resetting the rounds remaining counter without turning off the entire device.
The device can be in two modes: run and program. Run is the normal count-down-when-a-round-is-fired mode and the PRG/RST button will reset the counter (for when you put in a fresh magazine).
To enter program mode, press the PRG/RST switch while powering on the device. The display will show "PrG" for a second (as opposed to "run" in run mode) and then the counter will show 000. Pressing the PRG/RST button will increase the counter which is the magazine capacity. If the PRG/RST button is held down for a second, the counter will increase quickly. The capacity is saved in EEPROM every time is it increased so simply turn off and back on the device to use the new capacity.
Download the code here: firmware_rev2
Points of note:
- Both the photo interrupter and the reset switch work as external interrupts (INT0 and INT1, respectively)
- In programming mode, a 1 second timer compare match interrupt is used for hold-to-count-quickly
- Magazine capacity is stored in EEPROM
Schematic and layout revised again. I added the 10 µF capacitor (that really ought to be there) and a LED with accompanying resistor for debugging purposes.
Here a print-it-out-and-see-if-it-fits test. And it does fit. Note that all the resistors are the same value (doesn't matter of course since all 1206 resistors are the same size) and that I've placed a 1206 resistor instead of a 1206 LED. Also, the B sized 10 µF capacitor isn't placed on the printout but it shouldn't pose any problems.
And a new and revised schematic for the Airsoft Rounds Counter. The only difference is that the photo interrupter's collector wire is now connected to the ATTiny's INT0 pin.
Update: obviously I mean "to digit cathodes" and "to segment anodes" – not the other way around.
Oops. The photo interrupter's collector wire wasn't connected to INT0 on the ATTiny. That has been fixed now. Also, the board is now 1 mm wider so there is enough clearing from the segment A wirepad to the edge of the board.
And the VCC and GND traces are now 24 mils and all other traces are 12 mils wide. Refer to the first layout if you can't remember what the various wirepads are for.
Here are a couple of pictures of the breadboard setup:
The first picture is of the breadboard itself. The components are marked and the green dots are where the wires from the photointerrupter go.
The second pictures includes the photo interrupter mounted to the barrel using duct tape (what else). Note that this was before the Max7219 and display was mounted:
Here's the first draft of an SMD PCB layout for the Airsoft Rounds Counter project.
The wire pads are as follows:
9V power input
- AN, CA
Anode and cathode the the photo interrupter LED
- CO, EM
Collector and emitter for the photo interrupter transistor
- A-G, DP
Segment anodes on the display
Digit cathodes on the display
- RST/PRG SW
Reset and program tact switch
Actual size is 49.53 x 20.32 mm.
Here is version 1 of the firmware for the Airsoft Rounds Counter project. The code uses avr-gcc but should be real easy to port if you use a different compiler.
This firmware is by no means the final version. Rather, it is the firmware for the breadboarded version (the schematic is here).
The ZIP archive contains three files:
Contains all the code. Please note that the code assumes that a LED is connected to PB4 which is not shown in the schematic. This is purely for debugging purposes and you can add the LED or not. The code doesn't care. And neither do I.
Header file with definitions for the various Max7219 commands.
Standard makefile. Do a 'make all' to compile, 'make fuse' to set fuses (they are set to internal 8 MHz RC oscillator with slow startup, no BOD, SPI enabled), 'make flash' to flash the ATTiny and 'make clean' to delete the binaries.
Download the ZIP archive here: firmware.zip
I have the first prototype of the Airsoft Rounds Counter up and running on a breadboard.
Here is the schematic. A couple of notes:
- A 10 µF capacitor or so near the power supply certainly wouldn't hurt. Neither would a diode on the input side of the 7805.
- The "program and reset" switch doesn't do anything with the current code and can be omitted for this version.
- On the breadboard I also have a tact switch from the ATTiny's RESET pin to ground so I can reset the counter.
- I'm using a 9V battery for power.
Browsing around on AVRfreaks' forum I stumbled upon this thread about an Airsoft Round Counter to display the number of remaining rounds when playing airsoft. This is obviously a cool idea and the thread inspired me to want to make one myself.
In the thread people discussed using everything from a simple switch attached to the trigger over photo interrupters and photo reflectors to accelerometers for detecting when a shot is fired. There is also a link to this page on the Design Decisions Wiki where a group of people have designed an "Airsoft Electronic Ammunition Counter" with detailed design considerations and requirement analysis and timing calculations. Excellent work and a great source of inspiration for this project.
My initial considerations for this project:
- Enclosure. Everything should be mounted to an airsoft gun and it shouldn't be the size of a shoe box!
- Component count. This ties in with number 1 above: if this is to be small enough to be portable I have to keep the component count down so the final PCB is of a manageable size. (Yeah yeah, "use SMD". Right, I'll do that in phase 2.)
- Ease of use. This will be used in skirmishes so it should be real easy to use. No re-flashing of the processor to change settings, easy to attach to a weapon and so on.
So far I have settled on the following basic components:
- ATTiny 2313-20PU. I could probably get by with a smaller ATTiny but since I already had a couple of these lying around I went with those...
- Four-digit 7 segment display
- Maxim 7219 CNG display driver.
- Wide-gap photo interrupter
Off to EAGLE for some schematic drawing and thence to the breadboard for figuring out how photo interrupters actually work...
I just found out I forgot to post this article about choosing the right MOSFET for the autogun project. Here it is:
When switching on the gun, we're passing a significant amount of current through the MOSFET.
As shown on the power test tables in this posting, we should expect a peak of 50 Amps and a sustained current of about 20 Amps.
So the MOSFET should be able to handle at least 15V and 60A. And since we are turning on the MOSFET from the MCU control circuitry at 5V the gate threshold should be low enough for the MOSFET to turn fully on at 5V. In practice this means a logic-level MOSFET.
The datasheets of MOSFETs will list a whole bucketful of specifications. Some of the important ones are:
|VDSS||maximum drain-source voltage. In my case, it should be at least 15V|
|ID||maximum drain current. In my case, it should be at least 60A to be safe. (Although the *sustained* current will only be 20A.)
Be careful with this one. Often it will be specified as one value "silicon-limited" and another - lower one - as "package-limited". This means the chip itself can handle a high current but the casing might melt or burst into flames. Which is bad. So use the lower one.
Also, it might be specified as one value "@ 25 °C" and another - again, lower - "@ 110 °C". Again, use the lower one since it is highly unlikely that the MOSFET will be at 25 °C when we are pulling 20A through it.
|PD||maximum power dissipated in the MOSFET. This is calculated as RDS(on) * I^2.|
|VGS(th)||gate threshold voltage. This is a measure of how much voltage on the gate is required to turn the MOSFET on. As mentioned, since we're dealing with logic-level voltages, it should be no more than 2.5V|
|RDS(on)||drain-source resistance when fully on. This will determine how much power is dissipated in the MOSFET's junction.
Since all the power dissipated in the MOSFET junction is converted into heat we need to check how fast we can get rid of that heat. Otherwise, the MOSFET will heat up and eventually break. And possibly (albeit not likely) melt and/or burst spectacularly into flames. Therefore, we will also take a good, long look at the following:
|RΘJ-A||thermal resistance between junction and ambient. This is a measure of how much power can be dissipated as heat from the junction to the surrounding air without any help.|
|RΘJ-C||thermal resistance between junction and case. We might need this if we need a heatsink. In that case we need to add this with the thermal resistance of the heatsink (RΘHS) and check if we are below the max allowable thermal resistance.|
|TJ||maximum operating temperature for the junction. We need this to check if enough heat is dissipated.|
Browsing through dozens of MOSFETs, this one looked promising: IRL1404PbF. It is listed as a "N-LogL 40V 160A 200W 0,004R TO220AB" MOSFET.
(Which means "N-channel, logic-level, VDSS=40V, ID=160A, PD=200W, RDS(on)=0,004Ω in a TO-220 package".)
It looks good because:
- it is logic-level activated
- it can handle 15V
- it can handle 60A
- it has a low RDS(on) which means that the PD will be low (PD = RDS(on) * I^2 = 0,004Ω * 20A^2 = 1,6W) which means that we just might be able to get by without a heatsink
To check if we can dissipate the heat fast enough, we need to calculate how hot the junction becomes under load by using the following formula (Tamb is the max operating ambient temperature. in Denmark the temperature is never above 35 so that should be a safe value):
Tj = PD * RΘJ-A + Tamb = RDS(on) * I^2 * RΘJ-A + Tamb = 0,004Ω * 20A^2 * RΘJ-A + Tamb = 1.6W * 62 °C/W + 35 °C = 99,2 °C + 35 °C = 134,2 °C
The result is below the specified 175 °C.
(If, however, we were to run 25A continous current through, we would end up with a junction temp of 190 °C (do the math yourself) which is too high.)
As you can see the current rating for a MOSFET should be taken with a grain of sand. The IRL1404 MOSFET is rated to 160A. But without a heatsink it can't even handle 25A continously.
Bonus reading: choosing a heatsink
If we ended up with a too high temperature, we would need to mount a heatsink to the MOSFET in order to lower the thermal resistance.
In that case, instead of using RΘJ-A for thermal resistance, which is junction-to-ambient air resistance, we would use the combined thermal resistance by adding the following:
|RΘJ-C||junction-to-casing (0,75 °C/W for the IRL1404)|
|RΘC-S||casing-to-heatsink (0,5 °C/W for a "flat, greased surface" and typically between 0,5 and 1,5 depending on whether you use thermal grease, mica or bolt it directly on)|
|RΘHS||heatsink-to-ambient (depending on the heatsink)|
We can calculate the maximum thermal resistance that will dissipate the heat from the junction fast enough by using the above formula (transposed a bit):
maxRΘJ-A = (Tj-Tamb)/PD = (175-35)/PD = 140°C / RDS(on)*ID^2 = 140°C / 0,004Ω * 20 A ^2 = 140°C / 0,004Ω * 400 A^2 = 140°C / 1.6W = 87.5 °C/W
In this case the max thermal resistance of the junction-ambient without heatsink is lower than that (per the datasheet it is 62 °C/W) so we don't need a heatsink, but if we calculated it for a 25A sustained current we would end up with a max thermal resistance of 56 °C/W and since the j-c plus c-s is about 2 °C/W (if we don't use thermal grease) we would need a heatsink with a maximum RΘ of 54 °C/W. Like this little one here which has a thermal resistance at normal airflow (as opposed to "forced", i.e. fan ventilated) of 16,2 °C/W.
A lot about thermal resistance and heatsinks: http://www.jaycar.com.au/images_uploaded/heatsink.pdf
About choosing a MOSFET and explanation of the MOSFET's parameters: http://robots.freehostia.com/SpeedControl/MosfetBody.html
I needed to figure out exactly how much power the airsoft guns actually use. Voltage is pretty straightforward: the battery's nominal voltage is 11,1V so under load it will probably be a bit below that.
Current, however, is rather more difficult to measure. My multimeter is only good up to 10A and I expect higher current than that.
Luckily, I have data loggers on two of my remote controlled helicopters which are also electrically powered and run on 37V batteries up to 80A (yes, that is a lot) so they should be perfect.
So I went and connected the guns to one side of the data logger and the battery to the other, plugged in the USB lead, started the application and set it to live recording. Here are the results.
First the M110 gun:
And here the M130 gun:
The first shot draws significantly more current than the rest. This is seen clearly both when firing on semi-auto and on full-auto.
The M130 gun draws more current but not a lot more.
Based on these measurements I settled on a maximum current of 60A and a continous current of 20A.
This is the kind of data logger I use: Eagle Tree eLogger
What's the point of making robots if you can't mount lasers to them?
I am not making robots and I don't have any deadly lasers lying around. I do however play airsoft and I thought it would be neat to have a remote triggered, automatically firing gun which could be set up and left waiting for unsuspecting bad guys to wander into its line of fire.
Somehow, I settled on the following basic setup:
Two units: a sensor/transmitter and a receiver/trigger. The sensor would be placed where it can detect people that should be fired upon and the trigger unit will be connected to the gun.
Communication will be wireless using nRF24L01+ units, the sensor will be a passive infrared motion sensor (like the ones turning on the lights in the garage), gun will be triggered by a power MOSFET and both the sensor unit and trigger unit will be controlled by an ATmega168.
An Arduino will be used in the prototyping phase for testing the various components but the I will probably move over til plain C (avr-lib) at some point. Read the entire post »