Technical question regarding addressing

[Capt Ike]

So I have this question regarding address assignments for pixels.  Years ago I worked for a company that did concert lighting, so I'm very familiar with DMX addresses and how they work.  The part that is baffling me when it comes to Christmas pixels is how does each pixel know which instructions are for it? In the intelligent lighting industry, each fixture gets an assigned address on the fixture so that it knows any information coming down the line that starts with its own address is for it and it ignores the rest of the data on the line.  But since you don't address pixels at the node, how do they know what data belongs to them? 

This is really just for my knowledge and understanding.  My display is working as it should, I'm just curious how and why it works.  Thanks in advance. 

[Mr. P]

Addresses are assigned to the controller port. If it's a LOR controller then the assigned LOR Unit ID tells the data where to go. Once the data gets to that port then the pixels take there info in the order it is received. So if you have 50 pixels assigned to a port with a Unit ID of 01 then the first pixel in that string will take its data and pass the date to pixel 2. Pixel 2 will take its data and pass the data to pixel 3 and so on. The Pixels themselves are not actually assigned they just take the data in the order that the data gets to them.

[TheDucks]

Smart nodes are a bucket brigade chain PER PORT (LOR or DMX).

Think as a deck of cards. Take the top one, pass the remaining deck  to the next node. Repeat.

Pixies also have a Reverse (the port) where the deck is flipped. Node 1 at the far end.

All Other Pixie HARDWARE features affect the whole board.  BTW You assign the Base ID (port 1), the rest are inherited from there

[Capt Ike]

2 hours ago, Mr. P said:

Addresses are assigned to the controller port. If it's a LOR controller then the assigned LOR Unit ID tells the data where to go. Once the data gets to that port then the pixels take there info in the order it is received. So if you have 50 pixels assigned to a port with a Unit ID of 01 then the first pixel in that string will take its data and pass the date to pixel 2. Pixel 2 will take its data and pass the data to pixel 3 and so on. The Pixels themselves are not actually assigned they just take the data in the order that the data gets to them.

Ok, I can buy that....but then how does pixel 2 know that it is pixel 2?  I see where you say the pixels aren't actually assigned, so does that mean they just use the first "packet" of information and then pass the rest along?

3 hours ago, TheDucks said:

Smart nodes are a bucket brigade chain PER PORT (LOR or DMX).

Think as a deck of cards. Take the top one, pass the remaining deck  to the next node. Repeat.

Pixies also have a Reverse (the port) where the deck is flipped. Node 1 at the far end.

All Other Pixie HARDWARE features affect the whole board.  BTW You assign the Base ID (port 1), the rest are inherited from there

Ok....now I'm getting somewhere.  I really like this analogy.  So, if I understand this, in a string of 50 nodes, at the beginning of the string there are 50 instructions (or packets) of data and by the last node in the string there would only be 1 packet left for the last node?

[k6ccc]

48 minutes ago, Capt Ike said:

Ok, I can buy that....but then how does pixel 2 know that it is pixel 2?  I see where you say the pixels aren't actually assigned, so does that mean they just use the first "packet" of information and then pass the rest along?

It doesn't know that it is pixel 2.  Every pixel thinks it's the first pixel in the string.  When a pixel receives data, it processes the first 24 bits (normally) to control it and then regenerates the remaining data stream.  So for example you have a string of 50 pixels.  The controller sends 50 pixels worth of data.  The first pixel uses the first 24 bits for itself (first pixel worth of data), and then regenerates the remaining 49 pixels worth of data.  The 2nd pixel receives 49 pixels worth of data (in reality pixels 2 - 50).  Like the first pixel, it uses the first 24 bits of data for itself, and regenerates the remaining 48 pixels worth of data.  This continues to the last pixel that only receives one pixel worth of data.

One of the big advantages of this is if you need to replace a failed pixel, you just cut out the bad one and solder in a replacement.  Done.  No configuration required.

 

Edited June 15, 2022 by k6ccc

[TheDucks]

11 hours ago, Capt Ike said:

Ok, I can buy that....but then how does pixel 2 know that it is pixel 2?  I see where you say the pixels aren't actually assigned, so does that mean they just use the first "packet" of information and then pass the rest along?

Ok....now I'm getting somewhere.  I really like this analogy.  So, if I understand this, in a string of 50 nodes, at the beginning of the string there are 50 instructions (or packets) of data and by the last node in the string there would only be 1 packet left for the last node?

No! Pixel 2 has no clue of even how many nodes there are, let alone, where it was in the string. Cut off Node 1, and Node2 becomes the first.

3 reasons (that I know of) we recommend keeping spares from the same lot. 1) Voltage/chip type. 2)color order. 3)Actual color rendition (just like paint batches).  Makes patching up a bad string.

 

[Capt Ike]

I got it now...thank you guys so much.  I appreciate it! 👍

[Steven]

On 6/14/2022 at 8:57 PM, k6ccc said:

One of the big advantages of this is if you need to replace a failed pixel, you just cut out the bad one and solder in a replacement.  Done.  No configuration required.

One of the big disadvantages of this is that when a pixel (and all others following it) is not lit, you don't know if the one that has failed is the first non-working pixel, or the previous pixel (whose data output driver has failed). For my pixels, it seems to be about 50/50, so when a pixel fails, I often just replace two of them.

For example, if you have a string in which only the first 3 pixels are showing the correct colors, and the others are dark or some random color, the problem could be that the data output from pixel #3 is bad, and thus you have to replace pixel 3. Or pixel #4 is just bad. You can guess and replace pixel #4, but then if it still doesn't work, you have to cut and solder again to replace pixel #3.

[k6ccc]

7 minutes ago, Steven said:

One of the big disadvantages of this is that when a pixel (and all others following it) is not lit, you don't know if the one that has failed is the first non-working pixel, or the previous pixel (whose data output driver has failed). For my pixels, it seems to be about 50/50, so when a pixel fails, I often just replace two of them.

Absolutely correct, and I also normally just replace both - especially if the pixels involved are hard to get to.

 

[Lights on Bluster Court]

Similar question along this line... If I have a few pixels I want to "skip" and not have anything sent to them (they never turn on), do I just skip that number when I create the custom prop layout? What I'm trying to accomplish is run three corrugated plastic cutouts using 100 pixels (two 50 pixel strands together on one Pixie 4 output). To have a little space between them, I want to ignore 3 pixels so they don't turn on. When numbering, would I number ...28, 29, 30 [skip 31-33] start next outline on prop at 34?

I'm a little confused because based on the deck of cards logic above, this might not work?

[Steven]

22 minutes ago, Lights on Bluster Court said:

I'm a little confused because based on the deck of cards logic above, this might not work?

It will work, and that's one way to do it. When the software sends a lighting intensity to pixel 34, the firmware on the controller knows to send that intensity as the 34th packet of information in that pixel string. The software is also sending black to pixels 31, 32, 33 (via DMX addresses).

Personally, I would cut the line and solder a cable between the props, because then the distance between the props wouldn't be limited as much, and there wouldn't be 3 more pixels that could fail.