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.

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);

What Arduino are you using? AVR? ESP32?

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

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).

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.

$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.

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?

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.

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).

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.

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 ;-)

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.

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.

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

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.

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

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.

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.

Hi,

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

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?

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.

@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?!

@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

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

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.

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.

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.

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.