D.I.Y. Illuminated tailcap

Before and after:

I really like that! I have been following this thread, but have gotten confused. Can you explain exactly what you are using for this?
Thanks

this cqnuality goods are really gitd or just cheap good looking ones?never had it in hand…:slight_smile:

So… I made code to run on the fancy “smart” lighted tailcap. It works on my Ferrero Rocher driver, at least… though it’s a little odd on that driver since it uses red, green, and the FET-driven white LED.

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/sandbox/files/head:/ToyKeeper/tailcap/

You’ll need to calibrate voltage for your board, possibly re-assign pins for the various colors, adjust resistor values to balance the output of each color, etc. And also tweak a few compile-time options:

  • How long should it “spin” at each boot (when the main light gets turned off) before measuring voltage?
  • How fast should it spin?
  • How often should it re-check voltage after the first time? (a.k.a. how long between beacon blinks)
  • Should it act as a beacon, or always stay on?
  • Should it spin again each time it re-measures and blinks?
  • Should it do a full spin or partial spin at each beacon?

By default, it’s configured to spin for a second, settle on one of five colors based on voltage, stay there for a couple seconds, then turn off and enter a beacon mode. This beacon does an abbreviated spin up to the relevant color, stays on for a second, then shuts off. Beacon repeats every 4 seconds.

You could also configure it a bunch of other ways… for example, the loop could just stay on all the time and merely adjust the color as voltage changes. This gives a realtime voltage display while the main light is off.

Sounds fabulous ToyKeeper, as usual. :beer:

Now pilotdog68 gets to do the hard part — making the hardware actually work. :slight_smile:

BTW… As is, the colors from full to empty go: blue, cyan, green, yellow, red. Do you think it should use all six colors instead? Magenta, blue, cyan, green, yellow, red?

PD that looks awesome! I know we discussed it briefly in another thread and maybe I just missed the follow-up details here, but how did you accomplish that? Or is that done by brute power/leaving out parts?

Thanks TK. I’ll let everyone know when I get the boards.

Emarkd, I took out the black silicone piece completely. The switch still works perfectly, but even less waterproof right now.

Be, er, thoughtful about the 405nm emitters.
That’s close to the edge of perception, for most people’s vision — the retina has to intercept a lot of those high-energy photons before you see a faintly visible color.

From Google Scholar, the lab result:
http://iovs.arvojournals.org/article.aspx?articleid=2357960

Much back and forth among the bloggers, e.g.:

As the talking heads say after any industrial oops event, there’s “no immediate and acute danger to public health” from this sort of exposure.

That tailcap of the blue convoy is a beauty, PD68! Super nice!

Both rev 5.1 boards and the rev 6 board. Can’t wait to test that one. So, the bleeder resistor is going to have to change, the old 560 can’t supply enough to run it all???

Matt

Mm in my experience the 560 bleeder does fine all the way up close to 0.75ma draw in the tail before the driver starts acting weird. I expect it to still be fine with Rev6, but I guess we’ll find out in a couple weeks

I apologize if this has been suggested already. Has anybody considered putting one of these dual LEDs in the tail?

The green has a Vf of 3.3 and the red has a Vf of 1.95. Wouldn’t this work as a “dumb” battery level indicator?

I found a few green LEDs with a higher Vf but they were more expensive. My thought was that multiple greens that fall off at various voltages would allow the light to shift away from green, to yellow (green+red), to red.

EDIT: If we could find an appropriate LED where the lowest Vf is around 2.8 wouldn’t that be ideal? That way when the LED goes out the battery is depleted and won’t discharge any further.

It’d be great, but frankly, it doesn’t seem to work that way in my testing. I’ve used these led’s which have a rated Vf of 3.0-3.2v, and even with a limiting resistor in series, they are still giving off a little light at ~2.5v input. Eventually that would stop, but the listed Vf’s are usually at normal operating currents, not a strict cut off voltage.

At which voltage a certain colour led drops out I found also highly dependent on battery type. Not that I can explain why...

OK, so the consensus seems to be that using the LED Vf to prevent over-discharge probably won’t work. What are your thoughts on the dual LED that should shift its combined color spectrum as the voltage falls?

I think Djozz actually tried to jerry-rig something like that. Djozz?

IIRC, the dual-LED color-shift thing worked sometimes… but it was awfully sensitive to the wrong things — didn’t work the same on multiple units (or even one unit with different cells), and still didn’t really cut out at the desired voltages. But you can do it if you’re willing to fiddle with it a lot.

That’s much of why I’m hoping the smart version of the tail board will pan out. It can be more more responsive, consistent, and explicit about the cell status. And, if desired, even animated.

Plus, I want colorful shiny things to play with.

Basically the BLF motto

I can’t wait to see first results of the smart tailcap.

TK, I had a look at your firmware, but due to my lack of knowledge I have trouble understanding what it does… But I think I understand enough to say it’s cool. May I ask some questions?

That colorful swirl… it does it on every boot. So would it start blinking on every short press?

When is the MCU sent to sleep? If watchdog wakes it up every x seconds, basically all the functions like ADC (and that other stuff on page 32 in the t13A datasheet) could be turned off and the port pins can be set to inputs before going to sleep for power reduction, right?

I think we would need a firmware for calibration, right? Could we just use battcheck for that, or would we need something different here?