That can be set to whatever level you want. The highest regulated output is simply the default configuration.
For reference, the highest regulated level is 115/150 on the 219B model or 125/150 on other models.
Anduril gives the user a window of 24 ticks (0.384 seconds) to complete each action. For example, when pressing the button, if the user releases the button within 0.384s, the action is considered a “click”. But if the user presses longer than that, it is considered a “hold” action. And after releasing a click, the user has 0.384s to press again for a double click or a triple click, etc. After the button has been released for 0.384s, it decides the user is done pressing the button and it responds.
When turning off, there is one window worth of delay between releasing the button and actually turning off the LEDs. This is done to give the user time to press again for a double click, a click-release-hold action, a triple click, or other things they might want to do. If it turned off as soon as the button was released the first time, that would mean the light would have to turn off and back on when doing “double click for turbo” and “click-release-hold to ramp down”.
So it is a matter of one poison or another. I prefer the delayed-off issue over the off-and-back-on issue. But I plan on adding a compile option to choose whichever one the user wants.
There is a similar issue with doing a double click from off — the shortcut to turbo (er, the ceiling level). Since a lot of functions take more than two clicks from off, I don’t want it to flash turbo on the way to those other functions. The sequence of events for that looks like this:
- Button down: Light up at floor level for immediate moon.
- Button up: Oops, not moon. Go up to the memorized level for immediate mem.
- Button down: Oops, not mem either. Turn off and wait until the input window expires before taking any further action.
However, to avoid turning off before turbo, it could maybe do this instead…
- Button down: Light up at floor level for immediate moon.
- Button up: Oops, not moon. Go up to the memorized level for immediate mem.
- Button down: Do nothing.
- Button up: Do nothing.
- Button down: Not moon, mem, or turbo… so turn off and wait until the input window expires before taking any further action.
For double click, this would mean staying at the memorized level before jumping up to turbo, instead of turning off. Would that help?
Yes, you should be able to calibrate the sensor and set a temperature limit. I’d start with just the sensor, and then change the limit if it still doesn’t work how you want. It’s kind of buried though, because it only really needs to be calibrated once. Here’s how:
- Let the light settle to room temperature. Check a thermometer to find out what room temperature is, in degrees C, and remember this number.
- 3 clicks from off, for battery check mode.
- 2 clicks for sunset mode.
- 2 clicks for beacon mode.
- 2 clicks for temperature check mode. I’d suggest waiting for it to read out a value here, to find out how far off the calibration is. It should be the same number as what the thermometer said, but it could be significantly higher. (for example, a value of 31 C would be 3 blinks, pause, 1 blink)
- 4 clicks for thermal config mode.
- Calibrate the sensor: Light blinks once then stutters. During the stutter, click once per degree C for the current room temperature. It’s probably somewhere around 20.
- Optional: Set a temperature limit: Light blinks twice then stutters. Click once per degree C you want for the temperature limit, minus 30. So, for 45 C, click 15 times. 45 is the default. To skip this step, just wait a few seconds for the light to fall out of config mode on its own.
Usually calibrating the sensor is enough, and it only needs to be done once. After that, any further adjustment should typically modify the temperature limit instead.