Hi all, I've read through most of the issues related to RFduino and WS2812B

Archive FastLED Archive
1

Hi all,

I’ve read through most of the issues related to RFduino and WS2812B LED strips (60 LEDs). I am still having some troubles. I can’t connect with BLE without crashing the strip :/. Anyone have any suggestions? It seems that maybe wrapping every show() with noInterrupts(); and interrupts(); may be helpful… maybe?

Using Arduino IDE 1.6.8 and FASTLED 3.1 (tried a most recent pull with same results, so I rolled back)
Code Below:

#define FASTLED_ALLOW_INTERRUPTS 0
#include <RFduinoBLE.h>
#include “FastLED.h”

// Define PIN 5 to be the WS2812B data
#define PIN 5
#define NUM_LEDS 60
CRGB leds[NUM_LEDS];

void setup() {
pinMode(PIN, OUTPUT);

// Create the FastLED object
FastLED.addLeds< WS2812B, PIN>(leds, NUM_LEDS);
FastLED.setBrightness( 50 );
// Flash the strip to show it is on
noInterrupts();
wholeStrip(CRGB::White); FastLED.show(); delay(100);
wholeStrip(CRGB::Blue); FastLED.show(); delay(100);
wholeStrip(CRGB::Red); FastLED.show(); delay(100);
wholeStrip(CRGB::Green); FastLED.show(); delay(100);
wholeStrip(CRGB::Black); FastLED.show(); delay(100);
interrupts();
//Setup RFduino BLE
RFduinoBLE.deviceName = “RFduino”;
RFduinoBLE.advertisementInterval = 1000;
RFduinoBLE.advertisementData = “Hi”;
//RFduinoBLE.txPowerLevel = -24;
// start the BLE stack
RFduinoBLE.begin();
delay(100);
}
void loop() {
noInterrupts();
for(int dot = 0; dot < NUM_LEDS; dot++) {
leds[dot] = CRGB::Blue;
FastLED.show();
interrupts();
// clear this led for the next time around the loop
leds[dot] = CRGB::Black;
delay(60);
}
}
void RFduinoBLE_onConnect() {
// the default starting color on the iPhone is white
noInterrupts();
for(uint8_t i=0; i < 3; i++){
wholeStrip(CRGB::White); FastLED.show(); delay(100);
wholeStrip(CRGB::Black); FastLED.show(); delay(100);
}
interrupts();
}
void RFduinoBLE_onDisconnect() {
FastLED.setBrightness( 255);
for(uint8_t i=0; i < 2; i++){
noInterrupts();
FastLED.setBrightness( FastLED.getBrightness() * .2 );
wholeStrip(CRGB::Red); FastLED.show(); delay(20);
wholeStrip(CRGB::Black); FastLED.show(); delay(20);
interrupts();
}
}
// LED Constant For WHole Stripe
static void wholeStrip(CRGB c){
for(uint16_t i=0; i < NUM_LEDS; i++){
leds[i]=c;
}
}

2

The nrf51822 Bluetooth subsystem requires interrupts to be handled in a short period of time, and the nearly 2ms that interrupts will be disabled for when writing out a frame is too long. You can’t use setting ALLOW_INTERRUPTS to 0 and use Bluetooth on that chip.

3

Darn. A few weeks new to this, a lot to take in. Thanks for the help! Would switching to LPD8806 or APA101/102c alleviate this issue? I re-read some of your previous posts, and it seems the nrf51822 interrupts handling is just too slow. I am physical space limited, and the RFduino is super tiny, which is why I want to use it.

4

If you remove the allow interrupts line - then that will allow the bluetooth interrupts to fire - when that happens, the writing out of a frame of led data might be cut short - but I have code in place that tries to detect if/when that happens, and if so will do one more attempt to send the frame.

One way that you can work around this would be to split your leds into multiple, shorter strips - and run them off of multiple pins. This would reduce the odds even further of the writing out of a frame of led data getting interrupted in a way that would cause flicker that you would notice.

However - it turns out there was a bug in the way that I was doing this with the nrf51822 that I just checked in a fix for - so re-pull the latest FastLED code out of github :slight_smile:

5

@Colton_Bukowsky Strips that use a data and clock line can play safe with interrupts.

6

(Note: this ability to play nicely with interrupts and re-do frame transmits if an interrupt occurs directly came out of a contract job where we were using NRF51822’s with 20-84 leds and I had to make the world work with nordic’s stupid interrupt handlers (which can take an entire millisecond to run, WTH?) – the frame-resending thing was something that I added in to allow us to do the 84 led prop. (Of course, then I introduced a bug into that code a couple weeks ago, whoops)

7

Thanks for the bug fix Dan. Im getting better results, but for ~20 LEDs. I was hoping to scale to ~200 though, so I may or may not have enough pins. Sometimes you have to have the right tools for the job, so I placed an order for some APA102c’s, a bit sad to spend so much, but hopefully worth it!

Any reccomendend alternatives to the RFduino with a similar footprint/form-factor?

Thanks!

8

So, with the interrupt handling code that I have in place (and now fixed) - I found that I was able to drive about 85 leds at ~350fps. The problem is that BTLE sends updates on a somewhat regular schedule, which will cause the interrupts to fire, giving you an upper limit on the number of leds you can write out in a single strand. I’d say experiment with 50-100 leds to see what you can get away with before committing how many pins to use.

Unfortunately - you’re going to have similar issues with pretty much everything. As long as you’re running on a platform that requires regular interrupts to function (like the nrf51822 does with bluetooth or the esp8266 does with wifi) - you’re going to have interrupts fire and possibly interrupt frame writing (and possibly fire frequently enough that you will never have a long enough gap of time to write out a full frame). One thing you could do, in a pinch, is use a pair of nrf51822’s (or a 51822 and then something else) and have one nrf51822 handle incoming bluetooth data, and then have the other chip use something like SPI to pull data from the nrf51822 on it’s own terms/timing, vs. dealing with interrupts and pushes.

The ESP32 has two CPU cores, which means you could dedicate one core to writing led data, and the other core to dealing with wifi data/interrupts.

Alternatively - replace your WS2812’s with APA102’s, which don’t have the timing requirements that require disabling interrupts to function.

9

+Colton Bukowsky One nrf51822 alternative I like is the RedBearLab BLE Nano http://redbearlab.com/blenano/

10

@Tod_Kurt the BLE nano is an nrf51822.

11

APA102c strip came today :slight_smile: Tried to change it out, got the strip to turn on, can send some colors, but am having issues setting the color :(. Sending Explicit colors that are have 3 non-zero RGB values give the wrong color.

Any ideas?

Code is found here: LEDhoop/ColorWheelmodSPI1/ColorWheelmodSPI1.ino at master · soamaven/LEDhoop · GitHub
Colors on lns 68-69 come out white and then yellow, should be purple and “Hot Pink” respectively.

12

@Colton_Bukowsky Are you sure the color order is correct? https://github.com/FastLED/FastLED/tree/master/examples/RGBCalibrate

13

@Jon_Burroughs loaded .ino, to be triple-sure. Color orders are correct.
Odd thing is that there is some delay between lighting the first 5 LEDs and the last 1…

Maybe I should mention, I am not upshifting the DI or CI signals to 5V, could this be an issue? Might be a project killer since I was planning to run off 3.7V LiPos.

14

@Colton_Bukowsky Try and test with a 5v board to see if this is the cause before you determine your project a failure

15

I have since tried with a voltage up-shifter, but will try a 5v board also, though the effect should be the same though correct? Thanks for the suggestion

16

I think I may be having a similar issue with a Simblee board (made by RFduino, and I think is a nrf51). I documented it here: https://github.com/FastLED/FastLED/issues/294. @Colton_Bukowsky , can you try checking out FastLED commit 720f339 and see if it works? https://github.com/FastLED/FastLED/commit/720f339e3ca5d60ccc1217c0aa8c70e4f3314852

17

@Jason_Coon I saw your post yesterday and thought to myself “I should try that commit”. Thanks for the reply here. I’ve been away from my workshop, but will try this out in the next day or so and report back!

18

@Jason_Coon +Daniel Garcia Confirmed: commit 720f339 fixes my issues. Starting at cd2471 I have issues setting brightness reliably, and the causes issues when setting colors as described before.I also get flickering at lower brightness values via setBrightness(). Reverting to 720f339 I can properly set any color via explicit BGR values or via HTML colors.

So it seems that converting the SPI chipsets to use CPixelController base class in is causing issues for nrf51.

19

@Daniel_Garcia tag for comment regarding commit 720f39 above failed,

20

Thanks, Colton, for confirming it happens on RFduino and not just the Simblee. I’m still planning on trying to investigate the next chance I get.