Reading the value I see on the oscilloscope

hi guys

there is a WS2812B rgb led working with 5v on a device.

how can i read the outgoing signal from led.

sample project:

sample code:

What do you want to read it with ?

Welcome to the forum,
Can you provide a schematic to make your question more clear?

arduino due?

there are 3 pins
1- gd
2- signal

Have a look here:

i won't run the led.

i want to read byte going to a working led.

48 bits of data goes out every 20 milliseconds.

It's pretty difficult to read/decode data with an oscilloscope. If you're sending one byte you can probably decipher it if you know the code/format (as long as you have a digital storage 'scope). I knew a guy who was pretty good at "reading" RS-232 as long as it was one or two bytes.

You could build a reader/analyzer with another Arduino... And by the time you're finished you'd be an expert on the WS2812! :smiley:

If you have an Arduino and the code (not some pre-made product) it should be easier to figure-out what the code is doing. :wink:

There is sample pic code.
how can i adapt it for arduino

Don't think that the format described to generate the pattern could help you to decode it?ws2812-timing1

It's surprisingly tricky to read the input from that automatically. That data goes by fast for an AVR; fast enough that even polling is messy. Especially if you care about more that the first or last pixel.

That's something I have some brilliant ideas for (if you see spots when you look away from me, that's because my ideas are just that brilliant. Either that, or my the ideas are so bad that you're going into shock and are about to pass out, always possible too)

I'd do it on an AVR DA or DB series, and I'd use a TCB in 1-shot mode to generate a rising edge when a 1 will be high but a 0 won't. And use that to latch a CCL LUT to the value of the data line.... then you jumper that line to MISO on a SPI in slave mode. CS line controlled by another TCB in timeout check mode (and, also, probably another jumper. then you just need an sck signal between each latch, from either a third TCB in single shot mode, just with a longer delay... or synthesize it some other way; I can think of multiple approaches there, depending on what peripheral you have the most of (for example, if you have extra LUTs, you have a 2 clock delay line for a transient or transition, and a 4 clock delay line that only works for transitions. . So that is all happening with no CPU interaction up until a each byte is received.... at which point, the SPI interrupt fires (or flag is set that you can poll as long as you hit it at least once per 10 us), copy byte to buffer.

You can do a somewhat similar thing - theoretically at least (neither of these is tested) to generate your own signal in an interrupt driven manner (I'd use the SPI in buffered mode for this, though the protocol is actually more tolerant than people realize of pauses between bytes).... Only there the magic would be that the MOSI line would be an connected to input 2 of a CCL , acting to switch the output between mirroring input 0 (which is generating short pulses from a timer) or input 1 (generating long ones, ie, 1's from the same timer.

I think the two can even be combined to edit pixels as they pass through, assuming your editing can be done within 200 clocks (on a 2-series at max rated speed) 240 (dx at max rated speed). With overclocking, you can get 32 MHz from 2-series and 40 on Dx (maybe even 48 - I have an AVR128DB64I that does 40 with crystal, but won't do 48, even from a clock, and a AVR128DB64E (extended temp range) that appears stable with a 48 MHz external clock). Not sure if that is typical, or one of them is exceptional. I think I did all my O/C research on the tinies with F-spec parts (extended temp range there too) since the premium is just a few cents a pop, so like, no hobbyist should ever be using the N-spec except due to chip shortages/