BTW, there’s a bit of an undocumented feature in the candle mode now. During the final minute when it’s dimming before it shuts itself off, the user can “stoke” the fire to keep it burning a little longer. Simply touch the button while it’s dimming and it’ll perk up again. The usual button mappings still apply though, so I’d suggest giving it a button sequence which isn’t mapped to anything. Like click, click, hold. Or 4+ clicks.
It’s a bit like putting an extra coin into a game or a parking meter to keep it going a little longer.
On something with a lighted button, you should be able to tell if candle mode is still active based on whether the button has lit itself up yet. That happens when the timer has expired completely and the UI goes back to the “off” state. As long as the button hasn’t lit up yet, the fire can still be “stoked”, even if it appears to be otherwise off. And during that period, it may flicker briefly back to life on its own, too.
I’ve been running the latest version of Andúril with muggle mode and timed candle mode on nine of my lights for almost two weeks.
Last night I got to share some of them with several young muggles on a rainy walk. An Emisar D4, BLF Q8, and modded EagleEye X6R were used with muggle mode enabled.
The five year-old was excited to show me that power on the X6R could be toggled by twisting the head. Good thing TK chose to keep muggle mode enabled through power cuts! :+1:
I’ve been using a Q8 in timed candle mode every evening on the coffee table. I use a warm-colored diffuser and place the light just inside my peripheral vision while reading or watching TV.
Very neat. I wondered about the short delay between the candle burning out and the Q8’s switch relighting.
I ordered the needed components and excited to get my D4 reflashed. What is the programming language used to create this firmware? Is it same as programming Arduino?
NarsilM has a GT mode with LVP. Voltage is measured via a divider on pin 7, and getting it to work mostly just involves getting the right calibration values.
FSM has a pin7 mode too, with similar requirements.
Nothing yet appears to do multiple voltage ranges on a single firmware.
Oh, that makes sense. I didn’t even attempt to support muggle plus dual-switch. It would need an extra clause in setup() to pass in the memorized level as a starting point, and some extra code in muggle_state() to use the extra data instead of ignoring it.
It’s a fairly small change, probably under 10 lines, but it’ll take some testing to make sure I didn’t forget anything.
I’ve created a good morning / alarm mode in Anduril as a proof of concept. I put it after the goodnight mode, along with the other blinkies. That means to access it, you do 3 clicks, 2 clicks, 2 clicks. Once activated, it uses the standard config behaviour to ask you for a number of hours and a number of 10x minutes. Eg enter 7 then three for 7 hours 30 minutes. After the delay it will ramp up 1 level per second (too fast?) up to the ramp ceiling.
Current issues:
Timer accuracy could be better. I haven’t measured it properly yet.
Program size is 8164 bytes (99.7% Full), so there’s not much breathing room for other features. There’s a few bits in Anduril that I might try refactoring to cut this down but most of the time I’m just guessing.
Doesn’t do anything sensible to reduce power.
This definitely needs more testing but feel free to have a play. Be warned that this is the first time I’ve written C in about 10 years.
I haven’t got round to setting up a Launchpad account and learning bzr, so here’s the diff on Pastebin for the moment: dave1010-anduril.diff - Pastebin.com
Feedback welcome.
Edit: I may have messed up the timing. More testing needed.
If it helps at all, I need to add the half-sleep state soon, which makes it act like sleep mode except with the WDT enabled so it’ll wake up and send a “sleep tick” every so often. That should make it possible to do a low-power sunrise mode, and to make the button LED blink while off.
The main benefits are:
One tick per second (configurable at build time) instead of 62 ticks per second.
Much lower MCU power usage (~0.01 mA?), compared to idle mode (~1 mA?).
I also really should refactor the hardware definitions and build config options, but I’ve been procrastinating on that.
goshdogit, I added dual switch support to muggle mode. It needed a bit more change than I expected, but it wasn’t bad. It needed to do some extra things like saving the current brightness so it can be used momentary style.
The updates are in the fsm branch, not yet in trunk.
Halfsleep mode is working, though not finished. It’s a bit clunky.
How it works (so far) is:
#define USE_HALFSLEEP_MODE somewhere to enable it.
Set halfsleep_mode = 1; go_to_standby = 1; to activate it.
In your UI code, catch the EV_halfsleep_tick event to do something periodically during standby.
Currently it emits the event every ~0.512s. The arg parameter counts up by one each tick, starting from zero. The counter resets on full wakeup.
Halfsleep mode ends when the user presses a button, or when the code sets halfsleep_mode = 0; .
Power use in this mode measured at 0.00 mA on my cheap multimeter, and I haven’t checked it on a nicer meter. In any case, power draw appears to be negligible in halfsleep as long as the MCU doesn’t do anything fancy during its wake cycles.
The documentation says it should happen every 65536 cycles or every 0.5s, but in my testing it runs slower than 0.5s. Not sure if it’s every 0.512s or every 0.524s, but it’s off by enough that it’ll make precise time measurement tricky. Each “second” is either 1.024 actual seconds or 1.048576 actual seconds, approximately, depending on how the timer works.
I’ll upload it after I implement the blinking indicator LED function.
I’m also debating whether, if it’s enabled, it should override regular standby mode entirely. That way, standby mode would always send sleep ticks and there wouldn’t be an extra flag to set. Instead of “halfsleep” it’d just be “tick during standby” or something like that. Easier interface, slightly smaller code, maybe slightly higher power use.
I use the watchdog in quite a few of my lights with a 4 sec. interval for a flashing indicator (beakon). The 4 seconds are of pretty different length in my lights, the WDT for sure requires calibration when used as an alarm clock or so. Power consumption is negligible.
I haven’t checked the influence of temperature to the watchdog yet, could probably be compensated with the temperature sensor (if necessary at all).
I pushed up new code which implements a blinking indicator LED, using the half-sleep functionality. It’s simpler / easier than before though. Since power usage doesn’t seem to be much different with the WDT on, I made it always tick when in standby (if the option was enabled at compile time).
So, to use it:
#define TICK_DURING_STANDBY somewhere to enable it.
Optional: #define STANDBY_TICK_SPEED 5 to configure how often it’ll wake up. The available values are in the attiny85 manual, or in fsm-standby.h.
Set go_to_standby = 1; to enter sleep mode.
In your UI code, catch the EV_sleep_tick event to do something periodically during standby.
By default it emits the event every ~0.5s. The arg parameter counts up by one each tick, starting from zero. The counter resets on full wakeup.
Standby mode ends when the user presses a button, or when the code sets go_to_standby = 0; .
Anduril supports this in the off and lockout states, to implement a blinking beacon-like aux LED. The aux LED modes are now:
0: off
1: low
2: high
3: blinking
This is configured during lockout mode. Go there, then…
Click 3 times to change the aux LED mode in lockout.
Click 3 times and hold the last press to change the aux LED mode in “off”.
The ROM is running out of space now. On the Q8 build, it now comes to 8068 bytes (98.5% Full).
It should be pretty easy to run it on a Mtn FET+1 driver if it has tiny85. There may be unusually high parasitic drain though, if the voltage divider resistors are still there. Those aren’t needed for single-cell FSM-based lights, but if they are there IIRC they allow current to leak.
It may also be relevant to tweak calibration for VOLTAGE_FUDGE_FACTOR or perhaps the ramp shape, if the default Emisar D4 build doesn’t give the right battcheck readings or if moon doesn’t light up.
BTW, I’ve been doing a bunch of code refactoring today, to make hardware definitions easier. It’s not done yet, but I’ve been trying to put hardware-specific values and options into their own files, named after the driver type. Really, this is overdue… but better late than never I guess.
I think building the D4 flavor of Andúril should work, especially since Mountain offers that driver with the D4’s stock UI.
Remember to enable dual switch support if your light has dual switches.
If you can, I suggest making the emitter & switch wires long enough to allow easy access to the driver for future updates of Andúril. TK keeps adding more awesome features.
What light are you building?
EDIT: I see you got TK’s blessing and advice while I was typing. :partying_face:
Thanks TK. Yes this particular example does have the voltage divider removed.
I also have another 17DDm like driver where I plan on swapping to a tiny85 and converting to eswitch, ill be sure to remove the voltage divider resistors.
Sofirn C8F where I want to drill some holes and put a ring of Yuji in the blank space in the reflectors. This is a bit of a long term project especially since I need to mod the driver a bit to enable independent dual channels (cut trace), and modify the host as well. That and work
