Reading WS2812b leftover data through I2S

[Winz]

Hello there,

I am currently trying to read the leftover WS2812b LED strip data which was sent using a single channel I2S. The data sent from the board (through I2S) looks like this:

with around 34 mV for high and around 2~6 mV on low. I decided not to send FFF, but 888 instead.

I am aiming to calculate the length of the LED strip. Each LED chip will read the first 24 bits of the data, cascade (discard) it, then pass it to the next one. Therefore, the strategy is to get the data after being cascaded by the last chip and calculate the length of it (which later will be divided by 24 to see how many are left).

The question is: How will I be able to read those data? I tried reading as usual (set a buffer for the i2s, start it, listen for it (delay), stop it, then check its buffer), but I got my buffer filled with all FFF instead. and a thing is that... when I tried to read anything from the pin, although I am not sending any data (the LED strip is not powered on, but connected to other's ground), there will be data, which should not happen. I assigned pin 22, 23, 24, 25 to be the i2s input pin (which will be assigned and unassigned when used or unused), and they are configured as follows:

nrf_gpio_cfg_sense_input(DIN1_PIN, NRF_GPIO_PIN_PULLDOWN, NRF_GPIO_PIN_SENSE_HIGH);

Thank you in advance.

[Winz]

Oh, my bad.

I tried shorting pin 11 and pin 13 (which are the pin used to drive the LED and the pin used to receive leftover data). I am able to see that the PPI was working. Otherwise, still: the same delay. Cap8-no led.zip *Updated file*

The output of PPI was inverted. Probably since I did not set it somewhere. But I don't think it's a problem now

*edit*: This version is not inverted anymore. I've fixed it.

[Einar Thorsrud]

OK, so we agree that PPI works as expected. Then we can move on. What is actually the problem now? I have lost track of this thread...

[Winz]

Yes. PPI works. Otherwise, I am experiencing some inaccuracy. According to my 100 MHz Logic Analyzer, the HIGH signal was sent, from the end of a WS2812 or from nRF52DK's Pin 11, for +350 ns.

Otherwise, after being captured by the same nRF52DK's Pin 13, and being copied (by triggering) to Pin 17, the HIGH signal was sent only for +240 ns.

The same thing happened on LOW signal: sent: +900 ns, copied: +1.01 us.

I think a table will describe it better:

Something	Type	Acutal Duration	Copied Duration
Test 1	HIGH	350 ns	240 ns
Test 2	HIGH	340 ns	230 ns
Test 3	LOW	890 ns	1000 ns (1us)
Test 4	LOW	270 ns	130 ns
Test 5	HIGH	960 ns	980 ns
Test 6	LOW	900 ns	1.01 us
Test 7	HIGH	350 ns	240 ns
Test 8	LOW	890 ns	1000 ns (1us)

I hope this thing is visible

[Einar Thorsrud]

I see. If these are worst case numbers, then that is not unexpected. The 16 MHz peripheral clock means that you will have some variation on the GPIOTE sampling of the input signal. If you are looking at a pulse with two tranzitions, that means  up to two 16 MHz periods,  62.5 ns * 2 = 125 ns.

[Winz]

hmm, I don't quite get it. (Is the variation expected?)

Are you saying that I let GPIOTE to handle this accidentally? But I remember that GPIOTE is not fast enough to handle it. Therefore, I do not think it is GPIOTE.

In my case, one pulse (one high and one low) 1.24 us (~ 1240 ns). Is that what you mean?

I also read another question that (I think) is achieving the similar thing. If I am asking PPI to transfer the data to a timer, will I need to make 2 timers that does:
1. one records high (HT) and one waits for low (LT)
2. once a transition to low is sensed, PPI calls LT. LT stops and captures HT's duration and save it
3. once a transition to high is sensed, PPI calls HT. HT stops and captures LT's duration and save it

?