Almost. Check out my image in the third post
I think the only thing I miss (only a little) is a more granular battery indicator. However, for the muggle, it may be be one too many features on a nice simple UI.
They have updated their ATR now. Sofirn’s SF47T tested quite well, still a small fluctuation, but not detectable by eye
LP - If the OP is the one you want, let me review it carefully - need to study it in detail. Maybe I can take a shot at it. Dunno if anyone else committed to an implementation yet. If I got Q's, I'll post here.
Under lots of pressure now at work, but I'm limiting my hours to under 40/wk (only getting paid for 32/wk now), but guess I'm lucky still working - lots get laid off here, several over 25 years here.
Thanks a lot Tom! Your help is really appreciated. I have just uploaded another update, please see below. Maybe this can be something to start with. Anyway, I am open for more feedback to come. :-)
Thanks for joining Jacob.
This is my latest draft of the UI chart, now including the popular feature to enable/disable aux/switch LEDs via 7C. Most commands follow the Andúril style or the classic UI style that we know from Wurkkos FC11 for instance. I talked to Barry (Sofirn) before and he said he liked this simplified UI, still offering the choice between stepless ramping and stepped modes. Many members on TLF who favor the UI of Wurkkos FC11 said they only missed a better ramping curve and the option to enable/disable the switch LED. I did not have any chance to talk to Mark (Wurkkos) about this UI in detail this year. It seems they are kept busy with something else. Communication is a bit difficult right now, tbh. WildTrail (ex LuckySun) will also be deeply interested into this UI and chances look good that we will soon see some new model of them with such an UI (still proprietary though).
Now, if we get to transfer this UI into the FSM code that Andúril is based upon, I see some great benefits:
- better logarithmic ramping curve (representing a linear brightness increase perceived by the human eye, not by current increase)
- probably better thermal properties when stepdown is triggered (maybe Tom E or gchart can confirm or disagree with this)
- standardized code throughout the entire FSM firmwares used on ATiny85 or 1616-MNR chips, making things easier to bugfix and update
- standardized and consistent UI for the next generation of flashlights with a simple UI, i.e. less efforts for development on manufacturer's side and less trouble in getting used to just another new UI for flashlight users
- option to offer a dual UI on future flashlights with the new AVR-1 chips, i.e. both this simple UI and anything more complex like Andúril 1/2, resulting in more flexibility both for manufacturers and customers and eventually more profit, too.
Looks good! Again, the only thing I’ll really miss from Anduril is the voltage (and temperature) check (/calibration/stepdown value).
It appears there is an arrow misplaced though? in ramping mode, near the bottom of the lower ramp…
It was discussed about having voltage check blink out on the switch when it’s turned on.
The new AVR-1 chip would come with the temp calibrated, and the firmware set to 55°C. As a simple version, marketed to the general public, you wouldn’t want too much customization
If pads were easily accessible we could flash custom code
Huh that is a cool function I have not thought about, but maybe confusing for some users…
Yeah I’d love to get some flashing pads on some of the Sofirn/Wurkkos lights! I hope the’ll start doing that once…
That looks good to me. Sort of like Convoys 4 mode with refinements, like being able to go from moon to low and from turbo back to high.
Re-use of TK's temp regulation I think would be a good thing. I'm not fully understanding it, or am comfortable in tweaking it per light, but overall it's one of the best available, considering it's trying to "do all for all" lights out there. Early complaints on Narsil was it only drops output, doesn't try to regulate it thermally. TK has a lot of time/effort invested in this.
So this is how I understand it, tell me if my understanding is not right:
- ramping is always the full ramping table, smoothly up to max/turbo
- stepped mode is always 4 steps: moon, lo, med, hi
Overall I like it:
- Not fond of the 10 click switch but like keeping 3 clicks consistent to get to strobe from anywhere
- I would make a lot of the settings here at compile time, or configurable, like the moon level, lo/med/hi levels, etc.. You may want specific settings for specific driver designs, or specific lights, for example low could be max of a single 7135 channel
- would want voltage and temp readings with ability to calibrate them (AVR-1 temp cal is good but might still need voltage cal?)
- could be considered to add a configuration UI, but at the least, have everything covered in well documented compiler settings
- like the consistent use of 1H to navigate mode/levels in each state
- it's really not too far from Anduril (2), just more simplified
Hi Funtastic, my guess is you were able to test some batches of Sofirn/Wurkkos flashlights — would it be alright to mention which models (new batches) already have an updated ATR?
Thanks in advance!
Just the SF47T and SP35, I highly doubt they’ll update the SP33.
Thanks a lot, Tom. I take the liberty to quote and answer, hoping to avoid any confusion. :-D
Yes, that what I was up to. As much as I respect opinions for "safer lights" handed out to muggles, my personal opinion is to not hand out high performance lights to small children or people not understanding excess heat in flashlights. Children will find out anyway how to circumvent muggle or simple modes and most customers will probably rant that their lights do not perform up to specs just because they forgot how to unleash full power by toggling into an advanced mode. That's what Andúril 1 or 2 is for and with my idea of a dual UI on one single MCU customers could easily choose which UI they prefer. Otherwise, manufacturers could also sell their lights in two versions, one with Andúril and one with that simplified UI.
That is in fact discussable even though I personally think that three standard modes (low-medium-high) is what's often called the "golden standard" in most classic flashlight UIs. A hidden moonlight mode (1H) as well as the obligatory turbo mode (2C) would conveniently complement this stepped mode UI.
Those 10 clicks are somekind of a trade-off with regard to following. Please allow me to explain my point of view:
- Hold the switch for several seconds would interfere with the moonlight mode and stepping up to standard modes
- 4C from ON would work but easily cause confusion with 4C from OFF to toggle electronic lockout.
- 10C would be "far enough" to avoid accidental change between ramping mode and stepped mode. Most customers set up their lights in either one of these modes and like to keep it this way.
I fully agree with you. Some specific settings like mode spacing between low, medium and high could require individual fine-tuning by the manufacturer. I wonder if something like this could in fact be realized in a hidden config sub-menu, e.g. by setting up the actual current in mA, similar to voltage calibration? I do not know how Neven is planning to offer this kind of configuration in his new drivers that he is going to sell anytime soon. I know it's a lot of wishful thinking here but I like the idea that manufacturers can predefine some settings in a hidden config menu and leave customers the chance to set up slightly different values, e.g. like Haikelite did with thermal thresholds in their SC26 light. I always encouraged Sofirn to implement three basic stepdown thresholds like 45°C, 55°C and 65°C to choose from, so far without any success.
If you like, I could try to enhance my draft UI by a hidden config menu that offers following features:
- voltage calibration (if still required with those new AVR-1 chips? Maybe Gabe can tell something about it?)
- mode spacing by current settings (click n-times to set up n mA per mode)
- thermal stepdown threshold (select from 45°C, 55°C and 65°C, default is 55°C)
The ability to check or read the voltage is entirely separate from voltage calibration. We need to be able to see the voltage some way somehow. Even if it’s slightly off and we can’t calibrate it, we still need to see it. I know I sound like a broken record, but the UI is going to be broken if we can’t see the voltage. I’ve put out my suggestions. Maybe we need more. I think everybody wants it. Anybody else? Speak now or forever hold your battery posts. And if you’re using the main LED that is already ON to blink it out then you’re automatically going to introduce a tiny little bit of error/variance due to voltage sag.
10 clicks is fine as long as you don’t have to do them very fast like Convoy.
As mentioned in a few previous comments, battery check is planned to blink out on the switch when turned on.
Yes for us voltage reading is very cool feature but for most users battery voltage means nothing. They can’t understood difference between total empty battery at 3.0V for example or 3.8V, or full charged battery at 4.2V. They will be more familiar with simple 4 blinks for battery capacity.
I like it, and wouldn’t change a thing. Well, maybe a couple small things.
But, I’m biased, because this is substantially the UI that some Olights have had (sans the ramping mode), and I recently acquired another light, the SP35, in large part due to my familiarity and fondness for it.
The latest diagram could simply be pasted into the SP35’s manual as is, with only a few minor alternations (change the stepped/ramped mode toggle to 4C, change the SOS/Beacon toggle to 2C and remove the button illumination setting).
If there was to be an Anduril fork based on this concept, with better refinement (the SP35’s ramping mode isn’t great), good ATR, and some extensibility, it would be a welcome thing.
With regard to some other comments made:
- I’m not fond of 10 clicks either, so why assign it to the stepped/mode toggle, and have the button illumination setting only seven clocks? If anything, I’d swap the two.
I’d dare to say that most users would switch between stepped/ramping mode more frequently than they would alter how the button illuminates. With my lights that have lit buttons, I initially played with the options to see which style I liked most, and haven’t touched the setting since. To me, a major functional mode change should be prioritized over a lesser, more cosmetic one.
- An explicit, or granular voltage check falls outside the "simple" scope of the concept, and into feature creep. As proposed, a relative charge status indicator, perhaps situated inside the switch, would be useful without being overbearing or open to misinterpretation by those who lack the knowledge or the context of what such figures actually represent. Smartphones and computers may have conditioned users to expect an explicit, granular percentage measure of the state of charge, but those are still relative indicators, not absolute indicators. "3.1 volts" isn't going to be as useful to the typical lay user than a red light. Or 3.7 volts, or 4.1 volts, versus a green light.
- USB-C is a connector standard that is employed for a multitude of functions. USB PD is a charging protocol. The latter is predicated on the former, but they are not one and the same, though they are often conflated as such.
The USB spec allows for Type-C power sources to supply up to 15W of power (5V/3A) without the need to employ PD, simply determined by the termination resistance.
The USB PD protocol employs bi-directional handshaking between micro-controllers in the source and the sink.
Some are already distrusting of on-board chargers. How much would they, or any user trust that a typical $30 light, with a fair chance of having buggy firmware, not erroneously ask for 20, 30 watts or more, and cook the battery or turn itself into a firework? USB-C and PD already has its share of implementation issues in costlier products from companies that can well afford to do it properly.
And, given that the modest power needs of the majority of on-board chargers can already be covered without PD, plus, the poor/partial integration of the C ports on lights as they first appeared (for want of some lousy resistors), would it even be desirable to begin with? A light charger doesn't need to be smart enough to actively ask for, and receive a particular power level. it only needs to be supplied with enough power to charge an encapsulated cell at a decent but not too high rate, which a "dumb" device like a flashlight can be set up to do without PD. Two current lights that can be charged C2C, the updated FC11, and SP35, are not PD devices.
TL:DR - The added cost and complexity of implementing PD in a flashlight is probably unnecessary, nor practical for the budget lights favored here.
I’m not seeing it other than my various suggestions. I use this feature at the end of most days to see where it’s at. You wouldn’t accept a fuel gauge in your vehicle that showed full until you were down to 30% of a tank.
(I’m not sure what functionality is implemented already, so if described below exist - just skip my post)
Since there are only 3 modes + moon in stepped mode, it could be helpful and easy to introduce to have short blinks as indicator of reaching relevant light levels, but while in ramping mode:
- 1 blink - equivalent of low level for stepped mode reached
- 2 blinks - medium level reached
- 3 blinks - high level reached.
Knowing how strong the light is -> how heavily battery is being drained, we can quite easy estimate the remaining work time (e.g. medium mode for particular flashlight lasts 8h, so if ramping is stopped after 2 blinks on full battery, light should work for another 7-8h). Without it it’s hard to make any estimations about remaining battery life.
If this UI is dedicated for common, non-enthusiast users, I’d propose some simple battery indicator instead of voltage readout.
(just asked my better half how much juice she thinks is left in 3.6V battery, knowing nominal voltage 3.7V - she had no slightest idea; I bet most of regular users have similar understanding 
)
For battery indicator it could be e.g.:
- 3 green blinks - 80-100%
- 2 green - 60-80%
- 1 green - 40-60%
- 1 red blink - below 40%
- solid red - below 20%
Of course numbers can be different, 5 blinks may be used for simple counting 20% for each blink etc., but you get the idea.
What’ya think?