Beacon2

From Hackstrich

Jump to: navigation, search

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

Contents

Project Status

Beacon completed and used at Burning Man 2010! :) Successor project for Burning Man 2011 is Beacon3.

Post-Burn Writeup

  • Charging chip did not arrive in time, so the charge controller was bypassed and the solar cell connected straight to the batteries (through the schottky diode)
  • Overall the concept worked well, no technical failures at all throughout Burn
  • Runtime was far longer than required, which was good!
  • Next Beacon should be brighter, as Beacon2 wasn't super-visible from far away
  • Larger may be good too, as that would also help it be visible
  • Program 0 should run for less time. No more than 5 seconds at a time. Blank time makes it too hard to locate the beacon.

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 I2C.
  • 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 VMAX at PMAX = 80% VOC, then VMAX = 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
    • CTIMER = TEOC * 2.27 * 10-7 * 1000000 (hours / μF) ∴ CTIMER = 8 * 2.27 * 10-7 * 1000000 = 1.816μF
    • RSENSE = 0.1 / ICHG(MAX) (Ω) ∴ RSENSE = 0.1 / 0.310 = 0.3225ohms
    • RIN1 / RIN2 = (VIN(MIN) / 2.7) – 1 ∴ RIN1 / RIN2 = (7.4 / 2.7) - 1 = 1.7407 / 1
    • L = (10 * RSENSE / ΔIMAX) * VBAT(FLT) * [1 - (VBAT(FLT) / VIN(MAX))] (μH) ∴ L = (10 * 0.3225 / 0.3) * 4.8 * [1 - (4.8 / 9.25)] (μH) = 24.8237μH
    • VL(VSP) = VBAT(FLT) * (1 - VBAT(FLT) / VIN(MAX)) (V * μS) ∴ VL(VSP) = 4.8 * (1 - 4.8 / 9.25) (V * μS) = 2.3092V/μS
    • IL(SAT) = (1 + ΔIMAX / 2) * ICHG(MAX)IL(SAT) = (1 + 0.3 / 2) * 0.310 = 0.3565A
    • RFB1 / RFB2 = 3.3 / (VBAT(FLT) - 3.3) ∴ RFB1 / RFB2 = 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

Personal tools