Chips for pixels, and a common starting point for pixels.

[Blackbeard]

This pixel stuff seems to have a bottomless barrel of information that needs to be considered. One thing that seems to be certain is that it's expensive to do much more than a string or two.

I've been searching the web for a source of chips used in these pixels, and except for a very few common ones, they don't seem to be available to the common person. I've found the 2801 in a few places, and although not a real individual pixel controller chip, the Max7219/21.

I'd like to play around with these, but it seems the only way to do this is purchase the pre-made strings.

I'm still lost in the E680/E681/all the other controller stuff but I'll get through that since it seems to be all done for me.

What I'd like to see is a helping hand to some links that explain how a lot of this might be done, either the common way most people do this or a way to start making my own pixels. I've searched the forum here, but there's so much as most people do it "my way" and it's a little hard to digest all they've described. Some of those megatrees are absolutely amazing.

Thanks for any help.

 

[Barnabybear]

I think it's all so new & only a few people have done proper projects but have been happy to share their methods. Lots of people have ordered kits & parts (my self included).
The fun is just starting! Watch this space (forum), I think there will be lots of infomation, problems & ideas as the kits arrive.

 

[Zeph]

Steve, I'm not sure exactly what you are asking.

If you are asking for how "a lot of this" meaning playing with pixels is commonly done, then you are correct that most people buy pixels consisting of LEDs already soldered to their PWM control chips and resistors via a tiny PCB, and then connected to wires (if needed) and waterproofed to some degree. Mostly these are tiny surface mount assemblies, and a display would use lots of them. It's unlikely you can save money by building your own pixels (LED+PCB+components), tho you might find it fun if you like surface mount components.

The DIY part with pixels seems to be in mounting and getting power and data to the pixel assemblies (this can include building protocol converters which go from e1.31 or DMX to the various chip protocols like 2801/6803/180x/300x/etc, and then in coming up with sequences to run them. People also tend to get their wireless modules (eg: Xbee) and ethernet modules (eg: WizNet) pre-built and use them as components in their overall home build scheme - the surface mount soldering just isn't worth it for most people.


There is a new forum for pixels here as well as older messages on the subject in other forums. There is an evolving section of the wiki. There are videos referenced in the wiki. Also the aussies have a lot of info about pixels on their forums and wiki, as well as DLA. (I would look some of these up for you, but it's awkward where and how I'm typing now - but they are easy to find).

You can buy a few pixels, cut them apart if you wish, and play with them (or use a full string). You can send signals to them with one of the protocol converters ("pixel controllers") as described in those resources, or if you want to bit bang them you can use an Arduino or PIC - but then you need to understand the data protocols used by the type of chip you are using. Some chips are easier than others, some are hard to find documentation for. I would suggest this before "making your own pixels".

If you really want to make your own pixel, one option is to create one of the smart floods. Logically it's a pixel, but it uses Renard or DMX protocol (and it happens to have more than one LED die under its control).

Good luck. If you can refine what you are looking for better, we may be able to help more.

 

[raplass]

T
I'm still lost in the E680/E681/all the other controller stuff...

I'm with you Steve on being a bit befuddled by this technology, I think because it is more difficult to get a handle on what the magic smoke is up to in these systems. Renard and DMX are basically extrapolations of serial modem technology but I find my curiosity concerning the data signals coming out of the E681, down the three or four wires of RGB strings / strips, to each pixel chip is not being satisfied beyond discussions of different data protocols. Could "simplified theory of operation" sections of the new wiki pages be added when somebody knowledgeable gets a chance? Also, more details about color balancing and gamma correction like this page:
http://www.sandevices.com/12bits.html
but discussing actual implementation will be important to get beyond the pervasive "pastel" look I've seen in LED rich displays this year.

 

[djulien]

Could "simplified theory of operation" sections of the new wiki pages be added when somebody knowledgeable gets a chance?

This is probably an over-simplification, but for pixels with a dedicated controller it is basically a 3-step process:
1. Vixen or other software packages up a stream of bytes to send out to the controller that describes what color to make each pixel
2. The controller analyzes the data from Vixen and then transmits commands to the pixels to set those colors; this is often a serial protocol in order to keep the number of wires small
3. The dedicated processors on the pixels receive the (serial) commands, pick out the info for their node and save it into working registers, and then forward on commands for other nodes to down-stream pixels; simultaneously the dedicated processor on the pixel uses PWM (typically) to turn the R/G/B LEDs on/off with a duty cycle that will render the desired color

There are many variations on the details of how the above happens, but I think at a high level the descriptions above are correct.

hth

don

 

[raplass]

Thanks Don! So, in other words RGB controllers are not that different from Renard / DMX, but each different pixel chip type uses its own variant data protocol to get the job done. Sounds like the early days of computer data buses. Given that we have added different digital to analog converter bit levels to the mix, per the link above, are there also speed limitations among these variants like on Renard technology?
http://www.doityourselfchristmas.com/wiki/images/7/72/Renard_channel_limit.png
One of the key advantages LEDs have over incans, in my opinion, is turn on speed. In the right hands breaking the 50 ms speed barrier opens all sorts of interesting possibilities, in the wrong hands audiences get epileptic seizures. :nasty: But if the speed barrier reappears because of pixel count + controller processing limits + data pipe size +...

 

[djulien]

So, in other words RGB controllers are not that different from Renard / DMX, but each different pixel chip type uses its own variant data protocol to get the job done.

Yes. The RGB controller ("man in the middle") could, in fact, be a Renard if it spits out commands in the required format for the pixels (I'm using some Renards that way).

A DMX dongle is actually more like a fourth step in the communication - it rebroadcasts the byte stream from Vixen over and over again, and then the RGB controllers that are listening for the DMX protocol read those bytes and the format commands to send to the RGB nodes.

Sounds like the early days of computer data buses. Given that we have added different digital to analog converter bit levels to the mix, per the link above, are there also speed limitations among these variants like on Renard technology?

Yes, good observation.

The dedicated processors on the pixels each have their own speed limitations and expectations. Some have smaller tolerances than others. For example, GECE nodes use 30 usec for each bit in their commands, but they seem to accept +/- a little. Other nodes have different times and tolerances. Some are also more sensitive to noise or voltage variations, which affects the max distance between nodes.

The length of bit times and the number of instructions needed to package up bits into that format and the selection of released firmware will determine which RGB controllers can be used for a given node type. If the PICs in a Renard can execute instructions fast enough to generate the bit stream, they can be used; if it takes too many instructions then an alternate, faster microcontroller would be needed. There are also some newer PICs that are pin-compatible with older PICs, so in a few cases you could just plug in a newer PIC with newer firmware and then use the Renard even when the older type might not have been fast enough.

The Renard chart you posted actually just lists the max number of bytes that can be sent at a given baud rate within a given length of time. So the baud rate between Vixen and the RGB controller is also another limiting factor. From what I've read, most DIYC members run Renard at 56k or 115k baud, while DMX runs at a fixed 250k baud. For protocols that send 1 byte per channel, then this severly limits the number of nodes you can run on each COM port. There are also some controllers that use ethernet in place of a serial cable, so the max baud rate for those is much higher (but they will still have a limit on the max number of nodes).

One of the key advantages LEDs have over incans, in my opinion, is turn on speed. In the right hands breaking the 50 ms speed barrier opens all sorts of interesting possibilities, in the wrong hands audiences get epileptic seizures. :nasty: But if the speed barrier reappears because of pixel count + controller processing limits + data pipe size +...

In general I would agree that faster turn-on time is an advantage. However, in the case of something like a half-wave LED string, it could actually be considered a disadvantage in that you typically see flicker with those whereas you wouldn't with incandescent strings.

don

 

[aussiephil]

One of the key advantages LEDs have over incans, in my opinion, is turn on speed. In the right hands breaking the 50 ms speed barrier opens all sorts of interesting possibilities, in the wrong hands audiences get epileptic seizures. :nasty: But if the speed barrier reappears because of pixel count + controller processing limits + data pipe size +...

The only speed barrier in the DMX/E131 world and this includes ALL Pixel types is at this point of time the SOFTWARE. I've personally run 25mS timing in Vixen for 2 years with 8k and 10k channels.
E131 over 1GB network has limits far above anything the software can drive for the foreseeable future.

Some Pixel controllers have limits on how much data that can be buffered before sending to the pixel string that will limit the number of pixels that may be driven, though the single DMX universe, 170 Pixel length per output seems to be fine for all.

One speed limit I will say is similar to Renard constraints is the sheer number of Pixels that can be driven by one controller output.

Phil

 

[mschell]

As an engineer by training, and a systems person by trade, I'm reminded of a common phrase - it's the slowest part in the system that will be your bottleneck. So, in all of this "stuff", whether discrete channels or RGB or pixels, the slowest link in the chain will limit how quickly you can turn on or off a given light or feature.

Note that I'm using "pixel" as a generic, intelligent light - it could be a pixel string, a strip, a square or rectangular module - just as long as it has a pixel "chip" in it to individually control the LED or LEDs.

Phil mentioned it above - the pixel "protocol" is serial in nature, and longer strings will mean that it takes longer for that last pixel to change for a given timeframe. Think of each pixel as a 3 channel mini-controller - all stacked one after each other.

The software has to send the commands at certain intervals to make it look like you want. So your computer has to send commands often enough, those commands need to get to the controllers, and then the controller turns on/off the light at the right brightness level.

 

[raplass]

Don, thank you again for another in-depth and insightful reply. Always a pleasure.

Phil and Mark, :biggrin: Your comments make it easy to imagine where the high end of our hobby / obsession will be in a few short years: gamer computer-like "Vixen servers" with maxed out memory and processing power, crammed with the highest speed, highest quality I/O ports. High speed controllers feeding data packets down lots of lines to MANY RGB nodes, or wireless modems per node group. All orchestrated with object oriented Vixen 3.x...

Fun times to be doing DIYC.

 

[mschell]

Don't let me give you the idea that you need a super, high powered server to make pixels or anything else work. You can do it with a middle of the pack, normal desktop machine. I'm sure that Phil doesn't have the fastest processor in his machine that drives his 8k channels.

The point I was trying to make is that you need to consider all the issues when you start driving lots of channels. It's not just the speed or type of the output port that may effect how many channels you can drive from a given computer or controller.

In my mind, the way to drive pixels is via the simplest and higher speed channels.

For quite a while in the DIY space, the default choice was to use a serial COM port. With today's channel counts, we're starting to push the limits of those ports. that's not to say they won't work, and with serial cards, you can get lots of them. However, with the advent of Ethernet ports, you can send more data out in a combined stream (which is good for the software side, like Vixen), and distribute it easier to the controllers (via hardwire and wireless Ethernet). That's why E.131 (DMX over Ethernet) is coming into it's own.

But, as I mentioned, it's not just how you get it out of the computer. It's also how you get it to the controllers, and eventually to the individual light element. All those pieces of the system need to be considered when you choose how many "lights" you can stick out in the yard.

Don's comments - re: Renard/pixel controllers is a good reminder that you don't have to go totally into a new world to run pixels.

 

[beeiilll]

As for myself being a "noob" to the world of RGB versus just running strings of LEDs out in the yard, I too am pretty much suffering " information overload" at trying to understand all the new technology that is coming out as well as the software to make it work.
It is a balancing act between the hardware and the software along with the physical world that you are working on to make it all work.
A big problem for a lot of folks is the new terminology that gets in the mix as well. It can really confuse people when one person calls a part one name and someone else refers to the same part by a different name. Makes for a time to dig through and make sure that you are on the right path and not gotten sidetracked by someones use of a term in a different light than what you expect it to be.
And with the amount of information that you have to digess to understand things it gets frustrating at points till finally the little light goes on and you get that "Ah Ha" moment of understanding. Of course about the time you understand something, someone comes along with a new version of it that works a little different and throws you a curve.

Oh well, it still works better than I can sit and flip light switches to make the display work! LOL

I am looking forward to jumping into the RGB stuff over this summer as well.

 

[raplass]

Well, it has been confirmed that my sequencer needs retainers. hwell: So I'll be sticking with incans and joining the fray next year once you guys have all this LED stuff sorted out and in the wiki. :wink: Mark, yes, I agree mid-grade computers will do fine for most, but CLAP often seems to lead to obsession around here, I was extrapolating...