Workinonit wrote:I managed to get up to 40 arches working but the whole system is locking up very frequently at that distance. But this is why we did it 2 weeks before we have to leave. You do full set up to find the problems here and not on the playa. Several ideas have been thrown around and we ARE going to fix it!
I spent the better part of a couple days on what turned out to be a rather silly problem. I just felt the need to hijack your thread to vent!
I'm using a PIC microcontroller to drive a chain of LED drivers (PCA9922, shift-register-style drivers with 1-resistor current setting). I started using the PIC's synchronous serial port feature for the first time to shift the data out, and I was getting bizarre results. I surmised a clock problem, but couldn't really decipher it as it was spurious and weirdly effected by oscilloscope probes. I barked up the wrong tree for a bit concerning the duty-cycle (which, on the PCA9922 spec sheet expects 40% to 60% although it can handle "0 to 25MHz".) Nonetheless, I finally determined that it must have been some RF noise as a capacitor rounded off the clocks enough to work perfectly. Well, sort-of ... it _works_ at least.
The project is a sick bit of elegance that should let me drive 50 (or more) RGB LED's (150 emitters) with 8-bit pulse-width modulated (PWM) resolution from a 20MHz-clocked PIC. And then do animation and processing on the side. I'm using a technique called bit-modulation for PWM which disassembles all the PWM values into bits, sets the shift registers to turn on all LED's with bit 7 set, sets all the output-enable pins for 128 cycles, then moves to bit 6 for 64 cycles, bit 5 for 32, and so-on. The effect is that over the course of 256 cycles, each LED is on for its PWM value's duration, except the processor only has to do heavy computing 8 times per those 256 cycles. I cheat a bit and don't get to 100% brightness because of fixed delays between cycles and such, but it's accurate enough.