D.I.Y. Illuminated tailcap

Let me know how it goes. Are you using one of the light boards?

I don’t have the rings yet, but I think the 19mm Rev5.1 will work with some edge trimming because the led’s are so close into the center. I’m just going to try different things to do the waterproofing and do some dunk tests to see how it works. I’ll have to add the led’s later.

The pictures I posted earlier was just of a mock-up with a Rev4 board and zero water resistance.

Well I’m not too concerned with the waterproofness as long as its shower proof.

@TK

Thanks for your explanations, made it much clearer to me. I was stunned how fast you came up with that firmware, mad skills involved!

So, I never really asked… instead I just jotted down the first idea I had. But assuming the smart tail board works…

… what do you (anyone/everyone) want it to actually do?

It has three independent pairs of colored LEDs, probably red/green/blue. The location of each pair is likely to be sort of visible through the tailcap. It can sense voltage. It can measure time. It can make relatively simple calculations. It only runs while the main light is off (I think). So given that, what would you like it to do?

Personally, I can’t speak for the others, slight delay so that I wont flash during mode changes, blink the voltage (volts, pause, tenths) then either constant on or a beacon (can choose in firmware). The beacon could be in the different colours depending on the voltage?

That’s just me.

I think do as many different options as you have time to think up! Personally, I like simpler better. Animations are cool, but I think I’d tire of them quickly. I would like just a different color based on voltage/percent of charge. So from 100–50 it’s one color, from 50–25 it’s a different color, from 25–0 it’s the final color, then it shuts off the led’s completely. We could do that with the led’s on all the time, or have an option for just a ‘beacon’ flash every 3-5 seconds.

I think having in the firmware a choice of Animated or not would be useful. We can then turn on Animation to impress friends, and off again for normal use (for those who prefer no animation in normal use). Some of the Animations could be just for showing off, like a continuous spin, and some could be useful, like batt checks and things.

I’d also like to see a beacon flash that breathes (ramp up, then down). Bonus if it ramps up in a rotation (set one, then set two, then set three), and back down in the reverse.

For a simple, quick batt check, among other options, it might be cool to have the option of a “three bars” rough indicator. If all three sets of LED’s are on, you have great capacity left. Two LED’s would mean a middle amount. And one set would mean you need to change cells soon. Kind of like PD’s suggestion, except it wouldn’t rely on different colors of LED’s on the board.

Being able to set a universal “brightness” setting that covers all the modes would be a great feature. Then changing from Animation to plain or from batt check to a regular beacon, or whatever, wouldn’t require any further adjustment in brightness settings.

It would be great to have configuration options like TK’s other firmware, but I don’t see how that’s possible. Once the mcu is flashed and the board is installed in the tailcap we won’t have any way to input changes to the mcu. Everything would have to be decided at the time of build, unless maybe we could have a way to switch something based on grounding an mcu pin? It could be worked into the Rev4 boards with the smd switch on spring-side maybe.

So I like simple, but a “breathing” beacon would be sweet. Although I don’t think that will be possible either. :_( TK, the Attiny will only be able to output ‘high’ or ‘low’, with no steps in between, right?

Just use your switch board as a star. Switch one way and the star is joined ect…

Yeah that’s what I mean. I think it would require a re-work of the Rev6 board and obviously added to the firmware though.

+1

Would it be possible to make a board with a slot next to the spring, between spring pad and outer ring, where we could insert a smd-switch, that’s soldered on the backside and can be switched from the spring-side? Don’t know if there’s enough space or if it’s a good idea at all, it just came to my mind…

edit: I took a look at the sizes of that smd-switch and the board and it seems that’s quite unmanageable.

Well….
We already have Rev4 (and Rev5a). See Post 565 and Post 613

Yes, I knew that. I just thought with the slot-idea the spring would stay compressible all the way and maybe it would’ve been easier to solder, but again (see the edit), it was not one of my good ideas, sorry, I’ll just keep calm and let the experts talk, because I can contribute little to nothing anyways.

Yeah I don’t think it would work very well to try to mount it on the back. For the record though, the SMD switch is very low profile, I really don’t think it affects the switch compression any more than our usual spring bypass.

Keep the ideas flowing!

This is very do-able, with only small changes to the current firmware. You’d still have to select everything at compile time though.

This gives me another idea too. It could potentially spend the first few seconds acting as an OTC approximator. By that, I mean it could stay off for 0.5s, then turn one color until 1.5s, then start its normal standby routine. This might help people understand the short-medium-long button press timing better. That is, assuming the button timings are properly calibrated.

Also very do-able. It doesn’t currently shut off the LEDs below a minimum voltage, since it’ll still have the MCU’s sleep / standby current being drained and it might lead the user to think it’s actually “off”, but it could be done anyway.

Otherwise, this is trivial to do. It uses 5 colors instead of 3 right now, but that’s an easy change.

Runtime config options are probably not feasible. It could do like the main driver and change behavior based on timing of button taps, but that would kind of interfere with the main driver. A solderable star (or switch) somewhere could be used, but it needs a PCB change and would be limited to only one toggle option since there is only one pin left. So, it’ll mostly have to be configured at compile time.

Ramping or “breathing” beacon might be possible but it’s not exactly easy. The LEDs are on pins which only have “on” and “off” states, so ramping would mean manually trying to do PWM on pins not intended for it.

The three-bar indicator is very do-able too. It might draw more power with more LEDs on, but this remains to be seen. It also would be limited to only three levels unless the board were modified to use 4 LEDs instead of 6.

Brightness can only be meaningfully adjusted in hardware. The attiny can’t do PWM while it’s asleep, and it should probably spend as much time as possible asleep to avoid draining the cell too fast.

On my Ferrero Rocher driver, I measured about 1.23mA with one LED on and the attiny awake. I measured about 0.36mA with one LED on and the attiny asleep. And 0.33mA with one LED in a kludged “low” mode with the attiny asleep. (mis-used hardware features to get a 100% “high” mode and a ~2% “low” mode, but this isn’t supposed to be possible) So, there’s a big difference between being awake or asleep.

This stuff is really cool but what is the fix for the driver? the light doesn't even have to get super hot, just warm, and the modes don't work right until it cools down. I've tried thermal cubes on the c1 with bleeder resistor and on the mcu and wether I have it installed in a triple led light or a single xml2 emitter light it's always the same story, across a range of drivers with a range of firmwares, from 7135x8 njangs with 3/5mode firmware, mtn17dd with guppydrv, mtn17ddm with blf a6, the new temp controlled drivers in the x5/x6. As cool as the lighted tailcaps are, without the light comming on in low every time and strobes never working unless I am bored, I can't use it, and neither can my friends that really want lighted tailcaps in their lights. Same deal with the new x5 and x6 lights (so I know I'm not crazy and it's not just me) it's just not as bad because they have so much copper.

Could you explain “modes don’t work right” in more detail?

I assume it’s an issue related to button timing? Thermal cubes on C1 are unlikely to help. However, it might help to give the OTC an actual resistor to help it drain more consistently. Or perhaps use different R1 and R2 values to change the drain pattern (but I don’t really know the details). Or use a higher value in the tail to reduce overall standby current.

This is all in the realm of analog circuit design though, so it’s not my specialty. I’m just repeating other people’s thoughts on the matter.

I found that mode changing issues get less when rhe resistor before the tail leds are higher, you get less tail-light but the modes work again.