Yes, it’s definitely not slow. NarsilM turns on as soon as the button is released, or as soon as it has been held long enough that it counts as a “hold” instead of a click. If you have a better idea what to call it, it might make the concept easier to convey. Easier than writing out something like this, I hope:
When turning on with a single click…
Button is pressed. Anduril turns on at floor level, NarsilM stays off.
Button is released. NarsilM and Anduril both go immediately to the memorized level.
Timing window expires. Both UIs stop looking for more clicks.
When turning on with a hold…
Button is pressed. Anduril turns on at floor level, NarsilM stays off.
Timing window expires. NarsilM turns on at moon level, Anduril makes a subtle “blip” to provide a timing hint.
Second timing window expires. Both UIs start ramping up.
Eventually, the button is released. Both UIs stop ramping and stay at the current level.
When turning off with a single click…
Button is pressed. Nothing happens.
Button is released. NarsilM turns off, Anduril waits for more input.
Timing window expires. Anduril turns off and goes to sleep. Both UIs stop looking for more clicks.
5 seconds later: NarsilM goes to sleep.
The difference is a small one, turning on at button press instead of button release, but it’s something people seem to really notice. Same with the delayed vs immediate off. The response to it has been unexpectedly large.
I’ve been meaning to change that, and I keep forgetting.
The original idea there was, if there’s more than one click, it should turn off and wait until the user is done pressing the button before it responds. But to make the mem-to-ceiling change smoother, maybe it should instead use the policy of turning off at the beginning of the 3rd click instead of the beginning of the 2nd click.
…
Edit: Okay, the code change was trivial, but I still need to do some testing to make sure it didn’t break anything.
Edit 2: Seems fine; I pushed the changes up to the repository in the fsm branch. It should land in trunk within a few weeks; I do most of the FSM-related development (including Anduril) in the fsm branch and merge it into trunk every month or so.
Thanx TK! Just dnld'ed latest Anduril source and built it on Win10 Atmel Studio 7.0 for the first time, so I'll be checking it out.
In NarsilM, the dbl click from off first displays the last used level, then goes to max. I always considered that a natural progression.
Most of the ramping UI operation came direct from BLF users, so not sure where it's non-intuitive - would love to know more on that. Maybe the config settings is where the difficulty is? I find I got to look up stuff in the manual myself because I use it so infrequently.
That was fast I’m Android developer and still that impressed me. I guess that’s the beauty of open source, just a simple message in the forum, can lead to a change in product you love.
Is there a changelog for the builds you make? I want to be able to see when this made it to the builds, so I can update mine Q8.
For what it’s worth, I’d recommend grabbing the fsm branch instead of trunk. I do most of my development in the branch, and merge it into trunk every few weeks after a round of more detailed testing, so trunk is generally a few weeks behind.
I’m not sure how the build works in Atmel Studio. I mostly just run ‘make’ from a command line, to compile all the supported build targets. Each cfg-*.h file is a build target. I’m guessing Atmel Studio will need some settings copied from the bin/build.sh script into the GUI somewhere, to set up compiler options and include paths.
For an introduction to FSM and how to use it, I’d suggest looking at the first few posts of the FSM thread, or at the Baton UI code which is intended to demonstrate the general pattern. There’s also some documentation which may be of use, though I don’t always remember to update it when the API changes. I find it easier to learn by example than by reading documentation.
I don’t have a build changelog, but the repository has a commit log. Also, since this change was a universal one which affects every build target, and because it’s user-visible, and because it’s very low-risk, I uploaded a fresh set of builds for it:
My apologies. For some reason I was under the impression that you had provided the original code to Fireflies, but that they might have then tailored it further themselves. I don’t know where I got that wrong idea.
I was not aware that you were still in control of, and responsible for it, continuing to maintain, improve, develop and test it for them, still in the loop. Presumably for other torches too. Sorry for any FUD.
Are all of these torches built with the same final tested firmware release, or are your continuing improvements being sent to Fireflies for use as production continues ? I understand that you are continuing to refine the code, so I presume that Fireflies intends to make use of it, or is it now only a personal project ?
Should a skilled user be advised to flash a newer version them-self, having studied a bug-list/revision list and made a risk/benefit decision ?
Have you considered adding a hidden method of blinking out the revision version of the firmware, for those who are curious to know ?
With this high-risk fast-track approach to releasing under-developed stuff as early as possible, then relying on tweaking it in later production, early adopters being the guinea-pigs (and kick-starters), it could become important. This may not be the intended design philosophy, I’m sure everyone likes to think that their initial product is as perfect as could be, and that they, being young, know better and think faster (true) than those boring oldies who just get in the way in higher management, but that’s not really how it works, if you don’t do the basic boring development work, prototyping, testing, re-design, re-testing, field (user) testing, etc.
By including a connector that allows the manufacturer, or even users, to re-flash easily without disassembly, this may become important. It’s a great idea, and means these could even be completely built before the code has even been finalised, then flashed with the alpha release, and fully inspected and tested of course, as the final step before shipping. Excellent for the coders, hard deadlines no longer required, keep tweaking until the last minute, and even beyond. No longer a need for the MCUs to be sent out for programming before being soldered onto the driver, with all the logistics, expense and planning that that entails.
As you have said, these are early days for Anduril in production torches, and we must anticipate a few bumps and squeaks as they get into many hands, and feedback comes in. Sometimes the developer is the least capable of testing their own work critically, that’s why independent test teams are sometimes used, but that also requires a Software Design Specification for them to work with, and I get the impression that that’s not how you like to work, nor thought necessary for a torch driver firmware. However these firmwares are becoming so complex that perhaps they are outgrowing what is sensible for one individual to try to tackle alone. Or for a manufacturer to become totally reliant on that individual for ongoing support and development, instead of also having their own capable people. It can work very well for a while, fast and lean, but it also just takes one wobble (or being run-over by a bus) for it to quickly go pear-shaped.
My guess is that Fireflies works on a bus factor of 1 in most disciplines.
Do these torches carry an individual serial number so that their manufacturer can trace the firmware and hardware build standard, in case issues arise and need to be investigated, even corrected, or straightforward decisions made to just replace with a newer version, as it is a known problem ?
If not, I could foresee a configuration control and warranty crisis looming. It’s not as if it hasn’t happened before. ISTR the BLF X5/X6 got built with an early version of your firmware that you didn’t think you had released, and wasn’t quite right, instead of the later version that was too late for their production timescales.
Please could you also clarify whether the different LED options have different firmware, e.g. is the Nichia version throttled back to protect the LEDs, or is that still just left to the responsibility of the users to figure out for them selves? (LEDs degrade slowly, but the difference between lasting 20,000 hours, or less than 100 can be very close.)
Ok so I just got mine and I’m not exempt from problems….I kinda worked it out, but not solved, while I was typing this so just read in case yours has a similar issue.
I received mine in a stepped mode so I switched it to ramping. Ramping is working along with turbo just fine. The AUX LED were working; I toggled between off/on/blink and they seemed to be ok, I did that like twice but now the AUX LED won’t come on at all. I tried three different 18650 batteries with and without button tops and the included 18660 adapter. I don’t have to crank down hard and they fit fine. I own four ROT66 so I’m used to Fireflies UI. I’m not in muggle mode, momentary, blinkies, or locked out (lock-out makes 2 switch LED blink while the other 2 remain on). Again, ramping with turbo mode is working fine.
I don’t see metal shavings or burring. I did find way too much dirty lubricant all over the threads and driver area so I’ve removed most of it but no change to the torch action.
Just now I tried 7 clicks again to switch between AUX LED modes and instead the 4 switch LEDs are now on. 7 more clicks and the switch LEDs are blinking (2 of the 4, but I’m not in lockout, the ramping works), and 7 more clicks and 2 of the 4 switch LEDs are off. Then I did it all again, and it does the same thing. So the 7 clicks for AUX LED are instead controlling the switch LEDs. Did I somehow fall into a hidden backdoor? Remember the blue AUX LED were working originally.
When Aux are on all four switch are lit, then the top left and bottom right will blink in sync with Aux in blink mode, and those same two will be off when Aux are set to off. Sounds like something happened to your aux board or LEDs because the firmware is controlling the switch LEDs correctly.
Thanks Playd0h, that makes sense! The ROT66 didn’t have adjustable AUX LEDs so I wasn’t sure how that worked. I wonder if it’s the hardware or I somehow disabled the AUX LEDs since this is a new feature for Fireflies. I don’t want to say it’s hardware failure just yet without working through it.
I had it sitting with all four switch LEDs on and then the AUX LEDs came on by themselves. I turned the head off and back on and yep, they’re out again. It would appear to be a mechanical issue of some kind, poor connection.
Edit: It also has these other minor issues, and the AUX LEDs have started flickering too per my post below. The purple switch is not flickering so the head gets battery power fine.
-The head has a rough area, maybe scratched is the wrong word.
-It’s missing half a rib on the tailcap.
-It has the same optics marks I’ve seen posted by others.
-The PL47 won’t work with the included button top cap yet it will work without it, with a flat top battery in the adapter. May be due to that solder blob on the spring.
-The included headstrap is worse than the one in the original photo, it doesn’t touch the torch at all. It’s hard plastic. I don’t really care, just saying what it is.
All this is minor I suppose, except for the flickering AUX LED issue. Whoever quality checker #12 is needs retrained Jack. (It’s a stamp on the box)
All that is interesting but quite the opposite of the PL47 I got. Mine is well made, works perfectly, I have to give Kudo’s to Jack for a job well done. Giving the light as a Christmas present, wouldn’t do that at all if I weren’t confident in it.
May I ask what you intend to do with the light if/when Jack replaces it? I would like to see what is going on in there, if at all possible and if you yourself aren’t keen on modding and plan on breaking in…
I’m Android developer and still that impressed me. I guess that’s the beauty of open source, just a simple message in the forum, can lead to a change in product you love.