Ring Theory Project Guidance

Status
Not open for further replies.

JohnnyP

New member
Hey everyone,

I'm looking for some input on my Burning Man project -- Ring Theory.

V4 Render 5.JPG

From an architecture standpoint, the installation is organized into 8 panels. Each has a pixel count of about 500. Three 50W 12V-5V buck converters provide power per panel.

Here is a more detailed breakdown of pixel counts:

Total project: 8 panels
Each panel: ~500 pixels (not over 512)

One panel contains: Whole project contains:
2x 77 pixel strings 16x 77 pixel strings
2x 106 pixel strings 16x 106 pixel strings
1x 135 pixel string 8x 135 pixel string

After initially looking at FadeCandy (and realizing it is not compatible with the strip lengths above), I am looking for recommendations on how to approach this. I have so far observed the following options:

1. Use one Teensy 3.2 & OctoLED adapter to drive 4000 pixels, maybe integrate an SD card for added memory. Each panel would be treated as a single 500 pixel string. The drawback here is that, due to physical layout, data lines could get long (7-10ft) causing issues. This brings me to option 2:

2. Use eight Teensy 3.2s & OctoLED boards, put one teensy on each panel, and use a embedded PC (hopefully Rasberry Pi?) to control all of them via USB bus. I imagine USB will be more robust over a 7-10ft data line, and this would allow me to use a pin for each pixel string above. This will be more expensive, however, and considering this is my first major LED project maybe I'll be biting off more than I can chew. Option 3:

3. Similar to #2, but use Teensy LCs with USB Hub to minimize costs, as putting a Teensy 3.2 on each panel would be overkill. Use Rasberry Pi and USB hub to drive. I recognize that the LC is a bit more limited, but don't fully understand the implications for this project. If it seems suited to the task, it would be the lower-cost option!

Although I have a engineering background, LED projects of this scope are new to me. I'm really hoping someone out there can set me down the right path so I can deliver the best possible product! If there is another good solution out there, let me know! Thanks guys!

JohnnyP
 
For any Burning Man project, I'd suggest making your design modular with as much tolerance for failure in individual modules. The Playa is a tough environment, partly due to the dust, partly due to the many distractions once more people start to arrive. Usually there's no shortage of moderately skilled people willing to help. A design where each module can be hot-plugged and not take the rest of the project down if it fails gives you the most resilience to problems and the best chance of fixing things and leveraging help from others.

Cost-wise, usually the electronics end up being the least expensive part of this type of project. I know it's tempting to focus on the cost of boards and chips, but really you should keep things in perspective. Often wiring, connectors, metal fabrication, and transporting all the stuff ends up costing much more.

If you go with Teensy LC, usually the limitation is the 8K RAM, which you can figure using about half for the pixel data. FastLED's built-in driver and NeoPixel use only 3 bytes per pixel, but they're blocking. With serial communication that's a deal breaker. With USB, you won't lose incoming data but it does slow everything down, even on the host side sending. The non-blocking libs will ensure the most efficient communication, but the cost is more RAM used. If you use OctoWS2811 on LC, you need 6 bytes per pixel, so figure you can drive about 8 strips of 85 pixels each. If you use WS2812Serial on LC, it's 15 bytes per pixel, which gives you a single strip up to about 273 pixels.
 
For any Burning Man project, I'd suggest making your design modular with as much tolerance for failure in individual modules. The Playa is a tough environment, partly due to the dust, partly due to the many distractions once more people start to arrive. Usually there's no shortage of moderately skilled people willing to help. A design where each module can be hot-plugged and not take the rest of the project down if it fails gives you the most resilience to problems and the best chance of fixing things and leveraging help from others.

Cost-wise, usually the electronics end up being the least expensive part of this type of project. I know it's tempting to focus on the cost of boards and chips, but really you should keep things in perspective. Often wiring, connectors, metal fabrication, and transporting all the stuff ends up costing much more.

If you go with Teensy LC, usually the limitation is the 8K RAM, which you can figure using about half for the pixel data. FastLED's built-in driver and NeoPixel use only 3 bytes per pixel, but they're blocking. With serial communication that's a deal breaker. With USB, you won't lose incoming data but it does slow everything down, even on the host side sending. The non-blocking libs will ensure the most efficient communication, but the cost is more RAM used. If you use OctoWS2811 on LC, you need 6 bytes per pixel, so figure you can drive about 8 strips of 85 pixels each. If you use WS2812Serial on LC, it's 15 bytes per pixel, which gives you a single strip up to about 273 pixels.

Thanks for taking the time to respond, Paul.

If I interpret this correctly, it seems you would recommend the Teensy 3.2 over the LC. I did like that the LC already has a 5V pin for driving LEDs, as opposed to the 3.2 which will also require the Octo adapter board. It seems that, per panel, I'll be using approximately 3k RAM for pixel data alone with OctoWS2811 (500 pixels). I originally budgeted $200 for controls hardware, but it seems like I may blow that target.

I'm still a little fuzzy on communication between the host and the microcontroller. What software/protocol must I apply to the microcontroller to allow communication with a PC, and how much uC RAM will it take? Would a 8x Multi-TT USB bus allow fast enough communication? Is the Rasberry Pi suited to this task, or is there other hardware I should be considering?

Sorry for the barrage of questions, but I've read a ton of scattered bits and am still trying to make sense of it all. I still feel I don't have a good grasp on what is feasible, and where my potential roadblocks will be.

Thanks again for the help! If you have observations on any of the points above, I would really appreciate the feedback.

John
 
Status
Not open for further replies.
Back
Top