Raspberry Pi with WS2812b strips

You might damage your 'pi if you connect a 5V signal to your 'pi. Don't connect the "DOUT' signal of your strip to your 'pi.

You might not reliably transfer data from the PI to the 5V circuits because the "high" of the 'pi is only 3.3V. Officially the required level is "at least 3.5V". But in practise it will work reliably with the 3.3V that the 'pi provides.

So: My suggestion is: Just go ahead and try it.

Thank you Roger.

      As I already told that "I know that I must use a 3.3V to 5V voltage converter  to keep both strips and Pi safe."

      The thing I really wanted to know is

1) weather anyone has already done this?

2) what type of method would be more reliable python or C?

3) is there any available library for pyhton or C?

I am using RPi because I tried teensy and Uno and both are very slow for driving 300 led strips.

I need a refresh rate of 50Hz at least.

OK, As I already told you, I don't think the converter is necessary. Both your pi and strips are SAFE with out it. You /risk/ the leds not working if the 5V powersupply of the leds is "high" (i.e. rather nearer 5.5V than 4.5V).

1) yes. Not me though.

2) Both C and Python can be very reliable.

3) Yes. I think so. Use google to find it.

Are you placing them all in series? 300 strips of 60 leds means 18000 leds. Each led requires a fixed time to send it its data, thus when the datasheet says you can achieve 30Hz update rate at 1000 leds, that means you can only get about 2Hz when you have 18000 leds. This has nothing to do with whether you send the data using a teensy, uno or raspberry.

To get a reasonable update rate with 18000 leds you need to split the chains into 1000 leds maximum. And you need to find a way to drive all those chains in parallel. Consider chains of just over 1000 leds and only 16 chains. Then you'll get an update rate of just below 30Hz, but you have the "ease-of-use" that the transfers are exactly 16 bits.

I think that any library you might find will not be able to do these tricks required to drive so many leds.

Send me at least 5 led strips and 4800 dollars (60 hours at $80 per hour) and I'll write the software for you that can drive 16 chains of 1000 leds at the refresh speed the datasheet mentions. This will run on an STM32F405 processor on a board that I designed. The raspberry pi does not have 16 contiguous GPIO pins available that the tricks to do this reasonably require.

[edit] Ooops. I missed the "50Hz at least" of your post. If you require 50Hz refresh, I think the maximum chain length goes down to 1000/50*30 = 600. That would mean you'd need about 30 chains. My board does not have 2x16 contiguous gpio pins available. If you need that I need to redesign the hardware. Only 8 hours and $50 extra for the new hardware.

[edit2] I can guarantee the update rate of the leds. But I can't guarantee (right now) that you'll be able to feed enough bits into the board to sustain such an update rate. I'd have to do some math.... 18000 leds * 3 bytes/led * 50 per second = 2.7Mbytes/sec. USB won't cut it (12Mbps: I haven't been able to get 480mbps to work, I'll get that working in due time but not on a schedule with a deadline), but e.g. SPI might work. So you'll send the 54kbyte framebuffer to my board using SPI at 50 frames per second, and I'll send that to the 18000 leds within the next 20ms.

Thanks once again for your reply. But I am doing this to learn. So obviously if I pay you to do it, I would not learn anything. So sorry.

The thing you mentioned about max 1000 led at 30Hz rate is correct. Pi has 8 GPIO pins that can be used to control 8 led strips. So if say I could manage a 30Hz refresh rate then I can connect 8000 led per Pi. So I can use 3 Pi with MPI communication for synchronization.

That's about right. I'm not sure if you can synchronize the pi's enough to make the display "usable".

I'm guessing from the enormous amount of leds and the high refresh rate that you want to make a "video" display.... Having say the 'pi who handles the second one-third of the display  run 10ms behind will cause a difference that is visible to the naked eye. So synchronizing things will be difficult!

Similarly, you need to time the signals on the 8 GPIO pins to 150ns Accuracy. That's not going to be easy.

I have been looking into the feasibility of this too, I already have several Arduino custom solution running WS2811/2B LEDs, some on custom boards and some using the 60 LEDs per strip stuff. the issue you will find is that the PI can not guarantee maintaining the required 800Khz data rate reliably (A common issue with micro-processors running a multitasking OS like Linux, windows or other os), If you where to do this you will probably need to use C and directly interact with the hardware GPIO and may not be able to get more than a few LEDs working because of the above mentioned issue

What most people are doing in this space is to have an Arduino (ATMega ) or other Micro-controller do the refreshing of the LEDS and have the PI instructing the controller what pattern it requires. All the clasic micro-controllers have SPI or I2C support (TI MSP430, ATMEL ATMEGA etc) and are easy to interface to. by nature the micro-controllers are much more reliable at this kind of task (From a timing perspective)

A good platform to learn this technology and with the added benefit of learning distributed automation (More than one cpu in the system co-operating to perform a task) would be to get a Gertduino board from Element 14 ( http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/gertduino ), they are currently under review in the Road tests and there is plenty of information on how to use them. The AdaFruit Arduino libraries are the best I have found for driving the LED chips and I have tried quite a few) you can find the library here ( http://learn.adafruit.com/adafruit-neopixel-uberguide/arduino-library )

The issue with the Micro-Controllers is typically how much memory or lack there of and so if you get them to do too much thinking vs simply running the lights then you will run into problems. Have the PI or PC do the thinking and simply upload the patterns to the controller and you'll be able to do amazing things

If you need to know more, please let me know, ill see about digging out my code and stuff to share on the forum

Peter

At 54kbytes per "frame" the arduino-like processors are quite quickly "too small" for the intended number of leds. I think an STM32F4xx microcontroller has the DMA-capabilities to handle a significant number of led-chains in parallel. If I remember the specs correctly I'd say up to about 20kbytes of video-data per chip would be doable (you'd need to expand the raw video data to three bits-per-bit to allow the DMA engine to do its work (i.e. provide accurate timing) while the CPU does other things like expand the video data from one bit-per-bit to three bits-per-bit.)

But with $7500 in led strips it sounds like an interesting project with a larger budget than what I have available for my projects... :-)

Im not sure if Parag Kulkarni is trying to control 300* 60 LEDS, thats a bit more than an educational project, he may mean 5*60, Paraq, can you please confirm this fact.

I agree if it is truly 18000 LEDs then I agree a single controller would not be up to the task, but i'm not sure of I would simply put a single bigger controller in there either (My preference, not the only choice) I would have many smaller controllers assigned to banks of the strips so any single failure of a controller would not bring down the whole system

btw, 18,000 LEDs, the controller is the least of his worries, power (5V@0.06mA per LED * 18,000= 1080Amps or 5.4KW), cooling and other things are much more problematic with a system that large, this is why I think he will confirm it is actually 300LEDs (5*60 strips)

before I provide more help, it would be wise to hear from Parag Kulkarni regarding the actual number of LEDs.

If it's only 5 strips, I don't understand why the simple solutions in the first post don't work. moreover: He's said:

So if say I could manage a 30Hz refresh rate then I can connect 8000 led per Pi. So I can use 3 Pi with MPI communication for synchronization.

so I'm quite sure he means to use between 16k and 24k leds....

I agree, but that may just be hypothetical math at play here, he states this is a learning exercise, if your assumption is correct that is a very very expensive learning project, even the power supply and distribution wiring is going to run into thousands of $$$ ($2700 for the adapters), never mind the LED strips from Adafruit, that's an expensive way to purchase that many (7500$). This is why I think some of the statements are hypothetical, and some are fact, lets wait to hear from Parag.