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.
On Wed, Oct 24, 2012 at 2:21 PM, Bob Clough <para...@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.
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
> I'll have some please, at least if there's any left after the genuine
> HACMEN have placed their orders.
> -adrian
> On Wed, Oct 24, 2012 at 2:21 PM, Bob Clough <para...@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.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "HAC:Manchester" group.
> > To post to this group, send an email to hacman@googlegroups.com.
> > To unsubscribe from this group, send email to
> > hacman+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/hacman?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
> 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.
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
> 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.
> On Oct 24, 2012 2:21 PM, "Bob Clough" <para...@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.
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
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.
> --
> Alan Burlison
> --
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
On 29 October 2012 06:06, Kimball Johnson <kimb...@bowerham.net> wrote:
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 :-)
> On 29 October 2012 06:06, Kimball Johnson <kimb...@bowerham.net> wrote:
>> 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 :-)
> --
> Alan Burlison
> --
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
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?
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to hacman+unsubscribe@**
> googlegroups.com <hacman%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/** > group/hacman?hl=en-GB <http://groups.google.com/group/hacman?hl=en-GB>.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "HAC:Manchester" group.
>> To post to this group, send an email to hacman@googlegroups.com.
>> To unsubscribe from this group, send email to hacman+unsubscribe@**
>> googlegroups.com <hacman%2Bunsubscribe@googlegroups.com>.
>> For more options, visit this group at http://groups.google.com/** >> group/hacman?hl=en-GB <http://groups.google.com/group/hacman?hl=en-GB>.
> 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.burli...@gmail.com> 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.
> On 15 November 2012 21:31, Alan Burlison <alan.burli...@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.
>> --
>> Alan Burlison
>> --
> --
> Alan Burlison
> --
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
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.
thanks.
Kimball
On 16 November 2012 09:44, Kimball Johnson <kimb...@bowerham.net> wrote:
> As these are (allegedly)¡ high speed mode this is why I halved the times.
> I know red wasn't' working - what did you do?
> Can you paste your version of the code?
> Kimball
> On 16 November 2012 01:02, Alan Burlison <alan.burli...@gmail.com> wrote:
>> 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.burli...@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.
>>> --
>>> Alan Burlison
>>> --
>> --
>> Alan Burlison
>> --
>> --
>> You received this message because you are subscribed to the Google Groups
>> "HAC:Manchester" group.
>> To post to this group, send an email to hacman@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hacman+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hacman?hl=en-GB.
> 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.
> 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.
I've tweaked the timings some more and as far as I can tell the glitching is gone. I could have gone through the disassembly and carefully counted clock cycles but instead I cheated, stuck it on the storage scope, measured the amount the pulses were out and just subtracted that from the timings passed to the _delay_ns() call :-)
I'm still not convinced that these things are entirely practical when driven from a 16MHz AVR because of the high clock rate and tight timing constraints. I'm going to see if I can devise some way of getting some form of hardware assist rather than just bit-banging, because I think but-banging is going to be impractical when trying to drive a reasonable number of these whilst doing anything else at all.
> I'm still not convinced that these things are entirely practical when
> driven from a 16MHz AVR because of the high clock rate and tight timing
> constraints. I'm going to see if I can devise some way of getting some
> form of hardware assist rather than just bit-banging, because I think
> but-banging is going to be impractical when trying to drive a reasonable
> number of these whilst doing anything else at all.
They are practical - just. There wasn't any way to realistically generate the required waveform in hardware because the shortest pulse you have to send (250nsec) equates to just 4 instructions at 16MHz. After some googling around I ended up using 250nsec and 1000nsec as the two hi/lo periods rather than the somewhat odd ones given in the datasheet. I've written some assembler to do it, which is compact (around 120 bytes). The assembler generated if you use the delay_x.h routines comes out as a huge loop-unrolled routine, and it jitters badly anyway.
I need to finish this up properly, but here's a screenshot of the hand-crafted assembler outputting one byte of 0x0F. It's running at exactly 800KHz/bit :-)
> 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!
I tried ordering 100 of these from aliexpress but I got a mail back saying that payment could not be verified (I used a VISA card). How did you pay for yours?
> I tried ordering 100 of these from aliexpress but I got a mail back saying
> that payment could not be verified (I used a VISA card). How did you pay for
> yours?
> --
> You received this message because you are subscribed to the Google Groups
> "HAC:Manchester" group.
> To post to this group, send an email to hacman@googlegroups.com.
> To unsubscribe from this group, send email to
> hacman+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hacman?hl=en-GB.
