E-switch UI Development / FSM

I don’t understand most of the things spoken in this thread, I confess, but I do appreciate your work and efforts - TK - along with the one of other members! Thanks for making better UIs and for putting your imagination “at the service of the Light”!!! :+1:

Now, following your last post, I just wanna suggest that the first BLF light with the “Andúril” UI be named “Mithril”, being a “impenetrable” maybe “bullet proof” flashlight!! A flashlight for knights that can be kings of the Light! Just saying :crown:

This forum is getting better and better (and I’m just a noob here) due to people that are working and investing time, money, intelligence and other resources to make things (lights, components, UIs, drivers….) that somewhere in time seemed impossible and that now are just cool and feasible realities!

I’ll keep on reading, and trying to learn a bit from this work!
Keep it up :+1:

Mithril o_O
well, the FW3A colour is silver. That would fit.

The accent in Andúril is bad for searching. I think a simple u would be better.

Hum, don’t know if the FW3A creators/developers team would agree/appreciate that but…why not? :smiley:
Sharp inside with Anduril firmware, armored and blasted outside with a silver “shining” look as Mithril, aiming to protect us from darkness :blush:

If it wasn’t a long name, “Light of Earendil” would also be appropriate :sunglasses:

(well, just hope these names wouldn’t raise Copyright or whatever issues)

I checked first. Part of why I waited was to make sure people didn’t mind.

I’d like to flash Andúril to one of my Q8s.

I successfully reflashed my D4 with the v2 firmware, but I’m still a total n00b with the process.

I’m still confused about the fuse values. Are these dependent on the hardware, firmware, or both?

How do I know what to use for the Q8 and Andúril? Do I simply reuse the values that come with the Q8’s stock NarsilM 1.0 firmware?

Also, when I attempt to build a HEX file with Amtel Studio 7, I get two errors:

  • recipe for target ’main.o’ failed
  • spaghetti-monster.h: No such file or directory

I’ve downloaded spaghetti-monster.h, but I’m unsure of where to place it for ’#include “spaghetti-monster.h”’ to see it.

EDIT: I’m making progress! I now understand I need to place all of the .h and .c files in the project directory for the #include commands.

EDIT 2: I got a successful build! The ’Hey, you need to define ATTINY.’ error made me lol. :smiley:

Please forgive my ignorance, I’m in waaaaay over my head here!

Ohh, I was talking about the “Mithril” name for the FW3A, not about the firmware :wink:
Independently of the name of the flashlight, I’m sure I’ll love that firmware on it!!! All my lights have “conventional” clicky modes, so a ramping mode, also with clicks, and extras like those you’re inserting on it, will be awesome!!
Once again, thanks for the efforts on these masterpieces :+1:

goshdogit, it’s intended to be built with the bin/build-85.sh script and flashed with the bin/flash-85.sh script. These are written for unix-like systems though, so it’ll require adaptation to build in Windows.

It’s also a good idea to grab the entire repository to retain its directory structure, so all the files will be there. This is easy with bzr installed, or not so easy otherwise. Perhaps I should get in the habit of doing .zip releases of the entire repository, since that’s easier in Windows.

FWIW, this is what I’d normally do:

  1. bzr branch lp:~toykeeper/flashlight-firmware/fsm
  2. cd fsm/ToyKeeper/spaghetti-monster/anduril
  3. …/…/…/bin/build-85.sh anduril
  4. …/…/…/bin/flash-85.sh anduril.hex

The build uses fsm~~.c and fsm-.h in addition to the files in the subdir for the current UI… and some of the tk~~*.h files in the parent directory. Basically, it relies on having parent directories in the include path with the “-I… -I…/… -I…/…/…” options in the build script.

Thanks for the reply! I managed to download the header files individually and got a successful build.

I’ve got about 30 browser tabs open between two desktop machines and a tablet, but no Linux box. The last time I used unix was on a Sun Workstation in the tail-end of the ‘purple logo’ era. :smiley:

Can you offer any guidance for the fuse values? I read some stuff that made me worry about bricking the 85 by using the wrong values.

The fuse values are in the flash-85.sh script.

Me looking at Narsil and Andùril:
It is sick to operate that amount of stuff with one button.

:slight_smile: :stuck_out_tongue:

Can we have an easter egg?
Tapp 12 times and the lamp blinks out la cucaracha in morse code?

SUCCESS!

I’m currently being mesmerized by “Lightning Storm” mode on a BLF Q8!

ToyKeeper, thanks so much for all of your amazing innovations and willingness to help others!

I think you may be the first person to actually try this UI. Feedback is appreciated.

If you’re willing, I may also want to try to add support for the lighted button and ask you whether it works. I don’t have hardware for that yet.

I’m honored! I will fiddle with Andúril and report back with my thoughts. I’m loving it! I just put it on my D1, too.

I feel awful that you don’t have a Q8 to play with yet! As you mentioned when photos of the internals appeared, it’s easy to reflash because of the long emitter wires. Remove the two driver screws and you’re in.

I’ll be glad to test the illuminated switch when you add support. I didn’t put these pink 0603s in to remain dark! :wink:

I took a class in C (or was it C?) in high school, and I’m having fun browsing your code and attempting to understand what’s going on. It’s nicely commented. “Sleep dammit! (but wait a few seconds first)” :smiley:

BTW, to turn the indicator LED on or off, I’m thinking maybe triple-click in lockout mode? This would configure whether the button stays illuminated while the main light off. Unless there’s a better place to put this option.

I could instead put an actual config mode inside lockout, for all settings related to standby behavior, but so far it looks like there’s just one option.

I’m also thinking maybe it should do something different with the indicator LED depending on whether the light is off or locked. Like, one could blink while the other is steady.

Speaking of sleep… I finally made it go to idle mode during regular output (and goodnight) mode, since the MCU doesn’t really need to do anything timing-sensitive. It keeps PWM active, and the voltage / temperature measurements, and the WDT timer, but it doesn’t need to do any actual processing.

This only reduced power use by 2mA, but that’s still useful. It means the lowest firefly mode went from 5.6 mA to 3.6 mA.

Was hoping to reduce it by 4mA, but that might not be possible without turning off some features it needs, like the ADC, or reducing the clock speed (which would make PWM slower).

I like that idea. I don’t like the indicator toggle in Narsil when you ramp and quickly power off the light. When I want to ‘park’ the light and set memory, I tend to inadvertently disable the indicator. Don’t tell Tom! :smiley:

Yes. It seems intuitive that a solid indicator means ‘ready’ and a non-solid indicator means ‘locked.’

Do I remember you making reference to a ‘heartbeat’ or ‘breathing’ mode? Or something like a MacBook’s ‘sleep’ indicator?

I tried a couple other things. Running at 6.4 MHz seems to drop the PWM speed from 15.6 kHz down to 3 kHz. So that’s no good. I was expecting 12.5 kHz, not 3.0 kHz.

Turning off brownout detection reduces standby drain by quite a bit. Granted, it’s basically dropping from zero to even zeroer, but still. 24.7 uA with BOD enabled, or 0.35 uA without.

0.35 uA. That’s 0.00035 mA or 0.00000035 A. I had to use my Fluke to even measure it, since my regular DMM couldn’t.

So I think I’ll be leaving BOD off… It’s not really used in FSM and it increases standby power by a factor of 700.

It has no effect on non-standby modes though. So, I’m still at 3.6 mA or higher for firefly mode.

Dropping the clock speed to 4 MHz works. Moon mode is then 2.5 mA, but PWM runs at 7.7 kHz instead of 15.6 kHz. So I made it change clock speed depending on the brightness. The bottom ~dozen ramp levels run at 7.7 kHz and everything else runs at 15.6 kHz. This gives more stable and more efficient moon modes without making higher levels audible or strobey.

Long story short, I managed to decrease the lowest level from 5.6 mA to 2.5 mA, while also increasing the brightness from about 0.01 lm to 0.10 lm. This means a usable moon mode’s runtime went from 18 days to 50 days on a 3000 mAh cell. And standby time went from 14 years to 977 years. Not that the cell would last over a decade anyway.

@Toykeeper:

Why don't you use fast pwm with 4 Mhz clock speed all the time? You will still get 15.6 kHz pwm frequency then. I know the problem of not getting zero output with fast pwm and addressed it with:


#define PWM_FAST 0x03
#define PWM_7135 OCR0A
#define PWM_FET OCR0B
#define PWM_OUT_7135 0x80
#define PWM_OUT_FET 0x20

void output_on()
{
// In fast PWM there is a short output peak even when PWM set to 0,
// we just deactivate the PWM output override in this cases.

TCCR0A = PWM_FAST |
((PWM_7135 != 0) ? PWM_OUT_7135 : 0) |
((PWM_FET != 0) ? PWM_OUT_FET : 0);

TCCR0B = 0x01;
}

void output_off()
{
TCCR0A = 0;
TCCR0B = 0;
}

I’m not really worried about getting zero output on PWM=0, since it doesn’t apply to standby mode and it’s easy to add a clause to work around it in set_level(). I’m more concerned about getting a stable moon mode which isn’t voltage-sensitive. The activation time for the 7135 chip is long enough that 15.6 kHz doesn’t really work well at the low end. So, I normally cut speed in half on the lowest modes.

The difference here is that, instead of going from FAST to PHASE mode for moon, it’s going from 8 MHz to 4 MHz.

I don’t want to use fast PWM on higher modes since there’s an issue with PWM=255 not being completely on. It has a short “off” blip each cycle much like PWM=0 has a short “on” blip. And I don’t want less than 15 kHz on higher modes since it’s audible. So those really should be 8 MHz in PHASE mode.

However, it might be worth dropping the speed further at the low end, perhaps using fast PWM at 2 MHz to get 7.7 kHz with even lower power usage. Maybe that could save another half-milliamp or so at moon level.

Edit: Nevermind. That actually increased power use. It ran at the right speed, but using fast PWM also turns on the FET at each PWM pulse (even at 0)… so moon is significantly brighter and power use is higher too, despite the lower clock speed. I guess that’s the answer for “why not use fast PWM?” — because it tickles the FET.

Instead, I can run moon (and just moon) at 2 MHz, a few low modes at 4 MHz, and everything else at 8 MHz. All phase-correct. This gets moon down to 2.1 mA at 4.2 V or 1.3 mA at 3.0 V, and it’s still reasonably stable. Higher modes are unaffected.

So, runtime on moon should be up to about 73 days now.