Page 11 of 46 FirstFirst ... 91011121321 ... LastLast
Results 101 to 110 of 459

Thread: RGB LED's Now Consumer Grade - Hackable?

  1. #101
    Join Date
    Dec 2009
    Posts
    1,093
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    I checked the data being sent for the 3-light group fade sequence.
    About 200 commands are sent to the master address with intensity ramping up from 00 to $CC, once every 8ms, total time about 2 seconds.
    Then 200 more global commands with intensity ramping back down to 00, again total time about 2 seconds.

    Then a color command is sent to each pixel setting it's new color, and intensity 0. There are 50 of these, they are sent one per ms, so 50ms for this.

    Then the process repeats. This pretty much confirms my belief that the 'global' commands affect intensity only, the color bits in a global command are ignored.

    I am hoping to be able to drive these in some form from a prop chip tonight.

    To Summarize: (Most of this 1st published by joyangel)

    Each command consists of 26 bits. The time for each bit is approx 30us. Each bit begins with a high to low transition on the data line. If the bit is a 0, the line is brought high 10us later and held for 20us. If the bit is a 1 the line is brought high 20us later, and held for 10us.

    At the start of each command the data line transitions from low to high, and this is held for about 10us, then the 26 bits are sent. At the end of the 26th bit the data line is brought low and it stays there until the next command.

    26 bits at approx 30us per bit = approx 800us per command. The existing light controller pauses a minimum of 200us between commands. The required pause is probably significantly shorter but not yet determined.

    Bit timing isn't critical. I have observer 'short' pulse widths of between 8 and 11us, and 'long' pulses of 19 to 22 us. The self-clocking nature of the encoding scheme allows for pretty sloppy timing.

    The different data values that make up a command word all all sent most significant bit first. The format of the 26-bit command word, in the order the bits are sent is:

    6-bit pixel address. This is a possible range of 0-63. Values less than 63 address a specific pixel. A pixel address of 63 denotes a global intensity command that affects all pixels, but only affects their intensity.

    8-bit master brightness. Possible range 0-255

    4-bit Blue intensity
    4-bit Green intensity
    4-bit Red intensity.

    The color intensity values have a range of 0-15. Basically the 3 color values determine the color of the light, from a possible palette of 16*16*16= 4096 colors. The 8-bit intensity value determines the brightness.

    The Costco controller only appears to use values of 0 and 15 for color levels, thus a 7-color palette, but there is no reason to believe that other intermediate color values won't work.

    From looking at the data from the Costco controller, it appears that the global command (pixel address=63) affects every pixel, but only affects the 8-bit intensity value, not the color values. The purpose of the global command is to allow a smooth fade of the entire string. Without the global command, the maximum update rate for a 50 pixel string is 20 times per second.

    <edited to remove info found later to be incorrect re pixel addressing>

    So, are they going to be controllable via other controllers? Yes, with a few limitations. The first limitation is the maximum refresh rate of the entire string. 20 times per second is about half the speed that DMX is capable of for example. So fades may look a bit choppy.

    The other issue is how to convert from standard 8-bit Red, Green, and Blue channel values to the single 8-bit intensity value, and 3 4-bit color values of these lights.

    I'm going to do some experimenting and report back.
    Last edited by jstjohnz; 11-16-2010 at 01:40 AM.

  2. #102
    Join Date
    Nov 2010
    Location
    Livermore, CA
    Posts
    1,713
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    jstjohnz

    Is there a place that newbs could read up on the terms and possibly the testing methodology and required tools to dissect this stuff?
    Reading this is pretty cool, trying to understand it is the challenge (Although you and others seem to do a decent job of not wording this completely beyond the newb (me).

    Thanks for your time with this as well as others!
    Tory

  3. #103
    Join Date
    Oct 2008
    Location
    San Jose, CA
    Posts
    9,177
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    Nice work! I did notice the sloppy timing as well but thought it was just a limitation of my scope and/or the PICkit2 analyzer - guess not!
    Brian

    Christmas in San Jose! - WEB - FB - VIDEOS
    Halloween in San Jose! - FB
    2014 Halloween Show - Homemade tombstones, Video Projection - not much new this year...
    2014 Christmas Show - 5x E681-12, 1x6804, 4x Ren48LSD, 30x42 TLS3001 pixel MT/Star, 4x Rainbow Floods, 12x DIYC Floods, SuperPixelStar, 3x Pixel Arches, PixaBulb House outline

    Ignorance is Temporary - Stupidity is Forever...

  4. #104
    Join Date
    Dec 2009
    Location
    Royersford, PA (Philly)
    Posts
    1,264
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    Great work jstjohnz! I think that for the price that we MAY be able to obtain these strings at the end of the year might outweigh the few limitations of them. I don't think any of us are upset at the hard coding of the pixel address... if ya need a longer string, add another 50! :-) The limitation on the refresh is a little bit of a bummer, but again, I think for the price, and the somewhat higher quality in the hardware (Envelope and waterproofing wise), we still might have a winner

  5. #105
    Join Date
    Nov 2008
    Location
    Ruther Glen, VA
    Posts
    7
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    What happens if you swap the last pixel on the sting with say...one in the middle? Do they still play follow the leader, or does each pixel have its own address?

  6. #106
    Join Date
    Dec 2009
    Posts
    1,093
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    My assumption was that the transplanted pixel would respond out of order. But now I'm not so sure. I am to the point where I can send a specific command word to the string but I am not seeing the results I expected.

  7. #107
    Join Date
    Dec 2009
    Posts
    1,093
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    Well, there is obviously a (big) piece missing as far as understanding this protocol. I thought this was going to be pretty straight-forward, but not so.

    I have built up a test setup that allows me to send any command directly to the string. What I am seeing when I do that is not what I expected to see.

    Right now my string is in 2 pieces, the original controller is driving the first 6 original pixels, the 7th original pixel is no longer with us, and my test setup is driving the segment that was originally pixels 8 thru 50.

    When I send any command, even a command addressed to a specific pixel, it affects every pixel. The color and intensity bits work as expected, but I can't control individual pixels.

    Even more strange: At one point I disconnected the data line to the 8-50 string from my test setup. There was still power to the pixels so they stayed lit at whatever color I had lest set them to. I then reconnected those pixels to the original string (without interrupting power to any of the pixels), and then pixels 8-50 started going with the pattern from the Costco controller, as expected, but they were "out of sync" in terms of color. And they stayed out of sync until I unplugged the whole string and plugged it back in.

    So this is telling me that the effect of (at least some of) the controller commands depends on the previous state of the pixel. Not what I expected.

  8. #108
    Join Date
    Nov 2010
    Location
    Livermore, CA
    Posts
    1,713
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    Can I paypal you some coffee or soft drink funds for your effort?! Keep you up and searchin

  9. #109
    Join Date
    Nov 2007
    Location
    TRI-CITIES WA
    Posts
    39
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    Well today I just got done with my computer interface and now have cracked the protocol.

    In the first 6bits of the stream. ranges 0x00 to 0x3E are addresses and 0x3F is grandmaster.

    the next 8bits are are intensity. In address mode, this controls the intensity of a single pixel and in grandmaster(0x3F). This control all the pixels.

    Note 1: If you send a grandmaster (0x3F) message, It will override the set pixel intensity.

    Note 2: When sending a grandmaster (0x3F) message. Only the pixel intensity data is use. The 12bit color data is ignored.

    the last 12bits contain the color data (4bits for blue 4bits for green and 4bits for red..)

    There is one thing interesting about these lights. When first powered up. They are in this trap mode which means that the first pixel stops the data from getting to the next pixel and so on and so on. When you first send a data packet. it will light the first pixel regardless of the address that you set. How ever, The address you set in your packet will be assign to that pixel. After a pixel has received a packet. it will go out of trap mode and allow data to get to the next pixel down the line. With this process. You can assign any address to any pixel you want. you can also assign one address to more the one pixel and they will work as a group.

  10. #110
    Join Date
    Dec 2009
    Posts
    1,093
    Post Thanks / Like

    Default Re: RGB LED's Now Consumer Grade - Hackable?

    Progress. The pixels are identical, they don't have any hard-wired addressing. It appears that, when the controller first powers up, it sends a 0 intensity command to each pixel in turn. At this initial power-on state, the pixel control ICs are not repeating the data that they see on the input to the output, so only the 1st pixel sees the first command sent, the command addressed to pixel 0. That sets pixel 0's address. Once it's address has been set, it goes into repeater mode, where it sends everything it sees on the data line out to the next pixel. So the first thing the 2nd pixel sees is the second address command, and it sets it's address as pixel#1. This process repeats down the chain until every pixel controller chip knows it's address. From that point on they operate as expected.

Page 11 of 46 FirstFirst ... 91011121321 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •