D.I.Y. Illuminated tailcap

I’m looking forward to new driver designs which aren’t so finicky about these things. We can get all these new features to work, if they’re very carefully adjusted, but it falls over very easily. Hoping for something more robust.

New driver designs eh? Like bigger otc’s with bleeders, or different ways of measuring cuts in power?

Ummm… its GuppyDrv, so I guess so. I’ve never built one of these drivers. Richard sells them cheap enough I’ve never seen the need. So I’m not all that familiar with how they’re laid out. The cap is actually labelled C1 right on the board though, so that’s why I assumed it was the right thing to do. You can see it in Richard’s image here:

Obviously this isn’t working so I’ll probe around for other locations, but I’d like to understand why this wasn’t the right place if anyone has some insight.

Care to elaborate?

I’m not familiar with how Guppy works, but I think someone else has gotten it working before, maybe Matt?

Pilotdog68 was right, it did sound like you were stacking on an OTC… but it doesn’t look like you were stacking on the OTC. That sure looks like what we typically refer to as C1, the decoupling capacitor the the MCU. I’ve never taken apart a QLITE before, so I checked that cap with my DMM just now to be certain. It’s definitely the correct component. EDIT: it’s definitely the decoupling cap, but…

… err, sorry, I haven’t followed this entire thread. It’s probably not the correct place to stack the resistor. Unless I miss my mark, it C1 would be correct on a current-generation FET driver, but is not correct on a classic Nanjg / QLITE setup where C1 comes after the protection diode. Another user will correct me if I’m wrong, but you probably want to connect BAT+ directly to GND using this resistor.

Thanks guys. I don’t claim to fully understand all of that but I think I got enough of it. I’ll see if I can find a spot to just connect directly from + to gnd like you suggest.

I have never had to add the bleeder with Richards 7135 driver. There is an inherent bleed in the driver as well as most of the 7135 drivers I have tested. I have lighted switch boards working with 3 to 8 7135 boards and most of the FET and FET + 1 boards that are common here. I do use a 560 ohm bleeder and have a mix of boards with 22k and 19.1 k resistors in the voltage divider circuits. I do find that braiding the tail and head springs do make the boards a tiny bit brighter.

I am hoping to have one of the spinning boards working on a breadboard in the next couple of days, this way I can determine the correct balance resistor values. Had one built, but would not work. Pulled all the parts off and found shorts in or on the board at led3 and led5, but led6 would work and the software did load and run!

Matt

Er, your most recent designs, actually. They seem very promising. :slight_smile:

In general, drivers designed with more recent developments in mind… like more consistent OTC timings, parasitic tail lights, and protecting the MCU from power ripples. Perhaps fitting tiny45/85 too, though 25 is already a huge upgrade. I like the idea of having those things accounted for up front instead of trying to kludge something together afterward.

Even if it didn’t work quite right, I’m glad to hear that it at least boots and runs. That’s good news. The boot boots! Woot!

I’m hoping I can put a full-featured tail in my Convoy S7, or perhaps a 14mm-sized version in some BLF A6es. Perhaps also some UF-602C hosts.

Success!

Thanks everyone for the feedback. Matt, I guess I really should’ve tried to power the tailcap without the bleeder first, but I didn’t, so its in there. I may go back and take it out if parasitic drain is too high, but I’ll definitely try my other lights without it first. Its late tonight so I’m not going any further today.

Thanks again guys, this is great!

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.

Thanks again for your input.

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?