Tom, if there was a short there, you wouldn’t measure any voltage across the LED at all. Or the resistor.
And for one of the most important thing. The Q8 draws over 20A in turbo. A clicky switch does not like high currents like that. With E-switch you can easily turn on and off 30A current because the electric components of the driver do the switching, but a clicky will melt down.
In Narsil’s ramping UI, 4 clicks from off activates lockout.
In Narsil’s mode set UI, lockout is mapped to 2 short clicks and a long click.
The Emisar 6-click thing (and 4/2 blink thing) seemed strange to me too, but I didn’t change it… generally tried to minimize changes, especially ones which didn’t match the project’s specifications. However, I’ll send you some firmware showing how I prefer to do it instead.
Although most shorts change a connection from near-infinite resistance to infinitesimal resistance, it sounds like this may be more of a middle ground.
Even a partial short would cause problems on such a sensitive circuit; the smallest trace of conductive material in the wrong place could alter the voltage enough to interfere with the switch LEDs. For example, even an oily fingerprint on the PCB could potentially decrease resistance enough to cause intermittent misbehavior on a particularly sensitive circuit. Or if there was metal dust in the air during assembly, some could stick to the PCB in the wrong places.
Ah yes, that's just the TA SRK board. uhm.. well I couldn't really find a circuit layout for the Q8. Is there one around here? Wasn't this kind of stuff once in the first or second post? It's a piece of cake to define a new builld with different channels and pins, but I have to know what they are first. Of course I like the tripple channel modes, so I might make a new modegroup that re-maps them to one or two ramps, easy.
Agreed, a “partial short” across the whole circuit, (I think that’s what Tom reported) could drag down the MCU output to the point where the voltage across resistor+LED dropped too low, but not just an oily fingerprint (The MCU output pin can drive quite hard, rated for 10mA, max rating 40 mA. and I expect there is more to come even beyond that)
Contamination across the LED could be a plausible cause of a small leakage current, comparable with that set for the LED (150uA-ish) which bypassed the diode and dragged it’s voltage down. If so, a thorough cleaning of the PCB with e.g. IPA and a bristle brush ought to remove any obvious contamination.
Additional resistance in series due to a poor intermittent joint or internal PCB fault (via.) is also another potential mechanism.
In any of these scenarios a basic measurement of voltage across diode, voltage across resistor, battery voltage, and voltage between ground and the end of the resistor connected to the MCU, might be sufficient to narrow it down to which, if any, of these things might be happening, when the LEDs are misbehaving intermittently.
TK good point about OTSM switch cannot do ramping the same way. I'd still prefer a clicky, even for a ramping UI. Off is still off as it always will be and must be. Sure that means you probably need short tap to initiate a ramp, so can't use that for off, but you still have full cllick for off, so, it just means you don't have to hold the button down while it ramps.
Dale, the Emisars don’t actually use Narsil. It’s based on Narsil, but with a lot of small changes. I don’t know if it’s been given its own name yet. EDIT, (It’s called RampingIOS… but people mostly just call it “D4”.)
The Q8 uses NarsilM v1.0
It’s 113uA, if that makes a difference.
DEL has posted a schematic on the modding thread.
Even he’s not sure whether it exactly represents what has been produced.
Depending on battery voltage, 10% resistor tolerance, particular diode Vf at that current, etc. etc. 
OK, well I didn't find an actual schematic but the first board trace image I could find googled up on candlepower. Looks like a BLFA6 layout no? I will conjure up an eswitch build with TA modegroups, or something similar-ish, for a BLFA6 board. Should take all of 3 minutes, mostly to figure out how the ramps should look.
It’s in Narsil’s source code, at least. ‘grep -i diagram *.h’ Or it’s also in the D4’s source code.
* ATtiny 25/45/85 Diagram
* ---
* Reset 1 -| |- 8 VCC
* switch 2 -| |- 7 (unused)
* Ind.LED 3 -| |- 6 FET PWM
* GND 4 -| |- 5 7135 PWM
* ---
That won’t work if you are expecting to use the voltage divider, R1 R2, because it’s not fitted.
Otherwise it is the good old FET+1, but with subtle improvements to supplying the MCU with clean power, and a properly driven FET gate.
Actually pin 1 is no-connect. Except with programming clip applied ?
It’s called RampingIOS… but people mostly just call it “D4”.
Another idea on current bypass. At the same sort of level you might get with a fingerprint at these currents, how about an improper board cleaning with a conductive film left behind in places. A little etchant residue left behind. Maybe in a thru hole. Poor choice of cleaning material.
That must be a bright moon mode.
I think I have a couple that can run 100+ days on a single cell. Single led.
The Q8’s moon mode isn’t very efficient. Most of the power goes toward keeping the MCU running. It’s a common downside to most BLF drivers created so far. I think the stock Q8 gets about 70 to 90 days in moon mode, if it behaves the same as a stock D4.
I’ve managed to improve this recently, giving moon significantly longer runtime, but it’s still not as efficient as a ZebraLight. I estimate the Q8 (with indicator LED off) should get up to 300 days of moon mode after the changes I made to it. I measured an average of ~1.7 mA, so with four 3000 mAh cells that works out to ~294 days. This was on a D4 though; will have to re-measure when I get a Q8.
With both moon and the indicator LED on, it’s probably more like 270 days. Or with just the indicator LED on, a stock Q8 should emit light for about 10 years per charge. The indicator LED is easily bright enough to be a “firefly” mode.
I was not as elegant about it but I now have a working LED which appears to be holding up. The sequence of events goes like this:
- Remove right LED to see if it’s causing the problems. No luck.
- Remove left LED to see if there’s still current flowing between the pads. Ripped off the PCB trace by accident but at least I now have 4V across the (remaining) LED pads.
- Somehow soldered the right LED back into place without creating a bigger mess.
- Washed sweat off and swore never to attempt soldering SMT components again. At least not without better tools.
I’m not sure if I “fixed” the PCB by breaking it or if it’s the left LED which was “bad” and leaking enough current to prevent both from lighting up. The left LED was the brighter one of the pair. The whole thing is still about as bright as before and not much more uneven so I’m tempted to leave good enough alone. There’s a good chance I’ll break the other side of the PCB if I touch it again 