E-switch UI Development / FSM

Seems great so far. I voted ‘smooth ramp,’ so I’m quite pleased. :slight_smile:

I’ll update my Q8s and do some bug hunting. They’ll get some extensive use this weekend, so I’ll let you know if I find anything.

I really like the smooth ramping muggle mode. (Even though I voted for baton style, which i still think is easier to use and probably uses less space on the attiny)

I first tested it on the blf q8 since it comes apart so easily :slight_smile:

However, on the q8 the output does have a sort of bump in the middle of the ramp and it seems te be a bit jittery. Not as smooth as the main ramp. But I guess this is probably to reduce the size of the mode?
Also I noticed there is no click, hold to lower the output. It is more like hold , hold to lower the output. Perhaps this can be the same as the main ramp.
And finaly the ‘waiting time’ in muggle mode when you hold the button from off and the light starts to ramp seems to differ, but this can also be just me.

The four-click config modes is nice to have some more consistancy, though it will take a few days to get used to. :laughing:
The best thing in my opinion is the 6 clicks to exit, it happened way to often I lend a flashlight in muggle mode only for one person the unscrew the battery compartment and not understanding a thing how the light works.
The indicator led is also exactly how it should be in muggle mode; flashlight off, indicator led off. No questions why the led is on when the lamp is off.

TK, are the files in the depository up to date for building this latest version of Andúril? The dates seem to indicate so, but I wanted to double-check.

I like to disable boundary blinks and lower the value for HOLD_TIMEOUT.

Does this still apply to the latest version?

The repository files should be up to date, and the HOLD_TIMEOUT thing should still work.

I’ll probably merge the branch into trunk soon too, since it’s reasonably stable.

Aside from the limited range and slower speed, differences from the main ramp are there to reduce code size. The smooth ramp is, unfortunately, the largest of the muggle mode styles… and I still want to add some other things before the FW3A release.

That’s what i thought unfortunately. Maybe i’ll try to edit muggle mode to a baton style mode, however I have no programming skills so that might take a while.

Thanks! I successfully built GT and Q8 Andúril hex files without boundary blinks and HOLD_TIMEOUT set to 17. I reflashed three Q8s and my GT. :+1:

I’ll wait for timed candle mode and your other changes before digging the drivers out of my Emisars. I tried to build a hex for them anyway, but got a bunch of errors. FWIW, I was able to build one for FW3A drivers without issue.

I know you don’t use Atmel Studio, but I thought someone might have some idea what is causing these:

That looks like the driver definition line was omitted or misspelled. Check the area which says:


Thanks, you’re right! When I deleted the slashes, I accidentally got the hash too. :slight_smile:

I had recently requests for my drivers for GT Anduril, is it possible to get the whole Atmel Studio 7 files for GT Anduril?

Lexel, here’s what I do to build an Andúril .hex file in Atmel Studio.

You’ll need to download files from three folders on TK’s flashlight firmware depository.

Download the Anduril.c file from this folder.

Download 21 .c and .h files from this folder.

Download 5 .h files from this folder.

You should now be able to paste the code from Anduril.c into a new Atmel Studio Project. Place the other 26 .c and .h files in the project’s folder.

Set the driver type by removing the “//” from the “//#define FSM_BLF_GT_DRIVER” line. Add “//” to the other driver type lines.

Add a line “#define ATTINY 85” to specify the MCU model.

Make any other changes to the user-configurable options, such as blinks at the boundaries and ramp floor and ceiling.

Build and flash the .hex file.

I took some time today to add the “votive candle” mode (candle mode timer). It’s off by default, meaning candle mode will go until it’s manually shut off or LVP activates… but the user can click 3 times to turn on the timer and add ~30 minutes. Click 3 times again to add another 30 minutes, and so on. The maximum time it can handle is about 4.5 hours.

For most of that time, it’ll run normally. However, for the final minute or so, it’ll gradually dim, sputter, and then shut off.

The UI diagram has been updated too.

If anyone wants to test the candle timer but doesn’t want to wait 30 minutes each time, the part to tweak is the value of MINUTES_PER_CANDLE_HALFHOUR. Set that to like… 2. And then each test should take less than 3 minutes. :slight_smile:

The timing is a bit wonky because I used a power of two as the base unit of time, which didn’t line up evenly with human-friendly minutes. This helps reduce code size and improve consistency when the clock tick counter rolls over, but it also makes “30 minutes, exactly” unattainable. I think the current behavior takes about 31 minutes per triple-click “bump”.

I reflashed a Q8 to try votive candle mode, and it works great! It burned for about 29 minutes.

I was excited to reflash several other lights, but managed to launch my flashing rig off the desk and break a few of the soldered connections to the SOIC clip. I’ll fix it tomorrow. :smiley:

I’ll be using timed candle mode on the nightstand and hanging near my hammock during camping trips.

Thanks for the continued improvement, TK! You really do spoil us. :+1:

TK can you make turbo level setting like ramp max implemented? I have a Skilhunt DS10 but for that size of flashlight and for 2A protertion tripping 16340 battery I want to set turbo under 2A curent a bit and ramp max to 0,6A as that is he stock max current for that light. It will be useful for low forward voltage leds or smaller hosts not to heat up real quick in turbo.

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.

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.