Go Down

Topic: How do ws281x LEDs "understand" arduino instructions (Read 408 times) previous topic - next topic

Barbouuuu

Apr 16, 2019, 08:17 pm Last Edit: Apr 16, 2019, 08:22 pm by Barbouuuu
Hello,

 recently I tried to understand more in details, how ws2812b leds are controlled by an arduino.
I found that through some kind of pwm, depending on the time the signal is at "HIGH" and at "LOW" it will be interpreted as either a 1 or a 0, therefore allowing to transmit 8bit to each color to define the brightness of each one.  ( each 24 bit of instructions will then be stored in data latches )

What I would like to understand is how with only a signal oscillator, a data latch, a signal reshaping circuit, the LED is able to, firstly, "sense" the  different periods of time, and then to make the "connection" between that and the change of voltage ( HIGH,LOW ) .

Secondly, once the 8 bits per color have been received, and stored into the data latch, how is the led able to understand what the binary instructions tell it to do ?

Thirdly, is it asynchronous or synchronous ?

Some link I used in my research

Thank you in advance,

Alexandre

PerryBebbington


Quote
What I would like to understand is how with only a signal oscillator, a data latch, a signal reshaping circuit, the LED is able to, firstly, "sense" the  different periods of time, and then to make the "connection" between that and the change of voltage ( HIGH,LOW ) .
Dunno, must be Japanese or something. Probably something.

Seriously, I don't know but I am confident in saying there is far more inside the controller of each pixel than you describe. I imagine there is some kind of dedicated controller specifically deigned to do all this. Unless someone from the manufacturer reads this and decided to spill their secrets you probably will never know, but it might be an interesting project making an Arduino do this.


Quote
Secondly, once the 8 bits per color have been received, and stored into the data latch, how is the led able to understand what the binary instructions tell it to do ?
That bit is simple, each 8 bit byte is just a value for a PWM controller, so there must be 3 PWM controllers, one for each colour and each requiring 8 bits.


Quote
Thirdly, is it asynchronous or synchronous?
I would say synchronous, although I am interested to know what anyone else says. As there is only a single wire for clock and data I think it probably recovers the clock from the data and uses that to clock the data in and the data out to the next pixel. Note I am inferring this from how they work, I don't actually know.

Anyone else care to comment?







Barbouuuu

#2
Apr 16, 2019, 10:33 pm Last Edit: Apr 16, 2019, 11:03 pm by Barbouuuu
Thank you very much for your detailed answer =)

After checking they do have a controller ship embedded inside them.

Also, the LEDs datasheet indicates the protocol used for communication is NRZ ( non return to zero ).
But the sites I went to said they were using " bit banging ".

Is one a subsidiary to the other ?

Basically they're all different applications of pwm right ?

Paul__B

Also, the LEDs datasheet indicates the protocol used for communication is NRZ ( non return to zero ).
I think that is a a very loose interpretation of the term.  Perhaps "bit-banging" is a bit closer to the truth.

Basically they're all different applications of PWM right ?
In a sense, yes.

According to a recently quoted article, the decoding is quite simple, based on a couple of timers.  When a negative-going pulse is received, it is compared to one timer; if the pulse is shorter than the timer, that represents one logic level, if longer, the other (I haven't looked to see which is which).  So you can call that pulse width modulation.

The pulses simply ripple through shift registers and overflow out the other end.  If no pulse is received for a certain second timeout, they are latched and become the data used for the PWM timers.  It doesn't seem all that complex.


PerryBebbington


Quote
They were using " bit banging ".
My interpretation of 'bit banging' is the tedious process of sending serial data (SPI, I2C, whatever) a bit at a time using software instead of using a hardware driver for the protocol.

Barbouuuu

#6
Apr 17, 2019, 09:40 pm Last Edit: Apr 18, 2019, 10:34 pm by Barbouuuu
I'm starting to think that bit-banging is not the real thing happening inside of those libraries ( FastLed and such ) that convert high level code into low level instructions, but rather the "technique" they use to figure it out.


But anyway the name does not matter that much since I now, thanks to you, have a basic understanding of what's going on inside the system.

Edit : Bit-banging is a way to "emulate" a communication protocol, be it I2C, SPI, or UART.
As the Arduino-Leds system uses bit by bit communication ( serial communication ), and uses only one pin ( that could be like TX ), would it be ok to assume that to communicate with those LEDs, the librairy is actually bit-banging UART ? ( but without the RX wire, not allowing the LEDs to "talk back" )

If so, that would make the communication scheme asynchronous right ?

a very cool link to understand bit-banging if you're interested

And lastly, can all signals used for communication like serial be qualified of pwm ?

Grumpy_Mike

#7
Apr 18, 2019, 11:40 pm Last Edit: Apr 18, 2019, 11:41 pm by Grumpy_Mike
Quote
would it be ok to assume that to communicate with those LEDs, the librairy is actually bit-banging UART ?
No.
The data format produced by a UART is a NRZ (none return to zero) with a start bit, 1 or more stop bits and an optional parity bit.

Quote
If so, that would make the communication scheme asynchronous right ?
Yes but it is not. WS2812 communication is a simple bit stream.

Quote
And lastly, can all signals used for communication like serial be qualified of pwm ?
No.
PWM is what the controller does with the data once it has it to control the brightness of each LED.

Quote
once the 8 bits per color have been received, and stored into the data latch, how is the led able to understand what the binary instructions tell it to do
The latch storing the data is a preset counter that actually generates the PWM.


Barbouuuu

But if it is synchronous , wouldn't it need another dedicated wire just for synchronizing their clocks ?

Sorry for the dumb question but I'm just getting into communications protocols and all so I don't quite get it ^^

Grumpy_Mike

The data stream is a mixture of clock and data. The clock comes from the fact that all the data bits are of the same period, the data part comes from the fact that you have a different duty cycle for one and zero.
So there is no need for a separate clock and data signal. This is sometimes known as Manchester encoding.

Paul__B

The clock comes from the fact that all the data bits are of the same period,
And according to that other article, that is not necessary; the clock can be somewhat asynchronous.  The data is encoded in the pulse duration.

Grumpy_Mike

Well that just says the timing requirement is not as tight as the data sheet says.
https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/
It doesn't change the basic mechanism, which is why the data sheet says what it does.

MarkT

Think of it maybe as asynchronous serial with one start bit and one data bit per symbol?

Anyway is a pig's ear of a protocol really, whoever designed it should be ashamed!
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Barbouuuu

Thank you very much everyone, my understanding of those LEDs is way better now =)

Go Up