I’m currently mapping one of Tom Betgeorge’s sequences and with the current version of xLights, it tells you what the imported sequence was sequenced at. This one in particular was 100fps. I’m curious as to how to calculate how many pixels per port to theoretically accomodate this high fps. I mostly work on the standard 40fps at <~680 per port.
100fps how many pixels per port
- Thread starter crazymofo
- Start date
There are posts about specific controllers using their own refresh rate rather the sequenced rate. For example, at least some versions of Falcon controllers apparently have hard coded update rates built in the firmware. They change between 20 and 40 fps based on the max pixels per port.
I think Martin said espixelstick firmware will send the data out as fast as received. I couldn't find what it does when it reads fseq files off sdcard. Some controllers don't "control" the fps. They just accept data to a buffer and when they have it, they kick off the pixel update routine.
If the process is too slow overall, frames tend to get lost in the time while the pixels are being written or vice-versa, the pixel output is skipped while the controller is busy receiving data. That is why multi-cpu micros (like ESP32) and FPGAs (that can run multiple things at "one time") are important. One processing unit can be dedicated to pushing data while another is listening for or retrieving data.
BTW, the 680 pixels per port at 40 fps generalization was created because that was as fast as sporadic could drive the esp8266 version of the espixelstick without lag. He mentioned it in a post about seeing lag using more than 4 universes and it soon became "common". The theoretical limit is closer to 800 pixels but most controllers can not continuously push out that much data because of small overhead routines taking up a nano second here and a nano second there. I think the Baldrick8 with wired ethernet is getting pretty close at 750 pixels for 40 fps.
The theoretical calculation to get number of pixels goes something like this ((1-(interframeGap*fps))/pixelUpdateRate)/fps. Spreadsheet it and you can reverse lookup FPS for some number of pixels.
If I moved all the zeros around correctly...
1 is one second
interframeGap is the reset time in seconds (.000280 according one ws2811 spec sheet)
fps is the frames per second
pixelUpdateRate is the time to write one pixel's worth of data (for RGB WS2811 use 0.000030)
You can play with this calculator to simulate various configurations and the related FPS.
www.artiled.nl
I think Martin said espixelstick firmware will send the data out as fast as received. I couldn't find what it does when it reads fseq files off sdcard. Some controllers don't "control" the fps. They just accept data to a buffer and when they have it, they kick off the pixel update routine.
If the process is too slow overall, frames tend to get lost in the time while the pixels are being written or vice-versa, the pixel output is skipped while the controller is busy receiving data. That is why multi-cpu micros (like ESP32) and FPGAs (that can run multiple things at "one time") are important. One processing unit can be dedicated to pushing data while another is listening for or retrieving data.
BTW, the 680 pixels per port at 40 fps generalization was created because that was as fast as sporadic could drive the esp8266 version of the espixelstick without lag. He mentioned it in a post about seeing lag using more than 4 universes and it soon became "common". The theoretical limit is closer to 800 pixels but most controllers can not continuously push out that much data because of small overhead routines taking up a nano second here and a nano second there. I think the Baldrick8 with wired ethernet is getting pretty close at 750 pixels for 40 fps.
The theoretical calculation to get number of pixels goes something like this ((1-(interframeGap*fps))/pixelUpdateRate)/fps. Spreadsheet it and you can reverse lookup FPS for some number of pixels.
If I moved all the zeros around correctly...
1 is one second
interframeGap is the reset time in seconds (.000280 according one ws2811 spec sheet)
fps is the frames per second
pixelUpdateRate is the time to write one pixel's worth of data (for RGB WS2811 use 0.000030)
You can play with this calculator to simulate various configurations and the related FPS.
FPS Calculator - ArtiLED
www.artiled.nl
keithsw1111
Senior elf
Falcon can do 100fps but you need to contact support to enable it as we don’t want people enabling it and then running into issues because they don’t understand the consequences.
- Thread starter
- #6
Thanks for such a detailed reply. Much appreciate the infoThere are posts about specific controllers using their own refresh rate rather the sequenced rate. For example, at least some versions of Falcon controllers apparently have hard coded update rates built in the firmware. They change between 20 and 40 fps based on the max pixels per port.
I think Martin said espixelstick firmware will send the data out as fast as received. I couldn't find what it does when it reads fseq files off sdcard. Some controllers don't "control" the fps. They just accept data to a buffer and when they have it, they kick off the pixel update routine.
If the process is too slow overall, frames tend to get lost in the time while the pixels are being written or vice-versa, the pixel output is skipped while the controller is busy receiving data. That is why multi-cpu micros (like ESP32) and FPGAs (that can run multiple things at "one time") are important. One processing unit can be dedicated to pushing data while another is listening for or retrieving data.
BTW, the 680 pixels per port at 40 fps generalization was created because that was as fast as sporadic could drive the esp8266 version of the espixelstick without lag. He mentioned it in a post about seeing lag using more than 4 universes and it soon became "common". The theoretical limit is closer to 800 pixels but most controllers can not continuously push out that much data because of small overhead routines taking up a nano second here and a nano second there. I think the Baldrick8 with wired ethernet is getting pretty close at 750 pixels for 40 fps.
The theoretical calculation to get number of pixels goes something like this ((1-(interframeGap*fps))/pixelUpdateRate)/fps. Spreadsheet it and you can reverse lookup FPS for some number of pixels.
If I moved all the zeros around correctly...
1 is one second
interframeGap is the reset time in seconds (.000280 according one ws2811 spec sheet)
fps is the frames per second
pixelUpdateRate is the time to write one pixel's worth of data (for RGB WS2811 use 0.000030)
You can play with this calculator to simulate various configurations and the related FPS.
FPS Calculator - ArtiLED
- Thread starter
- #7
Just so i’m understanding, even if i create a 100fps sequence my F16V3 would play it at a capped 40fps unless i get it enabled?
I appreciate the reply, thanks!!