Yeah, for me I don’t really see a need to tell me I screwed the cap on. So many lights don’t have that, I’m just not sure how many users find it that necessary to have 2 bright blinks to say you screwed it on. I would at least love the optional choice if people do need it. We all have different needs and I know it is difficult. I appreciate the work and consideration. 
+1
I really like the H03 UI. It’s a very versatile UI (like the Zebralight…which I think you have a sort-of-copy version, Toykeeper?).
I like NarsilM, but I have two issues, both in the Mode set Operation:
1) Mode Lock
I’m not a fan of the light turning off when you click the switch after the light has locked in a specific mode. I just want to be able to make the light brighter immediately, not turn it off or make it dimmer first then brighter. If there was a “Mode Lock enable/disable” option, that would be great! I understand that changes the mode selection UI, but it would grant the user even more flexibility in use. I am constantly needing to change modes when using a light - it’s a necessity.
2) Long Hold (over 1.2s) for Strobe
I would LOVE to see this be a configurable option, allowing the user to choose between either Strobe or Max (of the selected mode set) when performing a Long Press.
I have read and re read and seen the topic went into details.
I can’t help but think I missed the core of the first three posts. A universal UI to be customized by all to their liking?
Diving into code is a huge step for me, with all the things I have too do a leap too much to ask and I am sure I am not the only one.
This FSM, could it be presented in such a way even newbies can set up a light, using some clever way of getting the desired modes in a light, by using say the LED as a receiving diode? FSM as a stand alone app?
+1 invitation remains open of course
+1
One more thing, the Unnamed UI from the original post looks great! I love the option of ramping up/down at any time, not dependent on your last direction. Also, getting too/from max is great!
Yes, there’s a clone called DarkHorse. It’s almost identical to a ZebraLight. I doubt I’ll end up actually using it on any of my lights, but it’s a nice example for reference.
I’m not a big fan of those either; that’s why I did the discrete / stair-step mode differently in my Narsil-like UI. It works exactly the same as smooth ramping, except it’s not smooth. Instead, it has however many steps you want, evenly spaced between your preferred lowest and highest levels. The same actions do the same things in either mode though, and switching between them is easy.
No, it’s not really intended for everyone to make their own UI. What it does, mostly, is it reduces the time to create a UI from ~50 hours down to ~5 hours. But to be a universal thing customizable by all, it would need to take that time down to like 5 minutes… and it doesn’t.
I’ll probably add that as a compile-time option later, but it’s not there yet. I don’t have a FW3A yet or a compatible driver to use for development.
My quick light-sensing test used a tiny25, but it’s a power-switch light and FSM doesn’t work on tiny25. FSM adds like 1.8k of overhead, or a bit more with thermal regulation enabled, so it’s not tiny25-friendly at all. However, above that base size, it seems to make the resulting firmware smaller overall. Like, I’ve got most of the Meteor M43 UI cloned and I still have almost half the ROM left. That’s a bit satisfying, since the Meteor’s firmware author insists that the only way to make the Meteor’s features fit (on the same MCU) is to use assembly code, because C is far too bloated for use on attiny MCUs. But the C version seems like it’ll be smaller.
Out of curiosity, I tested thermal regulation on a light with a H17F driver, a brand new Okluma copper DC2. Jeff sent me one to thank me for all the free code, and perhaps also because I think he might want an open-source version of it. And I graphed it against my D4-219c with FSM:
The H17F thermal ramp-down is as smooth as it can get (the occasional bump was because I was holding the light and I moved). It seems to step down at a maximum speed of two PWM levels per second on FET modes or one PWM level per second otherwise, one channel at a time, until the temperature is no longer out of spec. This makes it really smooth but also really slow. Eight minutes to reach stable state at the configured temperature limit.
My FSM-based D4 also steps down one PWM level at a time, but it’s much faster, up to 8 adjustments per second. It looks just as smooth in person, but it reaches its destination(s) sooner and then is a bit more jittery after reaching stable state. One minute to reach stable state in this test, and another minute for the aluminum body’s outer temperature to catch up.
The DC2’s slow response seemed appropriate though, because it has a massive chunk of copper to sink heat into. It never got too hot to hold; the outside of the light stayed a pretty steady temperature.
Meanwhile, the higher-powered D4 has only a small chunk of aluminum, so it got painfully hot during the first minute even though it was stepping down so fast. It remained pretty hot during the second minute, but it did not continue to ramp down because the predictive algorithm figured out that there was no need since the temperature was already decreasing fast enough.
As a side note, I need to recharge the DC2’s battery and measure its maximum output properly. Its vertical scale on this graph may be a bit off — IIRC it was about 2300 or 2400 lm at the beginning but I need to double check.
It’d be interesting to see how each light behaves with the drivers swapped. That’s not very feasible, but sometime soon I should at least be able to measure FSM’s behavior on a larger light, a SRK or Q8. If my guesses are right, it should still work fine with more thermal mass and should adjust output more slowly, because the extra thermal mass reduces the rate of change and that reduces the magnitude of response.
…
It’s not shown in the graph, but afterward I held a block of ice against the DC2. The output ramped back up, but it was just as slow as when it ramped down. Even with the light literally ice-cold, it was still slow. The D4, however, when it’s that cold, increases the output rather quickly. It’s not quite as fast as the initial ramp-down, but it’s still relatively quick.
I was thinking about how an alarm clock mode should work… how does this sound?
Let’s say the user sets an alarm to happen in 8 hours. After entering alarm clock mode, a few things happen:
- The light blinks 8 times to indicate 8 hours until the alarm goes off.
- Light shuts off.
- 7.5 hours pass.
- Light turns on at moon mode then slowly ramps up to ~150 lm. This takes 30 minutes.
- The light blinks at 150 lm until someone shuts it off or the battery gets low. On for 1s, off for 1s, repeat.
To exit at any time, click once.
To go to the next blinky in the sequence, click twice.
To set the alarm time, click three times, wait until it buzzes, then click N times for N hours.
Neat!
- Can the light be used while the alarm is counting down?
- Can Good Night mode do its thing after setting the alarm?
I haven’t implemented it yet… just thinking about how it should work. It had occurred to me that it might be nice if the alarm clock mode also worked as a momentary low mode during the waiting period, but only if it doesn’t cost much space.
Or I guess it could do the good-night thing instead, but that adds some complications. I’ll keep it in mind though, in case a simple solution appears.
… actually, I already thought of a fairly simple way to do it — push goodnight mode, then make it pop itself at the end instead of turning off. This way it can be accessed from both off and from alarm clock mode. Hmm. But that also means it would inherit the parent mode’s event mappings for unhandled events. And it’d be less friendly in a mode group rotation. That’s problematic. I’ll have to give it more thought. The modes weren’t designed to be nested.
Mostly just looking for ideas at this point, for how people would use it. So this is good feedback.
Very cool that you are working with OKLuma. Was hoping that would happen.
Extremely cool gift of a DC2! That means you are a compensated consultant.
Unfortunately, the programming side of things are well outside my range of skills, I don’t have any decent input to offer.
Please do carry on, you are making our hobby more interesting and enjoyable
That sounds great. That’s something I’d probably use quite a bit.
Looking at the config for other modes, it seems like setting up multiple things is straightforward (in the UI, at least, I’m not sure how much complexity it adds to the code). Just configuring hours would work pretty well but you could add:
- Delay granularity to tens of minutes, so 8 taps then 3 taps would be 8 hours and 30 minutes
- Customisable brightness. 150lm is probably fine but it would be nice if this was flexible. It could be based on the mode memory but that could give unexpected results.
- Customisable ramp duration.
I’m being a bit picky and know first hand that adding in more features and code into something isn’t always the best decision, so take these suggestions with a grain of salt.
Wow, look'n good! t looks like the Olight Baton mode is identical to what I have in Narsil/NarsilM ramping?
Not familiar at all with OKLuma, or the DC2. Just saw the DC1 on his website though: https://okluma.com/
Weird, never heard of them before. Guess the DC2 is not yet for sale...
The Olight Baton UI is one click for on or off, but it’s more of a staircase than a ramp… and it only goes up. Normally their lights only have moon, low, med, and high. Holding the button cycles between them in that order, with a loop from high to low. I gave my Baton clone 7 levels instead of 4, but otherwise it’s mostly the same.
It’s a very simple UI and the code for it is simple too. I include it with FSM because it makes a nice reference example, and because it’s kind of nice despite how basic it is. The plan is to include clones of several popular interfaces and at least one or two unique ones.
A big goal here is to keep the interface logic separated from the hardware support code, so that most of the interfaces “just work” on most of the hardware. Adding a new driver, or adding a new interface, should be mostly independent of each other. I guess it’s similar to how traditional software separates hardware drivers from software applications, only scaled down to fit in a flashlight.
I hadn’t heard of him either until a few months ago. He does premium hand-made lights in relatively small quantities. They’re similar to Sinner’s lights, but a bit longer and narrower with different styling. He has been working on his own custom firmware lately and used bistro as a base, so he sent me a sample of his new DC2 to say thanks. I really should put up a photo review soon since it’s a beautiful light, but I’ve been preoccupied just trying to keep up with all the BLF projects lately.
Jeff has been making lights for a couple of years now. His design is really a continuation of the TriEDC that Mac popularized on CPF years ago. He’s a machinist in Oklahoma who kinda jumped in to fill the gap left after Mac disappeared, if you followed any of that drama. Jeff makes great lights, super clean machining and nice to hold and use, but with simple off-the-shelf guts (so far). The DC2 is his newest design, basically a stretched DC1 to fit an 18650. He just shipped the first batch. I didn’t buy one, but I do have one of his DC1 lights (earlier run, back when he called them the TinyDC). I basically treated mine like a host though - stripped all the guts out and rebuilt it, because that’s the BLF way
I’m kind of anxious to do that too. The H17F driver is very practical, but it doesn’t have any of the fun stuff I like to put on my personal lights. However, that will have to wait. It’s my only H17F light and I’m not done poking it.
Understandable. The H17f is really a great driver. Mine was early production, just a basic Qlite driver, nothing exciting. Besides, I really wanted to build a lighted tailswitch onto a McClicky, so I did.
I’m almost certain he switched to reverse-clicky omtens when he switched to H17f’s though, because McClickies don’t really take high currents very well. I put a mtnelec FET+1/Bistro in mine, but I’m really kinda…careful with my light and never run it on turbo for long. If I melt the McClicky then I ruin all the work that went into that switch mod, and I do not want to do that.
@TK: Not sure where i read your comments regarding party strobes and frozen motion, but that rang a bell. There are several kind of strobes i would be glad to have in a powerful flashlight.
One would be a ‘motion freezing’ mode with adjustable timing. Not sure how short you can expect the pulse to be or whether it can be used for photography but that would be really cool, at least up to some scale and speed of motion. It may not work at catching real fast things though?
Another would be a really wild party strobe, cycling through different patterns, possibly with ‘tap tempo’ feature to sync on the music.
I have the adjustable motion-freezing strobe already working. It changes the pulse width depending on the frequency, and works pretty well for things like spinning fans and falling water. At the moment it only has two pulse widths though… 1ms and 0.3ms. I’ve been meaning to check if it’s a good idea to use more, but it works reasonably well as-is.
The “wild party strobe” may be best left to other devices though, particularly ones which have a microphone so it can respond to music. I mean, who wants to spend their time at a party messing with a flashlight to keep it synced to the beat?
* looks around, realizes where she is *
Er, nevermind. Don’t answer that.
…
On a related note, did I mention there’s a momentary mode? It could be used for flashing to the beat.
…how about a ‘flickering candle’ mode…? or ‘flickering neon’ mode? or ‘defective old school light’ mode? 
TK mentioned a ‘defective lightbulb’ mode a while back. :+1:
I love the candle idea! A few thousand flickering lumens in this year’s Jack-O’-Lanterns sounds awesome! :partying_face: