Reversing ā perhaps a compile-time option. After using reversing for a few years and non-reversing for a month or two, Iāve found I like non-reversing better. But it would be a good option at build time.
Blink at max ā also a compile-time option. I already added one for blink at moon and blink at channel boundaries, so this fits right in.
Maybe, if thereās room.
Already fixed. This happened because it picks the burst ramp level by multiplying the steady ramp level by 2. At the very bottom of the ramp, though, levels 1 and 2 are actually the same thing, so the burst didnāt change the brightness at all. Easily fixed by using a floor level of 2 instead of 1.
I also increased the bike flasher ceiling so it can run brighter than before.
It should blink out the MCU temperature in C. So, it thinks your room temperature is 8 C, and after 3 minutes on turbo it got up to 19 C. The attiny85 sensor isnāt calibrated though, so this value can be off by quite a bit. Mostly itās useful as a way to find out what the MCU sees, which can help with setting a temperature limit. But on a Q8, itāll take quite a while to get hot enough for thermal regulation to activate.
If thereās room. Perhaps on an inconvenient click sequence, like 8 clicks from off?
Itās something I want to try, at least. Not sure if itāll be in a build for production purposes.
Youāre very welcome! Thank you for the excellent UIs!
I think I prefer non-reversing too. If itās a compile-time option, would it be universal or could reversing be enabled independently for muggle mode?
I meant, ācould the blink at channel boundaries be removed?ā Compile-time option is fine. I think Iād prefer no blinks at moon, turbo, or boundaries but thatās just me. I know some folks are particular about knowing what circuit theyāre on.
Thatās what I thought, but the scale and the short blink was throwing me off. I think I understand now that a short blink is a zero. One long, one short = 10 C?
Sounds good. Can it be disabled only by power cycling, like momentary?
Ok!
Thanks again for being open to feedback. As I said before, Iām more than thrilled with AndĆŗril as it is! :+1:
You seem to have omitted any mention of additional blinky modes. I *know* you mentioned ādefective light bulb modeā somewhere but now I canāt find itā¦ ^:)
Added reversing to Anduril. Made EV_tick always send 0 while in āholdā state.
Rearranged some build options and made sure the build still works if some are turned off.
Fixed issue where double-click-from-off followed by double-click-to-true-turbo would overwrite memory with the ceiling level. (should make Agro happy)
Fleshed out build options to blink at floor, ceiling, and channel boundaries.
Adjusted bike flasher floor and ceiling: floor high enough to make sure it always blinks, ceiling can be higher than halfway up the ramp.
The reversing thing is slightly different than Narsil and Ferrero Rocher. I wanted to make it more predictable without having to remember anything, so if it has been more than a second since the last user input, a āholdā will always go up. However, if the last āholdā went up, there is a 1-second window where the next hold will go down instead. Also, āholdā at the ceiling level always goes down.
Soā¦ it reverses, but it doesnāt stay reversed long enough to confuse a goldfish.
Iāll probably leave it enabled by default, since it no longer has the issue with forgetting what direction itāll go.
As for muggle mode, Iām thinking itāll be similar to momentary mode where it has no exits (even for āoffā). Itāll be very very limited. The tricky part is figuring out where to put its config settings, if it has any.
OTOH, momentary mode makes a pretty decent muggle mode if set to a medium level.
I just reflashed a Q8 with this newest version of AndĆŗril.
Sometimes a hold from off will remain at moon and not ramp. At first I thought this was only occurring shortly after powering off, but Iāve seen it happen after the light has been off for 30+ seconds. It seems intermittent. I canāt replicate this with my D1 running the previous version of AndĆŗril. Could this be caused by the new ā1-secondā ramping reverse rule, like itās trying to ramp down from moon?
Other ramping functions seem normal.
Iām also getting some faint flickering during the āsteadyā phase of bike flasher mode. Itās very faint, and seems to go away at some brightness levels along the ramp.
If turned off while reversed, it could then try to reverse a hold from off. The amount of time it was off doesnāt matter for that, since it doesnāt measure time while off.
About the bike flasherā¦ it runs at ~4 kHz PWM now instead of 15.6 kHz, as a side effect of some power management changes I added a few days ago. Iām not sure if itās worth fixing or not, since the fix would cost a fair amount of space. Basically, all interruptible ādelayā operations run at 1/4 CPU speed. This affects modes which use those, such as biking, battcheck, and beacon. It doesnāt slow down PWM in other modes though, like ramping and goodnight, which have no need for explicit delays.
The upside of this is that things like beacon are now much more efficient for longer runtimes. The downside is that the PWM on a few blinky modes might be visible or audible in some circumstances.
Eh, probably not. I only noticed the faint flicker while ceiling bouncing the Q8 to check out the new brighter bike flasher levels. I doubt it would be visible on a bike.
I just reflashed the Q8 again. It sure is nice not needing to fire up the soldering iron!
How about clearing mode memory on lockout? You do this on physical lockout already and doing the same on software one seems logical.
After all if I lock it out, I will probably not use it in a moment.
Independently, time-related functions need to increase power consumption only when they are running. So when mode memory is cleared, you can go back to deep sleep.
You need to put these files in your projectās folder.
When you create a new Amtel Studio project, it creates a directory structure based on the name of your project. Right click the tab at the top left of Amtel Studio and click āOpen Containing Folder.ā Drop the .c and .h files into here and run the compiler again.
Another error you are probably encountering is, āHey, you need to specify ATTINYā in the tk-attiny.h file. Double click the error, then scroll up a few lines and remove the // from one of the lines reading ā#define ATTINYā and change the number to the proper ATtiny model number (13, 25, 85 etc.).
Iāve got AndĆŗril running on a Q8, D1, and D4 now. I love having several lights with the same awesome UI!
I have an EagleEye X6R with a TA driver running Narsil that Iād like to reflash, too. It has a forward-clicky tailswitch and an e-switch on the head.
Iād like it to light up at the memorized level when powered up, so I can use the tailswitch as momentary.
I found this piece of code but Iām unsure what changes to make:
void setup() {
// blink at power-on to let user know power is connected
set_level(RAMP_SIZE/8);
delay_4ms(3);
set_level(0);
load_config();
push_state(off_state, 0);
}
Am I on the right track?
Also, how can I format code to read properly when posting here? It becomes a mess if I insert spaces at the start of a line.
For that, it will need to save the memorized level to eeprom so it can remember after power loss. And given how often that level changes, it should probably be wear-levelled. This means bringing in the EEPROM_WL code, which isnāt otherwise used in Anduril, and making changes in a few places. Itāll cost more than a few bytes.
Yes, thatās one of the places which will need changes. Itāll need āpush_state(steady_state, value_from_eeprom)ā instead of going to the āoffā state. And, um, get rid of the initial startup blink.
The other changes are larger thoughā¦ I should probably add another compile-time option for it, because this is a request which will probably come up frequently.
As for posting code, BLF isnāt very good at that. It can be done, by using a <pre> in the fancy post editor, but usually I donāt bother.
Thanks, TK! Iāll wait for a possible compile-time option for āpower on at memory.ā
In the meantime, would a āpower up on turboā option be less complicated? Possibly something I could add/modify myself? Lexel enabled that in the previous install of Narsil when I ordered the TA driver.
I pushed an update with dual-switch support. It costs 172 bytes, if enabled at compile time, mostly due to bringing in wear-levelling functions.
The current method goes to the memorized level at boot, unless the e-switch is held. Then it goes to moon instead. (er, the bottom of the current ramp, whatever level that is, so it varies per-ramp)
Personally, I like having memory after lockout. If anything, Iād prefer to make it time-related, not lockout-related.
As for time-related forgetting, Iād probably want to set the time to something pretty long, like a few hours. I havenāt tried the half-sleep mode yet to find out how much power it uses, but hopefully itās not much.
I get the impression that perhaps the desired solution would be no memory at all, so it always turns on at a specific level. This might be do-able, and Iāve been trying to leave room for a memory option, but I havenāt thought of a way to fit it into the UI yetā¦ at least, not a way that Iām happy with.
Are you familiar with how the wizard character class works in D&D?
Every morning, they prepare their spells. Specifically, they take a guess at what spells theyāll need that day, and then they prepare each one. They cast 99% of each spell, leaving off only the last word or two, so that later in the day they can speak a few syllables and cause something big to happen.
FSM is the first 99% of a bunch of spells, leaving only the last little bit to be completed.
Personally, I desire memory for very short periods, like a minute or two.
I stop by the trail, turn off the light, empty my bladder, turn the light on.
Other than thisā¦Iām yet to find use for it.
I did some searching on how others use itā¦.Iām surprised I canāt find anything useful really. There are many comments where people just state that they like mode memory or not. Some say that they use it to make sure the light starts on low. The only other that I found was:
But this is a workaround for not having a configurable default mode and mode memory is ill-suited for the task.