A packet of badge-to-badge data on the I2C bus.
complete firmware reprogramming (including the
bootloader) and full debugging using
Code Warrior and the USB TAP hardware
prod_summary.jsp?code=USBTAP). Most people
who used the JTAG interface soldered a 2 x 7
male header (which is compatible with the USB
TAP) onto the prototyping “area” of the badge
and connected wires to the individual test points.
application note. The bootloader communicates via U1‘s
RXD and TXD serial pins at 19. 2 kbps and is enabled for
the first 10 seconds when the badge is initially powered on.
The RGB LED will alternate colors between red, green, and
blue, indicating that it is in the bootloader mode awaiting
data. During this mode, you are able to load firmware onto
the badge by simply uploading the text-formatted S-Record
file of your program (generated by Code Warrior) using a
simple terminal program, such as Hyper Terminal or ZTerm.
If the badge doesn’t receive the proper S-Record file within
those initial 10 seconds, it will jump to regular program
For aesthetic reasons, no discrete connector or
unpopulated footprint is provided, so attendees had to
solder a serial interface (e.g., a level shifter to convert the
3V TTL-level serial of the badge to RS-232 or a hacked USB-to-serial adapter to accept TTL-level signals) directly to test
points on the badge. I felt that this was a reasonable level
of entry for those who wanted to take advantage of this
functionality. Here’s an example of the text output during
Serial bootloader started.
Waiting for application S-Record.
Starting user application.
Welcome to the DEFCON 17 Badge.
If the firmware gets corrupted through a faulty
programming operation, test points for the MC56F8006’s
JTAG interface (TDI, TMS, TDO, TCK, and RST) are
available on the circuit board; these can be used for
RGB Blend a.k.a., Idle
Color Organ a.k.a., Party
Current VCC = 3V
4. 8 mA - 8 mA ( 6. 4 mA avg.)
4. 3 mA - 7. 2 mA ( 5. 75 mA avg.)
Table 2: Current consumption measurements for the three badge modes.
After using a beefy, heavy CR123A lithium
battery for DEFCON 16, I wanted to go back to
the slim, low-cost CR2032 lithium coin cell I
When designing any portable device, one challenge is
meeting your desired battery life specifications. For the
badge, my intent was to have a single battery last the entire
weekend conference, but I was not as stuck on this
requirement as I had been in previous years. As long as I
could get reasonable battery life, I would be happy —
especially considering that the badge would be performing
processor-intensive functions like FFTs much of the time.
The decision to use a CR2032 versus something with a little
more capacity (hence, larger) was a conscious engineering
trade-off. In this case, looks mattered more than
Table 2 shows the current consumption for the badge’s
three modes. It was slightly higher than the recommended
current discharge, meaning total battery life would be
affected. To reduce power consumption and prolong
battery life while the badge wasn’t being used, I
implemented an automatic sleep mode for U1. This mode
would be entered when the sound level detected by the
microphone was lower than a pre-defined threshold (set in
firmware) for 15 seconds.
Once the unit was asleep, U1 would wake up every
one second, check for sound, and go back to sleep if there
was still nothing above the threshold. If the sound level
detected was above the threshold, U1 would switch into
either the RGB Blend or Color Organ mode, depending on
how loud the sound was. A Sleep mode current of 1.2 mA
is still quite high, and I feel that I could have spent more
time to reduce it further.
With the current consumption measurements in hand, I
then calculated some estimates of battery life based on
“typical” DEFCON attendee use of the badge. Although
one would argue that most DEFCON attendees barely
sleep at all, assume the badge spends eight hours in each
mode per day: