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

LED Flashlights – General Info
1

Let me preface this by saying the fast majority of my flashlight collection are Convoys. I love the lights Simon makes and I appreciate his work tremendously. This post is not to bash on Convoy, but to offer constructive criticism because I love the brand so much and want it to succeed and grow. I posted this over on Reddit several months ago but another user recently pushed me to post it here too, and then send it on to Simon.

On the mechanical switch firmwares: Almost all of Convoy’s tailswitch lights are available with the “12 Mode Group” firmware that’s heavily based on Biscotti, and/or the “4-Mode” firmware that’s very simple. The 12-Group UI is good, but I find it lacking in a few areas and I think the 4-Mode UI can be made obsolete. I wanted to share and discuss some ideas for how I think these firmwares can be improved tremendously without any negative effects.

Add shortcuts
The biggest gripe I have with Biscotti is the lack of shortcuts. I think it would be great to have a quick double-tap function that can jump to 100% or to tactical strobe, and can be enabled or disabled. Right now the firmware’s main menu only has 2 sections: mode group configuration and mode memory configuration. I think it would be good to have a 3rd section for shortcut configuration. In this menu, a single tap should disable the shortcut. A double tap should enable/change the double-tap shortcut to 100%. A triple tap should enable/change the double-tap shortcut to tactical strobe. It should come with the shortcut disabled by default for ease of use, just like how Convoy’s 4-Mode firmware doesn’t have blinkies.

Move blinky modes
Right now there are several duplicate mode groups who’s only difference is the presence or absence of blinky modes. The duplicate mode groups should be removed and the a blinky modes toggle should be added as a 4th option in the programming menu. A single tap in this menu should toggle blinkies on/off, just how the 2nd programming option toggles mode memory on/off. They should come disabled by default for ease of use, and if they’re enabled they should just be added to the end of whatever mode group you’re currently using.

Add more mode groups & discontinue the 4 mode driver
Assuming blinkies are moved to a programming menu like I suggested in #3, that opens up room for more mode groups. With room for more mode groups, I think it makes sense to add the 4 mode group found in the 4 mode firmware and make it the default mode group. With mode memory enabled, shortcuts disabled, and blinkies disabled, and the 4 mode group set all by default, there’s no need for a separate 4 mode firmware anymore. I think the 4 mode firmware should be discontinued.

This will simplify buying options, eliminating questions for Simon and existing enthusiasts. It won’t make the light’s any harder to use for muggles either, because the stock configuration will be virtually identical to the existing 4 mode firmware. It will also retain (and add to) the customization possibilities found in the current 12 group firmware for enthusiasts. Finally, it will allow muggles who become enthusiasts to customize their lights down the line, rather than locking them into the 4-mode firmware they purchased with the light.

Adjust thermal regulation
Based on my independent testing of nearly a dozen different Convoy models, and based on reading reviews, I think that Convoy lights will not go below 35% current when thermal throttling. That is a huge problem because that still may be too much heat and cause temperatures to exceed safe levels. This lower limit should be eliminated to allow lights to thermal throttle as needed to keep temperature in check.

Change battery check
Currently, battery check is one of the blinky modes that appears at the end of a few mode groups. It uses 1-5 blinks to indicate battery charge level. Battery check should be removed from the blinky mode group and integrated as its own mode that’s always accessible through 10 quick taps of the switch. That’s out-of-the-way enough that no one will find it by accident, but it’s always accessible without having to enable strobe and the other blinky modes.

Add mode reversing & eliminate duplicate mode groups
Currently the 12-Group firmware includes a few mode groups that are duplicates, except that one is reversed. The duplicate groups should be eliminated and a mode-order-toggle should be added to the programming menu. This would eliminate some clutter in the mode group section while simultaneously allowing for more group possibilities.

On Convoy’s E-switch UI

Fix the issues or switch to Anduril 2
The E-switch UI used on Simon’s electronic side switch lights leaves a bit to be desired.

  • Turbo is always memorized. It should not be memorized when accessed via shortcut.
  • There is no way to go from Turbo back to the mode you were using. 2C should do that.
  • The only ways to get out of moonlight are off and Turbo. Hold from moonlight should go to low.
  • Holds take way too long (a full second). They should around 1/3 of a second.
  • Low is too close to Moon and too far from Medium. Low should be brighter.
  • Stepped ramp speed is too slow at 1 mode per second. It should be doubled or tripled to 2-3 modes per second.
  • Smooth ramping is too slow overall, taking 5 seconds to ramp from end to end. The speed should be doubled so that it takes ~2.5 seconds from end to end.
  • Smooth ramping is linear so the low end feels too fast and the high end feels too slow. It should be logarithmic instead so that it appears linear to the human eye.

At a minimum, those issues need to be fixed.

Lots of enthusiasts (including me, in a previous version of this post) have expressed a desire to have Convoy lights running the Anduril 2 user interface. While Anduril is fun for enthusiasts, it’s nothing but a headache for the average joe, even in the simple UI. It would be nice if Simon were to switch to using Anduril-compatible MCU’s, but it should not be the stock firmware on his e-switch lights.

On some minor hardware improvements

Lower the lowest mode
This is a hardware issue and not a firmware issue, so it’s harder to implement I think. I wanted to mention it nonetheless. On every Convoy light I’ve tried so far, the lowest mode has been very bright, like in the tens of lumens range. I would be delighted to see real moonlight modes (less than 1 lumen) in Convoy’s higher-powered models.

Add forward clickies as an official option in the store
Right now, Simon will usually install a forward clicky switch in most lights if you ask nicely, but I’d love to be able to just spec a light with a forward clicky on the product page.

Use ATTiny 1616 microcontrollers
Using these popular microcontrollers would allow enthusiasts to easily reflash whatever firmware they like onto a Convoy light, as well as perform easy firmware updates if features are added. This should absolutely be done on e-switch lights, but might it be possible to do on mechanical switch lights too? ATTiny 1616 specifically does not require thermal calibration (a big headache for other Anduril lights) and only needs 3 pins for programming, so adding a stadard 3-in flashing pad layout would be great. Selling a flashing adapter in the Convoy store would be even better.

What do you think about these changes? Are there any other changes you’d like to see? I’ll make sure to send this post to Simon soon.

2

I’d settle for a way to convert the E-switch drivers to Anduril. Whether that’s with flashed MCUs, MCU swaps… I’d love the L7 with Anduril, and others as well.

If Simon was using ATTinys we’d be able to easily flash whatever firmwares we wanted.

3

I agree. That would be excellent. I’ve added it to the hardware changes section.

L7 with Anduril would be interesting. The tailswitch would be rendered useless except for mechanical lockout, but I’d be happy with that. It bugs me that L7 current requires two hands to operate since it’s so large and the switches are so far apart.

4

All sounds good TG, no complaints.

5

Anduril has a compile-time option to enable dual-switch.

6

Oh, now that’s interesting! L7 would be incredibe with that firmware then!

7

I’m a big fan of Convoy flashlights but my biggest problem with the convoy drivers is that they seem to be unreliable. In my experience i’d say there’s about 70% chance you’ll get one that works properly. I had to replace the 4*7135 in my s2’s multiple times because of issues like it getting stuck in the config mode or stuck with the mode memory enabled or just randomly behaviour with the mode groups.
I ordered a packet of 5 drivers and 2 out of 5 had problems with config mode.
I love how easy it is to fix the S2 if it breaks (especially with the 4*7135 driver or the 5A driver because you have a retaining ring and don’t need to solder the driver to the pill) but I really would love it if the drivers were as reliable as the hosts.

As for the 12 group driver interface, I think the battery checker mode is really nice but there are only 3 groups that have it, it would be nice if there was a shortcut for battery checker from any group.

The mode spacing for the 5A driver could be better I think, with Lh351D and SST40 I think there is too much of a difference between mode 2 and 3. It seems like it goes from around 16 lumens on mode 2 (1) to like 160 lumens on mode 3 (10). A group that has a mode with 5% brightness would be really nice as a balance between brightness and runtime for general use.

I’m thinking maybe 1, 5, 10, 35 and a shortcut for 0.1% moonlight, 100% turbo and battery checker but realistically I’d be happy if the current drivers were just consistently reliable.

8

I quite like 12 group/Biscotti. It is nice and simple. The most pressing change to 12 Group/Biscotti is to change the strobe from the terrible alternating frequency strobe back to to constant frequency (anywhere between 10 to 20Hz with 50/50 on/off time would be good. Also strobe HAS to be able to memorized so that it is instantly accessible from off with a single click*. This would make it the best budget light for light painters.

  • sadly so many flashlights now make it so difficult to access strobes, that 95% of flashlights are useless for those who actually need to access strobes. It is possible to make firmware so that strobes might need the (what seems to now be usual) double or triple click to access from on, but after strobe is selected, it should then me memorized. This would mean that those who don’t need to access strobes should never enter strobe mode, but those who do use can have it memorized at the next turn on.

If Convoy does go down the Anduril route, a tail e-switch S2+ style light would be great.

9

I have no way of confirming this suspicion, but I think most driver issues I’ve heard of have been with 7135 based drivers. So, in theory, the newer linear drivers may be more reliable? Either way, unreliable drivers are certainly an issue.

I updated the post with details about how I think a battery check should be implimented.

After moving the blinky modes to a toggle-able option rather than having duplicated mode groups, there should definitely be space for another mode group with a 5% mode instead of 10%.

How do you suggest the 0.1% moonlight shortcut should work? The way I would do that is by selecting a mode group with 0.1% as a mode, and disabling mode memory. It’s not really a shortcut, but the light would always turn on at 0.1% mode. Do you have an alternative solution? Moonlight shortcuts are usually implemented on e-switch lights where holds are a possible action. Holds aren’t an option with mechanical switches really.

10

I added Anduril2 to the 3X21A, but had to lose the charging. Benefit was more power as well, 4 FET's replaced by one good one:

I know, it's cheating

11

That’s pretty incredible. I would be extatic to have Anduril on my 4X18A, even if it meant losing built in charging.

12

There ya go with the piggyback again!

13

I'm working on another one now for someone. Added a 3rd 20 AWG ground, and on mine I used two pair of 18 AWG wires, but for the new one, I'm using 1 pair of 16 AWG's. Every time I do a mod again, always make some improvements.

14

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.

15

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.

16

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.

17

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

18

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)

19

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

20

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.