I managed to reduce the hardware sensitivity of moon level, but didn’t eliminate the issue entirely. The method for doing this is to underclock the MCU at the lowest few levels, which makes each pulse longer but farther apart. The overall brightness is similar, but it’s less volatile, less variable from one chip to the next.
Comparing the two methods…
Adjustable moon at full speed:
- + Moon level can be lower.
- + Moon level can be somewhat more consistent from one light to the next, if each one is calibrated individually.
- + Virtually impossible to detect any PWM.
- - Moon may be fine on a full battery, but may not illuminate at all on a low battery.
- - Generally requires calibration for each individual light.
- - Uses about 5 to 6 mA of power, even at the lowest moon level.
Dynamic underclocking:
- + Less sensitive to subtle hardware changes, so moon level is more consistent from one light to the next.
- + Less sensitive to battery voltage, so moon level is more consistent as the battery gets low.
- + Uses about 1.2 to 2.2 mA of power, so moon runtime is typically about 3X longer. The next few low modes also have increased runtime.
- - Not adjustable for each individual light.
- - Moon level may be higher than desired.
- - PWM might be visible for a few people… though it’s still invisible to most.
Six of one, half a dozen of another. Different people choose different tradeoffs. Perhaps in the future we’ll use MCUs with more pins and we can have a dedicated power channel for moon… like how the lighted button works. Or the button channel could be used for moon instead. This would provide even higher efficiency, with no PWM.