Moon mode works just fine on 4x7135. It’s slightly higher than with 1x7135, but that only means a difference of, um, … *<i>does a quick measurement</i>* … 0.35 lm instead of 0.20 lm. Either one should be fine for a lantern. With a 360-degree beam, it’ll probably look dimmer than a regular moon mode anyway.
Color mixing at low levels has coarse resolution though, because it’s based on integer math. For example, if it’s running at brightness level 240/255, there will be 241 possible tints. But at 10/255, there are only 11 possible tints. The firmware deals with this by remembering what tint the user wanted, and picking the closest one available at the current brightness. At low levels, the user can see distinct steps while changing color, but at higher levels it should be too smooth to see any steps. Fortunately, only low levels are affected and human color perception is pretty bad in low light, so it shouldn’t look weird in practice.
Here’s how that looks. First, this represents the BLF lantern’s color space in its actual 8-bit resolution — 256 brightness levels tall and 256 tints wide, with the image sizes doubled to make it easier to see. Red is for the 3000K emitters, blue is for 5000K. So, it gets warmer toward the left, cooler toward the right, and brightness goes up and down. This is the actual resolution of the simple AMC7135 chip design, so I hope it is clear that there are a wide range of choices available. The user can set the lantern to run at any point within this space:
If we zoom into the bottom (cut off the top 224 levels, stretch it vertically, and increase the brightness to make things easier to see), here is how the bottom 32 levels look. See how there are visible patterns? That’s where the coarseness starts to be perceptible.
… and if I cut off the top half and increase brightness again, it becomes even easier to see how the lowest 16 levels look.
This is what I mean by saying the tint resolution gets coarse at the bottom of the ramp.
A 3+1 / 3+1 driver (or 4+1 / 4+1 or 5+1 / 5+1) could increase resolution at the low end by splitting each individual region into slightly smaller pieces, like it does on the “moonlight special”, but nobody really proposed that because the tiny85 doesn’t have enough pins or enough PWM channels.
Same thing with a 4-pin dual-linear-FET design, where each channel has its own current control and its own independent PWM. The resolution at the bottom should be a bit finer, but it needs more pins and it’s a little harder to quantify than a 2-channel design. The bottom technically still ends up with exactly the same horizontal coarseness as before, but the vertical steps should be closer together. Basically, instead of 350mA on one channel and 1400mA on another, it does ~12.5% to 100% via constant current and anything below 12.5% via PWM. So, the brighter of these two methods handles brightness levels 32 to 255. And the lowest 32 levels use 8-bit PWM at 12.5%, so there are 255 steps going from 0 to 32 in increments of 0.125. It effectively sub-divides the bottom steps. I hope that makes sense.
With a 3-pin dual-linear-FET design (shared PWM pin), things get complicated and entire sections of the color space disappear. Like, if the user sets the tint to 3100K, that’s 95% warm and 5% cool, but that combination isn’t possible because 5% is less than the stable constant current floor. More generally, since it can’t PWM one tint without PWMing the other, it doesn’t work at tints where the two channels need different duty cycles. So it could do 3000K and 3222K, but nothing between… even at high brightness where the resolution should be pretty fine. And the gaps get bigger as the brightness goes down. So I’m hoping to avoid that.
I’d like to stick with a proven 2-pin design for now, instead of letting feature creep drag this project out even longer. The 4-pin design is awesome, but perhaps would be better used in next year’s model.