Raspberry Pi with WS2812b strips

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.

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.