After playing with my lighted tailcap for a few minutes last night I noticed a strange behavior — the driver “acquired” mode memory, well more accurately it acquired next mode memory. I have memory turned off in my firmware but I now have it anyway. I thought it may be related to that unnecessary bleeder resistor like Matt pointed out above so I removed that from the driver. Didn’t help; I still have next-mode memory. I can confirm that it wasn’t necessary though. The lighted tailcap still functions well although it is dimmer than it was before, as is probably expected.
Its probably worth pointing out that I have three of these lights that are almost identical. The only difference between them is the number of 7135 regulators on the driver and the color of the emitter and anodizing. I can swap this blue lighted tailcap onto those other lights and replicate this same effect — “normal” tailcap has no memory, lighted tailcap has next-mode memory.
So a bit about my build might be helpful. I’m using the v5.1 ring board. The resistor pads are loaded with 3x 3.9Kohm resistors and the emitters are blue 0805 leds (obviously). I’m only using three though, one in each pair of pads equidistant apart. I’m measuring 84 mA of drain through the tailcap, which seems kinda high to me.
Anybody have any thoughts? Does that indicate that my mcu isn’t going to sleep? Any idea for a fix?
Not sure… I have not had that problem yet. Could be the MCU is not sleeping and when the light turns on it advances, that would maybe make sense. I am not sure why changing the tailcap would cause that. I have seen it mess up modes until dialed in with anything that uses medium presses, but that is a function of drain on the OTC. Do you have an OTC on the board that is not discharging and is keeping the MCU awake? Might try the pencil trick on the OTC to find out if that is the case. Pencil trick, if you have not used it is as follows. Draw or color a heavy line from one end to the other of a given component to cause it to be a short from end to end, must be a heavy line in order to conduct. Again, have not tried it on a cap, not sure it will have the desired effect.
I like mode memory on 90% of my lights, so I work hard to make it work with any mod.
Thanks Matt, in case you missed it I just went back and added some more detail to my comment including resistor values. There’s no medium presses involved here, just standard reverse clicky interface (GuppyDrv). There’s a C1 cap on the board but I don’t think that’s for OTC.
Its really not a deal-breaker either way. These lights are just for fun and having mode memory isn’t a big deal with them. I’m just curious is all. I’d like to understand what’s causing this so that when I try this with lights I actually use regularly I’ll have a better grasp of it all.
The bleeder resistor is only partially for brightness on the tail, it’s mainly to allow enough current past the driver to allow the driver to function normally. It sounds like guppy is indeed OTC based, and you need a bleeder with a lower resistance. 560ohm usually works up to around 0.70ma tail draw, anything above that needs less resistance up front.
I can’t imagine 84ma draw though. Either that is a typo, you have a small short somewhere, or those tail LEDs are insanely bright right now.
Yes, 84ma sounds like a fairly hard driven tailcap. Mine are typically under .35 to .40, since I like the LEDs to be dim enough to sit no the nightstand. guppydrv on a 7135 based driver does support OTC, if it is installed. I like and use guppdrv on many lights with MCU’s and drivers purchased from Richard.
I would inspect the tailcap board and the added resistor for any kind of short. It really sounds like something is going on with the hardware. PD is much more of an authority here than I am, he designed it, tested it and has built many of them.
I have built many of them, but usually all with the same firmware and driver designs. Different drivers behave differently with the tailcap draw, and I’ve never owned/used a guppy driver.
Usually though, if the driver is acting strangely, your balance of bleeder value / tail draw needs to be adjusted. On an OTC-based driver, the higher the tail draw, the lower value bleeder you need.
Since wight is back, maybe he can shed more light on the technical aspects of what is going on with the driver. I really just have my observations.
Thanks again guys. I’m not home now to check anything but I did remove the bleeder resistor. It’s gone, and the tailcap still illuminates. Plus like I said I can put the tailcap on another light that’s never been touched and its driver responds the same way.
So bottom line - its not the bleeder resistor ’cause there isn’t one.
I could put larger resistors in the tailcap and see if that makes a difference. Like I said they’re 3.9kohm right now, but there’s 3 of them because of the 3 discrete channels in the tailcap board.
I’ll also try penciling that cap this evening and see if that makes a difference, but it is the same cap I tried stacking a bleeder on first and caused me to lose mode switching altogether, so I think I don’t want too much current flowing around that cap.
That’s the problem. You usually need the bleeder to make the driver function correctly, not to make the tail light up. Everything you are telling me says you NEED a bleeder.
Higher resistor values in the tail will also help.
Oh, I guess I don’t understand all this as well as I thought :). That’s not surprising.
I thought Matt said his MtnElec Qlite drivers never needed a bleeder resistor. Regardless I can add one back. I did have one at first but removed it after I noted this memory issue, so I can already say that it’ll still do this with a 560 ohm bleeder resistor in there.
I guess it’s just a balance? Gotta play with resistor values until it acts right?
I think what they’re saying is that you need the bleeder resistor, not in the place you had it, but directly to ground, in order to get rid of the ‘next mode’ memory you’re seeing.
I don’t really know it all that well either, just what I and others have experienced. Typically drivers that use an OTC for mode changes need a bleeder resistor between Batt+ and gnd, and other types of drivers may not. The Qlite in stock form does not use an OTC (and may not need a bleeder) , but an OTC is often added to a Qlite to use different firmwares (like guppy, apparently).
It’s definitely a balance. I think your high tail draw was just too much for the 560ohm to “bleed”. So either lower the tail draw (higher value resistors) or use a lower value resistor for the bleeder
Man that looks awesome! I’ll be working with Simon on the possible redesign of the metal switch in the near future but he needs time to get things running smoothly in his new factory first.
If we do redesign it I’m trying to have the internal rubber seal replaced with a translucent material to let the light shine through.
emarkd, can you confirm was the 84ma figure a typo? Was it supposed to be 0.84ma? If so, that’s still high, but it makes more sense.
If it’s actually 84ma, I’m wondering if maybe the Rev5 ring is shorting on the metal switch in that S2+, I know it’s really tight up in there with the little switch button.
Hey David thanks for the input but I did try it directly between positive and ground. My original placement on top of C1 caused me to lose mode switching altogether. Still not sure exactly how that worked but the driver became a single-mode driver (on mode 1, moonlight) with the bleeder resistor stacked on C1. I moved it to a place directly between + and GND and my modes worked again, but then it was next-mode memory. I thought by removing it altogether as Matt suggested I could regain “normal” function but that’s not the case.
Thanks PD, but no that was not a typo. I read 84 mA using my trusty old Fluke 76 meter. Its 20 years old now and hasn’t been calibrated since I bought it, but I think its probably still fairly accurate.
There could be some small short in there somewhere, but I don’t think its against the metal switch. I added waterproofing in the form of a disposable nylon glove just below the metal switch so there shouldn’t be any contact there. I’ll check better this evening though.
ok, 84ma is crazy high, the highest I’ve ever measured was just over 1ma I think. There has to be a small short somewhere I think, I don’t think the resistors you said you used would allow anything close to that current. (and I think the tailcap would be ridiculously bright if it were getting that much current through the LEDs). At 84ma, it’ll totally drain a full 800mah cell in about 10 hours.
You know, now that I’m saying all this I’m starting to doubt myself. My meter has two lead connections for measuring amperage and if I was using the low-amp input, which I should have been, then I actually measured MICROamps. I’m used to dealing with several amps of draw, not microamps, so its very possible that I’m now telling you all a lie. I’ll double-check it tonight but there’s at least a chance that what I read last night was 84 µA without realizing it. :-/
Awesome, so lets assume I’m an idiot (not much of a stretch ) and that my tailcap setup really is pulling 84 µA and is working properly. Then the thought process is that I really need that bleeder resistor on the driver, yes? I’ve already had a 560 in there with no change in behavior. Should I go higher or lower?
) and that my tailcap setup really is pulling 84 µA and is working properly. Then the thought process is that I really need that bleeder resistor on the driver, yes? I’ve already had a 560 in there with no change in behavior. Should I go higher or lower?