Kimball and I have just bought some cool looking LEDs. They are RGB and
have a built in controller chip, so you feed them 5v and send them a 1 wire
control signal, and they stay that colour!
We split the cost (and the LEDs) between us, but I don’t need the full 100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
We split the cost (and the LEDs) between us, but I don’t need the full 100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
I’ll have some please, at least if there’s any left after the genuine
HACMEN have placed their orders.
-adrianOn Wed, Oct 24, 2012 at 2:21 PM, Bob Clough parag0n@ivixor.net wrote:
Hey All,
Kimball and I have just bought some cool looking LEDs. They are RGB and
have a built in controller chip, so you feed them 5v and send them a 1 wire
control signal, and they stay that colour!
We split the cost (and the LEDs) between us, but I don’t need the full 100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
Kimball and I have just bought some cool looking LEDs. They are RGB and
have a built in controller chip, so you feed them 5v and send them a 1
wire
control signal, and they stay that colour!
We split the cost (and the LEDs) between us, but I don’t need the full
100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
I’l have 20 :POn Oct 24, 2012 2:21 PM, “Bob Clough” parag0n@ivixor.net wrote:
Hey All,
Kimball and I have just bought some cool looking LEDs. They are RGB and
have a built in controller chip, so you feed them 5v and send them a 1 wire
control signal, and they stay that colour!
We split the cost (and the LEDs) between us, but I don’t need the full 100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
All gone.On Oct 24, 2012 2:21 PM, “Bob Clough” parag0n@ivixor.net wrote:
Hey All,
Kimball and I have just bought some cool looking LEDs. They are RGB and
have a built in controller chip, so you feed them 5v and send them a 1 wire
control signal, and they stay that colour!
We split the cost (and the LEDs) between us, but I don’t need the full 100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
Kimball and I have just bought some cool looking LEDs. They are RGB and
have a built in controller chip, so you feed them 5v and send them a 1 wire
control signal, and they stay that colour!
We split the cost (and the LEDs) between us, but I don’t need the full 100
I’ve bought. If you want to buy 20 of them off me for a fiver, give me a
shout.
I think this code is working more by luck than by anything else.
Assuming the pixels are set to high speed mode (800Kbps) then each bit
period is 1.25usec long. It appears that the WS2881 reads each incoming
bit by looking for a rising edge at the beginning of each bit cell, and
then sampling 1/2 way through each cell - if it’s high a 1 is being
transmitted, if it’s low then it’s a 0.
The example code is using a 4MHz SPI clock and writing 8 bits for each
bit of the value it is sending, either 0b10000000 for zero or 0b11110000
for a one. 8 bits @ 4MHz = 2usec per bit cell or an effective baud rate
of 500Kbps, whereas the spec says it should be 800Kbps, so it’s 37.5%
out - a huge margin. I think the only reason it works is because the
WS2881 must be re-syncing on the rising edge at the start of each bit
cell - if this was a normal async serial connection it just wouldn’t
work with that degree of clock skew.
What the code should be doing is writing 5 bits for each bit it sends,
say 0b10000 for 0 and 0b11110 for 1. 5 bits @ 4MHz = 1.25usec, which is
the specified bit cell length. Of course, writing 5 bits a time is a
lot more complicated to implement as there’s a more bit-fiddling to do
to marshal the 5-bit chunks into the 8-bit SPI output register.
On the AVR it may be possible to do this more easily with the USART
than with the SPI hardware. The USART has a synchronous mode where it
doesn’t use start/stop bits, using instead a clock signal on one of the
pins. If I’ve read the docs correctly, it should be possible to get
it to run at 4MHz (just!). The advantage of the USART is that it can be
set to transmit 5-bit frames, which will then give exactly the right bit
cell length of 1.25usec. The other advantage that the USART has over
the SPI hardware is that unlike the SPI hardware it is double-buffered,
so you can drive it at full line speed.
There’s other not-so-good stuff in the code as well, such as the use of
the modulo operator and multiplication instead of bit masking and
shifting. It might work OK on a 64Mhz PIC but on an AVR the
consequential multiplication and division operations will be problematic.
I think this code is working more by luck than by anything else.
Assuming the pixels are set to high speed mode (800Kbps) then each bit
period is 1.25usec long. It appears that the WS2881 reads each incoming bit
by looking for a rising edge at the beginning of each bit cell, and then
sampling 1/2 way through each cell - if it’s high a 1 is being transmitted,
if it’s low then it’s a 0.
The example code is using a 4MHz SPI clock and writing 8 bits for each bit
of the value it is sending, either 0b10000000 for zero or 0b11110000 for a
one. 8 bits @ 4MHz = 2usec per bit cell or an effective baud rate of
500Kbps, whereas the spec says it should be 800Kbps, so it’s 37.5% out - a
huge margin. I think the only reason it works is because the WS2881 must be
re-syncing on the rising edge at the start of each bit cell - if this was a
normal async serial connection it just wouldn’t work with that degree of
clock skew.
What the code should be doing is writing 5 bits for each bit it sends, say
0b10000 for 0 and 0b11110 for 1. 5 bits @ 4MHz = 1.25usec, which is the
specified bit cell length. Of course, writing 5 bits a time is a lot more
complicated to implement as there’s a more bit-fiddling to do to marshal the
5-bit chunks into the 8-bit SPI output register.
On the AVR it may be possible to do this more easily with the USART than
with the SPI hardware. The USART has a synchronous mode where it doesn’t
use start/stop bits, using instead a clock signal on one of the pins. If
I’ve read the docs correctly, it should be possible to get it to run at
4MHz (just!). The advantage of the USART is that it can be set to transmit
5-bit frames, which will then give exactly the right bit cell length of
1.25usec. The other advantage that the USART has over the SPI hardware is
that unlike the SPI hardware it is double-buffered, so you can drive it at
full line speed.
There’s other not-so-good stuff in the code as well, such as the use of the
modulo operator and multiplication instead of bit masking and shifting. It
might work OK on a 64Mhz PIC but on an AVR the consequential multiplication
and division operations will be problematic.
I believe the example code is for the pixels at 400Kbps.
It’s still wrong then - 500Kbps != 400Kbps
And according to the webpage that links to the source code:
The WS2811 recommended timing essentially divides the bit cell into fifths.
A 1 is sent as 1000ns high (4 segments) followed by 250ns low (1 segment),
while a 0 is sent as 250ns high and 1000 ns low. The fact is that either
approach will work, the only thing the pixel chip really cares about is the
state of the data line at 625ns.
That doesn’t agree with the intra-cell timings given in the datasheet, but
it does agree as to the overall cell length, 1.25usec, i.e. 800Kbps.
I guess we’ll just have to wait until they arrive to find out
I believe the example code is for the pixels at 400Kbps.
It’s still wrong then - 500Kbps != 400Kbps
And according to the webpage that links to the source code:
The WS2811 recommended timing essentially divides the bit cell into fifths.
A 1 is sent as 1000ns high (4 segments) followed by 250ns low (1 segment),
while a 0 is sent as 250ns high and 1000 ns low. The fact is that either
approach will work, the only thing the pixel chip really cares about is the
state of the data line at 625ns.
That doesn’t agree with the intra-cell timings given in the datasheet, but
it does agree as to the overall cell length, 1.25usec, i.e. 800Kbps.
I guess we’ll just have to wait until they arrive to find out
Just got hold of mine tonight from Bob, gonna see if I can drive them
from the USART in synchronous mode. For power, did you use any current
limiting with it, or did you just wire the LED up directly to 5V?
Yes And thanks as they show with voltage is for the LEDs and which is
the controls :)On 15 November 2012 20:16, Alan Burlison alan.burlison@gmail.com wrote:
I’ve got the datasheet for the controller, but not the pinout of the
pixels themselves. Are they as per the pinout on this page?
Yes And thanks as they show with voltage is for the LEDs and which is
the controls
For testing I’ve just wired them together, I’m sure they’ll need a
separate 5V for longer runs, and caps.
Oh current limiting, not sure.
Actually, I think they probably don’t. The WS2811 datasheet says:
Built in stabilivolt, Only add a resistance to IC VDD feet when under
24V power supply.
Which if if I have my Chinglish straight means ‘no’, and if you look at
the attached image of them on a strip there’s just a cap next to each
LED and nothing else.
I noticed the code you posted on github wasn’t displaying red properly so
I’ve fixed that in my copy.
I adjusted the on/off times to 250nsec/1000nsec to match the datasheet that
Bob sent a link out to, and that seems to work fine too - the timings don’t
seek to be all that critical.
I also noticed that the data order in the datasheet is wrong, it has to be
sent GRB not RGB.
And finally, I stuck the scope on the output and measured the actual times
on my tweaked version of the code they are about 62nsec longer than the
value that’s passed to the _delay_ns function, or about 1 instruction. The
original version showed a bit more variability, not sure why.On 15 November 2012 21:31, Alan Burlison alan.burlison@gmail.com wrote:
On 15/11/2012 20:50, Kimball Johnson wrote:
Yes And thanks as they show with voltage is for the LEDs and which is
the controls
For testing I’ve just wired them together, I’m sure they’ll need a
separate 5V for longer runs, and caps.
Oh current limiting, not sure.
Actually, I think they probably don’t. The WS2811 datasheet says:
Built in stabilivolt, Only add a resistance to IC VDD feet when under 24V
power supply.
Which if if I have my Chinglish straight means ‘no’, and if you look at
the attached image of them on a strip there’s just a cap next to each LED
and nothing else.
I noticed the code you posted on github wasn’t displaying red properly so
I’ve fixed that in my copy.
I adjusted the on/off times to 250nsec/1000nsec to match the datasheet that
Bob sent a link out to, and that seems to work fine too - the timings don’t
seek to be all that critical.
I also noticed that the data order in the datasheet is wrong, it has to be
sent GRB not RGB.
And finally, I stuck the scope on the output and measured the actual times -
on my tweaked version of the code they are about 62nsec longer than the
value that’s passed to the _delay_ns function, or about 1 instruction. The
original version showed a bit more variability, not sure why.
Yes And thanks as they show with voltage is for the LEDs and which is
the controls
For testing I’ve just wired them together, I’m sure they’ll need a
separate 5V for longer runs, and caps.
Oh current limiting, not sure.
Actually, I think they probably don’t. The WS2811 datasheet says:
Built in stabilivolt, Only add a resistance to IC VDD feet when under 24V
power supply.
Which if if I have my Chinglish straight means ‘no’, and if you look at
the attached image of them on a strip there’s just a cap next to each LED
and nothing else.
Seems I have it working now, i’ll put up the code later.
I misunderstood your timeings - they are high speed. No idea why red
wasn’t working on my original, but I think the bringing the line up
high again after the reset was the issue - misinterperation of the
datasheet by my Father and I.
I noticed the code you posted on github wasn’t displaying red properly so
I’ve fixed that in my copy.
I adjusted the on/off times to 250nsec/1000nsec to match the datasheet that
Bob sent a link out to, and that seems to work fine too - the timings don’t
seek to be all that critical.
I also noticed that the data order in the datasheet is wrong, it has to be
sent GRB not RGB.
And finally, I stuck the scope on the output and measured the actual times -
on my tweaked version of the code they are about 62nsec longer than the
value that’s passed to the _delay_ns function, or about 1 instruction. The
original version showed a bit more variability, not sure why.
Yes And thanks as they show with voltage is for the LEDs and which is
the controls
For testing I’ve just wired them together, I’m sure they’ll need a
separate 5V for longer runs, and caps.
Oh current limiting, not sure.
Actually, I think they probably don’t. The WS2811 datasheet says:
Built in stabilivolt, Only add a resistance to IC VDD feet when under 24V
power supply.
Which if if I have my Chinglish straight means ‘no’, and if you look at
the attached image of them on a strip there’s just a cap next to each LED
and nothing else.
Seems I have it working now, i’ll put up the code later.
I misunderstood your timeings - they are high speed. No idea why red
wasn’t working on my original, but I think the bringing the line up
high again after the reset was the issue - misinterperation of the
datasheet by my Father and I.
Yes, I’m using high speed timings and yes, I seem to remember the issue
with red was as you say, although I’ve hacked the code a lot since then
so I don’t have that version around any more.
Here’s a version that steps through the 7 primary/secondary colours and
then does a slow fade across them all. Note I’m using pin 0 on portb
rather than pin1 so you should change the PIN #define appropriately.
I can see glitching on some of the fades on the attached code. The
timings on the datasheet are ±150nsec and on the AVR at 16MHz each
instruction takes 62.5nsec, so we are talking about less than 3
instructions. The unavoidable loop overhead is going to skew the
timings, probably enough to cause the glitching I’m seeing. To get
reliable operation, it’s probably going to be necessary to drop into
assembly.
And thanks as they show with voltage is for the LEDs and which is