RGB Fairy String/Micro Rice LEDs support

[scarr999]

Make slight changes to bit timings so the library will work with these popular LED string https://www.ebay.co.uk/itm/373588834942?var=642594617777

I have tried many libraries but all fail

I do have logic analyzer screen shots attached and here are the timings

T1H 320ns T1L 1.28us T0H 1.12us T0L 480ns

it does have a 9.12us gap between LED packets, I can provide the actual capture file and you an download the free Saleae software to view it.

happy to pay to have a one off library or contribute if it becomes part of the main library

[Makuna]

What Arduino/uC are you using?

Also need the reset time, the time between the last pixel of current frame and the first pixel of the next frame.

You did try the NeoRgbwColor and NeoSk6812Method when you declared your NeoPixelBus?

Also try the NeoApa106Method as it is close to the same timing that you included above.

Interpixel gaps can't be supported by all methods at all and only one method core supports it today, Esp8266 Dma methods. But in a previous investigation on a similar pulse form we found that the interpixel gap wasn't a requirement, it was a artifact of the crappy controller they included.

[scarr999]

Hi Michael,

Thanks for the reply, I did try the code below both with NeoRgbwColor and NeoSk6812Method, NeoSk6812Method compiled but didn't work and NeoRgbwColor didn't compile saying "Compilation error: 'NeoRgbwColor' was not declared in this scope"

// NeoPixelTest // This example will cycle between showing four pixels as Red, Green, Blue, White // and then showing those pixels as Black.

include

const uint16_t PixelCount = 4; // this example assumes 4 pixels, making it smaller will cause a failure const uint8_t PixelPin = 3; // make sure to set this to the correct pin, ignored for Esp8266

define colorSaturation 128

NeoPixelBus<NeoGrbFeature, NeoRgbwColor> strip(PixelCount, PixelPin);

//NeoPixelBus<NeoRgbwFeature, NeoSk6812Method> strip(PixelCount, PixelPin);

RgbColor red(colorSaturation, 0, 0); RgbColor green(0, colorSaturation, 0); RgbColor blue(0, 0, colorSaturation); RgbColor white(colorSaturation); RgbColor black(0);

HslColor hslRed(red); HslColor hslGreen(green); HslColor hslBlue(blue); HslColor hslWhite(white); HslColor hslBlack(black);

void setup() { Serial.begin(115200);

Serial.println();
Serial.println("Initializing...");
Serial.flush();

// this resets all the neopixels to an off state
strip.Begin();
strip.Show();

Serial.println();
Serial.println("Running...");

}

void loop() { delay(5000);

Serial.println("Colors R, G, B, W...");

// set the colors,
// if they don't match in order, you need to use NeoGrbFeature feature
strip.SetPixelColor(0, red);
strip.SetPixelColor(1, green);
strip.SetPixelColor(2, blue);
strip.SetPixelColor(3, white);
// the following line demonstrates rgbw color support
// if the NeoPixels are rgbw types the following line will compile
// if the NeoPixels are anything else, the following line will give an

error // strip.SetPixelColor(3, RgbwColor(colorSaturation)); strip.Show();

delay(5000);

Serial.println("Off ...");

// turn off the pixels
strip.SetPixelColor(0, black);
strip.SetPixelColor(1, black);
strip.SetPixelColor(2, black);
strip.SetPixelColor(3, black);
strip.Show();

delay(5000);

Serial.println("HSL Colors R, G, B, W...");

// set the colors,
// if they don't match in order, you may need to use NeoGrbFeature

feature strip.SetPixelColor(0, hslRed); strip.SetPixelColor(1, hslGreen); strip.SetPixelColor(2, hslBlue); strip.SetPixelColor(3, hslWhite); strip.Show();

delay(5000);

Serial.println("Off again...");

// turn off the pixels
strip.SetPixelColor(0, hslBlack);
strip.SetPixelColor(1, hslBlack);
strip.SetPixelColor(2, hslBlack);
strip.SetPixelColor(3, hslBlack);
strip.Show();

}

I have attached a Saleae capture from the working ebay controller that should allow you to see everything including all timings. The Saleae software is free to download and use Software https://logic2api.saleae.com/download?os=windows This capture is a pulse brightness cycling colours.

Thanks again for your reply and help.

On Mon, Jun 12, 2023 at 3:33 PM Michael Miller @.***> wrote:

What Arduino/uC are you using?

Also need the reset time, the time between the last pixel of current frame and the first pixel of the next frame.

You did try the NeoRgbwColor and NeoSk6812Method when you declared your NeoPixelBus?

Also try the NeoApa106Method as it is close to the same timing that you included above.

Interpixel gaps can't be supported by all methods at all and only one method core supports it today, Esp8266 Dma methods. But in a previous investigation on a similar pulse form we found that the interpixel gap wasn't a requirement, it was a artifact of the crappy controller they included.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1587473653, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2VQXHPGF36LPJEWUVTXK4SFNANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

I meant NeoRgbwFeature together with NeoSk6812Method. Your commented out line suggest this is what you were using.

The attachment wasn't made. I don't believe you can include attachments; you can imbed images, or you link to external files that you share using a service.

JFYI: This part of the Wiki is helpful in the details.

You didn't mention if you had tried the NeoApa106Method method.

NeoPixelBus<NeoRgbwFeature, NeoApa106Method> strip(PixelCount, PixelPin);

[scarr999]

Hi Michael,

I have tried

NeoPixelBus<NeoRgbwFeature, NeoApa106Method> strip(PixelCount, PixelPin);

And still nothing, be aware the code I sent and am using is just what I downloaded from advice on a forum, I am just stabbing in the dark a little bit as this project is for a festival and I am running out of time! The time I would normally take to fully understand it all :-( I will look at "*NeoRgbwFeature together with *NeoSk6812Method" today.

When I looked at the SK6812 datasheet and the data capture, to me it looks like the bit timings on these ebay LED'S are out of spec, however I might be wrong and I'm sure you looking at the data stream would quickly be able to say YES/NO, I have added a link to the capture below

Capture file https://drive.google.com/file/d/1ymTzq5M-Cv76v-0opH1eyaHxXhQmpNj4/view?usp=sharing

Thanks again.

On Tue, Jun 13, 2023 at 4:52 PM Michael Miller @.***> wrote:

I meant NeoRgbwFeature together with NeoSk6812Method. Your commented out line suggest this is what you were using.

The attachment wasn't made. I don't believe you can include attachments; you can imbed images, or you link to external files that you share using a service.

JFYI: This part of the Wiki is helpful in the details https://github.com/Makuna/NeoPixelBus/wiki/NeoPixelBus-object.

You didn't mention if you had tried the NeoApa106Method method.

NeoPixelBus<NeoRgbwFeature, NeoApa106Method> strip(PixelCount, PixelPin);

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1589588249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2WS2ZTK5YFF5IT2BULXLCEE7ANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

What Arduino are you using? AVR? ESP32?

Without this I can't provide changes for you to try.

[Makuna]

The capture shows a different timing and variable. From what I see:

0 - 320us-480us high with total pulse size of between 1440us and 1600us 1 - 960us-1120us high with a total pulse size of between 1600us and 1760us reset time unknown, but they are waiting 14ms between or 14000000us

usually these are output as ratio of total pulse, with a consistent pulse pw 0 = 0.25 pw and 1 = 0.75 pw

using the highest of 0 and lowest of 1 for pw 1600 0.25 = 400us (seems fine) 1600 0.75 = 1200us (a little long)

But each platform has unique timing restrictions so I can't proceed without knowing the micro controller (uC).

[scarr999]

Hi,

I'm using the Arduino Nano

I have added another file to the cloud that will hopefully give you the reset timing, to me it appears to be 1.2ms Reset delay https://drive.google.com/file/d/1cRtK_K6qX878Cnxtzleh_6ZyUpX_vKRO/view?usp=sharing

I am going to try the NeoRgbwColor today, EDIT: I have attempted this but I think if you have an example its best if I try that, I don't want to say it didn't work and find out it's because I can't code it properly.

I did try "NeoPixelBus<NeoRgbFeature, NeoApa106Method> strip(PixelCount, PixelPin);" but it didn't work either.

I agree with the interpixel gaps as these should not be required.

Steve

On Mon, Jun 12, 2023 at 3:33 PM Michael Miller @.***> wrote:

What Arduino/uC are you using?

Also need the reset time, the time between the last pixel of current frame and the first pixel of the next frame.

You did try the NeoRgbwColor and NeoSk6812Method when you declared your NeoPixelBus?

Also try the NeoApa106Method as it is close to the same timing that you included above.

Interpixel gaps can't be supported by all methods at all and only one method core supports it today, Esp8266 Dma methods. But in a previous investigation on a similar pulse form we found that the interpixel gap wasn't a requirement, it was a artifact of the crappy controller they included.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1587473653, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2VQXHPGF36LPJEWUVTXK4SFNANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

The issue is that you are using a nano. The Sk6812 should have gave you timing close to what you need. But the AVRs use hand written assembly code to time the pulses, and there is only a standard pulse ratio and timing on that platform. So, it will require another instance of hand written assembly to truly support sk6812 spec'ed timing.

[scarr999]

Hi,

I'm happy to pay for this if that helps?

On Thu, Jun 15, 2023 at 5:01 PM Michael Miller @.***> wrote:

The issue is that you are using a nano. The Sk6812 should have gave you timing close to what you need. But the AVRs use hand written assembly code to time the pulses, and there is only a standard pulse ratio and timing on that platform. So, it will require another instance of hand written assembly to truly support sk6812 spec'ed timing.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1593343066, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2QEMNKL4ZTDFY2TP7LXLMWWBANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

$2000 an hour? 8-)

This branch contains a new Apa106 timing (for 16Mhz AVRs only). Your Nano is running at 16Mhz correct? https://github.com/Makuna/NeoPixelBus/tree/AVRSk6812 Check the readme and you can clone directly into your libraries folder replacing your NeoPixelBus.

Use the method NeoApa106Method.

[scarr999]

Hi,

Really sorry, I'm still learning and I think I have done what you said but to make sure I've made a new link https://drive.google.com/drive/folders/1E1vRE605s7jBzmI1cJALZuI3SmQ4ANpf?usp=sharing This contains all the the files.

There are two new captures, one from the original controller displaying RED, called "original" and the other from the code I have just created with your library displaying the same intensity of RED (48). called "My Code" There is also the actual code itself called "My Code".

All this said it is still not working :-( to install the library I removed the old one by deleting the folder and restarting the IDE and then renamed the one you linked to from NeoPixelBus-AVRSk6812 to NeopixelBus-master and installed that via the IDE.

Sorry for being a pain / newbie and I really appreciate all your help and patience.

Steve

On Thu, Jun 15, 2023 at 7:26 PM Michael Miller @.***> wrote:

$2000 an hour? 8-)

This branch contains a new Apa106 timing (for 16Mhz AVRs only). Your Nano is running at 16Mhz correct? https://github.com/Makuna/NeoPixelBus/tree/AVRSk6812 Check the readme and you can clone directly into your libraries folder replacing your NeoPixelBus.

Use the method NeoApa106Method.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1593538446, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2UJ2REOZAXTPYQ2Q4DXLNHTTANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

I am confused by your captures. "Original" doesn't look like the previous ones you posted, it actually looks like what mine will output (no space between pixels and only 4 pixels). At the same time "My Code" looks more like the original (12us space between pixels and many pixels). Should I assume you got them swapped?

The general bit pulse form looks good and matches between them, so it does look like you have the changes. Notice from screen shot, they both have red (48), (0x30, 0x00, 0x00) (a pixel underlined in green, the next underlined in blue). Also notice which has the interpixel spacing.

Please confirm what you see when running the original controller. All LEDs are Red? How many LEDs in the strip?

The interesting thing I am seeing from the data from what I consider "original" (titled "My Code"), is that it is sending all zeros (black) to many pixels, and red to some.
Note that the first pixels output are black...

Note that the last pixels output are red...

You can count up the number of pixels from the output and with the above info you could see which are red and which are black. Does the order match what you visually see? Is the data for pixels in reverse order?

[scarr999]

Hi,

Yes, looks like I saved them as the wrong names, sorry!

---

Please confirm what you see when running the original controller. All LEDs are Red? How many LEDs in the strip?

---

The modes on the original controller don't have a all RED on mode, it was a progressive flashing RED LED 1 pulses then goes off LED 1, 2 pulse and then go off LED 1 ,2,3 pulse and then go off etc .etc

I captured it when it had illuminated quite a few and then isolated a section, I then changed "my code" to emulate the original controller so we could compare it side by side as in the screen shots There is 200 per strip but I have added two strips together with the original controller just to test what happens and the original controller illuminates 400 leds

---

The interesting thing I am seeing from the data from what I consider "original" (titled "My Code"), is that it is sending all zeros (black) to many pixels, and red to some.Note that the first pixels output are black...

---

This will be the pulsing effect the original controller does in the mode described above.

---

You can count up the number of pixels from the output and with the above info you could see which are red and which are black. Does the order match what you visually see? Is the data for pixels in reverse order?

---

I think the pulsing effect is confusing things regarding reverse order. I have dropped a video of this mode in the folder that might help things.

https://drive.google.com/drive/folders/1E1vRE605s7jBzmI1cJALZuI3SmQ4ANpf?usp=sharing

Thanks

On Fri, Jun 16, 2023 at 4:29 PM Michael Miller @.***> wrote:

I am confused by your captures. "Original" doesn't look like the previous ones you posted, it actually looks like what mine will output (no space between pixels and only 4 pixels). At the same time "My Code" looks more like the original (12us space between pixels and many pixels). Should I assume you got them swapped?

The general bit pulse form looks good and matches between them, so it does look like you have the changes. Notice from screen shot, they both have red (48), (0x30, 0x00, 0x00) (a pixel underlined in green, the next underlined in blue). Also notice which has the interpixel spacing.

[image: image] https://user-images.githubusercontent.com/7972357/246457473-d595bfdb-77ef-47fa-88d1-9658140ddf38.png

Please confirm what you see when running the original controller. All LEDs are Red? How many LEDs in the strip?

The interesting thing I am seeing from the data from what I consider "original" (titled "My Code"), is that it is sending all zeros (black) to many pixels, and red to some. Note that the first pixels output are black... [image: image] https://user-images.githubusercontent.com/7972357/246459435-fc4671ad-1aab-4bde-991c-456f3077ced0.png

Note that the last pixels output are red... [image: image] https://user-images.githubusercontent.com/7972357/246460438-66c66a7f-ad62-430b-8dc8-39d4e019948f.png

You can count up the number of pixels from the output and with the above info you could see which are red and which are black. Does the order match what you visually see? Is the data for pixels in reverse order?

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1594874621, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2V4PGUXIOCT2BCOCBDXLR3W7ANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

So, as it sits right now, you see nothing using the Nano?
Do you know the logic level of the original, what voltage the pulse is? The Nano will be 5v (unless yours is a 3.3v one but I thought those ran at a lower speed).
I will look at adding the inter-pixel delay next. Normally this isn't a requirement but an artifact of a uC in the controller; but as it sits now if you don't see anything, it sounds like it is.

[scarr999]

Hi, Yes, 5v as seen on the saleae logic traces and yes its a 5v nano.

I see nothing, not even a flicker.

I actually thought the same as you, so in an attempt to prove this, changed the code to output just ONE led's data hoping this would show up because there was no interpixel delay needed.

Still nothing! Tomorrow I will check data out with the single LED packet, see if its getting past the first LED meaning that the pulse widths are still not right.

UPDATE: The single packet appears after the first LED (if fact it appears after the fourth LED!)

Thanks

On Mon, Jun 19, 2023, 5:26 PM Michael Miller @.***> wrote:

So, as it sits right now, you see nothing using the Nano? Do you know the logic level of the original, what voltage the pulse is? The Nano will be 5v (unless yours is a 3.3v one but I thought those ran at a lower speed). I will look at adding the inter-pixel delay next. Normally this isn't a requirement but an artifact of a uC in the controller; but as it sits now if you don't see anything, it sounds like it is.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1597461394, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2QSBNEEU5RSGOEYOULXMB4TDANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

Ok, where does this leave us? The chip is repeating the signal to the next LED, but is not showing anything. Could you capture the output using the latest for a single LED? (make sure to include the amount of time between sends).

[Makuna]

Pick up the latest changes to the working branch. Use the NeoAvr600KbpsIpsMethod method. This adds the interpixel delay so it should now mimic the original near exactly.

[scarr999]

Hi,

Still not working, I have made a new folder with todays data in it, it's called 22_06_2023

https://drive.google.com/drive/folders/1E1vRE605s7jBzmI1cJALZuI3SmQ4ANpf?usp=sharing

I installed the library and complied, I then did a Saleae capture (MyCode_Capture_22_06_2023) I can see the interpixel delays but nothing on the LED’S.

I can see the same data at LED1 as I can at LED4, if I understand the SK6812 protocol the data should reduce by one 24bit packet after each LED as the LED removes it’s data and passes the rest on. but maybe I have misunderstood this?

I also have added excel spreadsheets that may make it easier to look at timings if you’re not using the Saleae software that is to view the actual capture.

Saleae capture files:

• MyCode_Capture_22_06_2023
  My code outputting 4 x RED (0x48) packets

• Original_Pulsing_RED

            Original controller output pulsing LED’s as shown on the previous video. You have to hunt for a 
            RED (0x48)

• Original_pulsing_RED_Two_packets

  Two full LED string packets from the original controller captured at the end of the string.

Excel spreadsheets:

• My_Code_Capture_22_06_2023

  The “MyCode_Capture_22_06_2023” capture data exported and formatted for ease.

• Original_pulsing_RED_Two_packets

  The “Original_pulsing_RED_Two_packets” capture data exported and formatted for ease.

• Side By Side Comparison

  One LED's data from both original and mycode including interpixel delay , each has a value of 0x48 and shows 
  the difference in timings.

Thanks a million for not giving up, this is what I love about coding, figuring stuff out, with a lot of help ;-)

[Makuna]

I am using the Logic 2 app to view the captures. And yes, after each pixel, the first pixels of data should have been removed. One way to make this clear is to set the colors uniquely like the following....

    for (auto pixel = 0; pixel < PixelCount; pixel++) {
        strip.SetPixelColor(pixel, RgbColor(pixel));
    }

Then capture after the first pixel (should start with values of 1 with one less pixels of data) and tenth pixel (should start with values of 10 with ten less pixels of data).

One thing I noticed from your capture that I do not see when I capture using my library is that the pulse width after a byte (every eighth pulse) is larger; being over 2us rather than 1.6 us.

Other than this, it all seems within tolerance.

NOTE: I define tolerance based on looking at the capture from the original device, where the pulses already vary some and I noted this earlier. I have to assume it can then handle similar deviation.

Also, count up the number of pixels from a capture and try setting it the same in Arduino sketch.

[Makuna]

A few changes were pushed to tuned ASM to get tighter signal matching.

• Byte boundary stretching of the pulse is within tolerance.
• 1 bit high lengthened a little to better sit in the middle of tolerance.

Pickup the changes and give it a try, along with other things previously mentioned.

[scarr999]

IT WORKS!!!!!

I'm still investigating things but if I send 192 packets NOTHING, 193 I get 1 LED, 194 I get two LED's it's as if they have unique addresses as these 4 LED's where checked off the end of the string I had!

I pushed the LED count to 400 and still working

Well, you have been brilliant, the best person I have worked with, thanks for not giving up and I will make a blog type post in the future about these LED string as it will help others I am sure (any suggestion's on the best place to make the blog appreciated)

Steve

[Makuna]

I wish we knew the actual model number of the LEDs/Chips. The sellers site states SK6812 but they are not following the protocol for those. This is something else.

So, you have to double the output? What actual NPB pixel index is the one used for the output color? Is the first pixel color set by calling SetPixelColor(0, color) or by SetPixelColor(193, color)?
I have seen Two Wire (DotStar) LEDs that need extra "bytes" to push/latch the signal through based on the string count and my library does that without using extra memory for a buffer. Maybe this is a similar case. If so I can adjust the code. Let me know.

You could link your project site within the Wiki here You could write a "topic tutorial" for the Wiki Here You could post a discussion linking a blog on Github.

[scarr999]

You master library works! using so it appears not to be a timing issue but the fact these LED's are addressed! NeoPixelBus<NeoGrbFeature, NeoSk6812Method> strip(PixelCount, PixelPin);

I originally cut 4 LED's from the end of the string (199,198,197,196), and after trying to get these to work I thought I might have blow them so cut a further 4 LED's (195,194,193,192) from the string and these are currently being used.

Having just 4 LED's I assumed! that I could set the pixel count to 4 and control these 4 LED's. (1,2,3,4)

However to get these 4 attached LED's to work I have to set the Pixelcount to 200 and then use the following and they light up correctly strip.SetPixelColor(192, red); strip.SetPixelColor(193, green); strip.SetPixelColor(194, blue); strip.SetPixelColor(195, red);

I have now without doubt confirmed that they have unique addresses. this as far as I am aware cannot be SK6812 LED's several test but one that confirmed it was making a longer string from two strings by adding 20 LED's making it 220 LEDs long, I set LED 1 to blue and 1 + 201 light up blue.

Steve

[Makuna]

Great info. I suspect there is some protocol to reset the addresses, otherwise this would be a real pain to manufacture.

I have been trying to find the technical term for this addressing, but the noise level that WS2812 LEDs have on search engines makes it difficult. Cascading? Serial? Consecutive?

I merged in the changes I have done as the code was useful for many reasons. The custom branch is gone.

I am still interested in adding support to reprogram the order if we can find details.

[scarr999]

Hi,

I agree about the painful manufacturing, I assume you have a logic analyser? If so, would it help if I purchased some of these and sent them to you so you can see things first hand?

(Very happy to buy some as you have been a fantastic help)

P.S. I have reconnected this longer string to the original controller to see if it does as we suspect assign addressed. it didn't :-( Both LED 1 and 201 responded as if there were LED 1. So, this must be end of the line production process. they do sell several lengths 5m/10/20m (50,100,200 LEDs) This very strange addressing will explain why we see the same 200 packets at the start and end of the string.

On Mon, Jun 26, 2023 at 3:19 PM Michael Miller @.***> wrote:

Great info. I suspect there is some protocol to reset the addresses, otherwise this would be a real pain to manufacture.

I have been trying to find the technical term for this addressing, but the noise level that WS2812 LEDs have on search engines makes it difficult. Cascading? Serial? Consecutive?

I merged in the changes I have done as the code was useful for many reasons. The custom branch is gone.

I am still interested in adding support to reprogram the order if we can find details.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1607594005, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2UZWXGSHMJNYYVK5QTXNGK6VANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[Makuna]

I ordered the 20m, just make a donation using GitHub sponsor feature or PayPal as listed in the Wiki/Readme.

I know a few LEDs have a header that you can send that puts them into a configure mode, but I have only seen properties like current limits. Your captures didn't include a header of any kind, but I will experiment to see if something triggers.

[scarr999]

Hi,

What's the best way of monitoring the status of you looking at these LED strings when they arrive?

[Makuna]

Tracking states by Sept 15th. I suspect they will get here way before that. I pinned this issue (shows in a box at the top of issues); do you see that?

[scarr999]

Thanks, dam that's a long time! Maybe as you say quicker, was hoping to get it sorted for a festival custume but hey ho,

I made a donation yesterday and I'd like to thank you again, best support I've ever had 👍👍

On Fri, Jul 7, 2023, 4:44 PM Michael Miller @.***> wrote:

Tracking states by Sept 15th. I suspect they will get here way before that. I pinned this issue (shows in a box at the top of issues); do you see that?

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1625604283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2QBXJ3VSYOESXWVMLDXPAVGDANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you authored the thread.Message ID: @.***>

[scarr999]

FYI, I have 100 confirmed they are allocated a number. When lighting LED 1 the same LED lights regardless of what end of the string I connect the wires to.

[Makuna]

@scarr999 They finally arrived. Now I need to schedule some time to investigate.

With your last statement, are you stating that you set the signal input to the other side (what may be called the output from the shipped wiring) and it still worked?!

[scarr999]

@Makuna Yes, I removed the OEM controller so I had just a length of LEDs no matter what end I connect to, if I turn LED 1 RED the same LED lights up. this indicates to me they are pre-allocated an address. [using my arduino] not the original controller

[Makuna]

Thats a new twist, either the data wire is parallel to the LEDs or they can support input/output swapping.

[scarr999]

Does this not go with what we found? each led does not take its data from the stream, it simply sees it? So at either end you see the full 200 leds data.

That way there is no in/out just a data line.

On Thu, Jul 20, 2023, 4:02 PM Michael Miller @.***> wrote:

Thats a new twist, either the data wire is parallel to the LEDs or they can support input/output swapping.

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/714#issuecomment-1644090985, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXVZO2WQE4677X3KHY7WLELXRFCBRANCNFSM6AAAAAAZDCPLXQ . You are receiving this because you were mentioned.Message ID: @.***>

[Makuna]

Confirmed that they are not only individually addressed, but that connecting it to the other side doesn't change the order. This means individually, the look for their own nth data item in a parallel stream of data. This is not like any other RGBIC out there that I know of. I have yet to find a way to reset the ID and so far, the only Hints provided to me from sellers is that each led/chip is unique. This may mean that they may not be reprogrammable.

Something I noticed is that the voltage on the far side of a 200 LED strip drops to near 3v from 5v; but they still seem to work.

[scarr999]

Hi,

Good to know I'm not loosing the plot :-)

I realise it might be impossible to figure out how to reprogram these, I'm not sure how I'd start tbh. I have new ones arriving, slightly different make but very similar, I will do the initial analysis based on what I have learnt and report back here .

P.S. The voltage drop is to be expected and just a by product of having 200 LED's drawing power down a single sided wire, this can effect brightness at the far end but can bi fixed by connecting power to both ends.

[Makuna]

All of these methods work also; in order of fastest to slowest.

NeoPixelBus<NeoRgbFeature, NeoWs2812Method> strip(200, PixelPin);
NeoPixelBus<NeoRgbFeature, NeoSk6812Method> strip(200, PixelPin);
NeoPixelBus<NeoRgbFeature, NeoWs2812xMethod> strip(200, PixelPin);
NeoPixelBus<NeoRgbFeature, NeoApa106Method> strip(200, PixelPin);

Also note, running directly with a 3.3v signal and 3.3v power works without level adjustment of the signal.

[Makuna]

So, summarizing... These LEDs are individually identified, so the nth will always be the nth no matter if the strip is cut or the signal is fed from the other side. They are functional using NeoWs2812xMethod with the knowledge of the above. I have found no way to software reset the id of each LED.

Not sure there is more I can do other than document this well in the Wiki.