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

[Flintrock]

@Texas_Ace

You said you wanted a 1S setup so I assumed you were using a normal driver without an LDO. I also didn’t think there was an R7 in the normal ones, hence my confusion lol. An SOD-323 diode should fit on the 0603 pads if placed by hand. I have done it before.

No, no , I said ">1S" setup ;)

[Flintrock]

But I was just thinking that to wrap things up to make it usable. Actually I'm thinking of building a dual switch OTSM SupFire A2. It looks lightbringer had some success there.

Anyway, I'll work out the resistor values for that, make another HD config file for, and post it up. Then we'll have OTSM for the whole TA series.

Actually the >1S firmware should work with 1S using different resistors than what I used, and slightly worse OTSM performance (because the pin voltage will need to fall farther so takes longer). I just wanted make the best chances for everything to work in the first build and separating the resistors from voltage read helped with that in a couple of ways.

[ToyKeeper]

So, not really related to driver development… but I finally added 3-channel support to Crescendo, in case anyone wanted a ramping clicky UI on their TA driver. It requires tiny25/45/85 though, since tiny13 doesn’t can’t PWM more than 2 channels. And with 3 channels it can be tricky to adjust the ramp to be “elbow free”.

Otherwise though, it seems to work fine. It has most of the versatility of bistro, but without the complexity.

Code: ~toykeeper/flashlight-firmware/sandbox : files for revision 185

… and here’s the UI summarized visually:

[Flintrock]

Very cool! I think I stole bistro away from TK, lol, but I can't stop her.

[Texas_Ace]

@ToyKeeper

So, not really related to driver development… but I finally added 3-channel support to Crescendo, in case anyone wanted a ramping clicky UI on their TA driver. It requires tiny25/45/85 though, since tiny13 doesn’t can’t PWM more than 2 channels. And with 3 channels it can be tricky to adjust the ramp to be “elbow free”.

Otherwise though, it seems to work fine. It has most of the versatility of bistro, but without the complexity.

Code: ~toykeeper/flashlight-firmware/sandbox : files for revision 185

… and here’s the UI summarized visually:

Very nice and it even fits on a Tiny25! Combine that with the bistro with OTSM and we should be less then 4KB and have all the major features in place that we would want for a “universal” firmware with space left over for pwm current control, dual switches ect. The extra pins on the 841 sure opens the possibility as well.

[Flintrock]

I was thinking about it already TA. At least as much of my work on HD went into re-merging codes, so I was already wondering. I'm sure you wouldn't need to completely double the code, nowhere near. The interesting question is would there be any way to merge the UI's? Like click five times, do the Macarena and you're into crescendo mode? Could be possible actually.

[Flintrock]

Oh and you don't need extra pins for dual switch. Even in 4 channel pwm it can be done with pins that exist. I've already put in some code for dual switch considerations in HD (actually there's a dual switch hex in there already, although I'm honestly curious to know what it does, lol), of course if you have eswitch, the clicky will always do something. The issue is just trying to control exactly what it does.

[Lexel]

I talked to Tom E and he says R1 and R2 are not needed for LVP on Narsil 1S drivers

Pin 7 is in Narsil triple the Indicator LED output, so adding there resistors for 2S LVP needs a lot of changes in the Narsil code

Has anyone done this so far?
comment out the indicator LED and write code for 2S LVP on pin 7 instead

[ZozzV6]

6 years ago I thought that a clicky switch flashlight just go on and off :confounded:
And now they are smarter than my first phone :+1:
Keep up the good work! That is just amazing how much progress going on the last few years.

[Lexel]

@Flintrock

Oh and you don’t need extra pins for dual switch. Even in 4 channel pwm it can be done with pins that exist. I’ve already put in some code for dual switch considerations in HD (actually there’s a dual switch hex in there already, although I’m honestly curious to know what it does, lol), of course if you have eswitch, the clicky will always do something. The issue is just trying to control exactly what it does.

Tom E wrote how the Tailcap switch on narsil can be forced to light up the light on highest level instead the 2 blinks

@Tom E

Ok, think I got it worked out but it’s untested - “it should work” (last famous words)

At about line #1993, you should find:

      modeIdx = <span style="color: #000080;">0</span>;

Replace that with the following:

      modeIdx = modesCnt - <span style="color: #000080;">1</span>;
      <span style="color: #800080;">if</span> (ramping)
      <span style="color: #800000;">{</span>
         outLevel = rampingLevel = MAX_RAMP_LEVEL;
         <span style="font-weight: bolder;">SetLevel</span>(outLevel);
      <span style="color: #800000;">}</span>

This should work for both ramping and non-ramping. So for non-ramping, it’s setting the mode to the last (highest/max mode. If in ramping, it will initialize the output to the maximum level. I think this should be the correct way. I’d fell better though if I could test this out, but if you are on an easy to re-program bench setup, should be worth a try.

also calibrating the internal temperature is needed

@Tom E

It’s not in “Narsil” yet (Narsil is for the Q8 and FET+1 drivers), but it’s in NarsilTriple (for triple channel output drivers). In NarsilTriple v1.3, here’s the section of code defining the temp regulation/calibration settings:

//————————————————————————————————————/span>
//  Settings to modify per driver
//————————————————————————————————————
//————————————————————————————————————-
#define FIRMWARE_VERS (13) // v1.3 (in 10ths)

//#define STARTUP_2BLINKS  // enables the powerup/startup two blinks
//#define BLINK_ONLY_IND_LED  // blink the Ind. LED, not the main LED for: startup blinks, config settings, Enter/Exit lockout blinks

// Temperature monitoring setup
//——————————————/span>
// Temperature Calibration Offset
#define TEMP_CAL_OFFSET (–11) // On the TA22 board in SupFire M2-Z, it’s bout 11-12C too high, reads 35C at room temp, 23C=73.4F
//#define TEMP_CAL_OFFSET (8) // For the Manker U11 at –11, reads 18C at 71F room temp (22C)
//#define TEMP_CAL_OFFSET (2) // For the Lumintop SD26 at –2, reading a solid 19C-20C (66.2F-68F for 67F room temp)

// Temperature in C to step the light down (50C=122F, 55C=131F)
#define TEMP_CRITICAL 50  // use this for smaller size hosts (SD26, U11, etc.)
//#define TEMP_CRITICAL 55  // use this for larger size hosts, maybe C8 and above
#define TEMP_ADJ_PERIOD 2500 // Over Temp adjustment frequency: 40 secs (1875=30secs)
//——————————————-

The “//” is commented out lines. I’ve found 3 different offsets to use in three different lights I’ve tested/calibrated, as noted above.

For calibration, simply change the “–11” to what works. I use room temp to gauge it, letting the light settle to room temp.

For the step down value, set as desired.

For the “Temp adjustment frequency”, I’ve found 40 seconds works pretty good. If you go faster (lower), you may not give the light enough time to settle in to a lower temperature before making another output drop. Go too long, and it may get too hot, or well above your temp critical threshold, before dropping down.

How to go about calibrating the temperature readings.

To get a close to accurate temp calibration, I’d start trying with –2 for TEMP_CAL_OFFSET, so remove the “//” from the #define TEMP_CAL_OFFSET (–2) line and add the leading “//” on the #define TEMP_CAL_OFFSET (–11) line. Only one should be uncommented (no “//”), the other two should be commented out (i.e. leading “//”).

Unfortunately you would have to assemble the light now, then give it time to settle to room temperature, then in ramping, triple-click, then double-click to get into temperature reading mode. If it blinks out room temp in Celsius close to accurate, you are good to go. If not, say for example it blinks out 26© when the actual room temp is 21C, then it’s reading 5 too high, therefor the –2 offset should be changed to –7. Of course to make this change, you’d have to dis-assemble the light, make the change in the source code, re-compile/link and download — then re-check the temp. Again, if the light had been used and heated up, it will take some time for it to settle back to room temp. I really need to make this settable in the UI some how…

Maybe, not sure, but you might be able to do this open on the bench - I haven’t tried it this way, but would think it would be work ok. This would save the PIA assembly/dis-assembly steps. Some lights are easier than others - the SupFire M6 is great for quick programming because of the driver retaining ring, and extra long wires you need anyway - no soldering, just like the Q8 will be .

[Flintrock]

It's shouldn't be too hard. You just need to change the ADC mux and refs values. I haven't done this to Narsil, but I've done it to bistro-HD (going the other way around, from divider method to Vcc method). The fact that his ADC is run from an interrupt really shouldn't matter, it's just about how it's configured. The biggest challenge will be defining a calibration. The calibration for the no-resistor method is pretty different from the resistor method. You can see the original bistro or bistro-HD for two different ways to do that, but I suspect you'll be fitting it into a Narsil way of doing things. The good thing is I've found the divider calibration to be much simpler than the Vcc one. I calculate a table at compile time based on a one point calibration (either calculated from your resistors or better from using the battcheck build on a full battery), and so far I'm finding that to work great. There's an offset tweak too, but I haven't needed it.

[ToyKeeper]

@Flintrock

I think I can make some claims to the 2048 byte lightweight division, but I couldn’t find a way to beat BLFA6 in the featherweight category. That code is tight.

Aww… thanks!

[Flintrock]

Oh of course if you only want LVP and no voltage blink-outs, calibration is simple, you just need to figure out a single ADC value at your shuttoff level.

[Texas_Ace]

@Flintrock

Oh and you don’t need extra pins for dual switch. Even in 4 channel pwm it can be done with pins that exist. I’ve already put in some code for dual switch considerations in HD (actually there’s a dual switch hex in there already, although I’m honestly curious to know what it does, lol), of course if you have eswitch, the clicky will always do something. The issue is just trying to control exactly what it does.

I figured they would not actually double but I was giving some wiggle room for extra features and menu items.

In my opinion the simpler option is generally the better option. Particularly with these UI’s. They are already getting so powerful it is almost impossible to remember all the functions without the manual in front of you.

Personally I would say the easiest option to combine the firmware and have ramping and normal mode select be a menu option. You are in one or the other. I can’t think of a reason why you would need both at the same time.

My idea of the universal firmware involves a lot of menu options. You will need a manual in front of you to set it up the first time for sure but after that you should not need to mess with the menu. By having all these options in the menu it should virtually eliminate the need for code changes in 95% of lights and users.

The largest things needed besides modes IMHO is the ability to setup those mode groups as we need. The ultimate setup would be something completely user programmable when it comes to modes.

For example in the menu you could use the ramp function to allow the user to select each mode they want in the group, then lock it in with a triple click or something. Thus not needing all the pre-made mode groups and allowing the user complete control over the modes.

The hidden modes could be selected in a similar way as well. The user simply scrolls through them in the menu and selects the in the order they want.

It could be a bit code intensive to do this but it would eliminate the need to have every possible mode group setup from the factory. Plus I wounder how much more space it would actually take up vs 40-50 mode groups.

I have heard something about PID for things like this? I have no idea what that means though or how it works.

Although if guppdrv (SP?) can fit 22 mode groups on a tiny13, I am going to guess that it works well for repetitive things such as this.

[ToyKeeper]

@Flintrock

I think I stole bistro away from TK, lol

No, this is great; I finally got other people to do the work. I have minions!

Now, if you don’t mind, I must attend to a drink with a little umbrella in it.

[ZozzV6]

@ToyKeeper

No, this is great; I finally got other people to do the work. I have minions!

Now, if you don’t mind, I must attend to a drink with a little umbrella in it.

[ToyKeeper]

@Texas_Ace

My idea of the universal firmware involves a lot of menu options. You will need a manual in front of you to set it up the first time for sure but after that you should not need to mess with the menu. … The ultimate setup would be something completely user programmable when it comes to modes.

FWIW, if anyone goes that route, here’s an example of how not to do it:

http://www.rushmedia.de/ee/files/HiveLD-P_User_Documentation_McG.pdf

Another option would be to give it a light sensor and configure it by shining an animated GIF or something at it, like the BOSS light does. But don’t limit it to a maximum of 4 modes like the BOSS. Lots of potential missed there. Also, it massively restricts which hosts it could be used in.

Most people will just use the defaults regardless… so probably the most important thing is to make sure the default is good.

[Texas_Ace]

@ToyKeeper

@Texas_Ace

My idea of the universal firmware involves a lot of menu options. You will need a manual in front of you to set it up the first time for sure but after that you should not need to mess with the menu. … The ultimate setup would be something completely user programmable when it comes to modes.

FWIW, if anyone goes that route, here’s an example of how not to do it:

http://www.rushmedia.de/ee/files/HiveLD-P_User_Documentation_McG.pdf

Another option would be to give it a light sensor and configure it by shining an animated GIF or something at it, like the BOSS light does. But don’t limit it to a maximum of 4 modes like the BOSS. Lots of potential missed there. Also, it massively restricts which hosts it could be used in.

Most people will just use the defaults regardless… so probably the most important thing is to make sure the default is good.

I have long been interested in the idea of “dynamic” programming. Tom had mentioned before the possibility of using the LED itself as the sensor for such a task.

Well I just tested it and it would totally work! You would need an extra pin on the MCU to detect the voltage directly from the LED but that is taken care of with the 841 MCU.

I just used a random LED I had on my test rig, hooked it up to my volt meter and set it to mv expecting a few mv. Turns out that even with just room light it was putting out around .5v!

With my cell phone light turned on the voltage jumped to around 2v and with a S2+ reflector placed over the LED it was nearing 2.5V output from the LED!

That is easily enough voltage for the mcu to detect and use it to program itself. The biggest issue would actually be eliminating the external light.

Like this a basic phone app could be used to flash the cell phone LED to program the driver with whatever modes you want. It might take a few minutes depending on how much code was sent but still, it would be totally possible and a lot easier then blinking everything out.

The app could program everything frankly, hopefully reducing the amount of stuff the “base” firmware needed to store and freeing room for the programming stuff.

This would be a massive leap in flashlight drivers that is for sure! The best part is that it still uses all the existing and cheap components we use now with just some layout changes.

[Tom_E]

Well, I got a buddy EE who says you should be able to configure/program a flashlight from a cell phone, the light it puts out, to the LED. A LED is a diode - it can " read" light too. He thinks it could be done with the main CREE LED - dunno, unproven theory, but amaz'n if it could be done. Others lights on the market do this, but might be through another LED/sensor in the reflector/head area though.

[Texas_Ace]

@Tom E

Well, I got a buddy EE who says you should be able to configure/program a flashlight from a cell phone, the light it puts out, to the LED. A LED is a diode - it can ” read” light too. He thinks it could be done with the main CREE LED - dunno, unproven theory, but amaz’n if it could be done. Others lights on the market do this, but might be through another LED/sensor in the reflector/head area though.

Check the post just above yours, I just tested and proved him to be 100% correct. It easily puts out ample voltage to program the driver with an extra pin to detect said voltage.