Thank you so much for this information! If possible, please let us now when GearBest will have this.
FWIW I got my clear c8 from Simon a couple of days ago. Seems flawless to me. A bit difficult to get into configuration mode but that was just a matter of practice. I did somehow manage to have it go back to default configuration but I may very well have done that as I was messing around getting amp readings of the different modes. Put it back to my preferred mode 2 memory on and it has stayed.
Thanks again J-Dub, Simon, and ToyKeeper!!! This really is a nice light!
I have a few C8’s on order. Can someone clarify to me what thickness to reduce the centering ring spacer down to. I have a few lathes so Im thinking I could easily do this.
What is the stock thickness vs modded thickness?
Also where to source a thicker lens o-ring? What diameter & thickness for o-ring?
Thanks
Is thermal runaway a risk with leaving a C8 on at 100% power? Or does the light automatically step-down or have thermal protection to prevent this?
Alternatively, could I simply request the light configured with 7135x4 so it could be permanently used by muggles and hand it to someone without having to worry?
The older C8 does not step down, but I don’t think it needs to. I’ve never ran mine for really long periods on turbo, but I can say that it does not get real hot like the smaller S2 lights. The big head really helps keep it from getting too hot. If your still worried, then you can reflash the firmware yourself or else buy a new driver with a new firmware in it that can stepdown.
I ordered my C8 from MTN E and got Richard to flash the firmware to guppydrv. Not only does it have lots of mode options, it also has a user setable stepdown to 50 percent. It’s time based. I use this option on my 7135x8 S2+, but don’t see the need on my C8.
Now if it’s the new C8 with biscotti, I’ll let someone else answer, as I’m not sure.
What the heck are you trying to do?
Thanks for the detailed reply. I’m mainly worried about what would happen if it got turned on accidentally or if I gave it to someone and they just wanted to run it at 100% all the time. Sounds like this may not be an issue.
I do know that GB also stocks a 7135×6 version with the XM-L2 which may be an option too.
I just tried it for you. A new version 8x7135 Convoy C8, without the new firmware, stood on its tail in a room at about 18C, gets noticeably warm but not uncomfortable to hold (about 45C) after 20 minutes. Walking about with an airflow and heatsinking from your hand and it would be less. It’s got the mass of metal and surface area to get rid of the heat so it doesn’t need a step down. The LED is unlikely to be near its temperature limit.
Heat’s more of a problem with tube style lights with 8x7135 drivers which can get too hot to touch and souped up lumens are everything torches which have turbo mode with step down.
As for it being turned on accidentally in a backpack, they have anodised tail cap threads and so if you think there’s a danger of that loosen the tail cap by a quarter turn and it won’t turn on.
I’d guess the 6x7135 option appeals to people who prefer a longer battery life against lumens.
Thank you! This answers my question perfectly.
You also bring up a good point that the 6×7135 config would have a benefit of longer run time too.
It had been previously suggested that to lower the reflector (ie., get the emitter further into the reflector) would provide improvement.
Sorry, I didn’t remember that in this conversation.
You can probably just take the plastic centering ring and rub it on sandpaper to make it a bit shorter.
Take care that you have enough clearance between the reflector and the soldered wires so they don’t get shorted.
I don’t know any details on lowering the reflector for the C8, just on other models. I’ll let someone with C8 experience answer your question.
Keep on mind this thread is mainly about the new clear model and it’s new firmware, not a C8 mod thread.
Any chance someone could flash their red Convoy driver with new firmware and make sure everything works? 
The updated code is here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/convoy/files/head:/ToyKeeper/bistro/biscotti/
I managed to break the voltage divider on mine so I can’t check to make sure the values are correct. I’m guessing it should be fine since it’s the same values as before, but I can’t measure it directly until I get a new driver.
Anyway, this is pretty much the same biscotti as what Simon is currently shipping, but with a couple small things tweaked to hopefully make it more reliable and more tolerant of hardware variations. The specific things I want someone to check are:
- Does battcheck mode give correct values?
- Does moon mode light up?
If I understand correctly, Simon is ready to produce new drivers with this version if there’s nothing wrong with it.
Does this new version also address the “SRAM decay lottery” thing?
Yes, it should make that about a thousand times less likely. And it should also be tolerant of random eeprom contents (or at least should correct itself after tapping the button a few times).
I got it, compiled/built in AS 7.0 -
Program Memory Usage : 1000 bytes 97.7 % Full
Data Memory Usage : 16 bytes 25.0 % Full
Will be testing moon mode and the voltage reading shortly. Got a couple of the new drivers, trace cut to be able to program.
I'm assuming the headers come from working up the tree, the tk-calibration.h file dated July 4th 2016?
I see the moon mode lighting up (uses PHASE PWM value of 1), but the voltage values seem off a bit. Readings are generally higher, but in the low range, 3.1V reads as 3.3V. I enabled full n.n blinking to test it with real batteries.
I use 4 tables: for 19.1K and 22K R1's, and then with a diode before R1 or after R1. With these 2 variables you get 4 possible sets. Mine I've tested extensively. These should be the only variables effecting it, though I'm not familiar of what the impact is of a bleeder resistor.
These Convoy drivers use a 19.1K resistor (labeled 28C) and have R1 after the diode. So my table for this configuration seems to match up better on this driver. Here's your table:
#define ADC_44 194
#define ADC_43 189
#define ADC_42 184
#define ADC_41 178
#define ADC_40 173
#define ADC_39 168
#define ADC_38 163
#define ADC_37 158
#define ADC_36 152
#define ADC_35 147
#define ADC_34 142
#define ADC_33 137
#define ADC_32 131
#define ADC_31 126
#define ADC_30 121
#define ADC_29 116
#define ADC_28 111
#define ADC_27 105
#define ADC_26 100
#define ADC_25 95
#define ADC_24 90
#define ADC_23 84
#define ADC_22 79
Here's my table for R1=19.1K after the diode:
#define ADC_44 192
#define ADC_43 188
#define ADC_42 184
#define ADC_41 180
#define ADC_40 175
#define ADC_39 171
#define ADC_38 167
#define ADC_37 163
#define ADC_36 159
#define ADC_35 154
#define ADC_34 150
#define ADC_33 146
#define ADC_32 141
#define ADC_31 136
#define ADC_30 132
#define ADC_29 128
#define ADC_28 123
#define ADC_27 119
#define ADC_26 116
#define ADC_25 111
#define ADC_24 107
#define ADC_23 103
#define ADC_22 99Notice they are close/exact at 4.2V, some difference at 3.6V, and by 3.1V, they differ quite a bit, and that's where I'm seeing the biggest difference in your table on the Convoy driver: a 3.1V cell blinks out at 3.3V.
Ohhh - also ran into a compile problem when enabling full n.n blink out. I made this change:
#define BLINK_SPEED (187) // 2017-03-17 TE: this was 750/4
It didn't like the 750/4 because it did the math as a 16 bit value, then truncated to a 8 bit value. Also made this change:
_delay_4ms(252); // 2017-03-17 TE: This was BLINK_SPEED*3/2
because of the same reason. Not sure if it's the Atmel VS 7.0 compiler, and just happening under Windows, or not. Had to disable bike strobes, SOS, and remove some mode sets to get it tot fit in 1024 bytes, but it works! 
Edit: More info. I tested moon mode across 2 of the driver versions: 6 7135's (2.1A) and 8 7135's (2.8A) and on 3 different cells at 4.1V, 3.6V, and 3.1V and all combos worked fine.
Also -- I had to slow down the blink rate of the n.nV blinking in half because for some weird reason, I just can't count blinks going that fast - I can't. I tried many times, and just can't tell the difference between 6 blinks and 7, and it's even a little hard to see the difference between 2 and 3 blinks. Once slowed down, no problems counting then at all.
My sincere thanks to you both TK and Tom. This programming stuff is over my head but I will sleep better tonight knowing I have two BLF rock stars on the case! 
Thanks! It’s good to hear the moon level works; I was worried because it’s so low.
About voltage, I managed to fry my resistor so every reading is 255. Otherwise I’d just generate a new table with better values.
So, to clarify, the table from 192 (4.4V) to 99 (2.2V) gives accurate readings? If so, I’ll rebuild with that and send off the .hex. I think that was the only thing Convoy’s version needed, unless you found other issues with the default code.
About the 750/4 thing, I’m still trying to decide how best to handle that. Working in 16-bit makes milliseconds easier since we need 1000 of them for a single second. However, it takes extra ROM space. In this case, I needed a few more bytes and didn’t have them, so I replaced _delay_ms(uint16_t) with _delay_4ms(uint8_t). Lower resolution, but using an 8-bit parameter saves enough space to be worthwhile. However, it means all delay values need to be divided by 4, preferably at compile time instead of runtime. So I’ve been putting a /4 at each delay, to make it relatively clear how many milliseconds it should be, and that it’s not actually specified in milliseconds. But it still smells a little off.
The n.nV blink rate wasn’t actually tested in this project, but it’s good that you reminded me. I had kind of ignored parts of the code which were disabled for Convoy purposes. I didn’t even try to adjust the timing on that after messing with all the other delay-related stuff.
I'd say based on the measurements, relatively small sample, but spread from hi, med, lo, yes, the 2nd table is more accurate. I'm pretty sure I've done other testing against that table in the past as well.
From what I've seen, the only factors are the location of the diode and the R1/R2 values. The only unknown to me is the impact of a bleeder resistor - thought I'd seen it mentioned but not sure, but this driver doesn't have a bleeder resistor currently.