Author Topic: Digital rgb ledstrip driven by RFDuino  (Read 38927 times)

tolson

  • Global Moderator
  • *****
  • Posts: 838
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Digital rgb ledstrip driven by RFDuino
« Reply #75 on: January 09, 2015, 08:15:38 PM »
Right, this is an ARM. The ideal situation would be to do the whole routine in assembly. The routine also has limitations based on if you are using the radio. Even though the routine is wrapped in no-interrupts the nRF51822 radio has priority even over that. There are other tricks to play when the radio is active.

cromas

  • RFduino Jr. Member
  • **
  • Posts: 26
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #76 on: January 09, 2015, 09:43:23 PM »
I attached a digital logic analyzer @ 24MHz (i.e. sampling rate of 41.666ns), transferred 0xFF 0x00 0x00, here were the results.



T0H: 0.500µs. Extreme tolerance of spec (350ns ± 150ns)
T0L: 0.937µs. Inconclusive whether this is in-spec (800ns ± 150ns) or not, but if it is, it's extremely close. (This one fell on the edge of my sampler, so the results alternated between 0.9583µs and 0.9167µs; I took the average)

T1H: 0.6666µs -- this is probably actually 0.6250µs (aka 10 16MHz cycles). Easily in-spec (700ns ± 150ns)
T1L: 0.9583µs. Out-of-spec by 208.3ns (600ns ± 150ns)


I'm quite rusty in assembly and a complete newcomer to ARM. tolson, is there anything we can do with the existing code to get this in-spec?
« Last Edit: January 10, 2015, 08:59:12 PM by cromas »

cromas

  • RFduino Jr. Member
  • **
  • Posts: 26
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #77 on: January 10, 2015, 12:55:41 PM »
I suppose it's possible that the issue here is not a protocol issue but a higher-level timing issue. The pattern I'm using is 21.2Hz for the whole pattern, with ten segments within the pattern, so I'm sending 212 updates/second. I was under the impression that this was well within the performance range of the WS2812, but perhaps I am mistaken. Or perhaps the issue is that I'm updating "mid-cycle" somehow for the WS2812, and I need to find a way to align my updates to avoid the behavior I'm seeing.

cromas

  • RFduino Jr. Member
  • **
  • Posts: 26
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #78 on: January 10, 2015, 09:57:53 PM »
If you're thinking about doing anything with WS2811, WS2812, WS2812B, NeoPixel, etc., this is a must-read:

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

tolson

  • Global Moderator
  • *****
  • Posts: 838
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Digital rgb ledstrip driven by RFDuino
« Reply #79 on: January 11, 2015, 03:20:53 PM »
I attached a digital logic analyzer @ 24MHz (i.e. sampling rate of 41.666ns), transferred 0xFF 0x00 0x00, here were the results.



T0H: 0.500µs. Extreme tolerance of spec (350ns ± 150ns)
T0L: 0.937µs. Inconclusive whether this is in-spec (800ns ± 150ns) or not, but if it is, it's extremely close. (This one fell on the edge of my sampler, so the results alternated between 0.9583µs and 0.9167µs; I took the average)

T1H: 0.6666µs -- this is probably actually 0.6250µs (aka 10 16MHz cycles). Easily in-spec (700ns ± 150ns)
T1L: 0.9583µs. Out-of-spec by 208.3ns (600ns ± 150ns)


I'm quite rusty in assembly and a complete newcomer to ARM. tolson, is there anything we can do with the existing code to get this in-spec?

The waveform and specification you are using are for the WS2812 and are tight. The WS2812B is different.
You can manipulate the number and positions of the NOPs to get it to work with your setup and/or convert more of the subroutine to assembler.  For the WS2812B the T1L measured is even more so out of spec, while the others are OK.
« Last Edit: January 11, 2015, 03:38:02 PM by tolson »

tolson

  • Global Moderator
  • *****
  • Posts: 838
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Digital rgb ledstrip driven by RFDuino
« Reply #80 on: February 21, 2015, 03:43:31 PM »
I'm adding a new twist to the digital RGB LED strip issues. I finally got around to playing with the APA104 clone of the WS2812B. According to the Chinese timing specs for the APA104 the timing should be way off compared to either the WS2812 or WS2812B. But, I found that it works fine with my loadWS2812B() subroutine. What's up with that?! I don't know. But here is the video of it working...


<a href="http://www.youtube.com/v/DoEngksCe5w/" target="_blank" class="new_win">http://www.youtube.com/v/DoEngksCe5w/</a>

I am having an issue with the APA104 strip though, in that upon applying power, all LEDs come on BLUE. To test if is was a timing issue like the WS2812(B) had earlier, I grounded the Data IN pin to the LED strip and cycled the power on and off. The BLUEs all come on. Hmm! So it is important to send zeros out to all the LEDs in the array as soon as possible during power on bootup. Anybody else seeing this with the APA104 LEDs?

<a href="http://www.youtube.com/v/gNNepE1uvBY/" target="_blank" class="new_win">http://www.youtube.com/v/gNNepE1uvBY/</a>


« Last Edit: February 21, 2015, 05:23:09 PM by tolson »

cromas

  • RFduino Jr. Member
  • **
  • Posts: 26
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #81 on: February 21, 2015, 04:24:15 PM »
tolson yes the blue-on-power is in the spec, somewhere. "By design."

The wordpress link I posted before explains much of how the protocol actually works. The LEDs have a 400 or 800 Khz internal oscillator. The weird protocol essentially comes down to latching bits after some multiple of cycles.

tolson

  • Global Moderator
  • *****
  • Posts: 838
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Digital rgb ledstrip driven by RFDuino
« Reply #82 on: February 21, 2015, 05:06:06 PM »
Yep, I know how they work. If you come across where the BLUE is suppose comes on "by design" please forward the reference. I suspect it is more like "oops". Does the "by design" spec say at what PWM level they come on at. Could really play badly with a power supply not expecting to run all the LEDs at the same time.

Thanks

cromas

  • RFduino Jr. Member
  • **
  • Posts: 26
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #83 on: February 21, 2015, 05:19:55 PM »
I will definitely send it if I can find it, but it's only a vague recollection. I'm sure you know there are more than a few poorly-translated "data sheets" for these, each claiming different timing specs. I could be mis-remembering some other forum post about them being blue on power-on, but I feel like I did see it at least described in one of those sheets. Maybe not "design" but at least "expected". But I hear you on the power-up concerns.

You might try contacting Daniel Garcia of FastLED fame. He knows these better than just about anyone I've spoken with. He might know.

randymgn

  • RFduino Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #84 on: May 24, 2015, 08:55:18 AM »
APA104 have the same shape as ws2812b,ws2811, can be compatible as ws2812b,ws2811, can be use same control with ws2812b". So mainly, APA104 are for maintaining compatibility with older strips while the APA102 are not.

SamDecrock

  • RFduino Newbie
  • *
  • Posts: 10
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #85 on: September 08, 2015, 09:08:50 AM »
Hi,

I updated Thomas Olson's code so that it resembles the NeoPixel API but without using the actual NeoPixel library. It works on RFDuino using the latest Arduino IDE (Arduino 1.6.5):

https://gist.github.com/SamDecrock/80e30c9bae734858d50d



bikemule

  • RFduino Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #86 on: September 08, 2015, 01:34:38 PM »
I got the gist above working with 400Mhz WS2812Bs by doubling the NOPs, but if I call RFduinoBLE.begin() any time before, I only get 0-5 LEDs lit.

digitalledcolor1

  • RFduino Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Digital rgb ledstrip driven by RFDuino
« Reply #87 on: June 10, 2016, 02:02:06 AM »
I'm adding a new twist to the digital RGB LED strip issues. I finally got around to playing with the APA104 clone of the WS2812B. According to the Chinese timing specs for the APA104 the timing should be way off compared to either the WS2812 or WS2812B. But, I found that it works fine with my loadWS2812B() subroutine. What's up with that?! I don't know. But here is the video of it working...


<a href="http://www.youtube.com/v/DoEngksCe5w/" target="_blank" class="new_win">http://www.youtube.com/v/DoEngksCe5w/</a>

I am having an issue with the APA104 strip though, in that upon applying power, all LEDs come on BLUE. To test if is was a timing issue like the WS2812(B) had earlier, I grounded the Data IN pin to the LED strip and cycled the power on and off. The BLUEs all come on. Hmm! So it is important to send zeros out to all the LEDs in the array as soon as possible during power on bootup. Anybody else seeing this with the APA104 LEDs?

<a href="http://www.youtube.com/v/gNNepE1uvBY/" target="_blank" class="new_win">http://www.youtube.com/v/gNNepE1uvBY/</a>
   APA104 have based color ,when you power them without signal ,it turn on blue , and when it start ,it also have blue color ,but it is fast, normally if you don't pay attention , you will not see it , and ws2812b and WS2813 led Will not have this situation .

tolson

  • Global Moderator
  • *****
  • Posts: 838
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Digital rgb ledstrip driven by RFDuino
« Reply #88 on: June 24, 2016, 10:36:28 AM »
  APA104 have based color ,when you power them without signal ,it turn on blue , and when it start ,it also have blue color ,but it is fast, normally if you don't pay attention , you will not see it , and ws2812b and WS2813 led Will not have this situation .

Experiment show that if you don't pay attention they stay on forever. You have to intentionally programatically turn them off as soon as possible in your program. If you do not, they never  go out. Not good for a power supply not expecting to supply maximum power for entire chain.

 

anything