OctoWS2811 Library

I got the spec. Thanks! It looks pretty much identical to the draft. The spec is all I really need. It's a pretty straightforward data format in UDP packets, which is relatively easy.

I plan to do this in probably 3 stages.

1: receive E1.31 as unicast only
2: add multicast reception (requires hacking the Ethernet library)
3: add multi-source priority and merging features

I'll post here when #1 is ready for testing. I expect that will be sometime in June 2013.
 
That is very exciting to hear Paul :)
I'm personally not too worried about multicast support as unicast is just as fast (& easy) when the data is going to a single controller.

I have a couple of questions...
1. Would an Ethernet module be required for each teensy? Or can a larger matrix with multiple teenseys share a single Ethernet module?
2. What is the max pixel count per teensy output / matrix row?
3. What happens if the 1000 pixels / teensey recommendation is exceeded? Laggy or a complete no go?
4. Do you have any ideas how the E1.31 would be addressed to the Teensey yet? eg: One universe (e1.31 packet) per teensy output / row? or?
5. Is PJRC your store? If so I will purchase direct from you so I can start having a play :D
 
since each teensy needs usb input..
could a mega+eth control that need? (mega+eth can be got for as cheap as $30)
an how many teensy's could a mega handle?
unicast is perfect for e1.31 for me as well.
this is going to be a super project..
now we need a bulk supplyer for teensy's in australia
keep up the great work
 
Oh, many questions.... let's see if I can get 'em all quickly?

Driver said:
1. Would an Ethernet module be required for each teensy?
Click to expand...

Yes.

Currently the WIZ812MJ is supported. I'm planning to try supporting the much nicer WIZ820IO sometime later this year.


Or can a larger matrix with multiple teenseys share a single Ethernet module?
Click to expand...

In theory, yes, or maybe, or probably?

In practice, you'd need to write the software to do so. It might look like 1 master Teensy receiving the data on Ethernet, updating its 1000 LEDs, and maybe retransmitting 3 sets of data on the 3 serial ports. You might want to modify the serial driver code to increase the transmit buffer to more than 512 bytes, so you could write an entire DMX universe into the buffer at once (thereby not causing your program not to stall waiting for the serial port interrupt to slowly send all that data).

If those serial signals travel any substantial distance, you'd need some sort of interface chips to reliably transmit and receive the signal, like RS232 or RS485. It might turn out to be more trouble than just using an ethernet module at each location?


2. What is the max pixel count per teensy output / matrix row?
Click to expand...

The maximum recommended is about 1000 RGB LEDs (3000 individual color elements) per Teensy 3.0.

OctoWS2811 must drive 8 strips of equal length (or if they are unequal, those LEDs are still driven by the software even though they don't physically exist). So 8 strips of 120 or 128 are right in the recommended range.

3. What happens if the 1000 pixels / teensey recommendation is exceeded? Laggy or a complete no go?
Click to expand...

Lag isn't much of an issue, at least for the OctoWS2811 library. The entire 1000 LED array updates in exactly 3.8 milliseconds with OctoWS2811 using 8 equal length strips. That time grows linearly with the number of LEDs.

Lag might become an issue for other parts of the process, like transmitting and software processing the data for each frame.

Memory is the main limitation. You use more memory for the LED frame buffers! It's a low cost microcontroller, so you have limited memory.

The default usage of OctoWS2811 has double buffering. You could try only single buffering. But double buffering is a really awesome feature. It insulates you from all sorts of software delays that might cause visual artifacts. Timing issues with updating the buffers may or may not be an issue in practical usage, so single buffering might work ok? But the default is double buffering because it allows OctoWS2811 to provide very strong guarantees on LED update timing. No matter how slowly you update the drawing buffer (software & network/communication delays), when you call the show() function, all 1000 LEDs will update in exactly 3.8ms. The double buffering absolutely prevents ever displaying any partially updated state for longer than 3.8ms, because the software is working on the drawing buffer while the display buffer is being used for the update.

If you're using ethernet for all communication, you could edit the USB code to reduce the number of buffers it allocates. You might be able to free up enough for a couple hundred more LEDs. You could also try just pushing beyond the recommendation and have less free memory. But if you later want to add more functionality, or newer versions of OctoWS2811 or Ethernet or other libraries add really compelling features that use more memory, you'll probably be glad to have the free memory for future software upgrades.

In such a large LED project, a $19 Teensy 3.0 is probably one of the cheapest parts, even with adding a $20 ethernet module, even adding international shipping costs. It's unlikely you'll save much by pushing beyond the 1000 LED recommendation.


4. Do you have any ideas how the E1.31 would be addressed to the Teensey yet? eg: One universe (e1.31 packet) per teensy output / row? or?
Click to expand...

There are a lot of ways that might work.

Right now, I'm imagining writing 2 examples. The first would be a simpler approach with 512 LEDs updated by 1 universe. The second would probably have 2 universes updating the entire array, perhaps with the 2nd one triggering the LEDs to all update?

There's no need to map each universe to specific rows or strips, but of course you can if you want.

I'm open to suggestions on how DMX universes and updates should work. The idea is to publish examples that are good to be used as-is, but also serve as a template for people wanting to do more. So my goal is to keep things relatively simple. Rather than accommodate every possible configuration, the ideal is the examples gives you an easy path to build what you want.


5. Is PJRC your store? If so I will purchase direct from you so I can start having a play :D
Click to expand...

Yes.


smartalec said:
since each teensy needs usb input..
could a mega+eth control that need? (mega+eth can be got for as cheap as $30)
an how many teensy's could a mega handle?
Click to expand...

I do not quite understand this question. If you mean Arduino Mega with the Ethernet Shield (or a board with it built in), I can't see how that will help you distribute USB to other boards. It has only 1 USB port, and that is a device port. Mega has no USB host ports to send data to Teensy by USB.

If you're running USB to each Teensy (which saves the cost and trouble of adding an ethernet module to each one), you probably only need a good quality USB hub. You should make sure to use a Multi-TT type hub, as they work much better than Single-TT.

A board like Raspberry Pi, plus a good USB hub (and some significant programming) could be a really awesome solution. It could receive and parse E1.31 via ethernet and retransmit by USB various DMX universes in the format OctoWS2811's VideoDisplay example wants. That would even work with OctoWS2811 version 1.0 available today. That could probably handle a very large number of LEDs, assuming the code is written efficiently in C or C++, but I would probably only attempt one Raspberry Pi with 5 to 10 Teensys for 5000 to 10000 LEDs. The main limitation will probably be the USB cable lengths from the RPi+hub to each Teensy 3.0.



now we need a bulk supplyer for teensy's in australia
Click to expand...

I believe Mindkits in New Zealand is carrying Teensy.

If you buy a board, remember OctoWS2811 only works on Teensy 3.0. The older Teensy 2.0 and Teensy++ 2.0 do not have the DMA controller which makes all this possible.
 
I just worked out something..
My pixel matrix sign was going to be 8 strips of 5meters, but if i make it 8 strips of 4meters
i could get away with only one teensy an WIZ820IO for $40 (the WIZ820IO looks better) :D
now all we need is the e1.31 code written :eek:
an for me to save up $$$ an order the strips from ray ;)

Keep up the great work
 
I've been thinking about this project much more recently. For Maker Faire this year, I brought the 1920 LED board and ran it from the new Beaglebone Black board.

I'm planning to make a Christmas lighting package that uses a Beaglebone Black, USB hubs + cables, and 1 to 12 Teensy 3.0 boards (for up to 24 DMX universes). The Beaglebone Black board costs $45, which is about twice as much as a Wiznet ethernet module, but you only need 1 Beaglebone to transmit the data as USB to lots of Teensy boards that drive the LED strips. As soon as you're using more than 1024 lights, it's cheaper and it offers much higher performance.

I do have a couple questions......

For most people installing these LED strips as Christmas lighting, how important are solderless connectors? Is that worth spending a bit more, or is soldering the wires a solution most people would prefer (to save a few dollars)?

What time frame do people generally need to plan and buy controllers for next Christmas?
 
kryolla said:
Paul I have an uno how can I make it work with the 2811 strips? Thanks
Click to expand...

On Arduino Uno, you can use the FastSPI_LED or Neopixel libraries.

However, the Uno is limited to driving only a single strip, so it's only 1/8th the speed. The CPU is 100% consumed during the update, so the longer the strip you drive, the less CPU time for have to getting the next update ready. A small number of LEDs, like 100, works pretty well. But at larger numbers, these limitations really slow the performance and they make really large numbers, like 1000, pretty much infeasible.

OctoWS2811 solves these problems by driving 8 strips simultaneously. It leaves the CPU completely free during the update and has double buffering, so you can get the next frame ready... which makes 30 or 60 frames/sec video easy. Teensy 3.0 also has a fast 32 bit CPU and very efficient USB, which really helps move data around quickly.

The Uno is simply a low performance board. It works great for a small number of LEDs, but it just can't achieve the speeds with large numbers of LEDs that you get from a high performance board running OctoWS2811.
 
PaulStoffregen said:
For most people installing these LED strips as Christmas lighting, how important are solderless connectors? Is that worth spending a bit more, or is soldering the wires a solution most people would prefer (to save a few dollars)?
Click to expand...
The LED strip segments or other lighting elements all need connectors to make it physically manageable/practical.
I guess within a controller box itself, soldered connections are fine. Then again, having any sub-assemblies via connectors means it's easier to replace boards if something gets blown up - or the need for testing should a particular module appear to be dodgy.
PaulStoffregen said:
What time frame do people generally need to plan and buy controllers for next Christmas?
Click to expand...
I will need to be doing something pretty soon... probably June/July to get this project started. Factoring in 3-4 week shipping times, assembly time, life(tm), testing, working on other projects it'll be October before we all know it :)
 
You must log in or register to reply here.
Back
Top