Q8 modding

Now that’s the perfect motivation/argument right there to have a lanyard/glow ring/keyring light. All it takes is one trip or slip and you are effectively blind and incapable of finding your light again, assuming it is still working. I have been in pitch darkness outside once where I was incapable of finding my car, just 20m away. A single match would have been invaluable to me.

Lowest is PWMed 7135 which is also not linear (close, but no).
How are you going to catch it? I like linear mod but if I want to use it I will set with 3-5 fixed mods that includes one 100% 7135. After you can add as many chips as you want. But in ramping you will just pass this border (between 100% 7135 and low % FET) and wont recognize this easily.

> Just the zinc chloride

Make sure you understand zinc fume fever when you start soldering.

This was down a steep wooded hillside, eventually found the torch maybe 50 yards below me. Limped home with damaged knee, three butterfly plasters needed to fix. Meanwhile found what I was searching for, thank goodness.

Not sure. I heard the switch LED can flash 1, 2, or 3 times to tell you which driver is in use. Until I get mine, not sure how it works. Programming in fixed levels may be the way, if ramping doesn’t give that info.

Maybe I’m mistaken, but I was under the impression that there’s not enough pins on the tiny85 to do both the triple-channel setup (extra 7135 bank) and the lighted e-switch at the same time. You have to repurpose that pin to do one or the other. So maybe that’s why we wound up with “only” a 2-channel driver in the Q8?

Oh well… that does not sound too good to me… Most lights just flicker and come back on when having a weak connection, going dark can be a problem in some circumstance. Remind me not to use it for off road biking at night, speleology or anything ‘tactical’.

Rosin solder is also bad, some are particularly sensitive.

Basically don’t breathe in solder/flux fumes. In production situations there should be at least a desk fan blowing the other way, ideally proper fume extraction (that’s what I’m used to seeing).

5 I/O pins: 3 chans, 1 switch, 1 SMD LED -- sounds enough to me, and yes, it will work with the latest NarsilM.

Because we don't need an external voltage divider circuit (R1&R2), it's doable. With 2S setups, it's not do-able currently.

We are talk'n 1 1/2 years ago roughly when the driver was decided on. Don't recall timing, but if the triple channels with full support (hardware and firmware) came out after the initial submission to ThorFire, then it was too late. For some strange, whacky reason, we thought the Q8 would ship well before the end of 2016 .

Ohh btw, I'm thinking the firmware was not ready in time for a triple, because the board layout still has pads for R1/R2.

Yes Tom, I was inside on that discussion, at the time. :wink: You’ve come a long way since.

PS: would it be possible to add a proper capacitor in the driver design so that it can sustain short power interruptions? Not the main leds but at least the mcu so that it doesn’t reboot and keeps it’s current state.

No, this wont work with lvp.

I got it on the list to save off the current level setting, and detect short power glitches, then restore the output level. Do-able, just not sure how it would perform, timing wise, if it would recover from these type of hits, etc. This came up near the end and didn't have time to develop, test, get it in. Really wondering now if the stiff springs MtnE sells would prevent it. Problem is though if you have springs stiff enough to work with 30Q BT's, it's probably gonna be too tight for full size protected cells. Actually I didn't try protected cells with the stock springs - may work much better, not sure.

Can you elaborate?

Actually, most clicky switch drivers use power interruption to change state and they do ‘remember’ their state during the time they are off the battery - even long enough for a long press. Banging the light would be a very short event. And many of those can handle LVP nonetheless.

I can’t prove it, but given the way the light behaves when bumped this way, I think the processor does not lose power. Consider that when power is first applied, the light blinks twice to indicate this. That is not what I see happening. I think that the code is still running and polling the switch input. It perceives a very short term drop in voltage on that pin, checks what it is supposed to do in the case of a single click and turns itself off.

There is no intrinsic difficulty in holding up the MCU during very short term power glitches, it’s just a matter of circuit design and bulk decoupling.

It’s something not necessarily done with clicky tail switches (where the driver is looking for power interruptions to change modes), but for an e-switch it shouldn’t be too difficult.

I’ll be taking a look myself, not knowing the detailed design or layout it might be as simple as adding a big bulk decoupler across the MCU, or not.

In my SRK clones its a big problem to fix (I have considered it) because the LED power is also on the same rail/PCB trace as the MCU, so the tens of amps possibly taken by the LEDs exhaust any simple add-on decoupler/holdup cap. instantly. I’d have to cut traces and add a couple of things to improve it. But if the MCU is isolated from the main power by e.g. reverse protection diode, maybe it isn’t too difficult to fix, depending on how the driver PCB is laid out. Shared trace with the LED + supply would be a bummer. I’ll take a detailed look once I have mine, because it really is an issue for me.

I have no idea how this works but what you describe as a fake single click seems to make sense indeed.

If so, maybe that could be filtered out in firmware, or the e-swtich powered from the same isolated well-decoupled rail as the MCU.

I’m anticipating that when the batteries lose contact with a bump, they will then bounce around a bit, predictable if you know mass of batteries and spring constant. Just as most mechanical switches and relay contacts “bounce”, once you look closely at them.

Edit: if one of the four cells was replaced with a very lightweight part, with a big capacitor inside (maybe supercap), that might be much more resistant to losing contact, even when the main cells do. If it had a small spring on the + end too, even better.

if you are concerned about power loss when the light get hits you can increase C2 to compensate

Bistro HD OTSM does that to detect long presses of the tailswitch with a 47uF capacitor

Might not be so simple if, as suggested MCU is indeed holding up, but false switch presses are being triggered by transients. Glad this little issue, which is important to me, is attracting attention, but will wait until I have my torch before jumping to conclusions.

Edit: PS Lexel, how do your drivers behave in this scenario ? Like the look of your dual 7135 bank ones.