Go Down

Topic: Dynamically determine length of WS2812B LED strands (Read 20727 times) previous topic - next topic

jasmine2501

Maybe this will help. I am actually working on something with this stuff right now so I had it in Fritzing anyway. This image is a little confusing but it's basically what you describe, with a second controller at the end of the data line. In this example, there's only one WS2812, and its "Dout" pin is connected by the highlighted wire to the digital pin on the controller on the right. Data comes from the controller on the left.



What will happen here is, if you send 24 bits and then the EOF signal, the Arduino on the right will never see anything. The line will remain low the whole time. If you send 48 bits, enough data for two lights, the WS2812 eats the first 24 bits while leaving "Dout" low, then when it sees the 25th bit it passes that bit to the Arduino in our case, in most cases, to the next WS2812. So, we could send 24 bits for a test, get nothing, try 48 bits, see data, and know we only have one WS2812. The important thing to remember is that each WS2812 sees nothing until the previous chip has seen 24 bits of data. Once it sees 24 bits, it passes all the subsequent data on the "Dout" line.

V1x0r

I must apologize...that small adapter only does 50 light sequences.  so every 50 lights it runs the same code.  however, it still functions the same where it will instantly adapt from the smaller 30 led strip and re-cycle the affect instantly upon reaching the end of the strand.  with the 5m strip it will restarts as soon as it reaches the 50th led on the strand OR the final led on the strand.  I say OR because on one of the settings it doesn't wait for the 50th light to be lit but instead it finishes once the final LED is lit.  naturally 5meters of this isn't 50 leds a meter, it is 30 a meter so the strip gets restarted much sooner.   The remote control version is the one that goes to the end completely.  (it is also advertised for more leds however).  I ordered another small inline adapter that has all the affects as the large remote adapter so I'm waiting for that to come in.  maybe it will do the same as the remote.  it is newer after all.  still, i'm very impressed with the fact that it knows once the end of the strip has been reach. 

your image is intriguing.  but it would require a loop of some form.  there is nothing attached at the end of the strand.  and only utilizes three pins. 
The attached image displays four pins, the two center pins are grounds.  I'm a bit upset that they scraped off the info of the chips, but the first chip is an atmel chip for the RF receiver.  the other two are essentially attiny components.  (not actually attiny...but essentially the same thing).

V1x0r

The small remote looks like this.

Hopefully this site doesn't downgrade the image quality...if it did then the chip is

STC
15F104E
HAH388.A

Alibaba and ebay sells these like crazy

jasmine2501

I think a video of these effects might be helpful. I think maybe I can figure out what's going on. The adapter units seem to only have three wires, so I really don't think they are determining the length of the strand. It just doesn't seem possible.

In the image I posted, notice that there are four things connected to the WS2812 - power and ground, data in and data out... data in is connected to the left controller, data out to the right controller. This setup would work, and the right Arduino could see the data, except for the first 24 bits in each frame in this case. The LED strips would be the same circuit, but more WS2812s in between.

V1x0r

I completely agree!!!  this does NOT seem possible.  which is why I posted on here.  this concept seemed dumbfounding to me. 

The leds maintain a memory though...if you are sending a signal to the leds then disconnect the signal they do not simply turn off.  they instead hold to the last bit of signal that they had before.  which means they have a value written to them temporarily.  and to pull this value only seems like the next logical thing one could do.  instead of a send request you create a get request.  as for forming this get request I wouldn't know how to build it.   but I would assume that the great minds of china have probably already figured this out...especially since they are the once who mass product these things. 

I will have to upload a video tomorrow of these affects.  I gave my a 1m strip and an arduino so he could play around with it (his code is absolutely beautiful compared to what i'm used to seeing.  it's much smaller and more capable.  I will definitely have to share his stuff when he is comfortable with me sharing it.    Anyway...I'll have to cut a strip a to show you what i mean.  :)  i'm off to bed now though.

arduinodlb

At the end of the day, it's not magic. Not even Chinese magic.

WS2812B chips do not remember their state. If you eliminate the impossible, what remains must be the truth (paraphrased from Sherlock Holmes).

If what you are saying is true, and I understand it correctly, when you plug the leds back in the controller chip must re-send the LED data. It is a test setup, so it's plausible they may have done this.
Do not IM me. I will not respond. Ask questions in the forum.

V1x0r


At the end of the day, it's not magic. Not even Chinese magic.

WS2812B chips do not remember their state. If you eliminate the impossible, what remains must be the truth (paraphrased from Sherlock Holmes).

If what you are saying is true, and I understand it correctly, when you plug the leds back in the controller chip must re-send the LED data. It is a test setup, so it's plausible they may have done this.


^^  well said.  a test setup would make sense to check each led and verify if one exists.  I am impressed that they have done this, and being that each chip was setup to function a certain way I don't doubt that a return line is impossible from them.  I still have yet to test the octows2811 stuff yet...maybe that will help.  :/  I dunno.

jasmine2501


^^  well said.  a test setup would make sense to check each led and verify if one exists.  I am impressed that they have done this, and being that each chip was setup to function a certain way I don't doubt that a return line is impossible from them.  I still have yet to test the octows2811 stuff yet...maybe that will help.  :/  I dunno.


Well that's what I'm basically saying to do. Yes, the WS2812 "remembers" whatever the last block of data was, but it can't send that back out again. It will hold that color forever though, until power cycles and then it forgets. I plan to take advantage of that to reduce the need to do updates, so my Arduino can handle some other stuff while it runs the lights. If the controller can measure the current draw even in a simple on/off way, it could easily run a test on the currently connected light strip - when you turn it on, is there any visible flashing or anything before it starts the pattern?

The only data that ever comes 'out' of a WS2812 is the 'extra' data that it passes on after it eats 24 bits for itself - that 'out' signal is just the input signal, re-transmitted - there is no logic on that line, just an amplifier. The WS2812 never transmits the color it lighted up with, it eats that and keeps it.

It makes sense that these don't have a 'read' function, because theoretically, you're the one who sent the data in the first place, and there's no other way to change the values unless you send them. It's not functional as any kind of input device, so there's no reason to read it. Since these are intended to be used in large arrays, the component itself must be cheap - so they aren't gonna add some redundant feature like "give me the numbers I just sent you" which would just increase the cost and nobody would use that feature - it would be hard to compete with other chips that don't have that feature and thus, are cheaper.

BTW - you said you didn't like Pololu library - can you say why and give me some links to better ones then? To me, it's a one-function library, how much better can it be?

V1x0r

#23
Dec 18, 2013, 07:20 pm Last Edit: Dec 18, 2013, 07:23 pm by V1x0r Reason: 1
http://waitingforbigo.com/ FastSpi2 is one of my favorites, along with https://github.com/adafruit/Adafruit_NeoPixel

I hope those are helpful and fun for you.  I haven't tested the recent additions of the Adafruit NeoPixel library yet but those should be pretty awesome!  faster pwm for multiple strips at once.  (for Teensy...but w/e)

as for being able to read...if you are sending the data as an array then you naturally wouldn't need to know the color of the strip.  unless your code tells the strips what to do more mathematically. 

Code: [Select]
#include "Adafruit_NeoPixel.h"
#include <avr/power.h>
#define PIN 6
#define NUM_PIXELS 45
#define HALF_PIXELS (NUM_PIXELS/2)

Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_PIXELS, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
    if(F_CPU == 16000000) clock_prescale_set(clock_div_1);
    strip.begin();
    strip.show();
}

void loop() {int i = 0;
  int nexti = 0;
  int spacing = 3;
  int colorcount = 0;
   int color = 0x00FF00;
  while (1) {
   nexti++;
   if (nexti >= spacing) {
     nexti = 0;
   }
   int variance = 8;
   colorcount += variance;
   if (colorcount >= 253) {
     colorcount = 0;
   }
   int numlight = 1;
   while (i < NUM_PIXELS) {
     int tmpcolor = colorcount + ( numlight * variance);
     while (tmpcolor > 255) {
       tmpcolor -= 255;
     }
     color = colorWheel(tmpcolor);
   strip.setPixelColor(i, color); strip.show();
   i += spacing;
   numlight++;
   }
   delay (90);
   i = nexti;
  strip.setBrightness(0);
  strip.setBrightness(255);
  }
}

uint32_t colorWheel(byte WheelPos) {
  byte state = WheelPos / 21;
  switch(state) {
    case 0: return strip.Color(255, 0, 255 - ((((WheelPos % 21) + 1) * 6) + 127)); break;
    case 1: return strip.Color(255, ((WheelPos % 21) + 1) * 6, 0); break;
    case 2: return strip.Color(255, (((WheelPos % 21) + 1) * 6) + 127, 0); break;
    case 3: return strip.Color(255 - (((WheelPos % 21) + 1) * 6), 255, 0); break;
    case 4: return strip.Color(255 - (((WheelPos % 21) + 1) * 6) + 127, 255, 0); break;
    case 5: return strip.Color(0, 255, ((WheelPos % 21) + 1) * 6); break;
    case 6: return strip.Color(0, 255, (((WheelPos % 21) + 1) * 6) + 127); break;
    case 7: return strip.Color(0, 255 - (((WheelPos % 21) + 1) * 6), 255); break;
    case 8: return strip.Color(0, 255 - ((((WheelPos % 21) + 1) * 6) + 127), 255); break;
    case 9: return strip.Color(((WheelPos % 21) + 1) * 6, 0, 255); break;
    case 10: return strip.Color((((WheelPos % 21) + 1) * 6) + 127, 0, 255); break;
    case 11: return strip.Color(255, 0, 255 - (((WheelPos % 21) + 1) * 6)); break;
    default: break;
  }
}

V1x0r

That example is very choppy I know...it needs a faded appearance on the empty colors.  colorwheel is a pain to work with for that so I will probably just use rgb values.  :)

jasmine2501

Yeah, this is the code for the GetPixelColor function... it's just reading an array. That seems to be what the library does - maintains an array of colors and pumps them out to the strip on request.

Code: [Select]

uint32_t Adafruit_NeoPixel::getPixelColor(uint16_t n) const {

 if(n < numLEDs) {
   uint16_t ofs = n * 3;
   return (uint32_t)(pixels[ofs + 2]) |
#ifdef NEO_RGB
     (((type & NEO_COLMASK) == NEO_GRB) ?
#endif
   ((uint32_t)(pixels[ofs    ]) <<  8) |
     ((uint32_t)(pixels[ofs + 1]) << 16)
#ifdef NEO_RGB
     :
   ((uint32_t)(pixels[ofs    ]) << 16) |
     ((uint32_t)(pixels[ofs + 1]) <<  8) )
#endif
     ;
 }

 return 0; // Pixel # is out of bounds
}

V1x0r

yup.  hence my post earlier not working.  it fed back the array color and not the registered color on the led.  :(  hence why I want to try out
http://www.pjrc.com/teensy/td_libs_OctoWS2811.html    though, I haven't looked at it's definitions just yet so it may be doing the exact same thing.  :/

jasmine2501


http://www.pjrc.com/teensy/td_libs_OctoWS2811.html    though, I haven't looked at it's definitions just yet so it may be doing the exact same thing.  :/


If it has any kind of GetColor() function, it has to be reading an internally maintained array, because there is no way to get information out of the WS2812, it is input-only.

V1x0r

that is why this stupid thing is so confusing!  how do they do this!!  >_<

Grumpy_Mike


how do they do this!!  >_<


Well if you could monitor the presence / absence of current draw, you could send a single lit LED along the row and when the current drops to zero you know you have shifted it off the end. This could be one on start up so fast that you would not see it flicker.

Go Up