I am very new to pixel LEDs and am super happy with the PB! I am not looking to do anything crazy at the moment project wise, but rather am looking to add some customizable lighting to my media room.
I am installing crown uplighting using WS2812B 60pixels/m. I have a 5v / 40A power supply with multiple supply lines and plan on providing power injection at each strip. I’m looking at 72ft of LEDs to do all the uplighting (roughly 22m or approximately 1,320 pixels).
I have been mesmerized by the fluidity of just one strip (300 pixels) - using the pixelblaze. What will the framerate hit be if this is one large run? I’m wondering if I need the output expander and split all the LEDs into channels - if that will make sure it stays smooth.
Basically, I want those velvety transitions that I see at 300 pixels look close if not the same at 1320 pixels.
Can I just make one long strand, set the pixel count in PB to the right number and throw in some power injection and all will be good, or will the framerate drop and drop as I add more and more pixels.
Thanks in advance - amazing little board!
EDIT: Forgot to add - I’m also using the expansion board so I can have patterns respond to music in the room as it also doubles as a party room.
Hello, and welcome!
What you’re doing is a lot like my first installation – the longest run in my living room wound up being 10 meters (600 pixels) of WS2812B. The frame rate will definitely drop as you add pixels.
How much depends mostly on the complexity of the pattern – more complex patterns require more computation, which just takes longer. Also, the WS2812B uses a relatively slow wire protocol, so more pixels just take more time to send. There are several things you can do to speed things up.
For example at the momnt, I’m using the output expander board to drive my 600 pixels through 3 channels to reduce the communications delay. It takes more wire to do it this way, but it is definitely smoother. You could also separate your run into two sections, each driven by its own Pixelblaze. That’d give you some really interesting animation capabilities. In the near future, there’s also the Pixelblaze 3, which has much more processing power.
The other thing about long runs is that voltage drop is a very real, very visible concern. You may have to feed power in at both ends of each strip. I had some color weirdness at the far end of mine until I did this. Also, be sure that your Pixelblaze is close enough to a power injection point to get full voltage.
IMO, the best way to figure this out is to wire it up, get it running and see if you’re happy with how it behaves. This is a super flexible technology and there are always things you can do to make it better and faster. If you get stuck, there are people around here who are good at every aspect, so just ask!
Thanks @zranger1 - I believe you are the one who did the Hubitat app (I’m the same ffingers from the Hubitat forums - we talked there too haha)
Yeah, I figured as much on the frame rate drop. I may try the expander as it says it can handle something like 600 per channel, so in theory I could break up my 1300 pixels into a few channels. If that doesn’t work, I did see a run of around 1200 running off two PBs and the animations look fine.
What I’m curious about - if it would be better to go with two PBs or the expander first. The expander seems better because I’m using the expansion board for audio processing so if I went with two, I would need 2 boards, 2 PBs etc…(my blow past the wife approved budget for this).
As to the power, yeah I planned on branching it and seeing if I can’t get the voltage needed. Worst case scenario, I get another power supply and try and locate it closer.
I have to do all the carpentry work first then place the strips, then I can start testing responsiveness.
On a sidenote: I’m gonna probably ping ya about the Hubitat driver as well. I want to run a dashboard that just controls lighting effects of the PB - I think I know how I want to do it, but may want to check with ya on the driver to make sure.
Thanks to both you and electromage - seriously awesome stuff!
Hi! I would go for the second Pixelblaze personally. It’s closer to a guaranteed doubling of frame rate, whereas with the output expander you can still hit pixel generation rate limits with that many LEDs. Also, Firestorm is easy once you try it out.
By the way, 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.
Just for reference, here are framerates for the default “New Pattern” pattern running on Pixel Teleporter, which runs at the speed of the output expander.
Pixels FPS (Expander)
1536 40
512 112
256 203
Framerate drops proportionally with LED count. And eventually you get to a point where you’re really constrained by the strip’s communication rate. So in the long run, Jeff is right – for really smooth animation two controllers is the way to go. Especially since you can share the sensor board. I totally hadn’t thought of that.
I have a spouse-constrained project budget too. The nice thing about sharing the sensor board is that you can set it up initially w/one Pixelblaze and potentially add the second one later.
@zranger1 - So I guess next question is - how does your driver play with Firestorm? Does it? I want to be able to create a dashboard to select and control the uplighting. If I use two PBs and use firestorm to keep them in sync - would the Hubitat driver still work? I’m not familiar with firestorm enough, if all it does it keep one PB in sync with a master - in which case it looks like it would work or if you control Firestorm as the control mechanism?
Use Firestorm for syncing the system to audio when super tight timing is needed. It has its own Web UI, so you can control it from a computer or phone, and it plays well with the Hubitat driver.
The HE driver isn’t specifically aware of Firestorm, but it knows what Firestorm is telling the Pixelblaze to do, so things stay roughly synchronized and the HE dashboard controls for on/off and dimming, etc will work as always.
Also, Firestorm has its own API – a Hubitat driver for it is definitely feasible. I’ll take a look next week. (Once you’ve got the scaffolding for one driver written, subsequent drivers are a lot easier. )
Use the Hubitat Groups app and create a virtual button for your Dashboard so you can start patterns and keep the Pixelblazes roughly in sync for non-entertainment use. The Hubitat’s not really built for precision timing, but it’ll get close enough for day-to-day use. This is how I handle the several Pixelblazes in my house.
If you don’t mind doing a little coding, use the hardware! Connect the two Pixelblazes together via a couple of GPIO pins and use digitalRead() and digitalWrite() from within your patterns to let the boards signal each other. If you do this, you can sync things any way you want without involving Firestorm or the HE driver.
Also, let me offer a little reassurance. When I started my first installation, everything I knew about addressable LED lighting was exactly this:
“Hmmm… this room needs light. And none of the commercial options do what I want.”
Yeah, it’s definitely DIY-land, but go slow, ask many questions, dive in and experiment freely, and pretty soon you’ll have a setup that can’t be duplicated by anything off the shelf and that makes you smile every time you use it!
Hmmmm…this sounds interesting. I used to code WAAAAY back in the day - I am still good enough to hack together something from existing code. Also have NO problem wiring and soldering, so this option seems very feasible to me. If I can somehow “hard link” two PBs together to treat them as one from a control perspective that would be ideal. I mean the only real reason for using two is to keep framerates decent. This lighting system will be treated as one run always, I will not have a need to break this specific setup up.
Since I know NOTHING about PB coding yet, could you share a little bit about this. I would bet a ton of people would benefit from the ability to do this kind stuff.
One additional thing is the the sensor boards and expanders are compatible between the PB V2 and the PB V3 that will be shipping soon(christmas-ish time) https://www.crowdsupply.com/hencke-technologies/pixelblaze-v3 . So if you decided to go the route of an expander that would still work on the new V3 hardware that is coming. Good info, and I’m not advocating one direction over another . I am just pointing out choices and info.
Pixelblaze is as fun and painless a way to get back into programming as I’ve ever seen. It speaks a simplified javascript and has an IDE built in to the web interface. You don’t need any additional tools.
There’s no compilation or uploading either. Just type in your idea and see if the blinking lights are doing what you want. If you’ve ever worked with any C-like language, you’ll find it really easy to get going.
@zranger1 - Yeah I looked at that - that seems more than simple enough for me. I’m curious about the digitalRead() and digitalWrite() . I just briefly skimmed the tutorial pattern and didn’t see that in there (maybe I missed it). What GPIO pins do I used to link up two PBs?
Sorry maybe I just need to tinker, but was hoping to shortcut some of the experimentation phase and go more into testing lol.
Sadly, there is no skipping the experimentation phase for this, unless @zranger1 has some amazing sample code (hint hint nudge nudge), as this would absolutely be an very advanced thing. Firestorm is the usual method to sync 2+ PBs (using a push method to all of them).
Alright - I guess maybe I’ll try two PBs with a shared sensor board to start…
I could split the 1300 pixel run into two of like 650ish or so pixels then see if firestorm can keep the effects together. Then see how the hubitat driver handles it.
@ffingers, in case you haven’t found it already, documentation for the Pixelblaze’s pattern language is on the same page as the pattern editor. Scroll down — waaaay down!
I’m kinda looking forward to playing with sync via GPIO. It’ll probably be the weekend before I get enough time to try it. Work is… work this week.
If you map the pixels on PB1 to be “left half” of the pixels, versus the ones connected to PB2 (“right half”) and run the same code (that uses mapping).
So long as the two PBs are in sync, they should calculate the same results and map correctly to the overall map. (So for example a music reaction program that puts moving colors out based on frequency bins and volume)
OH…i like this idea a TON - please keep us posted…do you have a thread about what you are doing. I would love to follow it.
Besides my basement which is where my “long-run” is going, my kids have asked about nano leaf stuff. I have a projector in my media room in my basement (150") where my kids game. Would be cool to put up nano leafs. Also have an arcade I built that has it’s own “arcade corner” that I could use that.
