Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RGB Fairy String/Micro Rice LEDs support #714

Open
ThunderChild999 opened this issue Jun 12, 2023 · 38 comments
Open

RGB Fairy String/Micro Rice LEDs support #714

ThunderChild999 opened this issue Jun 12, 2023 · 38 comments
Labels
documentation This issue is tracking a change in documentation and not in code

Comments

@ThunderChild999
Copy link

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

ebay
@Makuna
Copy link
Owner

Makuna commented Jun 12, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 13, 2023 via email

@Makuna
Copy link
Owner

Makuna commented Jun 13, 2023

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

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 14, 2023 via email

@Makuna
Copy link
Owner

Makuna commented Jun 14, 2023 •
edited
Loading

What Arduino are you using? AVR? ESP32?

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

@Makuna
Copy link
Owner

Makuna commented Jun 14, 2023

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

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 15, 2023 via email •
edited
Loading

@Makuna
Copy link
Owner

Makuna commented Jun 15, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 15, 2023 via email

@Makuna
Copy link
Owner

Makuna commented Jun 15, 2023

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

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 16, 2023 via email •
edited
Loading

@Makuna
Copy link
Owner

Makuna commented Jun 16, 2023

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

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

Note that the last pixels output are red...
image

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?

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 19, 2023 via email •
edited
Loading

@Makuna
Copy link
Owner

Makuna commented Jun 19, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 19, 2023 via email •
edited
Loading

@Makuna
Copy link
Owner

Makuna commented Jun 21, 2023

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
Copy link
Owner

Makuna commented Jun 21, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 22, 2023 •
edited
Loading

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
Copy link
Owner

Makuna commented Jun 22, 2023 •
edited
Loading

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
Copy link
Owner

Makuna commented Jun 22, 2023 •
edited
Loading

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 23, 2023 •
edited
Loading

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
Copy link
Owner

Makuna commented Jun 23, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 26, 2023 •
edited
Loading

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
Copy link
Owner

Makuna commented Jun 26, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jun 26, 2023 via email •
edited
Loading

@Makuna
Copy link
Owner

Makuna commented Jun 26, 2023

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.

@ThunderChild999
Copy link
Author

Hi,

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

@Makuna Makuna pinned this issue Jul 7, 2023
@Makuna
Copy link
Owner

Makuna commented Jul 7, 2023

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?

@Makuna Makuna mentioned this issue Jul 7, 2023
Open
@ThunderChild999
Copy link
Author

ThunderChild999 commented Jul 8, 2023 via email

@ThunderChild999
Copy link
Author

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
Copy link
Owner

Makuna commented Jul 19, 2023

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

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jul 20, 2023 •
edited
Loading

@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
Copy link
Owner

Makuna commented Jul 20, 2023

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

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jul 20, 2023 via email

@Makuna
Copy link
Owner

Makuna commented Jul 25, 2023

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.

@ThunderChild999
Copy link
Author

ThunderChild999 commented Jul 25, 2023 •
edited
Loading

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 Makuna changed the title Timing changes RGB Fairy String/Micro Rice LEDs support Jul 25, 2023
@Makuna
Copy link
Owner

Makuna commented Jul 25, 2023

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 Makuna added documentation This issue is tracking a change in documentation and not in code and removed enhancement labels Nov 20, 2023
@Makuna
Copy link
Owner

Makuna commented Nov 20, 2023

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.

@Makuna Makuna unpinned this issue Dec 16, 2023
@Makuna Makuna pinned this issue Dec 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation This issue is tracking a change in documentation and not in code
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Makuna @ThunderChild999