D.I.Y. Illuminated tailcap

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.

I wish it was that easy, but even turning the current draw down to .15 which is the lowest I can go and still get any light at all, causes the same effect.

Let your x5 or X6 run on high for awhile and you'll see what I'm talking about. It is worse in an aluminum host due to poor(er) heatsinking.

A picture is worth 1,000 words, so a video should be even better. I'll see what I can do about that today.

I have been stacking the bleeder on top of the C1, but I will try using it as a resistor for the otc cap instead...or I have some accidentally ordered 560K ohm resistors I could use for the OTC if you think that would be better?

**edit, it wasn't as hard as I thought it would be to upload. This early in the morning I guess noone is hogging my Internets!

The blue S2+ looks pretty awesome. Could I ask though what was done? Looked back a few posts - maybe further back?

I haven’t really said much about the S2+, because it’s not really done. That was just a mock-up to show how it would look. I’m waiting on Oshpark to deliver parts.

Don’t mean to step in on PD’s discussion but I can answer this. You didn’t find it because it kinda follows from another discussion in a different thread. Bottom line, he removed this black rubber piece from the switch mechanism:

…so that the light from the board can get through.

You can read how it all goes together in this thread.

TK, the blinkenlights will get pirated by the people making those hotwired inhalers for the stoner-vaper crowd.

“I was not predicting the future, I was trying to prevent it.”
― Ray Bradbury

I build box mods for a prestigious local shop, and we have no use for lighted switches. Occasionally someone will use a lighted switch, but it is not commonly accepted as A good thing due to using .01A that the atomizer could use, and the extra parasitic drain is "bad". Like anyone would notice the loss of power, but the masses don't like it.

I vape also, and the insinuation that I am a stoner is offensive and ignorant, but hey if you want to be ignorant, that's on you. I won't call you names or imply your on drugs for it.

Has anyone thought about squeezing a mosfet into the design? You could eliminate the Omten 1288 switch in favor of a smaller tactile switch and a FET that would be much more suitable for the conditions, and have room on that upper board for more leds if you didn't need the big hole in the middle. Would also free up a lit of space in the tailcap and possibly eventually lead to shorter flashlights if designed to optimize the newfound space.