Zozz, you can achieve that effect by changing the values in the ramp table. Basically, cut the FET values in half or something. Maybe even calculate a new ramp with level_calc.py if the shape doesn’t look right. Or use a driver with only 7135 chips and no FET.
It can’t reliably control current on a FET though, so it’ll take trial and error to get things working at the desired level.
I don’t really can do things ike this. I tried some times but I only has windows and run in errors every time. I only flashed hex files. I thought it will be the same as ramp ceiling setting and it can be another line in ramp cfg. but it sets the turbo level. then with a power supply I can test what turbo setting giving the desired current for me.
But if it is not possibble I will ask somebody to make a hex for me as you described.
Thanks!
How hard would it be to change it so in a FET+1 the two channels ramp one after other? Say ‘1’ ramps till it hits max (or some value below max) then engages FET channel and ‘1’ channel shuts off.
staticx57, that should be pretty easy. Just set the first ramp to all zeroes after the point where the second ramp starts. However, this is not recommended because it will reduce efficiency, make the PWM more visible, and make the power-related tint shift pretty obvious.
Thank you! Not so easy when I really don’t know much about programming. I want the 7135 channel to control some Yuji LEDs then switch to the FET channel to power some normal emitters, cut trace of course. On that last thought, any advice on what to change to limit the 7135 channel in all other modes besides ramp? Ideally I am going to base this on your excellent Anduril.
Changing Anduril to support two independent LEDs may be a little tricky. It’s just not designed for that. It can be done, of course, but without knowing much about programming I’m not sure the changes will be very do-able. I’d suggest making it run as a single-channel ramp, then adding a second single-channel ramp, and explicitly using one or the other in the mode logic.
The only UI I’ve made which does multiple independent emitters is for a RGBA setup. It’s not released yet though, and doesn’t have any traditional modes for flashlight use. Instead, it runs on my lightsaber. The modes consist entirely of colorful patterns configured by the user, and most of the interface mappings are for configuring those.
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).