Proposed Improvements to Convoy's user interface(s).

Yea I do think the 5A driver is more reliable, I only had one of them fail, I had my 5000k LH351D on mode 3 (10% brightness) and the beam started to turn angry blue and it got super hot so I had turn it off, not sure what went wrong but the lower brightness modes stopped working completely. I replaced driver and Led and it’s fine now though.
I just like the mode spacing and runtime of the 4*7135 drivers but I’d pick the 5A driver for reliability and nice output.

Well I think it’s probably good if the light always comes on in moonlight, just need to find a good balance between the mode spacing and having too many modes to tap through. Most of the groups are too similar in terms of mode spacing. Adding a toggleable option to be able to choose whether you want ascending or descending mode order would further reduce the amount of groups needed, pretty much like the Reylight driver.

I like the idea of being able to disable/enable a true low moonlight, like the way you can disable it in Reylights or the way you can disable mode memory in the current convoy drivers.

So for example an S2+ with 5A driver and SST40 (take these number with a large grain of salt)

Mode 1 (0.1%) 1.8 Lumens

Mode 2 (1%) 18 Lumens

Mode 3 (10%) 180 Lumens

Mode 4 (35%) 630 Lumens

Mode 5 (100%) 1800 Lumens

Modes 1 and 2 are fine.
There’s a big difference between 2 and 3.
Most of the time Mode 5 will look very similar to mode 4 because it will step down due to heat.

So I think adding a mode with 5% would give a nice brightness of around 90 lumens maybe in this example. And 20% could give around 360 lumens maybe.

I don’t like how the current drivers have 20% separate from any of the groups that have moonlight or 10% so all of my convoys just have the default group 1 selected, the other groups are just too similar with minor differences.

Also for your suggestion of 10 taps for battery indicator, I think that would be good as long as you don’t accidently go into config mode and yea i’d love too see accurate voltage read outs rather than the current indicator.

Agreed. I think having several groups starting at moonlight and ending with 100% would be good. Probably five total, ranging from two to 6 modes, with an even multiplier between the modes so the spacing looks consistent. For example, the 4-mode group would look like 1 - 10 - 100 - 1000 lumens, where the multiplier is 10x.

Being able to reverse the mode order is a great idea. That would eliminate a few duplicate mode groups and it would also allow for more total configurations.

That strikes me as crossing the line from adding complexity for the sake of improvement, to adding complexity for the sake of complexity. I don’t see a need for moonlight mode to be toggle-able because I think most users who would not want moonlight would be served just fine by a mode group that doesn’t have it.

Keep in mine we perceive brightness logarithmically. Jumping from 1.8lm to 18lm is visually the same increase as jumping from 18lm to 180lm. Out of those particular lumen numbers you provided as an example, mode 4 seems out of place to me because it breaks the otherwise consistent 10x lumen increase multiplier between modes.

Yeah, I would not want the 20 taps for programming to be changed, so 10 taps for battery check should not get anywhere near the programming mode.

It is not accurate to say “we perceive brightness linearly.” We perceive it logarithmically. 2 lumens does not appear twice as bright as 1 lumen. But you are comparing relative increases in terms of percentage and saying equal % increases will be perceived equally.

You are absolutely right. That was a typo and has been corrected.

That’s great if the number of groups can be reduced and added more variation for users. Like if you preferred a different multiplier for the mode spacing. I don’t know if it’s possible to make the brightness of the mode groups this specific (I have rounded up and down some of the numbers) but it would allow for a lot more customization of brightness and personally I think the x3 multiplier could be really nice.

0.1, 0.4, 3, 17, 100% (x6 multiplier)

0.1, 0.8, 4, 20, 100% (x5 multiplier)

0.4, 1.5, 6, 25, 100% (x4 multiplier)

1.2, 4, 11, 33, 100% (x3 multiplier)

0.4, 1.2, 4, 11, 33% (x3 multiplier)

There needs to be a 35% mode as that is where the S2+ tends to thermo-regulate.

That depends heavily on the emitter used. A super efficient emitter like SST40 is going to sustain a higher drive current than a lower efficiency emitter like an SST20 4000K. Since sustained output varies based on emitter efficiency, I don’t think that should be a deciding factor when determining output levels.

Actually they both regulate at approx. 35% in the S2+ but have different drivers suited for the emitter’s max output - 5A and 2.8A respectively.

That’s true that there are two different drivers. I believe it’s just a matter of older versions coming with the older 2.8A driver though, as all of the newer releases (except for 219B which can’t handle 5A) come with the newer 5A driver and newer 12 group firmware.

The efficiency of the emitters doesn’t appear to correlate with the drivers either, as the 2.8A driver comes with a few high efficiency emitters (xpl-hi, SST20 5000K+, XPG2) and a few low efficiency emitters (219C, LH351D, SST20 4000K-), so the stable outputs don’t appear to correlate with the driver choice as you’re suggesting.

Regardless, in my proposed UI changes, you could simply choose a mode group that includes a level near 35% like you prefer. Or, you could adjust the thermal limit up or down to achieve the stable output you want.

Use ATTiny microcontrollers

Not really big fan of Convoy’s 12 mode group UI here but I mostly use custom UI anyway but since Simon changed MCU those drivers become totally worthless for me which is a huge hassle because now I have to find them from other suppliers so you have a big YES from me for returning Tiny13a MCU.

I would like to see a way back to last used level from turbo in the 4 mode UI.

That’s super easy to do already. You just have to know what mode you were in, then it’s a quick 1-3 taps to return to that mode. I can’t think of a simpler way to do it than that.

Anduril has spoiled me. Also some UIs double tap to turbo, single tap back to last used level. You can sort of do this double tap back if you do it slowly but you are turning the light off first then the second tap turns it back on to memorized level. After going to turbo with the Convoy, you have to cycle through L, M, H to get back. Low seems like off practically after turbo.

Oh yeah I get that. It’s just dependent on the switch type. For e-switches I want Anduril 2 of course. But, most of their lights use mechanical switches and I can’t think of a great way to do a “return to last used mode from turbo” function on a mechanical switch.

Sorry, I should have said with their side switch lights.

Oh yeah totally. As I said in the first post, rather than improving Convoy’s existing e-switch UI, I think it would be better to go ahead and adopt Anduril 2.

I wish so too. As long as he keeps his boost driver with it.

tactical_grizzly those are nice ideas, I would like simon to replace the 4 modes driver into a 5 or 7 friendly groups without tactical strobe, something like this:

Great feedback, Josh V!

That defeats the purpose of both the 4 mode driver (being very simple with no configuration) and defeats the purpose of my proposed modifications (no longer needing multiple user interfaces in Convoy’s mechanical switch lights to suit novice and advanced users). The suggestions I propose would accomplish the goal of making the default configuration simple, and it would not have tactical strobe enabled by default.

To be clear, “clicks” on a mechanical switch light turn the light on and off. It’s not just sending signals to the driver like on an electronic switch. So, I’ll assume those are meant to be “taps” of the switch after the light has already been turned on.

I don’t think a double tap for moonlight would work well. The light would turn on in whatever mode, then after a double tap would change to moonlight. In my experience, moonlight must be directly accessible from off for it to be useful. Otherwise I just blind myself first before moonlight comes on.

A triple tap for battery check might be OK, but I personally would prefer a triple tap to be reserved for something I need more immediate access to, such as Turbo, Strobe, Bike Flasher (for crosswalks), etc. Battery check is something I only use when time is not off the essence, so I would prefer it take more taps (like the 10 I have suggested) so that double and triple tap shortcuts can be used for more time-sensitive functions.

That looks almost exactly like what I’ve proposed, just with 75C and 85C added as options. I don’t see much point in having them since most batteries cannot safely handle temperatures that high, but I wouldn’t be oppose to those options being present as they don’t detract at all from what I’ve proposed.

Not in this case. We’re discussing the drivers for Simon’s mechanical switch lights, and lights with mechanical switches cannot detect clicks and holds. They can only detect momentary interruptions of power, achieved by quick taps of the switch once the light has already been turned on.

I agree. Having tactical strobe (or any of the blinky modes) in the default configuration of the 12 group firmware is a problem. I think that simply making the 12 group firmware default to mode group 2 would be enough to eliminate the need for the 4 mode firmware entirely, but I would also like to see these additional changes I’m proposing implemented as well. I don’t think there needs to be separate “friendly” and “advanced” firmwares. The firmware should come by default in a friendly state, then the user can customize it if they choose.

tactical_grizzly nice points of view!, It seems that the only way to fit all tastes is a wireless driver with a phone app, if i knew of electronic components and circuit building, I think I would having fun building slowly the app and testing a full customizable driver.