Can I use this with 12v leds? #7
Comments
|
Huh? There are better forums to ask this question. This forum is specifically for this WS281x LED RaspberryPi driver. |
|
Sorry let me rephrase my question: Will this library work with 12v ws2812 pixels? |
|
This software library is independent of the electrical environment. If these LEDs are ws821x signal compatible, they will work as long as your electronics are properly designed and implemented. Sorry, I can't advise you. Get the spec sheet and be careful. I'd be very surprised if they really ran at 12v. If you fry something, be sure to send pictures. |
|
If it's a strip of pixels you might cut off the last one to experiment with too. Just be careful not to let 12V onto any of the pins that touch the Pi as it could damage them. I haven't seen 12V WS2812 pixels myself, but maybe try them first at 5V to see if they work. |
|
Ok thanks/ Fried pictures to follow! |
|
@gavspav did you manage to get this working? I want to use 12V as well, unsure about the signal input, I guess it just works with 3.3 or 5V, and the 12V is simply for the LED power? |
penfold42
added a commit
to penfold42/rpi_ws281x
that referenced
this issue
Feb 8, 2019
* Added delay to ensure reset time being met with low led counts (jgarff#157) * Fix includes as per jgarff#178 (jgarff#189) * clean up doco and strandtest (jgarff#187) * updated documentation on GPIO usage strandtest now defaults to GRB colour order added version.h to gitignore * updated python readme * more README cleanup * added notes on spi max transfer size * Fix freeze after running for long time (jgarff#197) * Whitespace cleanup * Move channel_protocol_time so it handles 32 bit Color LEDs. * Fix a freezing issue when running for a long time. When current_timestamp overflowed 2^64, rolling back to 0 and ws2811->render_wait_until had not, this caused an incredibly long usleep in ws2811_render. * Update README.md (jgarff#191) * Update README.md * updated spi buffer size location * Add -lrt link flag for systems with older glibc (jgarff#195) * Fix 32-bit overflow in get_microsecond_timestamp(). (jgarff#206) On Raspbian systems, the tv_sec member of struct timespec is 32 bits wide. get_microsecond_timestamp() was overflowing in 32-bit arithmetic on this member. This causes the time that it returns to jump ahead by many thousands of years at uptime = 35 minutes, 48 seconds. (While the starting point for CLOCK_MONOTONIC_RAW is unspecified, it seems to track system uptime in practice.) This overflow didn't cause noticeable problems for me--ws2811_render() skips the sleep when it thinks such a huge amount time has elapsed--but it could possibly result in rarely-occurring skipped frames if the WS2811 reset time isn't effectively honored by ws2811_render(). * Add TOOLCHAIN option for cross compilation (jgarff#213) Use this option if you want to cross-compile the library. Typical usage is: scons TOOLCHAIN=arm-linux-gnueabihf * Add -Wextra compile option and adapt code to suppress warnings (jgarff#214) The changes in code are mostly type casts between int ann unsigned. * Add shared library rasbpian package builder. The package is not built by default. To generate the package you need: - The dpkg-deb utility. - Use "scons deb" to generate the package. * Merge user-settable gamma correction into master (jgarff#216) Merge user-settable gamma correction into master * Bug fixes for Stretch and Compute Module support (jgarff#222) * Bug fixes Missing aligned(4) attribute in pcm.h makes the PCM case failing under Stretch, due to a newer version of gcc (6.x). Also fixed a bug in check_hwver_and_gpionum, so original Model A is recognised. * README, using SPI on RPi3 Added note to change the core frequency to 250 MHz when using SPI on RPi 3. * README fix * Add support for Compute Module 1 and 3 * Fix undefined clock_gettime symbol * add missing memory allocation for SPI mode (jgarff#231) * added Ctrl-C handler to turn off all LEDs on exit (jgarff#140) * added Ctrl-C handler to turn off all LEDs on exit * added option -c * Fix for segmentation fault on exit for Python API (jgarff#239) Remove useless __del__ because the cleanup() function gets called by atexit(). Remove ws.ws2811_fini() call which causes the SEGFAULT on exit. Python does not complain about the memory leak in this way. * Add support for new A+ hardware. * Change default DMA channel to safe choice (10) (jgarff#253) add warning on README.md * Add getBrightness for brightness feedback from the buffer (jgarff#248) * Instructions to install the Python library (jgarff#254) Solving issue jgarff#142 * Fix for non-root users & SPI (jgarff#257) * Fix for non-root users can use SPI * use DEFINE'd device strings also add a note to the readme * Basic Golang Examples (jgarff#256) * Added golang example * Added basic README for golang examples. Added os exits for errors during color wipes for golang examples * Fix the default DMA in python code (jgarff#266) DMA 5 causes file system errors on PI 3 * Fixed typo in README.md (jgarff#273) Was perusing recent commits and saw this. * clarify electrical notes (jgarff#264) * Fixed strandtest.py (jgarff#258) * Fixed keyboardinterrupt, indentation inconsistency, & a few other minor bugs. Added shebang. * Fixed KeyboardInterrupt. Again. * KeyboardInterrupt works now. For sure. * Tabs to spaces, removed redundant signal handling * Removed unused sys module import * Added Raspberry Pi 3 B+ (jgarff#276) * Added Pi 3 B+ * Remove unused import
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm thinking the answer might be 'no' but I'm struggling to find any concrete information about this.
I have read that the signal voltage needs to be 70% of that powering the led's. Is that applicable for pwm voltage also?
I am a bit confused as to whether 12v ws2812 are actually driven at 12v or if the voltage is stepped down to 5v.
I'm thinking of trying it and seeing what happens but I thought I'd ask here because I don't like fried pi!
The text was updated successfully, but these errors were encountered: