Hello! I have a hardware question. After some research, I found an LED strip that suits my needs that I would like to connect to the Imp. Vin is 5V so that’s not a problem. However, I’m not too certain what to do on the software end.
I’m familiar with the Imp process and have two up and running that make use of RGB LEDs & PWM, but I’m unfamiliar with how the to properly clock the data, as described in the code above code.
ANY help would be greatly appreciated. And any example code that you think/know would make me your new best friend. Thanks!!
If you’re curious, what I’d ultimately like to do is be able to take an HTTP IN and interpret 2 colors/intensities and send color1/intensity1 down to fill the first half of the strand and color2/intensity2 throughout the rest.
I know how to interpret HTTP IN arrays and have them execute to variables, but it’s the rest that makes me o_O
You’ll need to connect clock to the SCLK and data to the MOSI of one of the imp’s SPI peripherals. However, the imp is 3.3V, not 5V – are you sure the voltage will work out? The WS2801 datasheet says min VIH is 0.8*VDD, so for 3.3V signalling that would imply that you shouldn’t run the power supply at more than 4V.
All parts are in and the code works well. Thank you, again, Peter.
Looks like I got it figured out. I had some issues with flickering after about a minute passed. Thought it had something to do with the buffer or clock until I realized it was a power issue. I had connected the wrong wall wart to the unit and instead of 2000mA, I was only sending 300, leaving the imp and the LED strip fighting each other for power, I assume.
I’m now looking for a way to cleanly iterate a color between each pixel with a 100ms delay, or so. The way I’m doing it is with a for-loop, writing the SPI out to an additional pixel with each pass.
I’m hitting an issue when I try and display the pixels at a linear, non-max, RGB (i.e. R:100 G:100 B:100). They become “white”, but have a faint flicker. Other, non-linear, combinations work great, and max 255 on RGB returns a nice white.
Does anyone have any ideas what is causing this? My goal is to have the ability to produce faint “white” on each pixel, sans flicker.
This flicker happens when you’re not talking to the LEDs? If so it may just be the LED’s internal PWM frequency is too low - not seen that myself though - or that your power supply is oscillating a bit?
Correct, they flicker when I’m not sending anything. Also, I tried three different power supplies, two with sufficient current and one that doesn’t. The flicker (again, only when displaying all “white”, non-255, values) was reproduced with all three.
However, I found that if I put the LEDs at low enough RGB values (<15) the flicker either disappears or is too faint for me to notice.
Is there a way to adjust the PWM via the Imp? I’ve done it with standard LEDs, but not via SPI.
No, the PWMs on those LED controllers is within the controller; you just send the requested output value - but generally it should be too fast to notice.
Maybe the controller has some undesirable behavior when RGB are all set at the same level (though I’ve never seen this myself). If you do, eg, 100, 101, 100 does it still flicker? How long are the wires from the PSU to the LED strip?
Ah, good idea. Was away this weekend, but I can confirm that it still flickers with the values 100, 101, 100 (or similarly close, yet high values). The wire from PSU to strip is around 4 feet. Ordered another quality power supply to use as a control. We’ll see if that does it. Until then, I’ll keep using low values.
And pardon my unfamiliarity with the code, but could someone show me how to execute the sample code (from Peter’s link above) that would send values to the strip (i.e. const setup_params = “\x55\x23\x11\xff”;). More specifically, when I send the values through the blob (about half white, half green) the instance I get in the log is 0x0x20010208. I assume this is the value I would need to send to achieve the same result as the for loop I’m using.
It refers to using a table in the example. So would this be the means by which one would send these values? And would it just be something like hardware.spi257.write(ioexpander1) or am I way off? Thanks!
I got to play with my new LED strip (this one) this weekend and here is some code I’m working on right now. Feel free to comment/clone/work on the gist!
Next goal is to add http in capabilities for my fancy LED strip.
You are my hero, Per. That code is really fun to play with. I have the same strip, but with 25 pixels. Going to toy with it a little later and try and see if I can get it to do some more effects. Particularly, have it repeat a “rainbow cycle” of just red/orange colors down the strip, for example. Any input on how to achieve this? Will report back.
Glad you like it! I’m working on a better version and a reasonably easy way to control it over the net. The code is here on Github if you want to keep an eye on how’s it progressing. I will continue to work with it tomorrow.
I haven’t actually tried this, but I’ll get some sleep and try it first thing. Just wanted to know if anyone knew of a clean way to break out of a loop with HTTP IN.
The “fake loop”, made using imp.wakeup, is the right way to do this – for exactly the reason you point out. InputPort events only happen when Squirrel is otherwise idle, so each time you’ve updated the strip you should set an imp.wakeup and drop out of Squirrel altogether so that event handlers run. The same would be true for input-pin events. There’s no point in updating the strip faster than the human eye can follow it, which is going to be at most 100Hz.