Testing TI’s LaunchPad

TI LaunchPadEver since I read Hack a Day’s post on TI’s $4.30 LaunchPad development board, I’ve been itching to get my hands on one. So two weeks ago, while putting together a small DigiKey order, I checked to see if the LaunchPad was in stock. Lo and behold, it was. So of course I immediately added it to my order. This past week, my LaunchPad arrived.

I must say, what you get here for your four bucks and change is pretty impressive. The development board is USB powered and contains all the necessary hardware to program and debug MSP430 microcontrollers (MCUs) in up to 20-pin DIP packages. The kit includes two MCUs, the MSP430G2211 and the MSP430G2231. Both chips have 2kB of flash memory, 128B of RAM, and 10 GPIO pins, but the 2231 also provides a universal serial interface (I²C and SPI only), an 8-channel 10-bit ADC, as well as an internal temperature sensor. The board ships with the 2231 in place and programmed with a nifty temperature sensor program that’s ready to run.

The kit also includes two optional headers you can solder into the 0.1″ pitch breakout connectors on the left and right sides of the board. There’s even a 0.5m USB cable included! The only thing lacking is software, but who wants CDs anyway? Instead, TI offers two free (but limited) IDEs for download on their LaunchPad Wiki.

Now before I delve into my experiences with the LaunchPad, I should let you know that I’m very much a fan of Atmel’s AVR line of MCUs. I’ve been programming 8-bit ATTinys and ATMegas for about five years now and am quite satisfied with their performance. I’ve never touched another Texas Instruments MCU and have only had limited experience with PICs. So, just understand that this is where I’m coming from. I’ll also include a short comparison between the MSP430G2231 and the similar ATTiny24 at the end of this post.

The Project: Does Your Fridge’s Light Really Turn Off?

Ok, call my crazy, but the first thing I thought of when I found out the 2231 had a built-in temperature sensor was, “I wonder how cold my fridge is?” My second thought (having been running tests with a phototransistor last week) was, “I wonder if that light in the fridge actually turns off?” It’s a question I’m certain everyone has asked themselves at one point or another. Of course normal people might just test this by pressing the door switch, but not me (and yes, I know what that means). So here’s what I had in mind:Launchpad Fridge Test SetupI started by modifying the demo program provided with the launchpad to read two analog inputs: the temperature sensor and input A7. I then connected A7 to a phototransistor (which you can think of as a light-dependent resistor) wired in series with an adjustable resistance (a 500kΩ potentiometer) as shown here:

Phototransistor CircuitThe potentiometer is used the adjust the sensitivity of this circuit for varying lighting conditions. That extra 2.2uF capacitor isn’t strictly necessary, it just removes noise caused by EMI and flickering lights. So, I connected the UART TX pin from the LaunchPad to my SparkFun BlueSMiRF module (a nifty Bluetooth serial modem I picked up a couple of years back for a different project). Power for the entire setup is provided by a 9V battery run through a 3.3V DC-DC converter (see my previous post on regulator efficiency).

LaunchPad in FridgeWell there it is – the entire setup powered and running inside my refrigerator. The green light on the BlueSMiRF tells you it’s connected. But as you might imagine, with the fridge being a large metal box, Bluetooth reception was quite poor with the door closed. I had to put my laptop right up against the side of the fridge to get a good connection. But other than that difficulty, the system worked great. And of course, I built a small LabVIEW VI to plot and display temperature and light data on my laptop:

LabVIEW Data Graph (Arrow Indicates Door Closing)The graph on the top indicates temperature in Fahrenheit while the bottom graph plots phototransistor voltage versus time. The red arrow indicates the point at which I closed the fridge door. Now, voltage and light intensity are inversely related in this case. In other words, a low phototransistor voltage means high ambient light. A voltage of 1.5V indicates a total absence of light. So, since the voltage at the arrow jumps from almost zero to 1.5V, we can be confident that yes, the light inside the refrigerator did in fact turn off. Yay!

My Impressions of the LaunchPad

As I was working with the LaunchPad, I kept a few notes about my experience which I’d like to share here. The first thing I’ll mention is that TI is doing a great job keeping lots of useful information on their LaunchPad Wiki. I had no trouble finding the software and information I needed. Plus, they’re maintaining a Learning Community with links to many interesting LaunchPad projects. So good marks for TI there.

In looking through the available IDE options on the LaunchPad site, I decided to go with Code Composer Studio (CCS) because of its higher compiled code size limit (16kB vs 4kB for IAR) and because it’s produced by TI. I must say though, the download and installation of CCS took quite some time, even on my fairly modern T61p laptop, even with just the MSP430 components selected. However, the default layout of CCS suited me fine:

Code Composer StudioAs I mentioned, to develop the code for my fridge project, I started with TI’s demo application, then added and removed bits as needed. Before even touching the code however, I went through it line by line with the datasheet open next to me so that I could start to understand the MSP430 line a little better. I was slightly disappointed in the amount of commenting provided, given that this was a demo application. My feeling is that in demo code, just about every line should get a comment. Also, I noticed one or two comments that appeared to be incorrect (specifically, near the clock divider settings).

I was further impressed by the LaunchPad’s ability to perform debugging with hardware connected. This is something I’ve not done with the AVRs because I’ve never had the proper equipment, only a programmer. But with the LaunchPad, you can actually step through your code line by line and watch the results on your MCU. Very cool.

One thing that struck me as strange was the need to stop the watchdog timer at the start of every program (unless your program makes use of its default settings). It looks like the WDT defaults to a reset every 32768 cycles unless stopped or handled properly. This seems like something that could trip up even seasoned users every now and then.

Comparison Table

Finally, I’d like to show you a feature-by-feature comparison between the MSP430G2231 and the ATTiny24. I’ve selected the ATTiny24 because it provides exactly the same amount of RAM and flash memory as you get with the 2231:

Feature ATTiny24 MSP430G2231
Price $2.52 $2.17
Program Memory 2kB 2kB
RAM 128B 128B
EEPROM Size 128B 256B**
Max. Clock Rate 20Mhz (10Mhz*) 16Mhz
Max. I/O Available 12 pins (inc. reset) 10 pins
Voltage Range 2.7 – 5.5V (1.8 – 5.5V*) 1.8 – 3.6V
ADC 10-bit, 8ch 10-bit, 8ch
Internal Temperature Sensor? Yes Yes
ADC Sampling Rate 15ksps (at max res.) 200ksps
Timers 1x 8-bit, 1x 16-bit 1x 16-bit
Serial Interfaces I2C, SPI I2C, SPI
Architecture 8-bit 16-bit
Active Power @ 1Mhz 540µW* 484µW
Lowest Power Draw 0.18µW* 0.22µW

*Data for the slower, low-power ATTiny24V.
** This chip does not have EEPROM but instead uses flash “Information Memory” for permanent storage, 64B of which is for calibration data by default (this can be changed).

In the above table, I’ve used green to highlight better features, where it seems a clear distinction can be made. Now although the ATTiny24 truly can provide 12 I/O pins, I should note that this requires you to disable the reset pin (via fuse settings). So unless you have a high-voltage programmer available, the code on your chip will be permanent.

Well as best I can figure, these two chips are about equal in terms of hardware. It really comes down to your specific application. Do you need high ADC sampling rates? Then go with the MSP430. Do you need an extra timer? Then get the ATTiny24. Of course, there are other chips within each family that may provide a better match for you. Ultimately, I suspect most people will pick the chip they’re most familiar with. For me, it’s the AVR.

There’s one last cool feature I should mention about the LaunchPad before closing. It can be used program some of TI’s other MSP430 products like the Chronos watch module.

LaunchPad with Attached eZ430-RF2500 Target BoardIn closing, I’d say TI has done a great job with this board. I’ve certainly enjoyed toying with it. Plus, at $4.30 it will certainly help to grow the MSP430 user base. I’m looking forward to using it more in the future. Thanks for reading!

Project Files

Enter the XMOS

XMOS XC-2Funny how time flies. It seems like only yesterday I was scrambling around grabbing books, spec’ing parts, and testing components for my MS thesis. In fact it’s been almost a year since I wrapped up my design for a six-DOF laser-based position sensing system. But last September, I was busy pounding my head against a Xilinx Spartan-3AN FPGA development board (and given its numerous header pins, this wasn’t particularly pleasant).

What I needed was an easy way to run four independent 32-bit counters at 100+ Mhz, to communicate with eight discrete serial ADCs, to perform multiple floating-point calculations, and to return all of the resulting data to a control PC using a single high-speed serial line.

I was told, and still believe, that this should be no problem for an FPGA like the Spartan-3AN. Unfortunately, prior to this project, I had no experience with VHDL, Verilog, or anything having to do with FPGAs or CPLDs (besides the blessed CompactRIO). So needless to say, I was having all sorts of weird problems. I started off coding just a single counter in VHDL. It measured the time between digital interrupts and returned a value via a parallel interface. The only problem was that, at high frequencies (above 150Mhz), it would occasionally return bad data. Well, I could go on and on about my troubles with this FPGA, but I’ll cut to the chase. I was running out of time and needed a solution fast. So, I posted on SparkFun’s forum asking for recommendations. One of the guys suggested I look into XMOS. I’d never heard of it before and sortof dismissed the idea at first. I mean, a quad-core microprocessor? That didn’t sound very helpful. But given its ability to handle 10ns pin events and to run an almost unlimited number of counters at 100Mhz, I convinced my advisor to spend $150 on the XC-2:XMOS XC-2And boy am I glad I did. Once I got to writing code for the XMOS, I was an instant fan. Just take a look at the specifications for this powerful chip (the XS1-G4):

  • Four processor cores providing 1600MIPs (at 400Mhz) and up to 32 concurrent, deterministic real-time tasks.
  • Up to 64 input/output pins (per XCore) that can be dynamically configured as input, output or bi-directional.
  • Each port provides 10ns timing resolution for precise interfacing.
  • Next-cycle event servicing from pins, communications or timers.
  • The XMOS-originated XC language extends C to support parallelism and real-time control.
  • 64KBytes single-cycle unified SRAM (per XCore) for code and data storage.

This device was unlike anything I’d worked with in the past. And yet, I could code it in C or the C-like XC language (which supports parallel processing). This fact is what really set my mind at ease. The only slight issue was the lack of standard hardware modules you’d find in most microcontrollers; the XS1-G4 has no built-in hardware to transmit serial data, measure analog inputs, or generate PWM signals. But hey, neither do FPGAs. The plus here is that the XMOS has so much horsepower, you can implement anything in software.

The XC-2 development kit I received even came pre-programmed with a fancy web server demo application. All I had to do was plug it into the network, attach the supplied 5VDC power adapter, and point my browser to the correct address. And of course, the good folks at XMOS provided source code for the entire project, plus code for a generic Ethernet interface, digital audio transmission, UARTs, and more. I also found the XMOS support forums to be very helpful. I was actually able to explain my problem to the support staff and have them detail how it could be accomplished with this development board. Plus, there’s now the XCore Exchange community of users.

Now I imagine this is starting to sound like a paid endorsement of XMOS. But let me assure you, it’s not. I’m just a satisfied customer. The XC-2 helped me finish my thesis work much sooner than if I were to have stuck with the FPGA. In the end, my sensors were able resolve positional changes of less than 1mm in all directions.


So at $150, the XC-2 may be a little bit pricey for most hackers. However, if speed and power are what you’re looking for, you should seriously consider it. The single-core, $99 XK-1 module (pictured above) may also be worth looking into. Multiple XK-1s can also be linked together. I may pick one up myself if I find a good excuse. 🙂 Oh, and did I mention the development tools are free and unlimited? The package even includes a simulator so that you can try out your design without a device. You can download the tools for Windows, Mac, or Linux here. Have fun and let me know what you make!

So You Want to Use PWM, Eh?

PWM Waveform Captured on an OscilloscopePulse-width modulation. It probably sounds a little confusing if you’re new to electronics. Kindof a word mashup, really. What do pulses, width, and modulation have to do with each other anyway? I remember first learning about PWM during my freshman year of college at RPI. I was in a pilot course called “Foundations of Engineering” under the excellent instruction of Professor Kevin Craig (whom I later worked for). I remember thinking later, “Hey, this PWM stuff is pretty clever!” So let’s take a look at PWM and see what we can learn. (If you’re already familiar with the basics of PWM, skip down a few paragraphs for more advanced topics and experiments!)

Say you’ve got a light-emitting diode (LED) and a battery. If you connect the two directly, the LED should produce a lot of light (assuming the voltage of the battery isn’t too high for the LED). But what if you wanted to reduce the amount of light that LED produces? Well, you could add a resistor in series with the LED to reduce the amount of current supplied by the battery. However, this won’t allow for easily adjustable brightness and may waste a bit of energy. That loss may not matter for a single LED, but what if you’re driving several high-power LEDs or light bulbs? This is where pulse-width modulation comes into play.

PWM Graph - 30% Duty CycleImagine you could connect and disconnect the LED and battery multiple times per second, causing the LED to flash or pulse (see graph above). If this ON-OFF cycle is fast enough, you won’t even notice the blinking. In fact, the LED will appear to be continuously lit, but reduced in brightness. In addition, its brightness will be proportional to the ratio of the on and off times. In other words, if the LED is connected for 30% of a pulse cycle, it will appear to be producing about 30% of its full brightness continuously, even though it’s actually turning completely on and off. So to adjust the brightness of the LED, all we need to do is adjust, or modulate, that ON-OFF ratio, also known as the pulse width – hence the name! The ratio between the on and off time is also commonly called the duty cycle.

Now in case you’re imagining yourself frantically flipping switches on and off, or tapping wires against battery terminals, you can stop. Just put a transistor in series with your LED! It can act as a switch which can be controlled by a microcontroller or some type of oscillator circuit (see links below).

Hobby Servo (Commanded via PWM)So what’s PWM good for, anyways? Well, dimming LEDs and other lights is just one of a number of applications (example). You’ll also find PWM used in motor controllers. You can make a very simple DC speed control using a PWM generator and a single transistor (examples – notice the extra diodes in use here to prevent damaging inductive spikes). In addition, PWM is very important for some types of power supplies; specifically the aptly-named “switched-mode” PSUs. This technique can also be used to create a digital to analog converter (DAC) by low-pass filtering the square wave. Finally, pulse-width modulation is sometimes used as a means of digital communication. For example, to command the position of a hobby servo.

Now you may be wondering why I’m writing about PWM all of a sudden. Well, there’s actually a point to all of this background information. By now, you’ve probably seen a car or two with these new-fangled LED tail lights. They’re pretty easy to spot since you can typically make out the individual LEDs within the whole tail light assembly:

Ford LED Tail Light Upgrade - Ain't that a Fancy Photo?
But have you ever noticed that on some cars (e.g. Cadillacs), these lights tend to flicker? You may not see it if you’re looking straight ahead, but if you quickly move your eyes from left to right, you may catch a glimpse of the flicker created by a low-frequency PWM controller. Now, call me strange, but I find this really annoying and distracting. Maybe I just have fast eyes or something, but I hate flicker. Back in the days of CRT monitors I could usually tell the difference between 60Hz and 70Hz refresh rates. But in the case of these tail lights, it sounds like there’s danger for people with photosensitive epilepsy. According to the Epilepsy Foundation, flashing lights in the 5 to 30Hz range can trigger seizures. Obviously, having a seizure while driving would not be a good thing for anyone.

By the way, if you’re ever trying to determine the frequency of a blinking light, just snap a couple pictures while moving your camera (or the light). The one catch is that you need to be able to specify a known shutter speed. Then you just have to count the blinks and divide by the shutter speed (in seconds) to find frequency. Here’s an example:

LED PWM Frequency Comparison

This method can also give you a pretty good indication of duty cycle – in this case it looks to be about 60%. Here’s a second shot I took while on the road one night. You can tell the streetlights are running on 60Hz AC (although they’re not LEDs so they never go completely dark during a cycle), while the green stoplight is likely getting DC:

Pulsing Streetlights

I’m thinking this long-exposure shot might also pass as modern art in some circles.

The Advanced Stuff

So what’s the deal with these awful low-frequency PWM tail lights? Well, one reason you might choose a lower frequency is to save on energy lost during switching. Both LEDs and the transistors used to drive them have parasitic capacitance. In other words, they store a very very small amount of energy (think nanojoules) each time you turn them on. This energy is consumed in addition to the steady-state power drawn by the LED to provide illumination. Furthermore, this stored energy is rapidly dissipated (and thus not recovered) each time the device turns off. Now if you’re turning an LED on and off fifty times per second, it’s probably no big deal. But what if you wanted to eliminate any possibility of flicker by driving the frequency up into the kilohertz range? Would this introduce substantial power loss? I was curious, so setup a simple experiment to find out.

Test Setup
The heart of this test circuit is fairly simple – two bright red LEDs (Model OVLBR4C7) along with 92Ω current-limiting resistors controlled by a BS170 MOSFET. To measure the power consumed by this circuit, I’ve taken a non-traditional approach. Because I was worried that the cheap ammeters I have available would be thrown off by varying PWM frequencies, I decided to measure power consumption based on the discharge time of a supercapacitor. And who doesn’t love supercaps, anyways?

The theory is pretty simple. The energy stored in a capacitor is equal to ½*C*V² (Joules). So all I had to do was charge up the cap, measure its voltage, let the circuit discharge it over a fixed period of time, then measure the final cap voltage. For my 2.5F capacitor (from NessCap), I chose ~60 seconds as my discharge period. Here’s a screenshot of the voltage logging application I used to collect my test data:

IOBoard Test Program
The white line in the graph above plots the capacitor voltage during discharge. The red line indicates the voltage measured across a phototransistor (L14C1). This was used to quantify the amount of light produced by the LEDs at each test point. To get a better measurement I covered the LEDs and phototransistor with an opaque plastic cup, then covered the whole setup with a shoebox and turned off the lights. I was trying to see if, for some reason, the intensity of the LEDs was non-linear with respect to duty cycle or was affected by PWM frequency. Unfortunately this data turned out to be rather boring, but I’ve still included it in my summary spreadsheet which you can download below.

Now before I go on, you’re probably wondering what sort of data acquisition hardware I’m using. Well I doubt you’ve heard of it as it hasn’t yet been commercially released. Right now it’s being called the RPI IOboard. It’s a pretty impressive piece of hardware with dual 12-bit, 1.5MSPS ADCs, dual 14-bit, 1.4MSPS DACs, and a host of digital I/O all powered by a 400Mhz Blackfin processor. For the past few years it’s been developed at RPI and tested at a number of schools across the country. However since the project’s lead professor, Don Millard, left RPI last year, I’m not exactly sure what will become of the board. The screenshot you see above is actually one of several executable VIs I developed as examples for use with the board. Further information on the hardware can be found here.

Test Setup Closeup
So back to the experiment at hand. For my first round of testing, I utilized the IOBoard to generate varying PWM signals for the MOSFET. Thus, the current required to drive the BS170 was not included in my first measurements. I varied both frequency and duty cycle for three pairs of LEDs: white (C513A-WSN), red (OVLBG4C7), and green (OVLBR4C7).

TABLE 1: Data for power consumption tests without gate-drive losses:

Frequency/Duty Cycle (WHITE LED) 30% 60% 90%
50 Hz
36.15 mW 62.08 mW 84.89 mW
300 Hz
36.26 mW 63.50 mW 85.12 mW
10 kHz
38.75 mW 64.25 mW 86.14 mW
100 kHz
38.52 mW 62.80 mW 86.59 mW
Frequency/Duty Cycle (RED LED) 30% 60% 90%
50 Hz
54.70 mW 93.82 mW 123.75 mW
300 Hz
57.76 mW 93.81 mW 125.35 mW
10 kHz
56.99 mW 94.00 mW 126.08 mW
100 kHz
56.61 mW 95.11 mW 125.47 mW
Frequency/Duty Cycle (GREEN LED) 30% 60% 90%
50 Hz
41.49 mW 71.29 mW 91.65 mW
300 Hz
41.93 mW 70.29 mW 91.69 mW
10 kHz
41.90 mW 69.96 mW 93.36 mW
100 kHz
42.57 mW 69.71 mW 93.58 mW

So if you look through the data above, you’ll notice that there is, on average, a slight positive correlation between power consumption and frequency. In other words, the higher the switching frequency, the greater the power consumption. This is just what we would expect. Again, this data does not include losses due to transistor gate capacitance, only losses due to the LEDs’ capacitance and the MOSFET’s output capacitance.

For my next test, I wanted to see what losses might be incurred in driving the MOSFET’s gate. Thus, I called on my trusted 8-bit AVR microcontroller (ATMega644P). I wrote a very simple program (which may be downloaded below) to produce a varying PWM output from one of the MCU’s timer/counter outputs. I then measured the power consumption of the entire circuit, AVR included. For this test I only used a 60% duty cycle:

TABLE 2: Data for the ATMega644 driving a BS170 and two green LEDs:

Test Frequency Total Average Power (mW) Calculated Switching
Losses (mW)
50 Hz
91.741 0.000
300 Hz
92.708 0.000
10 kHz
92.622 0.016
100 kHz
92.978 0.157
1 Mhz 95.789 1.568

TABLE 3: Data for the ATMega644 driving a FDP8860 and two green LEDs:

Test Frequency Total Average Power (mW) Calculated Switching
Losses (mW)
50 Hz
93.475 0.004
300 Hz
95.809 0.021
10 kHz
98.238 0.710
100 kHz
114.526 6.848
1 Mhz 161.657 60.914

TABLE 4: Data for the ATMega644 directly driving two green LEDs:

Test Frequency Total Average Power (mW) Calculated Switching
Losses (mW)
50 Hz
69.278 0.000
300 Hz
67.926 0.000
10 kHz
68.778 0.015
100 kHz
68.534 0.147
1 Mhz 70.708 1.467

Discussion of Results

In Tables 2-4, we’re starting to see a much clearer positive correlation between frequency and power consumption. For these tests I also added a fifth data point not gathered with the IOBoard: a frequency of 1Mhz. This should in theory increase our maximum losses by 10x. The results seem to support with this prediction.

The tables above also include a rudimentary calculation for switching losses based on capacitances. I measured the capacitance of my green LEDs to be about 120pF (this value was not mentioned in the datasheet). The gate capacitance of the BS170 is given in its datasheet as 24pF. Finally, the input capacitance of the FDP8860 (a much beefier power MOSFET) is typically listed as 9200pF. To determine switching losses I again applied the formula for a capacitor’s stored energy (½*C*V²). At each switching interval, the parasitic capacitances in the circuit store and then dissipate this much energy. So to determine how much power is lost, we simply multiply this lost energy by the switching frequency (since 1 watt = 1 joule/sec). It appears that these calculated figures match the measurements fairly well. Isn’t it nice when math agrees with reality? Gives me a fuzzy feeling, that.

Now we can essentially think of the 50Hz test point as a baseline with zero switching loss. For the data in Table 4, the 50Hz power consumption is about 69.3mW. The calculation predicts that at 1Mhz, we’ll lose 1.5mW to parasitic capacitance for a total consumption of 69.3 + 1.5 = 70.8mW. This isn’t that far from our measured 70.7mW.

It’s also interesting to note the substantially higher losses incurred when using the FDP8860. This is largely due to its (relatively) enormous input capacitance of 9200pF. This is nearly 400x the capacitance of the tiny BS170. That’s the price you pay for the ability to sustain larger currents without overheating. For more information on power MOSFETs have a look at this IRF document called “Power MOSFET Basics.”


Well after all that, I’m going to say that whoever manufactures these tail lights can’t really use efficiency as an excuse for choosing a low switching frequency. Unless they need huge FETs to drive huge currents, switching losses really aren’t so much of an issue. I’m guessing that somehow it was just cheaper to go with a low frequency. I’m pretty sure the components themselves aren’t any cheaper, but perhaps the assembly was less expensive. It may be that some automakers already had a low-frequency module in place to drive old incandescent bulbs and then when LEDs came along they just kept using that same module. Anybody out there care to comment on this?

So my advice to those making LED dimmers: pick a frequency of about 300-500Hz to eliminate flicker while keeping switching loss low. Then find yourself a sufficiently large transistor with low capacitance and low on-resistance. And if you’re working on motor controls or power supplies, things get a lot more interesting, but as a start, try a frequency in the 20+ kHz range to avoid audible whine. Good luck!

  • For further reading on LED losses, try this NI article: Light Emitting Diodes.
  • For more accurate MOSFET swithing loss formulae, try this MAXIM article.
  • Test code for the ATMega644P is available here.
  • A complete spreadsheet containing all data can be downloaded here.

Update (9/22/2010): In the comments below, Jas Strong pointed out that in my switching loss calculations, I’d also neglected the power lost in the MOSFET during turn-on. Jas is absolutely correct about that; I should have mentioned this previously. Essentially, while the gate capacitance of the MOSFET is charging, the resistance between drain and source will pass from very high to very low resistance as the conduction channel is formed. This time period, although short, includes a region of, shall we say, “moderate” resistance which briefly dissipates additional power.

Now, in the case of my two-LED test setup, I neglected the effects of resistive switching loss because they’re quite small. Let’s take a quick look at the numbers. First, we need to know how long it takes Vgs to reach the threshold voltage. For simplicity, I’m going to assume that my AVR drives the gate with a constant current of 40mA (the maximum an AVR will provide per I/O pin). Our worst-case turn-on time will occur with the FDP8860, which has a gate capacitance of 9200pF and a typical threshold voltage of 1.6V. Using the formula ic = C*(dv/dt), I find dv/dt = 4,347,826 which means we reach Vth in 1.6/4,347,826 = 368ns. At a switching frequency of 1Mhz, this represents about 37% of a switching cycle. However, we need to double this since we lose power durning turn-on and turn-off. Thus, we’re losing energy in the MOSFET’s resistance over 74% of a single cycle at 1Mhz. That sounds like a lot, but just how much energy is actually lost?

To determine this loss, I’m going to make a big assumption and say that the MOSFET ramps linearly from 20kΩ down to 0Ω during turn-on. I’m also going to assume the voltage of the diode is constant at 3V and the power supply is constant at 4.2V. Remembering that I have 92Ω resistors in series with the LEDs, the instantaneous power dissipation in the FET becomes 2*Rmos*[(4.2-3)/(92+Rmos)]^2 (based on the fact that I have two LEDs and using the formula P = RI^2 and ohms law, I = V/R). Now I need to integrate to determine an average power dissipation over this interval. If my math is correct (feel free to check me), I get a loss of 0.632mW. Since this occurs during 74% of a cycle, the total loss at 1Mhz will be about 0.468mW. Not too serious in my opinion.

Now of course, the power required by my two-LED setup is piddly in comparison with that drawn by a couple brake lights. Once you start sinking more current into your LEDs, this resistive switching loss, as well as the on-resistance of your MOSFET, is going to start to make a bigger difference. So thanks very much Jas for pointing this out!

Frequency Duty Cycle Start Cap Voltage Start Phototransistor Voltage
50 0.3 4.248407 1.464428967
300 0.3 4.246836767 1.4911225
10000 0.3 4.2389857 1.4911225
100000 0.3 4.243696367 1.538228733

Computers: The Early Days

The other day I came across an old CompuAdd magazine from the summer of 1992. One word: wow. Guess how much hard drive space you’d get for $2000 back then: only 630MB. Today I get about 12 times that amount for free with GMail. But back then, the average user couldn’t even buy 1GB in a single drive. If it were possible, such a drive would’ve cost about $2500. Today, you’ll pay about $0.10/GB for a drive with platters. And people complain about the cost of solid-state drives! They’re still 800 times less expensive than standard drives from 18 years ago – and ludicrously fast by comparison.

CompuAdd Magazine Cover - Summer 1992
Yes, the early 90s, the era of 486 power and built-in math coprocessors – I barely remember it anymore. This was a time when “Realtime clock/calendar” was included in a PC’s list of features, right alongside “4MB DRAM – expandable to 64MB!” This was a time before USB, before digital cameras, and before high-speed internet. There was dial-up though, but back in 1992 most computers could only handle connections at 9600bps – that’s 1.17KB/second. Just downloading the header image on this blog would’ve taken about one minute and twenty seconds.

CompuAdd Catalog Pages 24-25Intel Overdrive ProcessorMy family’s very first computer was bought from this old magazine – a rugged 486 box complete with a blazing-fast 33Mhz processor. That’s fully 6% of the clock speed of my current cell phone’s CPU! Ah, but never fear, with the Intel OverDrive Processor, “obsolescence is a thing of the past!” Just snap this baby in when you’re ready to upgrade and boost performance by up to 70%. And for the right price you could even take your 486 powerhouse on the road. Just $2600 would make you the proud owner of a CompuAdd 425TFX laptop, complete with an 80MB hard drive, 25Mhz processor, 4MB DRAM, and a 64-level grayscale display! Now I’m not sure what the battery life might have be on one of these devices, but I doubt it was all that impressive. Most of the desktops back in ’92 were shipping with 300W power supplies – still not an uncommon size in today’s PCs.

CompuAdd Catalog Pages 12-13Want to hear something really interesting? None of the prices I’ve listed so far have been adjusted for inflation. So paying $2600 for a laptop back in 1992 would be about like spending $4000 today. Well, it’s tough to live on the bleeding edge.

And whatever became of CompuAdd? After a less than successful foray into retail superstores in the late 80s and early 90s, CompuAdd shut its doors in 1993 and filed for Chapter 11 bankruptcy protection. They did briefly continue product development, but in 1994 were acquired by a private investment group. Based on one article, it sounds like they failed because of pressure from competitors like CompUSA (who’s now struggling to keep its own stores open) and Dell. While Dell was raking in money from its public launch in 1988, CompuAdd was struggling with loans to pay for expansion. Interesting stuff if you’re into business and economics (my minor as an undergrad).

Idea: Car-Sensing Automatic Garage Door Closer

Powered Garage Door OpenerIf you’ve got a garage with an automatic door opener, I’ll bet that at one time or another, you’ve left it open by accident. No? Well, whenever I come home and find my garage wide open to the world, my heart races. Thankfully, the few times someone in my family has done this, nothing has been stolen. But according to the makers of the “Protectrix” automatic garage door closer, more than 40% of all burglars enter through an open garage. Their system, which is similar to the “Garage Butler” and several others on the market, automatically closes your garage door after an adjustable amount of time. But what if you want to do some work in the garage, or outside, and you’d like to leave the door open while you’re home? In that case, you’ll need to remember to hit a special button on most of these automatic systems which tells the door to stay open despite the elapsed time.

Here’s a thought though: why not have the closer sense the presence of your vehicle and then only close the door when it leaves? Then you won’t have to worry about overriding the automatic closing feature (and forgetting to re-enable it later). In my case, I rarely leave home without my car, so this would work perfectly. But how might this sensing be accomplished? My first thought was to use a couple of these wireless XBee modules:XBee Pro ModuleThese are great little devices, and I’ve used them in a number of projects over the years. They may be a little expensive for some applications though; the basic models cost about $20 while the mile-range “Pro” versions go for around $35. But this isn’t bad for an FCC approved 115kbps wireless link. Plus all models also come with a bunch of I/O (digital and analog) and a number of sophisticated features including encryption and mesh networking.

So my idea is to use a pair of these devices as proximity sensors. One of them would hang out with the garage door opener and the other would plug into your car’s cigarette lighter. Both would need additional power regulation circuitry to provide the necessary 3.3V supply. The one connected to the opener would likely be controlled by a cheap microcontroller (MCU) of some kind. The MCU could monitor the status of the garage door and send “pings” to the car-mounted XBee. If the car leaves and the door remains open, the MCU would then send a signal to the opener to close the garage door. And if for some reason you still wanted to door to remain open, well you’d still need that override button. But still, I think this approach greatly simplifies things.

Oh, and if you’re worried about the car-mounted device draining the car’s battery, don’t. While the “Pro” device (whose extended range is probably unnecessary in this case) draws 1W during transmission, we only need to transmit for a split second every 10 seconds or so for our sensing ping. So let’s say the transmission takes half a second, and we ping every 10 seconds – that’s an energy draw of 1.2Wh/day. Let’s say your 12V car battery is rated for 40Ah. Power equals voltage times current, so your battery stores 12*40 = 480Wh. Thus, the XBee could run on battery power for up to 400 days. No problem.

I may try this out in the next week or two. We’ll see what kind of modifications are necessary to the garage opener… Any suggestions, feel free to comment! Thanks.