03-18-2015, 10:00 PM
(This post was last modified: 02-09-2016, 02:42 PM by Adam.)
Hey Super excited to get my hands on a couple of these when ready for sale to the public!
I've been using the Teensy 3.1 for a while now almost exclusively it has great cost per pixel as a driver board. However recently I've found my self hitting a bottleneck on how many led's I can control from a PC and I'm wondering if AllPixel might be a good solution to switch to.
Basically right now I have serial data going to a teensy, which dumbly puts that data on the leds. I'm using the octows2811 library which allows for near 60 fps of 4000 pixels.
- The good thing here is that there are 8 pins thanks to the library so I can fan my 4000 leds out over 8 pins which is really useful for the modular led systems I build (I use touch designer for mapping and parsing the RGB data so no issue generating data).
- The bad thing is that, teensy 3.1 uses a form of serial emulation so data communication is severely limited since it's not taking full advantage of hardware usb speeds. So adding another teensy via usb hub gives me 8000 led's potential but I'm limited to roughly 30 fps. It continues to drop from there.
- My question is can the All Pixel handle the communication aspect more quickly than teensy 3.1?
- Any idea as to how many could be grouped together with a multi-tt usb hub?
I'm trying to gauge what's the practical limit for number of controllable led's using your system with out dropping below 60 fps is basically.
The software I use to generate data/visuals has native python support, so I'm hoping it's easy enough to write a n output script to communicate with the allPixel? What kind of communication protocol is being used?
Thanks for your time!
Thanks for your interest!
So... it's a bit complicated, but in general the Teensy 3.1 is going to be better for that many pixels.
The AllPixel is limited to 700 pixels total because it uses a less capable chip than the Teensy so you would need a lot more AllPixels to do 4000+ LEDs.
Also, the AP uses the same exact USB Serial that the Teensy uses as our code is based on the Teensy 2 core and for the specific reason that it is the only USB Serial implementation we found that could actually reach full USB (1.1) speeds. We top out around 1.2MBps... there's really no way to get USB 2.0 speeds with these kinds of chips. They just aren't clocked fast enough to handle it. So, no, it's not going to be faster.
Also, the AP is purely a single output setup. There's 4 total output pins: Power, Ground, Data, Clock (if needed by the chipset).
The AP was design to do ALL of the major chipsets very well, even if it could technically do some very specific ones better. The FadeCandy is probably our closest competitor and it's great, but we didn't like that it was limited to one chipset, 64 pixels per output and had a true USB protocol, which is faster than serial by a little bit, but much more complicated and less open. We chose serial so that it was stupid simple to interface with. We tried to make it more useful in more situations than specializing in just one... so the user doesn't have to think about how to to all the chipset protocol stuff. Someone like you with a big project will probably be the type not afraid of rolling their own setup, like you have.
That being said... using WS2811/WS2812 is going to be a speed limiting factor and why people have come up with all these parallel output schemes. Something like the APA102 can achieve MUCH higher framerates even from a single data output. Even still, I can usually achieve greater than 60fps with the WS2811 but I've never tried beyond about 2500 pixels.
BiblioPixel does, however, support setting up one large logical display and then automatically breaking it down into sub-displays, each controlled by a separate AllPixel. And it will update them all on their own threads. It's quite fast.
As for the protocol, it's very simple:
You could either communicate with the AllPixel directly using serial and that protocol or output from the python interface you have and just push the data over to BiblioPixel and then let it worry about the details. We already do something similar to this with our NetworkReciever class: https://github.com/ManiacalLabs/BiblioPixel/wiki/NetworkReceiver
I know, I'm not being a very good salesman, but I want you to have a solution that works for you
I'd be surprised if doubling the pixel count decreasing your FPS is serial speed related though... with the AP when I use multiple together the FPS almost always increases. Though, it's very possible that your software is outputting to the teensy's serially which would then make sense. As I mentioned, you can thread the AP communications so they output at the same time. What software are you using exactly?
03-19-2015, 12:16 AM
(This post was last modified: 03-19-2015, 12:22 AM by EnviralDesigns.)
Thanks for the detailed response! I appreciate all the behind the scenes info, as it really helps me figure this out.
- So the AllPixel received serial data formatted as r1,g1,b1,r2,g2,b2,etc for the entire 680 pixels worth regardless? Or is that something that has to be set beforehand?
I did check out the fadeCandy, but I was really interested in your device for the very reason that there wasn't a limitation of 64 pixels per pin, and that you could use any strip type. In that sense it was very compact, modular, and streamlined!
From what I've been learning recently, if I want to go the route of apa102's - which are way faster, I have to ditch the idea of parallel updating - which as you pointed out came to be more because of the speed limitations.
So now that I'm thinking about controlling led's sans the multi pin thing I've began rethinking what controller to use since the teensy 3.1 has a lot of extra pins, need resistors for clean signals, level shifting, etc. Again, I like the allPixel because it seems to simplify all that and is ready to go.
- Do you have an estimate on how much you will be charging for the public release of the allPixel?
I actually don't mind having say 10 allPixels over 2 teensys if it means the setup / wiring can be more modular and simplified while keeping speeds at 60+ fps. My main concern is finding a solution that is scalable to larger sizes while still being able to run from a single computer (to a point).
I've been developing a geometric and modular led panel system that I want to eventually turn into a kit that people can buy and use to build customized display systems. The emphasis is on plug and play and being modular with 3d printed connectors for all kinds of shapes and layouts.
Again, this is why I am really interested in your product because 1 device could get someone up and running with say, up to 5, 100 pixel panels. If they wanted to do 8 panels ,they would need another pixel controller plugged into a hub, and it could scale linearly for a while that way (Hopefully!).
- Do you know when units will be avaible for sale? Or if I could purchase a beta unit to test out in the mean time?
The software I use is called Touch Designer - It's a really amazing piece of software, very open ended. Best way I can describe it is being a node based visual programming environment with the ability to quickly build programs and UI's with a lot of different communications protocols supported. The software is geared at generating visuals for love / realtime performances.
Currently I write out of TD via serial directly to the teensy's, so my understanding would be that the allPixel would be a drop in replacement?
One other question!
Do those large holes on the allPixel take dc power in and power up to 680 pixels worth directly?
BiblioPixel internally always stores the pixel data as r1,g1,b1,r2,g2,b2,etc but for the AllPixel it swaps the channels around before sending it if your LEDs don't use standard RGB order. So were you to interface with the AP directly, you would need to do the swapping. It's not hard in python, just a few lines.
Glad to hear you prefer our design approach
While we think the FadeCandy is a neat device, we kind of used it as an example what we didn't want to do, in terms of limitations. And also, yes, it was designed to abstract away all the weird signal stuff you have to deal with, so it definitely would be easier than a Teensy.
We'll be selling them on Seeed's (our manufacturer) online store starting in April and I believe the decided on price was $27.99, but that's probably subject to change. Send us an email at contact [at] maniacallabs [dot] com and we can discuss further working with you since it sounds like you will possibly need a bunch. We might be able to work out getting you an early version, but they will be available to the public very
As you can imagine, there's a lot of combinations of uses and we haven't tested all of them, especially the number of pixels you want. Framerate is often very dependent on the computer controlling them. But I would imagine you could hit 60FPS with the APA102. I don't actually have that many APA pixels on hand but tonight I'll hook up 3 or more APs all set to control 700 pixels and see what kind of speeds I can push and let you know. The beauty of these pixels is I don't actually have to have any hooked up to know how fast they'll run
The AP would be basically a drop in replacement as long as you can replicate our protocol. I get the impression that right now you are just throwing bytes at it and it assumes it's all pixel data. With the AP there's a header format that you have to follow that defines command intent and package size for error checking. But you could always use BiblioPixel as a go-between... I'd have to look at Touch Designer more closely.
Yes that sound great, I'll send you guys a message there soon!
Yeah currently I'm just throwing pixel data at it, I've settled on finding the point, in number of led's just before the teensy starts to drop down from 60 fps and I leave it there. with the octows2811 library thats 500 per pin. In touch designer I just dont use all of them if I don't need to and leave those values at 0. Since I'm capping FPS at 60 in TD this is a good solution for me at least.
The header sounds reasonable to recreate in td as well if it's just adding a few specific bytes to the front.
- Does the AP have any querying capabilities for configuration? or is it just one way communication.
Last night I was doing more testing with touch designer -> 4 teensys using fastLED to "4000 simulated apa102's" each (over SPI) for a total of 16,000 leds @ 60 fps with success!
Touch designer had a very linear increase in milliseconds consumed sending out to 1 teensy, 2, 3, and 4 respectively based mostly on the amount of data being sent. (at 4 teensys / 16,000 led's serial communication OUT was at 5 ms)
Each Teensy was just about maxed out on it's own but there seems to be room to scale more in terms of number of MCU's.
My point there is that, hopefully the AP can scale the same, simply until that usb data rate is reached.
- Can the AP handle more than 5 amps through it's board? Or is it recommended to keep the led power external for amp requirements closer to 30-40 amps.
To keep things simple, AP only has set, not get for the configuration. If you send it a config that is different, it will return a code stating that it will reboot and then it will do so (which reconfigures the AP to use the new settings). I know the reboot thing is a little weird, but it ensures that you get the most speed possible, and it's only going to happen when you change chipset or number of pixels.
So, if you implement the protocol, the way I handle it is:
Connect and send expected config...
If OK, continue, but if reboot code returned, wait for about 5 seconds and try connection again.
At that point, send the config again and it should now return OK code.
Then you can go about sending pixel data.
AP maxes at 5A through the board, mainly because that's all the connector is rated for. Beyond that you must provide power externally. For your setup, I would recommend NOT installing the power connector at all and only hooking up Data, Clock and Ground to the AllPixel then run power externally.
Hello to both of you, I'll just chip in with my 2 cents here.
@EnviralDesigns: personally for large projects, I like to use raspberry pis with the open lighting architecture, as it uses ArtNet (DMX over IP) to receive the data and pushes it out with SPI. This is obviously over ethernet (or could be wifi) and we have ensured pretty decent speeds here depending on your networking hardware. The downside with this is that the Raspberry Pi doesn't have support for a whole lot of different chip types. According to what I found here, the strip needs both a data line and a clock line.
"(describing the APA102): Each LED has two inputs and two outputs which can be daisy chained. At the first sight this may seem wasteful, but it has the advantage of being supported by standard microcontroller periphery and it is insensitive to timing variations. Due to the critical timing requirement it is not possible to control the WS2812 from SOCs with multitasking operating systems, such as the Raspberry P" found here: https://cpldcpu.wordpress.com/2014/08/27/apa102/
The open lighting architecture (OLA) has support for LPD8806 and WS2801 only, but you can do some simple mapping of the artnet subnets, universes and channels with the webinterface. More about that here: https://wiki.openlighting.org/index.php/OLA_LED_Pixels
I don't know what the limitations are for the raspberry pi, as I don't own that many LEDs (yet). But I like the idea of it running over ethernet, so you can add as many (more or less) raspberry pi's to your network as required.
I'm not here to try and put Adam out of business, personally I think his boards are great and I just recently found the BiblioPixel library and decided to learn python because of it (really great work you've been doing, thanks a lot!)
The AllPixel is just for a different kind of application, like the geometric LED panels you talk of. Speaking of, that sounds like a really interesting project, so if you got a blog or something, I'd like to know more.
@Adam: I just have one quick question. I'm wondering why the AP has a limitation of 680 pixels. My guess would be that the 32U4 chip (as seen on the board of your kickstarter) has 2.5kbytes of SRAM and that you need 3 * number of pixes bytes of SRAM (since R, G and B takes 1 byte each). A quick calculation says that is 2,04 kbytes used, leaving some for other stuff. Is this correct or am I just taking a shoot in the blind? Again thanks a lot for your work, and sorry for taking this a bit off-topic.
@hackstage - No worries... don't think you are trying to steal business. Look in the original response, I tried to steer him in another direction before he clarified that the AP could work for what he needs. And integration with things like OLA, ArtNet, etc. is very high on my list. EnviralDesigns and I have been working on integration of BiblioPixel with his tool of choice, TouchDesigner. I want people to have as many options as possible. But I also want them to have the right tools for the job, even if those aren't mine
Regarding the pixel limitation (which is now actually 700, BTW) you are correct. We use 2100 bytes of the 2.5K on the 32u4 and need the other 400 for running the actual firmware. It actually only requires about 250 bytes for the firmware on average, but we leave a buffer for a wide variety of reasons.
As with much of the features of the AP, we had to find a middle ground on the features... one good way to handle the pixel limit is to just pass the data directly to the strip as you get it over serial. But this only
works with a handful of strip chipsets. So it wasn't an option. But that's why we have the ability to run multiple APs as one
Also, glad to hear that BiblioPixel got you into Python! Awesome
The APA102 LED
only have a maximum of 400Khz while the WS2812B LED has a maximum (and minimum) of 800Khz.I think for bigger things the WS2812
is better since it's not that hard for a powerful MCU to control them + the higher refresh speed + when you do something with allot of LEDs you alredy are using a powerful MCU/processor.
05-22-2015, 06:33 AM
(This post was last modified: 05-22-2015, 06:55 AM by Adam.)
Actually, APA102 has a max clock speed of 30MHz and is MUCH faster than the WS281x series. The WS281x is not recommended for large displays because it takes much longer to update the LEDs and your frame rates will suffer. You can find details about all the LED types and their specs here: https://github.com/ManiacalLabs/AllPixel/wiki/Connecting-the-LEDs