New Convoy C8 – Clearly better

Wait, what? You’ve got ramping working on a clicky switch?

I just built an MTN FET driver (no chip) for a triple XHP-50.2 that’s making 11,696 lumens, sure would love to have it ramp! :smiley:

I’m about to put it into an actual light for the first time, but I’m waiting for a cell to drain so I can calibrate the voltage. I had a spare S2+ (blue) with triple XP-G2 in it, so I gave it a new MTN17DDm with tiny25 and I’m putting Crescendo on it as soon as it’s calibrated.

Was surprised to see the 7135 activation level. It doesn’t light up until 5/255, even though an older MTN17DDm was working fine at 2/255. Not sure if it’s a difference in the new driver or just random luck. The voltage values seem different too.

After using it in a real light for a bit, I might tweak things more. Like, while waiting, I made it so there’s a way to go backward from turbo back to the memorized level. Seems a bit finicky though; still need to mess with it.

Very cool on the ramping. Given the difference between the number of steps between tiny 13 / tiny 25, does that effect the duration, in time, for the off to ‘full on’ ramping function? Just curious.

No, the timing isn’t affected. It automatically sets the delay between steps so that it will end up taking the same amount of time to go from one end to the other. The default is 2.5s from moon to turbo.

What kind of 7135 do you have in each? Crappy Sailboat, or Raptor Claw? :smiley:

The old and new MTN17DDm drivers seem to use different 7135 chips. The new one apparently has a Sailboat 38E (380mA), which is known to activate slower and not work as well for moon mode. Not sure if this is normal though, or if he just put the wrong chips on a batch sometime.

This week the replacement for my “SRAM decay lottery” driver and an usbasp programmer has arrived, so I made my first (and then a several) attempt to flash a firmware to a driver:

First I was trying to reflash the failing driver with the new crescendo firmware, but nothing happened, there was no light coming from the led at all.
Then I tried to flash the latest biscotti, that was somewhat working, but weirdly. In many cases I was not able to change mode, moonlight came after moonlight, sometime the setup came in unintenionally. It’s like the driver expects faster tap than I was able to do.

Then I was trying to flash the firmwares to an older green driver, with 105D wording on it.
The crescendo one wasn’t working here, biscotti was, but there was no moonlight.

I tried to do the flashing first with fuse values that avrdude showed when I just checked the status of the driver, then with the standard 0x75 and 0x77 values, but to tell you the truth, I don’t know yet what those values really mean :slight_smile:
And I was working with the hex files only, I did not do any .c to .hex conversion, nor code modification.

FWIW, I got a clear C8 last week from Simon with whatever stock biscotti firmware (it is a red PCB). Mine works flawlessly and I truly appreciate all the hard work that went into it!!!

I don’t have the equipment to measure lumens and FWIW, my DMM is an Innova 3320 so I am merely in the ballpark with my observations. That said, with the stock XPL-HI, my readings are roughly:


This is so fascinating to me as I don’t really have a clue as to what lumens really are supposed to be. I do know that I would like an even lower low if that were possible so that I could move around without waking up my wife or affecting my night vision. That said, my rough guess is that the current low .008A in my case is actually a pretty usable amount of light and probably I am better off just using my Ti3 when moving around the house in the dark. At .008A I am guessing that the XPL-HI actually puts out a touch more than 2.6 Lumens. This is quite amazing to me as I used to carry a Maglite Solitare around and that was all it could put out and it was useful. The C8 can do that on a single 18650 for as long as something like 100 AAA batteries in the Solitare. That is just an amazing advance in my lifetime.

At .07A we are roughly in the territory of a 2D Maglite from my youth!!! 10X the power and 10X the light? Perhaps not but it feels kind of in the ballpark. Yet, with this light this is actually low mode.

Roughly 5X more power (0.36A in my case) and you are in the ballpark of a 6D Maglite from my youth. Certainly quite noticeable compared to the 2D but nowhere near 5X the light.

The next step for me is 1.12A or roughly 3X the power for likely 2X the Lumens. This is still a very noticeable increace but 2X and for 3X the power.

What is most amazing to me is that at the 2.8A turbo setting it is using roughly 10X the power to put out roughly 5X the number of Lumens and to my eye it seems like maybe only 2X the light.

Lumens to apparent light? Power to Lumens? Law of diminishing returns? Logarithms in action? I just can’t quite get my head around it. I do know that I really like the clear C8 and I am amazed at what it can do even if I don’t understand it.


Be careful with those fuse values. Give it the wrong number and it can brick your driver.

Anyway, it sounds like you’ve been running into issues with moon mode calibration. Depending on the driver (and some other factors), moon mode will be anywhere from PWM level 1/255 to level 9/255. This is set at compile time, based largely on trial and error, and it’s one of the main reasons why moon mode isn’t more common. Slight hardware changes can make moon mode stop working.

If the existing .hex files aren’t calibrated correctly for your hardware, you’ll basically need to calibrate it and compile with more appropriate values. Typically this involves trying moon values until you find the lowest one which works, and also measuring voltage readouts to make LVP and battcheck work. For drivers with an offtime capacitor, OTC calibration is necessary too… but that shouldn’t matter for biscotti or crescendo since they don’t use OTC.

The button taps are indeed quick. If the button moves far enough to click, it’s way too slow. The timing depends entirely on hardware design, but I’ve seen anywhere from 0.1s to 0.6s as the threshold between a short press and a long press on this type of driver. This morning I actually made a robot determine the tap time threshold on one of my lights, and it ended up being about 0.17 seconds.

I really hope that Convoy now understands how amazingly sensitive some of this stuff is to small changes in hardware. Last time, the driver hardware changed completely between development and production, so a number of things weren’t quite right. I hope now he realizes that one can’t change the hardware without recalibrating the firmware… not even switching to a different brand of 7135 chip with the same specs.

The relationship between lumens and apparent brightness is widely considered to be a cube-root function. Take the cube root of the lumens and it approximates how bright the output actually appears.

For that, you’ll need a different driver. That low mode is about as low as it can go. You could use a “moonlight special” from MtnElectronics, which is designed for this, or a FET+1 like the MTN17DDm. Both are designed to get good performance on both low and high modes, with a separate power channel for low modes.


Thank you for that explanation!

OK, the more I think about it, the more I am willing to just use my Ti3 for the moonlight. Pretty happy over all with your driver. THANK YOU. At 0.1%, as long as I am careful it doesn’t blow my night vision. It is truly a usable amount of light that can go for hundreds of hours on a single battery. This is a huge improvement over my other C8s. Good to know about the other drivers as well and perhaps one day I may indeed add to my collection that I say I’m going to stop adding to;-)


The triple channel driver that Pilotdog68 worked up and Texas Ace is implementing is one of the most efficient of our modern FET style direct drive Turbo drivers. It using 3 channels, first with only one 350mA 7135 chip for moon and maybe the second level, then a second channel that has from 6 to 8 of the 7135 chips for regulated current to the middle modes up through high, and third the MOSFET that drives Turbo more or less direct from the cell. This clever arrangement makes the most of a cell and is particularly useful for small cell lights that push the envelope on the high end, like with the new XP-L2 emitters where 2000 plus lumens is possible. The C8 fares well here, as does the X6, both of which I’ve seen over 2000 lumens from a single 3V emitter.

With the reversing function one need never hit the cell with the Turbo BAM!, it’s easy to stay in the lower modes and conserve battery life until life demands the utmost delivery…

I want to make sure that I’m understanding the math correctly.

1000 Lumens -> cube-root is 10
500 Lumens -> cube-root is 7.94
100 Lumens -> cube-root is 4.64

Based on this, 1000 Lumens is perceived as roughly 25% brighter than 500 Lumens, correct? And 1000 Lumens is a little more than double the brightness of 100 Lumens?

The cube-root units are totally arbitrary. You can think of them as “steps” of perceived brightness. So, 500 lm looks about 3 “steps” brighter than 100 lm, and 1000 lm looks about 2 “steps” brighter than 500 lm. Here’s an example with nice round numbers from my ramp calculator:

./ 1 10 7135 1 1 1000
1: visually 1.00 (1.00 lm): 1.00/255
2: visually 2.00 (8.00 lm): 2.78/255
3: visually 3.00 (27.00 lm): 7.61/255
4: visually 4.00 (64.00 lm): 17.02/255
5: visually 5.00 (125.00 lm): 32.53/255
6: visually 6.00 (216.00 lm): 55.66/255
7: visually 7.00 (343.00 lm): 87.95/255
8: visually 8.00 (512.00 lm): 130.92/255
9: visually 9.00 (729.00 lm): 186.10/255
10: visually 10.00 (1000.00 lm): 255.00/255
PWM1 values: 1,3,8,17,33,56,88,131,186,255

I find that a useful mode spacing should have roughly the same number of steps between each level, and that an interval of ~2 steps looks pretty good. So, on a light which goes up to 1000 lumens, I’d normally do about 6 or 7 steps instead: (this example is something like a “moonlight special” driver)

./ 2 6 7135 2 0.2 140 7135 2 2 860  
1: visually 0.58 (0.20 lm): 2.00/255, 0.00/255
2: visually 2.47 (15.03 lm): 28.84/255, 0.00/255
3: visually 4.35 (82.36 lm): 150.69/255, 0.00/255
4: visually 6.23 (242.26 lm): 255.00/255, 31.56/255
5: visually 8.12 (534.79 lm): 255.00/255, 117.82/255
6: visually 10.00 (1000.00 lm): 255.00/255, 255.00/255
PWM1 values: 2,29,151,255,255,255
PWM2 values: 0,0,0,32,118,255

OTOH, for a light which does smooth ramping, like the BLF Q8, I find that it looks better to have only ~0.1 or ~0.2 steps between levels… and a lot of levels. IIRC, it has a ramp 128 levels long.

./ 2 128 7135 2 0.2 140 FET 2 10 4000
1: visually 0.58 (0.20 lm): 2.00/255, 0.00/255
2: visually 0.71 (0.35 lm): 2.27/255, 0.00/255
3: visually 0.83 (0.56 lm): 2.66/255, 0.00/255
126: visually 15.63 (3820.73 lm): 255.00/255, 243.22/255
127: visually 15.75 (3909.68 lm): 255.00/255, 249.06/255
128: visually 15.87 (4000.00 lm): 0.00/255, 255.00/255

It may seem weird that low levels have only 0.15 lm between while high levels have 90 lm between, but it looks linear in practice.

I’m getting old enough that my long multi-paragraph answers annoy even me.

Just go do things, use the light that makes it fun to do what you’re doing. KISS

I was gonna +1 that post Dale, but regretfully didn't . All good!

Thanks for the detailed reply. This makes sense to me.

Oh you.

Me, I would never write anything so wordy. Don’t scroll up to see my comment a few posts ago.

Simple is good though. Like Narsil. It’s so easy and simple that it’s almost boring. It just does what I want, by default, without me having to mess with anything. I almost want to throw in some inconvenient quirks just to make it exciting again.

You can fit me into Narsil?

<—- 215 lb bag of inconvenient quirks

If every Narsil came with a free Dale, even China wouldn’t be able to produce them fast enough.