I just built a lamp that was a huge success – I built off of a cheap white lamp from Amazon and turned it into a sound-reactive RGBW piece (see video links at the bottom).
I am inspired to make another 5 of them and connect them with a Firestorm setup to illuminate a small dance floor or chill space.
My question: When they are running in synchronized mode with Firestorm, does each lamp need its own separate sensor expansion board on the PixelBlaze, or can I get away with just one sensor board and the other 5 being “regular” PBv3 boards.
Obviously I can add a sensor board to each, but that adds a LOT to my cost per lamp – Moves the project from just under $100 a lamp to $135 a lamp, roughly, plus the Raspberry Pi, which, well, is stiff for a cool piece for parties and the like.
Bonus question: Any “gotchas” beyond the main github documentation on https://github.com/simap/Firestorm/ for what I’m describing, running on a Raspberry Pi?
Edit from two years later, as a housekeeping note for people who find this topic via forum search:
This can now be accomplished without a separate computer running Firestorm. The new sync feature built into firmware v3.40 and above allows a single Pixelblaze to sync patterns and playlists across multiple Pixelblaze (as well as to send sensor board data wirelessly to other Pixelblazes).
Firestorm will synchronize which pattern is running and any calls to time(), but it doesn’t distribute sensor board data. You could put a sensor board in each lamp, or for a one-off install, if you can run wires to each, you can distribute one sensor board’s data on two wires to each lamp.
From a prior thread on this:
You can share a single sensor board across 2 or more Pixelblaze. If you were to bisect a big linear install, this is nice and easy because both Pixelblazes and the sensor board can be within inches of each other. You connect GND and TX from the sensor board to GND and RX on the PB boards. For longer distances you might try running a shielded twisted pair like a CAT5+ (internet suggests UART at “tens of meters”) may work.
Other threads mention achieving longer ranges for LED signals by using differential transceivers - those should work for sensor board data as well.
Thank you @jeff ! This would need to be easily set-up and tear-down-able – aka I’d want to be able to pack the whole “setup” into a plastic tote and bring it to a party, and I’d prefer the lamps to NOT be hardwired to each other if possible since that adds a lot of complexity to a plug-and-play setup.
To clarify, this means that the lamps would NOT be showing the exact same pixel data, just the same pattern and time, if they are different distances from the speakers, right?
Aka the lamp that’s literally sitting on top of a big speaker would be brighter than the lamp on the other side of the room because it’s getting “hotter” data off of the microphone.
That’s probably fine – and might look pretty cool – but either way, the only work-around is hard-wired connections between the lamps, right?
Dumb last question – this time for @wizard – have you considered adding volume pricing to the Sensor Boards as well as the PixelBlazes, and is it intentional that your 1-2 unit and 3-9 unit pricing is the same? It looks like you probably meant to do $33 for 3-9 units. (Note: this is in the spirit of a helpful suggestion; $1 a PB more or less doesn’t change what I’m going to buy this week).
I’m a solid PB supporter, but you might want to look into using LedFx on the Pi, and then use either WLED firmware (on a cheap esp32 setup, not as nice as a PB) which can receive e1.31 or use the e.131 proxy that @zranger wrote on PBs…
If you are doing a Pi, then that’ll be cheapest solution with the most bang for the buck. No sound hardware needed except for your Pi. Your light cost drops by a bunch.
Hugely good sound stuff…and all synced to the LedFX software.
Right, but with the various volume normalization approaches we have in the community, I think you could still get something pretty great by putting a sensor board on each lamp. In pattern code we’ve seen PI controllers, noise gates, AGC - lot’s of decent approaches that could keep them all bright. I think what you’re be likely to observe is slightly different responsiveness and accuracy between the close and far lamps.
Scruffynerf might be right about using LedFx/WLED, but I just have no experience there.
Thank you @Scruffynerf - I’m a huge fan of PixelBlaze and this community as well (heck, I’m talking about a v2 project where v1 was built on PB and I shared a video above) but I’d recently heard of WLED and you’re right; it might be a better fit here – probably $200-300 cheaper for BETTER results, which is a powerful combination. But it’d have a large extra learning curve, of course. The only (obvious) downside is they’d no longer be able to run separately if I wanted to split them up later.
I’ll think about that tradeoff seriously, and thanks again for this community being willing to talk about other projects.
I think you’re right; the big downside to this approach is cost and part complexity, and it’ll “look” fine to the naked eye, even if it’s a bit complicated to do.
@ZacharyRD ,
Adding a few ideas here that won’t require multiple sensor boards:
Wireless: you can modify Firestorm to pull sensor board data from one PB and push it to the others (using getVars and setVars). They will have some latency not present on the source PB, and might not see every update, but it might be so minimal that it doesn’t impact the patterns. It could be sourced from a PB + SB that isn’t even in a lamp.
Wired: if you are OK running wire, you can send out the Sensor Board serial data to multiple PB. There is a 1k resistor on the SB output that you can short to increase drive strength (it’s there in case expansions stack, or a programmer needs to drive the data line with a soldered sensor board attached).
3: Wired: Like above, could also buffer that serial data signal to increase drive strength or run multiple separate lines out to lamps.
Wired: For longer distance, you can use RS485 (a long distance multi-drop protocol) transmitter and receivers that work over a pair of wires to send the Sensor Board serial data over long distances (like up to 1200 meters) to multiple receiver drops. Something like these:
6. Wait it out: I do plan on adding a way to sync Sensor Board data to other PBs built-in.
Also, thanks for the heads-up on the pricing, not sure how I missed that!
I just learned that the SoundReactive WLED will actually UDP sync the sound info, so only one needs to have a microphone.
It doesn’t allow the ESP8266 version to do the FFT stuff, sadly (the ESP8266 branch is getting less and less attention, as they add more and more to the ESP32 branch, like matrixes). But it’s better than nothing.
If you used a similar method, given that you’re already syncing time between PBs on the same network, that seems like it could be the right approach.
Till then, I agree, modifying Firestorm to do that is likely the best answer.
