HD108 Support

[DaAwesomeP]

Is your feature request related to a problem? Please describe. The HD108 is a relatively new 16-bit two-wire chipset supporting very fast data rates (40 MHz) and PWM rates (27 kHz). It has a similar protocol to the HD107S or APA102. It also supports a 5-bit global dimmer.

Describe the solution you'd like Implement HD108 support

Describe alternatives you've considered This chip is of particular interest to me because of the combination of 16-bit dimming (like the UCS8903), high data rate (even faster than APA102), and high refresh rates (I don't think I have seen anything faster). Since it is 16-bit, it should have good color coherence at at low brightness. The high data rate means that more pixels can be on one data chain and still have a high FPS. The high PWM rates mean that this should look good on most any camera.

Additional context This datasheet has some funny annotations (maybe this is not the original manufacturer?), but at first glance it does seem correct: https://www.rose-lighting.com/wp-content/uploads/sites/53/2019/11/HD108-led.pdf

This is basically the 16-bit version of the HD107S, which is a very similar chip (also 40 MHz clock/27kHz PWM).

[Makuna]

Overall, not too difficult to support. The issue is that spec has ambiguous and conflicting information. It often shows and demonstrates 8 bit, but at other times it is 16bit.

It will need a new method as it differs from all the other DotStar/TwoWire methods. But its simpler than most as the start and end frames are static in size.

It will need a new feature. Currently it is similar to DotStarL4Feature/DotStarX4Feature but those are only 8bit. Need to create two new ones that are 16bit. BUT the spec sheet is rather unclear on an important detail. It shows a pixel that matches the DotStarL4Feature, but then it scratches out the 8bit color fields and overlays with a 16bit. Further, the first field that contains the global brightness was left alone at 8bit. I suspect it is also 16 bit. Calculations on speed are referencing the original 8 bit fields not the hybrid or full 16bit fields. But without a strip in my hands, I can't experiment to figure this detail out.

Note, the current strategies of using global brightness are either to leave it as full and use a RgbColor (DotStarX4Feature) or allow it to be set using a RgbwColor (DotStarL4Feature) where the W channel is used to control the global brightness on a per pixel bases.

[Makuna]

Ok, this site is more specific, but the actual spec it links is a dead link.

https://www.hd108-led.com/how-to-driver-hd108-leds/

It states the LED segment is four 16bit fields, where the first field is {1}{5bits}{5bits}{5bits} - each channel gets 5 bits of brightness.

[DaAwesomeP]

Note, the current strategies of using global brightness are either to leave it as full and use a RgbColor (DotStarX4Feature) or allow it to be set using a RgbwColor (DotStarL4Feature) where the W channel is used to control the global brightness on a per pixel bases.

I suppose you could also have a mode that accounts for all 21 bits by taking in 24- or 32-bit integers and shifting out the lowest bits down to 21 bits. I don't have these LEDs on-hand (yet), but I would like to see how necessary the global brightness even is with already 16-bits of dimming per channel.

[Makuna]

Those two strategies were previously selected (and both supported) due to default case of not using the global brightness at all. Then the next case was a global dimming across all the channels due to the current chips never supported per channel. Dimmed per channel just never was even discussed as even interesting.

[Makuna]

While investigating and researching, I already kicked out the work for the features. The Method should be easy as well. If I haven't finished it by then, let me know when your LEDs get in so I can have you test them.

[Makuna]

https://github.com/Makuna/NeoPixelBus/tree/HD108

Works like all the Two Wire methods. If you want to control the global dimming using the W channel, use the Hd108LbgrFeature feature, which takes a Rgbw64Color instead of a Rgb48Color.

for default 10Mhz SPI speed

NeoPixelBus<Hd108BgrFeature, Hd108SpiMethod> strip(PixelCount, DotClockPin, DotDataPin);

for bitbang

NeoPixelBus<Hd108BgrFeature, Hd108Method> strip(PixelCount, DotClockPin, DotDataPin);

for 40Mhz SPI speed

NeoPixelBus<Hd108BgrFeature, Hd108Spi40MhzMethod> strip(PixelCount, DotClockPin, DotDataPin);

[Makuna]

@DaAwesomeP Have you had a chance to try the custom branch?

[DaAwesomeP]

@Makuna my sample of the HD108 hasn't arrived yet. I ordered directly from Newstar. It should come in the next two weeks.

[Makuna]

https://github.com/Makuna/NeoPixelBus/releases/tag/2.8.0

[mkovero]

for me to get HD108 working it was required to change const uint8_t startFrame[16] = { 0x00 };

Also my strip follows RGB-color instead of BGR, otherwise good times with bit-banging, was not able test out SPI in full yet though.

[Makuna]

@mkovero If you are having issues with the HD108, please create a new issue. Commenting on a closed issue will not get you a solution.