Hi there

[chrisparton1991]

Hi all,

I'm new to the forums and thought I'd introduce myself. My name is Chris and I'm a software engineer living in Wollongong, NSW.

I've been tinkering with electronics for about a year and I really enjoy a good Christmas light display. The centrepiece of my display this year is quite modest, just four pillars running some effects from four Arduino Pro Minis using FastLED. Video below (apologies for poor quality):

View: https://www.youtube.com/watch?v=0LetAVtUFUM



There will be lots of other lights added to the house over the next few weeks, of course

For 2017 my plans are more ambitious. I'm working on my own LED sequencing software called Sparkled that will allow me to sequence lights to music. I know there is software out there that can do this better than I'll be able to, but for me it's a great hobby and learning experience.

I'm looking forward to seeing more of the fantastic work this community is doing!

Cheers,
Chris

 

[keithsw1111]

Hey Chris, welcome to the mad house. Have you considered joining one of the existing projects and helping make theirs better? xLights is written in c++, vixen is written in C# and then there is the falcon player (not a sequencer but still a major open source project in this space).


I also did what you did the first few years before deciding I was mad not jumping onto e1.31. I still write my own arduino firmware (https://bitbucket.org/keithsw1111/arduinodmxws2811) but I now work on the xlights project and have been for about a year now.


If you havent already done so:
- read the 101 manual
- watch the xlights videos ... even if you stick at your current approach there is stuff to learn about how other sequencers approach the problem
- join us in chat any night or on the friday zoom call at 7pm Sydney time
- try to join the sydney mini conference when it is held in May/June each year. 2 days of all things blinky ... it really changed my understanding of what was possible and the best way to source materials.


Keith

 

[Fing]

hi Chris


ditto what Keith said...


cheers Fing

 

[MikeKrebs]

How did you sync the four arduino?

 

[keithsw1111]

I don't have 4 arduinos I have 12 and they are all in sync because they get the instructions about what bulbs to light through network packets. Each arduino has an enc28j60 board spi attached which listens for e1.31 data packets from xlights or the falcon Pi player. The enc boards are about $3 each and the arduinos are Megas which are about $7 each direct from China.

 

[keithsw1111]

I suspect I know the way you are thinking of doing this and I went that way myself for a couple of years before I came to understand the power of full house sequencing that you can do in vixen and xlights.

 

[MikeKrebs]

Keith or Chris, how many pixels are you able to drive from one arduino?

 

[chrisparton1991]

Thanks for the replies everyone!

I appreciate the advice keithsw1111 (and Fing ). I suspect I could move on to a more mature technology in a couple of years, but I'm really keen to see what I can build myself using simple Arduino gear. I know it's never going to be as robust as a well-developed system, but I really enjoy pushing myself to learn a bit about all the different aspects of getting a display together.

MikeKrebs, I've pushed my Arduino sketches to https://github.com/chrisparton1991/xmas-2016 and added a README explaining a bit about what I've done. My synchronisation is very basic for this year. I've manually tuned the Arduinos to run at close to the same speed. A separate Arduino cycles the ATX power supply that runs everything. This keeps the animation in sync over a longer period of time. I'm not a fan of this approach, but I have something better in mind for next year.

I'm driving 150 LEDs from each Arduino, though they're only addressable in groups of 3 LEDs, so effectively 50 LEDs per Arduino. Rendering out to the strip takes around 2 milliseconds, so I could easily drive a lot more strips from each Arduino. I'm currently using cheap UCS1903 strips, which are quite slow. I'm sure I could speed up the rendering considerably by using some APA102 or similar strips, but it's not currently an issue for me.

For next year's lights, I plan on using ESP8266 (or possibly ESP32) chips to run the strips. They'll be pulling UDP packets over Wi-Fi from a local server that provides animation data. This will eliminate the need for any manual synchronisation or power supply resets. The main challenge will be getting the ESP chips to be robust enough.

 

[keithsw1111]

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.

 

[fasteddy]

Welcome to ACL, glad to see another person in the Illawarra taking up the hobby. Ill have to find out where you are so I can take a look at your display.

 

[chrisparton1991]

Hey Fasteddy, I've added my location to my profile. I'll have to try and get down your way to take a look at your lights. I work in Jamberoo and drive through Albion Park daily, but I finish work well before the sun does down

 

[marcus_vix]

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.

Hi Keith I'm using the RateManager like (http://www.itwinkle.org/) but the after reboot FPPD is stopped.