Facebook
youtube
Home
What's new
New posts
New display videos
New media
New media comments
Latest activity
Forums
New posts
Search forums
Wiki
Search wiki pages
Media
New media
New comments
Search media
Display videos
New display videos
Search display videos
Display locations
Displays by region
Members
Current visitors
Latest activity
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Navigation
Install the app
Install
More options
Close Menu
New to Christmas lighting?
Get started with the
AusChristmasLighting 101 Manual
Home
Forums
Welcome
New members say hello
Hi there
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
[QUOTE="keithsw1111, post: 81678, member: 2445"] If only this had a simple answer. In theory I think I could get approx 1000 before I run out of memory without significant lag. 2000 if you were willing to group pixels into pairs. In practice the most I have is about 650. But to achieve that you need to make a bunch of tradeoffs and technology choices. - Arduino type ... I use the Mega. Unos and the like can do a lot less. Tensy's, Duos etc could in theory do more. The biggest constraint is memory. But CPU and the ability to clear the network card buffers is also a factor. - I run at 20fps ... I doubt you could do 40fps. 10 fps would be easier to keep up with but its not smooth enough for my liking. - If you are super fussy about how snappy the display is all arduino solutions running significant pixels have the risk of lag due to dropped packets. If it needs to be perfect every time then you wont be able to push it that hard. - To get the best results I use a piece of software I wrote which sits between the FPP/xLights and the arduino which manages the packets being sent to the arduino. It does things like packet deduplication and packet arrival time management. This makes a huge difference to the number of pixels I can reliably run. This software is available and can run on the Pi or a PC. - Grouping bulbs can also make a big difference. While this does not address memory constraints it does reduce the network packet size which allows the arduino to clear the packets faster - Tight management of settings. Making the universe only as big as it needs to be and using unicast help. - I have built but dont currently use an optimised e131. My rate manager can strip back the e131 header from 126 bytes to just 4 bytes which makes a huge difference to packet processing times ... but it is non standard. I would only go there if you really wanted to push for better frame rates. - I also run 400 GECE bulbs off an arduino. This is much more challenging due to the slowness of the GECE protocol but because bulbs can be addressed directly I can do some further optimisations to limit the impact as long as not every bulb is changing. To achieve this I use 8 outputs on the arduino and drive out the data in parallel ... so the time spent outputting data is a lot less than other solutions and I dont get long string lag. The downside is I use a lot more memory which is where my constraints come from. [/QUOTE]
Verification
The title of our introductory lighting manual contains a three digit number. What is that number? Clue: Display basics forum
Post reply
Home
Forums
Welcome
New members say hello
Hi there
Top