I’ve been keeping an eye on the HD108 LEDs and they certainly look promising, though I haven’t ordered any yet. As far as I can tell, software support is pretty thin on the ground for them so far. Until there’s PixelBlaze support for them, I imagine this library will be your best bet in conjunction with an ESP32. There’s more info on this libaray and HD108 in general here and also some example code for how to control them directly with SPI here.
Whatever you end up doing I’d be interested to hear how you get on. Also, any chance you could share where you ordered the strips from?
Interesting, I hadn’t seen those before. It took me a while to find an English data sheet for them. They sound pretty good on paper at least, though somewhat less so based on the earlier thread where you were discussing them. It doesn’t look like there’s an obvious supplier of WS2816 strips unfortunately and I haven’t yet tried any projects requiring SMD or custom PCBs, so personally I’m unlikely to try them anytime soon. Maybe other people here feel differently?
I had some bit/math error with the hack I was using. These are quite good.
I would add that at some of the very low levels the PWM/refresh rate is more noticeable. I suspect they are using bit dithering for much of the extra range. I would suspect hs108s to do this as well. I haven’t put these to a photodiode and scoped it yet.
16 bit PWM requires 65k cycles per refresh, a refresh of 10k would take a clock of 65k*10k = 650MHz, which im sure they aren’t doing. If they did 8 bits at 10khz on a 2.56MHz clock, every bit dithered on top of that would be at half the refresh, down to 39hz for the LSB, which would be quite visible if it wasn’t so dim. Again they could double that by doubling the clock and having more bits in the primary PWM.
Awesome led tricks like this explained in this video
Ill share the website, but it doesn’t really come with a recommendation. https://www.addressableledstrip.com
Newstar Led. You cant order directly on the website you have to email them for a quote and then pay through PayPal. I have not been able to get the strips to work properly but, I can verify that the whole strip is lighting up. Fast Led has a hd108 branch available and thats what I’m going to try next.
Is there anything I can do to help boost NS108s from the backlog? I’ve been driving mine from custom code, but my daughter just expressed an interest in talking to them with Pixelblaze.
I’m thinking I could fork the Apa102Adapter header and tweak it to upscale 8-bit source data into the new NS108 protocol.
Assuming I can demonstrate that working through strandtest, would that help you land basic 8-bit support into Pixelblaze soonish?
Huge appreciation to you: you’ve got a remarkable thing going here. I’m eager to indulge my daughter’s interest before it fades, so let me know anything I can do to help. Programming graybeard, electronics noob. Put me to work.
That would certainly help! I would make a new one (either new repo or a new object/driver).
My plan is to convert all the PB internals so that the color is kept in 16 bits (for all kinds of other good things) which is the bulk of the work, then downscaled if needed. I’ll treat apa102/sk9822 as a completely different LED type than NS108/HD108.
Perfect! Sounds like we’re very much on the same page. 16-bit is a huge ask, but just doubling 8-bit on output should cover most of the need for now. Maybe adding experimental clock rates up to 40 MHz.
I’ll need to run by Microcenter once it’s open, to get my hands on an ESP8266 dev board. I’ve got some Seeeduino Xiaos and a few other collected oddities around, but it’s been a while since I’ve gone smaller than Raspberry Pi.
While I wait to level up on hardware, I’ll post my early once-over of the C++ into the GitHub issue.
BTW it looks like Adafruit’s APA102 table of macros is misconstructed for RGB sequences that aren’t in common use anyway.
Well, then I’m probably in for a rude awakening about either endianness or word size for this build chain and MCU. Far be it from me to challenge both you and Adafruit!
But just on the face of it: neither the LSB nor the MSB consistently tracks any specific component? That’s what jumped out. On closer analysis, it seems to me that RGB, RBG, GRB, BGR are correct while GBR and BRG are swapped. That’d reflect a trivial mis-edit.
I just brought home a SparkFun Thing and Thing Plus; hopefully I’m not far from learning how far off I was at 4AM.
This assumes a source in RGB, and defines the output index for a given element. In other words an answer to the question “given a value for red, where in the output does it need to be?”
buf.b[rOffset] = rgbv.b[0]; //push red to dest
buf.b[gOffset] = rgbv.b[1]; //green
buf.b[bOffset] = rgbv.b[2]; //blue
write32(buf.frame);
You code works in the other direction, the indexes define which index into RGB to pull from for a given output byte.
output.s = {1, gain, gain, gain,
(pixel.b[componentOffset[0]] * 0x101), //pull first byte from src
(pixel.b[componentOffset[1]] * 0x101), //pull second byte from src
(pixel.b[componentOffset[2]] * 0x101), //pull third byte from src
};
Your color coding makes it clear! Much appreciated.
I imagine I’d have gotten there once I see wired runtime results, but I wasn’t resolving it from staring alone. Wild that the forward and reverse mappings are equivalent for 2/3 of the set…
Yup, these make me happy. FWIW: I had also initially guessed wrong on endianness. Big day!
Let me know if there’s anything more I can do to facilitate readying it for Pixelblaze. Of course I offer it to you Ben to use for any purpose, and consent to your licensing it MIT and/or in any other form you choose, presumably consistent with the other drivers.
I’ve taken another run at a new write64, and that’s performing great (on ESP8266 so far). Eliding half of the spinlocks, and presumably leaving far more parallelism for pixel calculations.
I’m trying to hold back on posting another full source file as comments in a GitHub issue. Maybe go ahead and add a driver project in the style that you want. Or I could DM it to you?
Added later: GISTS! Why didn’t I think about gists.
I purchased a Digi quad and was able to install the fast Led library and several of the pattern examples work fine with some of my other strips, ws2811 and ws2815. But I could not get the the HD 108 Library written by nlag to work kept getting errors when I went to upload to the esp32. My last option was to order a garbage controller that new star and super lighting LED verified was compatible with HD 108 strips. I’ll report back once I get it next week.
Twilight
Right now I’m just testing with a hack to swap out apa102 with the NS108 driver, using the same 8 + 3 bit color. Let me know if you want a build to play with.
These will update at 40MHz on Pixelblaze, which is quite impressive. It’s way overkill, even a trivial pattern like the example rainbow don’t benefit beyond 8MHz. I think 20MHz might be useful for patterns entirely from a buffer, but marginally so.
In addition to a crazy high data rate, they latch and display very quickly. I was able to see at least 5000FPS (only 18 pixels, but still).
The sad news is that the LEDs I used are either bad or had absorbed a lot of moisture even with a sealed pack + baking, and out of 4 8x8 panels every panel is bad, with 1/3rd to 2/3rds usable.
I’m also seeing some per-pixel variations that might be caused by damage. Some weird things / glitches happen for some of the LEDs in the first 10 or so levels.
The brightness around the lowest range is really good for most things and on par with APA102 even without the extra 5 brightness bits. With the extra bits, it would be hard to see them fade to blank unless you were in pitch black and looking right at them.
The extra bits aren’t directly compatible with SK9822 / APA102. Looks like they have a range of 3-34 out of 34 instead of 0-31 out of 31.
Sure, I’ll order one. Let’s take this fresh blinkiness 2D!
OooooooOOOOOOOooooooo! YESPLEEZ! Thank you so much. That’s almost unbelievable turnaround.
Yeah, they’ve been a hoot. I have two spools of 30/m IP68 for outside, and two spools of 60/m in the crown molding of a pitch black home theater. Apart from a variety of hand-coded demos, I’ve pretty much just used them for lights-on and lights-off. (While planning ambitious transition animations and other triggered effects.) The kid would now like to take charge and run it much further, much quicker. Cue that happily obsolete feeling.
The theater strips are powered and controlled from right above the projector lens passthrough, on the rear wall. So, from the center of a horseshoe configuration 12’ : 12’ : 12’, with 10AWG feeding the front and back of each 300pc strip.
Electronics-wise, how would you suggest I plan to transition from my Raspberry Pi 4 to our new V3, with or without our new output expander? (The exterior 150pc runs are easy: each will just be driven by its own Pico instead of a Pi Zero. I’d pulled one strip inside for this Thing Dev work.) Should I put the theater on a pair of Picos and try to drive it from Firestorm?
Once again: thank you for bumping this special request forward so quickly! The girl and I are both just tickled about it. High fives all around.
Hello, @wizard I am trying to control the HD108s LED strip and it is lighting up as you mentioned but in very few occasions which I couldn’t understand what causes it. I couldn’t manage to control it. I am using H807S controller. Please let me know if you recommend anything or if you have figured out how to work with this strips.
Far be it from me to challenge both you and Adafruit!
Much appreciated.
Maybe go ahead and add a driver project in the style that you want. Or I could DM it to you?
YESPLEEZ! Thank you so much. That’s almost unbelievable turnaround.