I've just discovered BlinkyTape, which is quite similiar to what I've been doing.

I’ve just discovered BlinkyTape, which is quite similiar to what I’ve been doing. I should be able to use their software which is cool! It appears to be using the Adafruit NeoPixel library but ultimately the hardware is much the same.
The main difference I can see is they’re using an Arduino Leonardo compatible (I’m using original). Why do you think this is? It has hardware serial, so maybe data transfers are faster?
http://www.kickstarter.com/projects/740956622/blinkytape-the-led-strip-reinvented?ref=live

I like them :). I’m curious how many pixels you are going to control? I’ve had success with 512 channels over serial to an rf transceiver -> to an rf receiver and then outputting to the pixels. They update within 22ms for the whole string with those speeds you can update faster than my eyes can see.
The nRF24L01 transceiver can go faster (its currently at 250kbps can go to 1mbps) but i didnt need it to. The Ethernet->rf transmitter can go faster too :slight_smile:

At the moment I just have one spool of 240 leds, I don’t know exactly what I will do with it but I have a lot of ideas (mood lighting, interaction, signaling, costumes, straight lines, loops, infinite depth, etc etc) and I will just play and see what works well.

Did you mean 512 pixels, not channels? If not what do you mean by channels?
If you’re using serial what is the bottleneck speed, PC serial to RF transceiver? 115200kbps?

I have only been experimenting with 30 leds so far just to keep things simple. As you can see in my other thread I’m having trouble with it going fast enough (or my expectations were too high). I haven’t calculated exactly how fast each row is to transfer but it takes 5-6 seconds to go through a whole cycle of 256 as a test. Which, actually, is about 23ms, the same as you quote for 512?
Sure it’s faster than you can see, but limits fast movements. I guess I will just see how it goes interactively.

I said channels and meant bytes, or 170 pixels (510 bytes of data). I didn’t experiment much beyond that. I scaled out with multiple transmitters /receivers on different channels to add more lights. I am only connecting one string of 50 pixels per Atmega so it made sense. It looks good though even with fast movement Chasing, fading etc works for me :slight_smile: But ya, its turtle slow compared to the speed of FastSPI!

Cool :slight_smile:
What’s slow compared with FastSPI?

Oh you implemented your own library for controlling the led strip?

ok, I should have mentioned that. Yes. I did used the FastSPI_LED2 to control the actual pixels The Arduino Sketch is available here: (http://tinyurl.com/l3fy43h). I am using my RFPixelControl Library(http://tinyurl.com/kgfe6ru
) and mainiacbug’s RF24 libraries to control the RF portion.

(randomly, a little birdie told me that blinky tape may be flipping over/has flipped over to using FastSPI_LED going forward :slight_smile:

smart birdie

I’ve been walking down a similar path, but I’m only using RF (nrf24l01+) to send signals (eq (from a spekrum shield) and the animation to play) to the two pieces (a dress and a chandelier).

I’ve found it fast enough to do sound reactive stuff, but I’m not getting all of the packets through consistently and so it doesn’t look quite right yet.

I quickly threw together a demo with some ws2811’s, a nrf24l01+, a teensy 3, the amazing FastSPI and Thomas’ great set of animations.

I use an arduino connected to my music source via a spektrum shield and that transmits the current eq setting along with the animation I want to send to the dress.

Nice. I have used JeeNodes in the past, they are arduino compatible with RFM12B radios attached, in either ~484, ~800 or ~914MHz varieties. I find them to be quite fast and reliable for low-latency purposes, even through walls. Plus they have ACK and resend capabilities, though that would affect latency.
A caveat is that they are not the same form factor so you can’t use existing shields without adapting them. Instead they have 4 “ports” for which the creator sells different sensors or output devices, which is pretty clever. The libraries are all very fast and reliable.

I was inspired by jeenodes to make my rf1 board… Like jee they are running on 3.3 but have the nrf24l01 on them and are more focused on running pixels.

How do the RFM12s and nrf24l01’s compare in terms of raw speed, reliability, distance, etc? Also ease of use? I guess what I’m saying is why not just use jeenodes? :slight_smile: You can put whatever code you want on them so I don’t see how they are “focused” better?

The jeenodes are moreso intended as remote low power sensors or home automation, but I found them quite fast (although I didn’t encounter any contention). I controlled a remote control car and servos using them and there was no noticable latency.

the nRF24L01 modules can handle up to 2mbps and distances of up to 700 feet or more depending on the radio. I am running them at 250kbps to increase the range further.

the RMF12 radio is somewhere between 9kbps and 38kbps from what I read so a bit slower.
The issue was also one of cost, I need to use 30 or more of the radios/nodes for my setup.

The nRF24l01 radio’s are also less than $1 and I managed to keep them on a footprint of 2.5cm x5cm and kept the total cost < 10$ total which is more than half the cost of a jee node.

I meant by focused was that I incorporated a trace capable of using the powersupply which is powering the atmega and providing it for the pixels to use up to 3a so i could run power to one string and have the controller and the string run off the same power.

OK cool. I think the jeenodes (as distinct from rfm12b) could do a bit faster, there was a post about it on the blog, it depends on traffic and noise and whether you wait for acks but maybe closer to 100kbps. Probably depends on the frequency you’re using too.

For less than $1 I definitely should give them a look… :slight_smile:

I looked into it and apparently the jeenodes (without library modification) can do about 350 packets per second, of only a few bytes each, so not really a lot of data transfer at all.