D.I.Y. Illuminated tailcap

The dumb boards have resistor spots anyways, so you can have 20k resistors on the ring and a pot in series down below to dial it in, or just skip the pot and use the resistors. My M6 just had a lot of room in the tail area, so I threw the pot in there.

I try to keep as much of the non-subjective info as possible in the first post. That said, I actually recently removed resistor values from the OP because I’ve found it depends on a few variables, the biggest of which is the person’s preference for brightness, and also what board design is being used. I think it’s better for each user to buy one of the assortments of resistors or some potentiometers and dial it in for themselves.

I added this line to the first post:
“Depending on what LEDs are used, what board is used, and what brightness is desired, the required resistance value can be anywhere from 1k - 50k+”

Hey Pilotdog, would it not be a bad idea to leave a value posted, while not optimal for every situation but one that would make light in 95% of the builds?

I looked in the other project threads and did not see if you had found a suitable replacement seal for the metal S2 tail cap rubber that you had removed.
Made any progress on a permanent replacement?

Depends on your definition of “permanent.”

In my blue S2+ I used a piece of ziploc bag, and it actually works pretty well as long you don’t rip it during installation. At the recommendation of another member, I’m planning to replace the ziploc with part of a latex or nylon glove

Quick newbie question - I just received my first shipment of these boards and am doing my first build. I haven’t even started on a tailcap yet but in having issues with the bleeder resistor. Driver is a normal Qlite from Richard, so I should be able to stack on C1, yes? But if I put a 560ohm resistor there I lose modes. The driver won’t change modes anymore. I think C1 isn’t bleeding down. So I upped the value to 1k with no change, still don’t have modes. How high can I go and still have a functional tailcap? Any 1st hand experience with this driver?

Is your Qlite configured with off-time firmware? It really sounds like you’re stacking it on an otc instead of c1

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.