Welcome to BLF. :+1:
It’s impressive that the LED still lights up a little at 0/255 in fast mode. That doesn’t happen on most 7135 chips, or on older LEDs. This suggests to me that it may be feasible to lower moon to 1/255 at 8 kHz. I’ll have to give it a try.
However, if any hardware changes, it’ll probably turn that nice moon mode into another “off” mode. There’s a reason why I calibrate my personal lights individually instead of using identical code on each. Some of this stuff is really sensitive to small hardware variations.
BTW, the reason why fast PWM=0/255 can still light up is because of a quirk in the attiny’s PWM generator. In fast mode, it spikes the signal at step zero, no matter what, then turns it off again when it hits step N. When N=0, that gives it something like half a step worth of pulse. It does something similar at the other end too, turning off after step 255 no matter what. So, fast PWM=255/255 will still be off (ish) for a very brief time between cycles.
The phase-correct PWM mode doesn’t do either of these things. At 0/255 it doesn’t generate a pulse at all, and at 255/255 the signal stays high with no interruptions. However, it runs at half the speed (512-step ping-pong / triangle wave instead of a 256-step sawtooth wave).
I thought it was going to use a reflashed 105D. That’s what the code was written for, at least. It sounds like it should still work fine though, aside from some timing differences. Those can be changed by cutting a trace and reflashing, or perhaps by waiting for a new batch.
Personally, I recommend that people use this as an excuse to get into driver flashing. You can do all sorts of cool stuff by changing the firmware.
Thank you for the review. I love the new firmware. I just ordered one and can’t wait to get it! 
From where did you order it? Aliexpress says no longer available?
Just FYI, Simon’s Convoy Store on AliExpress is closed for Chinese New Year Celebrations until mid February.
That is why it says that, no orders are being taken at this time because they are closed. 
Yes, that’s why I asked him where he just ordered it.
I ordered it from banggood: Convoy klar C8 Xp-l-hi 7135x8 Neue Firmware LED Taschenlampe Sale - Banggood Deutschland sold out-arrival notice-arrival notice
Only 3A tint in stock which is luckily the one I wanted, but other tints due back in stock January 28.
Total cost: $20.76 delivered with code: c8series
:+1: …… Just sharing the info in case someone did not know or misunderstood the reason why, after you said; “Aliexpress says no longer available?”
Banggood has them in stock still.
TK, I couldn’t agree more!
I ordered the driver with new firmware, timing seems ok on them easy to do modegroup and flashy modes seem ok
Is there a clip for this light? Or for any c8? Only one I can find is very thin, made also for a s2. I actually have a few of those already and they are too flimsy for s c8 size. And the other clip I found was needed to be screwed on.
Yeah, the snap on clip we made technically works on the C8 but it is far from ideal. Really, there is no ideal clip for a C8 and honestly the format of the light itself is not “clip-friendly”. It is much better suited to holster carry and lanyard attachment.
The convoy clip works also on the C8
I just received a clear C8 from Simon’s store, and it is acting weird:
When I click the button the first time (to switch it on), it blinks a few times with variable rates, then settles at the minimum level (0,1%). After this I can go through all the modes and back to moonlight by tapping the button, but when I switch it off, then back on, the same weird blinking happens again.
I made a video about it:
Hi. Benoe,
I had one of the separately sold drivers from Simon’s Aliexpress Store do exactly the same thing.
Unfortunately no sensible reply off Simon, just Huh?, don’t understand, etc.
Very unlike him, as usually one of the Good Guys to trade with. Won’t be making a case out of it, not here to persecute the Better dealers and have placed orders with him since.
Just very disappointing as I know he has been contacted from here about the Fuse Settings in the software being programmed wrongly.
Only appears to be us 2 so far with this starting glitch, as well as being too fast on the programming select / bike mode etc.
Cheers,
S-L
P.S. Mine is the 8 x 7135 2.8A or 3A one. What rating is yours?
Mine came from Simon’s Aliexpress store as well, and it is a 8 x 7135 2.8A (red driver with “convoy” text on it.)
In the meantime I found a better description of the problem, here
The new driver and the moonlight mode was one of the reason I bought this light, but in this form, it is useless to me.
So I came here to try to find a solution, if there is any.
benoe,
Thanks for the reply and link.
The start up “test” or whatever it is, was ONLY on the 2.8A 8 x 7135 version.
I also fitted a 3 x 7135 version, 1A, that was just fast, NO problems on start up.
I still have 3 left I have yet to put in lights, but not done so yet (as the fault is limiting my original purpose for buying them).
Cheers,
S-L
It sounds like some units may have lost the SRAM decay lottery. Typically each bit decays to 1 when power is removed, but it has a random chance of decaying to 0 instead. This is the natural state of that bit.
For detecting fast presses, the normal method sets a byte to all zeroes, 00000000. Then at boot, it checks to see if the value is still zero. If so, it assumes that was a fast press.
If any of the bits have decayed to 1, it assumes the button was pressed for a longer time. This could give you a value of 1 to 255, but not 0.
With a probability of 75% for each bit to decay to 1, or 25% to decay to 0, that gives us 0.25 8, or a 1-in-65536 chance that a particular byte will decay to all zeroes.
Or, using an offtime capacitor like in most BLF drivers, it eliminates the lottery effect completely.
However, there is no OTC so the byte which tracks fast presses is used to detect button timing. IIRC it uses 4 or 5 bits to count the number of button presses and 3 bits to detect how long the button was held: 0000 0000 or 000 00000 … That increases the chance of an all-zero decay to 1-in-256 or 1-in-64.
I’m going to see if I can make enough room somehow to use a second byte for tracking the decay. That should get us back to the 1-in-65536 chance of error.
It seems there is nothing I can do to have a correctly working C8 right now, let’s see what and when(!) Simon will reply to my message…