Beacon2

Beacon2 is a lighted beacon that will be used on top of a flag pole at Burning Man 2010, to help us locate our camp (and be blinkie and flashy).

Project Status

Schematic/board done, BOM on file at Digikey, board sent to MyROPCB for manufacturing. Parts from SFE and Digikey and boards from MyRO received. Slave code complete and tested on an Arduino Duemilanove, master code has 5 programs complete (and is as of yet untested). All 5 boards assembled as slave boards, and code running on them with an FTDI umbilical back to my laptop. Slave code seems to be working fine, slave hardware is all working fine. Programs 1-8 (all of them) on the master board is working, and the regular slave code is working reliably. Advanced Slave code (including WFT support, SoftPWM, and a number of other nice-to-have things) causes the whole stack to crash right now. Stuffed the regulation and solar switch components on the master board (serial #1) and began testing the solar switch.

Design Overview/Ideas

• Enclosure is a CD spindle, as it's a good shape and easy to work with.
• Each layer board has 10 LEDs around the perimeter (every 36deg).
• Multiple layer boards stack together to add a vertical component to the image.
• Boards will communicate via I²C.
• The whole assembly will be solar charged, using NiMH batteries.
  • Needs to intelligently charge, not like the garden lights do (trickle).
  • Needs to last all night! Last year's beacon was mostly out by 0200.
• Boards are using the ATmega644P/V chip.
  • Means we can use/are using the Arduino/Sanguino bootloader.

Power Management

• ~2500mAh 4.8v pack for power (4x Sanyo 2700mAh AAs)
  • Duracell 2650mAh are the same cells, and may be easier to find locally
  • 12Wh of power at a full charge
• Charged using a 2.5W SparkFun solar panel, Voc = 9.25Voc, Isc = 310mA
  • Assuming V_MAX at P_MAX = 80% V_OC, then V_MAX = 7.4V
  • Solar cell puts out 2.5W in peak sun
  • ~7 hours of peak sun per day on the playa
  • Solar can (in ideal conditions, with 100% efficiency in conversion/charging) put 7*2.5=17.5W of power into the batteries per day
  • Charge timer needs to be set for 8 hours (want to take advantage of extra peak sunlight in the event we get it!)
  • Charge current needs to be set for 310mA
  • Charge temperature limit needs to be set for 45C (NiMH chemistry can only charge safely up to this limit)
• Needs to run from 8pm-7am or so (11 hours)
  • Given 12Wh of power in the batteries, we can draw 0.916W average from the batteries
  • At 4.8V we need to keep average draw to 190mA
• LT3652 solar peaking charger IC will be used to charge the batteries
  • C_TIMER = T_EOC * 2.27 * 10^-7 * 1000000 (hours / μF) ∴ C_TIMER = 8 * 2.27 * 10^-7 * 1000000 = 1.816μF
  • R_SENSE = 0.1 / I_CHG(MAX) (Ω) ∴ R_SENSE = 0.1 / 0.310 = 0.3225ohms
  • R_IN1 / R_IN2 = (V_IN(MIN) / 2.7) – 1 ∴ R_IN1 / R_IN2 = (7.4 / 2.7) - 1 = 1.7407 / 1
  • L = (10 * R_SENSE / ΔI_MAX) * V_BAT(FLT) * [1 - (V_BAT(FLT) / V_IN(MAX))] (μH) ∴ L = (10 * 0.3225 / 0.3) * 4.8 * [1 - (4.8 / 9.25)] (μH) = 24.8237μH
  • V_L(VSP) = V_BAT(FLT) * (1 - V_BAT(FLT) / V_IN(MAX)) (V * μS) ∴ V_L(VSP) = 4.8 * (1 - 4.8 / 9.25) (V * μS) = 2.3092V/μS
  • I_L(SAT) = (1 + ΔI_MAX / 2) * I_CHG(MAX) ∴ I_L(SAT) = (1 + 0.3 / 2) * 0.310 = 0.3565A
  • R_FB1 / R_FB2 = 3.3 / (V_BAT(FLT) - 3.3) ∴ R_FB1 / R_FB2 = 3.3 / (4.8 - 3.3) = 2.2 / 1
• Programming limits
  • LEDs current 20ma/component color
  • Peak current/board: 200ma (Rn+Gn+Bn <= 10 component colors)
  • Peak current/overall: 600ma (Rn+Gn+Bn <= 30 component colors)
  • Mean current overall: <= 190ma (Rn+Gn+Bn < 10 component colors)

Random Notes

• Differences from the Sanguino
  • 4MHz crystal instead of 16MHz
    • Means the U2X bit has to be set on the USART in the bootloader, and the URR calculation changes
  • No auto-reset-on-DTR capacitor
    • Means you have to hit Reset to drop into the bootloader before uploading new code
• Required configuration fuses to make the bootloader and board in general work
  • Low: 0XFC
  • High: 0xDC
  • Extended: 0XFE
  • Lock: 0x3F
• Sometimes burning the bootloader takes a few tries. If fuse verification fails, retry the whole thing. I think this is because my AVR programmer is flaky.

To burn the bootloader:

 avrdude -c stk500v2 -p atmega644p -P /dev/tty.usb* -B 2.75 -e -v -F -U flash:w:ATmegaBOOT_644P.hex -U lock:w:0x3f:m -U efuse:w:0xFE:m -U hfuse:w:0xDC:m -U lfuse:w:0xFC:m

LED Program Ideas

Source code for the master board can be found on Github.com at http://github.com/lisa/beacon

1. (5 on) Offset LEDs in each layer rotate around the axis with random colour choice for each vertical frame:

   x x x x x x x x x

   x x x x x x x x x

   x x x x x x x x x

   x x x x x x x x x

   x x x x x x x x x

2. (10 on): Illuminate each row and oscillate up and down the vertical axis with a random colour for each frame
3. (5 on): Vertical columns of LEDs rotating around the axis with random colour for each frame
4. (5 on): Vertical columns of LEDs rotating around the axis with random colour for each LED of each frame
5. (10 on): "Rain down" LEDs from top to bottom. In each frame any unlit LED immediately below an illuminated LED will become lit and the above LED will go out. When the sequence reaches the bottom they will stay illuminated for a random time (1-5 seconds) then go out. The next step for the LED will be to go to the top layer and repeat.
6. (5 on): Rotate around the axis a zig-zag pattern, pick a random colour at the start of the sequence and maintain throughout:

   01 xx 17 xx 09 xx

   02 16 18 08 10 24

   xx 03 xx 07 xx 11 (03/15, 07/19, 11/23)

   14 04 06 20 22 12

   13 xx 05 xx 21 xx

   • Variables: color, position, direction, speed
   • Following variations support swarms of up to 30 individual LEDs, or a single sequence or up to 24; at 24 it's just a solid line, but that's okay if there are shorter sequences moving about as well. With just one sequence, we want to limit it lower in size... When two sequences share a single LED, the component colors can combine to the final output for that LED, or the longer sequence/first/last/etc sequence can take precedent.
     1. (1-30 component colors on) Variation 1 - Sparse: Number of instances (1 to 30 weighted low), length (1 to (min (15,30-number)) weighted low), component colors (1 to 30-(number*length))
        • length=1: 30 LEDs in one of RGB; 15 in one or two of RGB; or 10 in any combination of RGB
        • length=1-2: 15 in one of RGB; 7 in one or two of RGB; 5 in any combination of RGB
        • length=1-3: 10 in one of RGB; 5 in one or two of RGB; or 3 in any combination of RGB
        • ...
        • length=1-10: 3 in one of RGB; or 1 in any combination of RGB
     2. (30 component colors on): Variation 2 - Packed: length (1 to min (24,available_colors)), color (1 to min (3, available_colors / length)); repeat until available_colors == 0
7. (1 on): Quick flashes of individual random LEDs in random colours.
8. (18-20 LEDs, 28-30 colors): Spaceshipmode: 3 rows on, 2 rows off, center row all LEDs on, any one or two colors; outer two rows (one above, one below) are the inverse colors (R=!R, G=!G, B=!B) rotating around. Variables: Center color, outer pattern (alternating on/off or 2 on, 3 off, 2 on, 3 off), direction of rotation for each outer row (deosil or widdershins), speed of rotation for each outer row (slow/medium/fast).
9. (30 component colors): Messages in morse code, one row of RGB, or three identical rows of one RGB
   • 'CAMP OCTARINE'
   • 'BURNING MAN 2010'
   • 'THIS SPACE FOR RENT INQUIRE WITHIN'

Images

• Video of the first working test 4 of the 5 boards are working in this video, and only in program 2.