Texas Avenger "TA" Driver series - Triple channel + Bistro or Narsil + Clicky or E-switch - The Ultimate open source driver!

Flashlight Modding and DIY Parts
961

There are basically 3 practical solutions

1. Light up when power is applied to max or a high output, even when the mode order is low to high ignoring mode memory,
similar like Klarus XT series, which got 2 different eswitches and the forward clicky is the 3. eswitch as the battery is never disconnected from the driver

2. Light up with last mode the light was used, also when mode memory is disabled

3. As standard Bistro light up last mode memory or the first in your mode order low-high or high-low when mode memory is disabled

962

OK, right now option 3 should just work, with the right component selection and firmware configuration. ( normal C2---not OTSM-sized---and probably the existing dual-switch firmware, I'll recheck it).

Yeah, but maybe I'll aim toward option 1, in that case I'd make the particular mode a compile configuration. That helps anyway since turbo can move around, and it's easier to switch modes than define an output level override. Also, configurable is nice.

I do like the idea of tail switch double tap to get turbo (double because it would usually already be in the on position, with e-switch sleep), but I don't normally like my light starting in turbo. Ok, this sounds good. As for signaling, I generally just use the phone.

963

So the present dual switch tripple build is actually OTC, not OTSM (because OTSM was broken then). OTC doesn't work for this. Even if you leave off the OTC cap, then power-off will probably get read as a short click. So I need to reconfigure it with e-switch and OTSM. For now, you can just comment out USE_OTC and uncomment USE_OTSM, but I'll make that the default in the next release. It should be anyway now.

964

I can share my F-2. I made a dedicated thread for it: Mike C drivers: v8 series, ATtiny1634 based.

Just know that this current version is untested (it is on it’s way from OSH Park). Order at your own risk, I have screwed up before and will again! I can also share my customized 84 MU Eagle library part, I use it for the 841 as all pins are the same.

If you build and populate the board, PA5 (MISO) has a via for flashing but is otherwise unused, so this pin could be used for additional testing of inputs/outputs. I don’t have a shareable baseline firmware yet, but will share one in the above linked thread when I do.

965

how hard is it to port Narsil Triple v1.4 to another MCU and add LVP divider on another pin taking the code sections from Narsil v1.2
I know Tom E is busy with Q8 Narsil final code, but hes not the only capable programmer here

If this works out great a 30mm version for Convoy L6 planned?

966

I’m not very familiar with Narsil’s code, but in general most of the MCU and pin layout details can be abstracted out to make these things compile for multiple targets. Some of that is already done, by defining the layout and MCU type at the top of the file (or on the command line), but any new MCU will require some adjustments to that. Of course, hardware-specific features still require deeper changes… like we’re not going to get 3 PWM channels on a tiny13, since it lacks the features needed to do that.

967

So I realized (or re-realized, that happens often it seems) that dual swtich with OTSM has an issue. Eswitch needs 220kohms (ish) to keep parasitic drain down. OTSM needs max 4kohm (ish... but actually that high is already having a 20% impact on OTSM performance, would have been more without the powersavings option) to keep C1 discharge time fast for power-off detection.

These are directly contradictory. There are a few possible solutions:

1) Do nothing about it. you've got two switches anyway, just use the eswitch when walking around and lock out power with the clicky when done. A person is bound to forget this though. On the other hand, at 1mA of drain that's still 3000 hours off a 3Ah cell, which is a 125 days! So even if you forget, it won't drain overnight. I will drain significantly in a few weeks.

2) compromise, try to reduce C1 by 10 times, DEL doesn't like it, but it might work ok. Then you can increase the resistances by 10 times, 40kohm, so that gets you to 1,250 days... not too bad.

3) Need an active pulldown. This would basically require a depletion MOSFET, normally open, so when power goes down, it opens and drains C1 fast. It's an extra component on the board. I guess this requies another diode too, or some combined part. Hmm, seems there are ldo's with active pulldowns that could do it. This doesn't just replace the usual LDO though. There needs to be a barrier before C1 and one after C1.

By the way, this has nothing to do with the lexel option 3 solution. That's an OTSM firmware used without the OTSM cap.

Regarding OTSM, I ran my light down to LVP twice. No issues really. OTSM keeps working all the way to the end (2.7V LVP). I had long press set at 1.25s, so I don't know beyond that. I've changed the default to 1.5 since 1.25 feels a touch too short, and there's 3 or 4 s available.

The "worst" behavior I found was that when the LVP stepdown triggered it just marched its way straight down to off, when it seemed like there was enough juice to turn it back on in moon mode. I have trouble even caring. It was 2.8V and playing with it in different modes for about 2 minutes completely finished it off, so it's not like there was much left to save. Otherwise, no issues.

968

4) Make a dual switch dedicated firmware option/definition that always has a mode active if the power is on.

969

I almost like it for a second, but then not really sure. You want to be able to turn the light off from the side switch. I suppose it could be an ultra-low moon, just to remind you its on. Not loving it, but it's better than nothing. And actually an firefly mode can use less power than than the 1mA drain, so in that's sense it's not bad. I'm on the fence.

970

I take it back, an ultra low moon can't use less current than 1mA. The lowest I got the mcu itself while running PWM was 2.1mA, after adding idle sleeps. Still it will save you power for the most part, when you don't forget to turn it off.

971

You know I'm not really sure reducing C1 matters in this case. There's of course already a HUGE cap buffering the mcu itself from voltage spikes. C1 is at most buffering the diode/LDO from voltage dips really, not even spikes (the diode still passes spikes to C2) and also the voltage divider. Part of the solution may just be getting a diode that can take it. The question is how much does the noise on the voltage pin matter. For OTSM itself you don't want pin bounces. For >1S lights you'd like good voltage readings. I'm just not sure how low it can all be pushed. 0.1uF is a pretty standard bypass cap, but for logic not ADC, and probably not for environments slamming 5A of current on and off, so yeah, the 1uF number seems sane, just not sure where the limit really is.

972

If you want to be able to do that, then it’s not the best option, no. I don’t see why you would want to if you have a power switch, but that’s irrelevant.

973

Just a matter of ergonomics. One nice thing about a side switch is just where it is under your thumb when holding the light at your side. I don't always walk around in police tactical mode with my thumb at my ear. Actually the tail switch still works well at my side, if I want to see something behind me.

974

Actually between the two options, I'd rather just have the power switch not be OTSM, just a dumb switch, and get full control at the eswitch, assuming a tail power switch and side e-switch. Fortunately there are in-betweens for that route too, OTC or noinit. I'd probably just go with noinit in that case. If I need revers/hidden modes, can still use the side switch for that. Better than being forced to use the rear switch for off.

975

I agree with the ergonomics, I use my hand held lights that way while moving around underground, using the side switch to change modes. I just don’t need to turn it off that way.

976

You know, I’ve been really tempted to do that. I don’t have any dual-switch hosts, but I do at least have a test light with an e-switch for development. I think it could be very simple:

While off:

  • Click the clicky switch to turn on at the last-used level.
  • Hold the e-switch and click the clicky switch to turn on in moon or turbo, depending on preference.

While on:

  • Press and hold the e-switch to ramp. Release and hold again quickly to ramp the other way.
  • Press the e-switch once for turbo, once more to return to previous level.
  • Press the e-switch twice for battcheck, once more to return to previous level.
  • Click the clicky switch to turn off.

It’d save the current level to eeprom every time ramping stops, and then the clicky button would easily be able to do signalling and other momentary use, in addition to its normal purpose of turning power on/off.

Offtime doesn’t need to be measured at all.

I recall several people asking for something like this… so I suppose I should probably make it. I’ve been procrastinating because I don’t have any hosts capable of using it. I’d imagine it should work fine on a common tiny13, though tiny25 and FET+1 would be preferable.

977

@ToyKeeper +1 :+1:

978

I finally had a chance to catch up on this thread. Wow!!!

I found myself having many comments along the way but I was kind of late to the party:)

However, regarding programming from a smart phone, even if programming from the led is not possible yet, programming from USB should be possible? The config options of this “new” HD firmware is SCREAMING for a smart phone app.

Some of the recharge lights out there have a couple extra data pins unused on the USB port. Programming from a computer is tedious, but programming from s smartphone is acceptable family fun even at the dinner table :wink:

979

I’ve been running dual switch firmware with a whole lot of stuff like that. It’s all in that X85 firmware I shared a long time ago. I think it’s even in your repository, although it should be removed. I no longer support the drivers it was designed for.

980

Most lights don’t have a USB port… or any ports at all, for that matter. However, almost all lights have at least one LED exposed where visible light can get in and out. It would probably be quite a bit easier to add LED-based programming than to add USB-based programming.

From a phone screen, I’m getting about 0.280V from a white part of the screen with the backlight turned up… or about 0.002V from a black part of the screen with the backlight turned up. Compared to the attiny’s built-in 1.1V reference, that should give ADC values of about 64 for a bright screen or 1 for a dim screen. So, if my guesses are correct, it should be possible to hold the front of a flashlight against a phone or computer screen, put the light into a special programming mode, and press a button on the phone/computer. Then it sends a binary signal which tells the attiny how to configure itself.

On the driver, I think this would involve connecting LED+ or LED- to a pin on the attiny and putting that pin into ADC mode to measure voltage. I’m not sure what exactly needs to be connected to what though, or if it risks frying the MCU when the light is on, or if there are other risks when the voltage exceeds the onboard Vref. But it seems like it might be easy to do by merely adding a single extra wire on the driver, then writing firmware and software to do the rest. And it would be pretty universal, requiring no extra ports or other hardware changes.

Granted, it wouldn’t work on lights which don’t emit visible light, like UV or infrared. But I think it should work on pretty much any flashlight in the visible spectrum.