I am a programming amateur, arduino noob, trying to decide which board will be better for my project. I need a small board. I am trying to decide between the Teensy 3.2 and the RFduino. I want to have blue-tooth capability for over air routine changes to a WS2812B LED strip, which makes the RFduino attractive because of its integrated BLE4.0 antenna. However, I want to be able to have enough speed for imperceptible LED modulation, which makes the 72MHz speed of the Teensy attractive.

What would be the objective difference between the 16MHz processor on the RFduino versus the 72MHz on the Teensy3.2? Is this something I should be concerned with?

  • What sort of LED strip?
    – Nick Gammon
    Commented Apr 3, 2016 at 6:30
  • Planning on 3M of 60LED/M WS2812B strip as of now.
    – aeolus
    Commented Apr 3, 2016 at 7:16
  • You'll have to set some kind of timing requirement. Like: I want to be able to send and execute a bluetooth message in .. milliseconds. That's where it gets interesting. You might come to the conclusion that bluetooth is the limiting factor (thus a higher clock speed won't help a thing).
    – aaa
    Commented Apr 3, 2016 at 12:52
  • 1
    On the LED strips, the WS2812B's have a fixed timing, so a faster processor != faster LED strip you might try a "DotStar", SPI-controlled or APA102 led strip. In that case, faster SPI = faster LED strip. But those strips need 64 extra bits and 8 bits extra per LED.
    – aaa
    Commented Apr 3, 2016 at 12:56

3 Answers 3


You have to set your requirements, or atleast elaborate what you want to achieve.

Best would be to program in a set amount of effects on the microcontroller and only send which effect you want to "start" with maybe even a color.

But you have to specify stuff, you should make a list like this:

Length of messages
(Max) baudrate of bluetooth device & microcontroller

amount of bits in the total LED strip
speed of sending bits into the LED strip

Maximal time from sending to effect

Sample calculation for NeoPixel (WS2182)

If you can make a good approximation (or find actual values) you can determine which speed you are going to need. This might even be 1Mhz, try to avoid premature optimization.

60 leds/m for 3M = 180 leds. 24bit data per LED.

180*24 = 4320 bits of data.

One bit takes around 1,3uS, so 4320*1,3 = 5616 uS Which is 5,616 milliseconds to update the LED strip. (Processor Mhz won't help you here)

Sample calculation for DotStar (APA102)

180 leds, 32bit per LED = 5.760 bits total. +64 bits (32bit start frame, 32bit end frame). 5824 total bits.

You can set the SPI clock divider to 2. So if your board runs at 16Mhz, divided by 2, you get 8Mhz SPI output.

8 megahertz = 8 000 000 hertz


The fastest rate is "divide by 2" or one SPI clock pulse every 125 nS. - Nick Gammon (http://www.gammon.com.au/spi)

Neopixels take 0.85us + 0.4us = 1,25 us (1250ns). So they would be 10x slower.

(never mind this calculation, it was from before using Nicks' facts)

8.000.000  |  5824
 1 sec     |   x

(Your x value will be the time in seconds to update the DotStar strip with SPI@8Mhz)

What was your point?

After this you can check your baudrate + message length to see how long sending/receiving your message will take.

You can then reliably tell if you need 1, 8, 16 or 72Mhz.

I believe the DotStar led strips should be faster, but I haven't completely calculated it out. You could ask yourself if it's worth trying to omptimize that.

BUT, note that the DotStar/SPI led strip allows you to have "interrupts". Which means you can receive characters over the bluetooth while you're writing to the LED strip.

And, we're probably overthinking the situation. But it's better to overthink it using hard values :)


As was mentioned earlier about the DotStar LED strip/led

There is one thing missing in the calculation above. The End Frame shows as a 32 bit frame of all 1's. That is almost correct. The least obvious is that you need to add 1/2 of a bit for each led in the strip. This is due to the way that the clock is sent down the line. So the 180 led strip would require 90 bits in the End Frame. If you don't do this you will have some of the leds at the end that are not reacting correctly. I know this sounds strange, had me for a while (I use Raspberry Pi).

Also, I have seen where some have tested the SPI mode of sending the data down the line and managed to achieve about 16Mhz clock speeds. Great for POV display.

The DotStar don't require refreshment at all. Each LED has it's own PWM chip built in. They are more expensive than the Neopixel, so it depends on the application as to which is better for you. I loaded my string with colors and then disconnected the data lines (led strip on different power supply) and turned off my Pi. Yup, the DotStars stay as they are.

It has been said they are 'addressable' which is not truly accurate. When sending data, it is the first one, then the second and on. If you wanted, you can change only the first few. Odd hack. Just send the Start Frame (32 or more 0's) and start sending data to the first without affecting the rest of the strip. Note: you might have to account for the 1/2 bit clock loss. eg: 1 bit per 2 leds.

Here is a pretty good description of the DotStar functionality : https://cpldcpu.com/2014/11/30/understanding-the-apa102-superled/

Here is a Youtube tutorial (2 short videos) that helped me quite a bit: https://www.youtube.com/playlist?list=PLhXSL6B3uLd551fEQlQGd3LrhzvudKfJQ


You would think on the face of it that a faster processor will give you "more speed" however that does not necessarily work in a linear way. The faster processors tend to have more sophisticated chips. And "more sophisticated" can be code for "it takes more clock cycles to achieve the same thing".

I have code that drives 300 NeoPixels in a seamless manner, on a 16 MHz Arduino Uno, however during the driving it is pretty processor-intensive (and interrupts have to be off). So certainly you can have some smooth effects at 16 MHz. However controlling them in real time, via Bluetooth, may be a different thing.

NeoPixels will "remember" the last thing that was sent to them, so (when interrupts are active) you could be accepting new instructions, and the pixels will just display what they were last sent. This may be acceptable for you.

The Adafruit page for RGB LED Strip mentions that their library is only for the AVR processors. So that may be a consideration for you.

Even with other display strips, you may find that, during reception of radio signals, the strips cannot alter their patterns at high speed. The 72 MHz you quoted is only 4.5 times as fast as 16 MHz. The NeoPixel timings are in the order of nanoseconds (350 ns for a zero-bit) so timing is tight. Having 4.5 x the clock speed isn't necessarily going to give you enough leeway to do radio communications.

I just want to be able to select and change the program remotely via BLE, rather than send sequential commands over air. Does this change your answer at all?

Your design seems to me to consist of two components:

  • Showing some pattern
  • Receiving a new pattern (or code for a new pattern)

You can't be doing both at precisely the same time. (Maybe with two processors you might - one doing the radio, and one displaying the pixel pattern). I found I could refresh 1000 pixels in 63 ms, which is roughly 16 FPS. If you have less pixels it will be faster. I don't know exactly how long it takes to determine if a Bluetooth message has arrived, I assume not particularly long.

Planning on 3M of 60LED/M WS2812B strip as of now

So, 180 pixels. At 63 µs per pixel that would be 11.3 ms to refresh the strip. You can see that this gives you quite a bit of time over in one second to receive new instructions.

  • I see now that I should elaborate more on "real-time". I just want to be able to select and change the program remotely via BLE, rather than send sequential commands over air. Does this change your answer at all? Edited in original question. Also added the LED IC spec -- could you confirm that WS2812B "remembers"? I have only found literature that LPD8806 "remembers" as you describe.
    – aeolus
    Commented Apr 3, 2016 at 7:28
  • Certainly the WS2182 pixels that I have a page about here (amongst lots of pages that other people have) remember the setting. If you disconnect the Arduino (but leave power to the pixels) they retain the last setting. That's how they are designed. A 10 µs (or so) gap in sending any bits latches the previous setting. Once latched it stays there indefinitely.
    – Nick Gammon
    Commented Apr 3, 2016 at 10:46
  • @aeolus you only have to write to the strip when you want to change it. If everything would be lost immediately, you wouldn't be able to work with these strips ;)
    – aaa
    Commented Apr 3, 2016 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.