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

I thought of this as well and without drastic driver layout changes there is no easy way to take the measurements from V+ while battery voltage is flowing.

The ideal setup would be to compare led V+ to led ground but that would only really work if the battery was disconnected.

Now if the voltage on the ground was simply too low then we do have an option as we shrink things. We could use an opamp to increase the voltage and thus make it much easier for the MCU to detect. This is an extra part though which is both space and money and best to not have it if we can.

I also agree that if the cell phone flash might be a better option then a screen. I saw some morse code apps for android so obviously the flash can be blinked, I am not sure what the limits are though.

Although I am still curious why your screen readings are so low contrast. I get a 20x difference in readings myself. I might toss a real LED on the screen and see if it agrees.

I tried two — XM-L2 with S2+ reflector, and XP-L HI in a BLF X5. Similar results. I measured one using my expensive fluke, the other with an attiny25 and a bit of math. Similar results. I think it just needs to be able to work with relatively small voltage changes… and, fortunately, it does.

Plus, the auto-calibration lets it accept a wide range of input sources. Just try not to change the brightness too much during data transfer, since it works on a midpoint threshold instead of edge detection.

Given enough ROM space, that should be possible. I’m still targeting tiny25 though, to make it work on existing drivers (after an “optic nerve” mod). However, the approach I’m using should make it relatively easy to add other stuff.

That might be worth the extra space it’d require. Instead of streaming all of eeprom, it could send a couple header bytes — start point and length — then stream the data. It wouldn’t cost much ROM, and would dramatically speed up small changes. I personally don’t want to wait for like 2 minutes every time I tell it to change one setting.

This would also make it a bit easier to detect when there was a transfer error. If the flashlight doesn’t blink out a confirmation after the app stops, the user can see that it didn’t work.

Most cheap lights from MegaMart already do what most people want. We’re a long way into that “20% of the gain takes 80% of the time” part of this field, only it’s more like 2% and 98%. And no solution is ever truly universal.

But it’ll be nice for people who really enjoy detailed customization, and probably also nice for people who make or sell flashlights. Could allow per-sale customization without hardware changes.

Anyway, I’m in it for the fun, mostly. I might do what I usually do — implement the fun part, the prototype, then leave the detail work to people who are more interested in that sort of thing. I’m a lot better at starting things than I am at finishing things. :stuck_out_tongue_winking_eye:

Nope.

I have no intentions of making a config app which doesn’t work on every popular OS. But if someone else enjoys writing phone apps, they’re free to do so. The protocol will be completely open.

If it works is all that matters. If you figured out a way to “calibrate it” that that should work great!

Personally while trying to keep it as compact as possible is a must have goal, I would by no mean limit it to a tiny25. No existing driver will work as is and in most cases people would rather get a new driver that supports it then try to mod an existing driver. Plus for existing tiny25 drivers you would also have to add a resistor before the diode to make them stable at high currents which is even more fun.

I see us moving to an MCU with at least 8kb of rom within the next year in all new designs. So we might as well take advantage of that. Also, I would look into the 841 MCU as that is the most likely candidate. Any code that can be done in such a way as to be easily ported over to it would make the switch easier.

That said, leaving some extra space for future updates is very wise, so optimized code is very good indeed.

As far as the 98% thing. I am a big picture guy. I look at things to see what kind of far reaching effects they can/will have.

I see this as a major leap forward in driver design with more possiblites then even I can think of at the moment.

With things like this you are always better off having more options then fewer. You can easily take options away but adding them is far far harder once it starts to be adopted.

On the very basic level most flashlight manufactures all go with a basic 3 mode setup or propitiatory firmware just because other options don’t offer anything tangible that they can advertise.

This on the other hand would add no cost but a ton of features and real world benefits that they can advertise. I could easily see a stable firmware/driver combo like this turning into something of an arms race as manufactures adopt it to not be left off the bandwagon.

That means it would be a rare opportunity to get our ideas into the mainstream, be it on a small or large scale. IMHO, we should grab this chance by the horns and try to get some proper firmware into the mainstream. It only makes our lives better.

It is also something that if 1 adopts it, then others will as well in order to not fall behind. Until there is something worth adopting though none of them will. Just look at the A6 and bistro drivers. They went from nothing to now being used in virtually all of astrolux’s lineup in the space of like a year. This is something that could have far wider reaching potential.

For this to happen the more features and options, the better. Features sell lights. Lights that sell are what manufactures want.

For example if convoy was to offer a driver with our hardware design and this proposed firmware, it would truly become a no-mod needed flashlight company. The only thing there would be to change would be the LED. He would still make even the most basic user happy all the way up to the most advanced.

Don't have time to post more or read more of what's goin on, but:

For TK, you'll increase the range of the voltage reading by adding a load in the form of a high resistor value to ground. High enough, it won't effect LED output, but enough to provide a load for the read back --- just got this tip here from an EE

So if you want this driver fully assembled and tested join in in this topic

36 boards are already reserved

I will do a total of 50 boards

I think you might over-estimate my soldering skills. :slight_smile:

I think I have some ~20k resistors floating around, but that’s about all. Think it’d be high enough? Maybe I could try a streak of graphite. Also, where does that go exactly? Pin3 to ground in parallel with pin3 to LED- ? Wouldn’t that keep the LED lit up, just a little, all the time?

Was think'n bout this more - a bleeder resistor for the tailcap might be doing the same exact thing. My friend drew up a simple circuit design - I should take a pic and post it. But basically, you connect LED+ to ground with this resistor. 20K may be fine to try initially. I order cheap assortments from FastTech or eBay/China. Just ordered an 1800 pack of 0603's rated at 1% from eBay for like $6, I think, the other day. Even if you only use a couple, it's worth having them available.

For what he's saying, it should really open up the range - might take some tinkering to get a range you want, but worth air wiring something up for a quick test. Soldering small stuff is all about seeing what you doing - magnifying and light.

I made a comment in the TA CC thread on this, but I would suggest a 10k-100k from Bat+ to LED- (parallel to the LED, easy to solder). Or even try the pin3 internal pull-up resistor (no soldering required!).

We are set up backwards on the typical driver. LED+ is fixed at Bat+, only LED- can modulate. The pull-up will create a higher voltage when not illuminated, without affecting the voltage (much) when illuminated.

Ohh - ok, good to know, thanks DEL Hope TK is up to it - I have zero time right now to try this stuff out. I'm afraid I'm gonna hold up the Q8 launch a little.

I suspect the resistor may also improve speed significantly.

Hey, how did we end up in this thread, lol. I just posted about OTSM here cause it's a ready and working build-up option for TA drivers. Oh well, this is the BLF way, it's all ok. I do think if this could get high-speed enough to flash whole firmwares that would be amazing. Would need some bootloader code to go with it. I think the attiny's are capable of self programming, no? Might require the big one though. Probably even worth losing OTSM ( :( )to open up flashing to anyone with a smartphone.

I see no reason at all that we would need to loose OTSM in order to gain flashing. To be honest any future drivers I work on will be OTSM or nothing. I refuse to even consider OTC as a viable option anymore. I an fed up with all the issues that go along with it.

As far as flashing the whole firmware, this would be cool but not if it comes at the expense of a larger components / significantly more expensive or loosing any other needed features.

Just being able to adjust any of the defines at will via flashing would be enough for me. Although once that starts we will inevitably want more and more things to be setup as defines to allow for more adjustability. Hopefully things can remain compact enough to allow extra space for such options.

I REALLY want to get a driver that is good enough to have made in bulk to both reduce costs and allow easy access to the beginner to mod lights. Then hopefully from there it be adopted by some manufactures. I think Convoy would adopt such a driver with little effort on our part if we could prove it works.

Much like how there were no XHP70 lights on the market at the start of 2016 and by the end of the year there were a dozen (dozens?). Once one company does it, the rest have to follow suite in a hurry.

TA did you also consider MCUs with more pins that need just pins with acupuncture style to flash drivers

That way you got more IO pins, more space for other parst on the driver board and can flash it without removing from the host

Yes, at this point the 841 MCU is looking like the best bet, although if someone knows of another option with more features / memory that would be great since the 841 will still need some adaptation to the firmware and whatever we move to will most likely be with us for quite some time.

Although the vias for flashing are a nice workaround for some of the drivers there would not even be room for this. That is why a combination firmware with both clicky and e-switch/dual switch support and the ability to be flashed from a screen is so helpful. It removes the need for flashing for 98%+ of users and those that still needed to flash it for some reason would also have the ability to do so.

For example neither the TA or TC drivers have remotely enough space for a single extra via much less several. Every component is right on the 6mil tolerance limits. This will only get tighter as we progress.

Well, that's the direction I've been going TA. I've spent more time cleaning up defines than writing actual code. (nobodies fault, just spinoff versions kind made them a bit incompatible). I even made this big universal make file largely to make sure my defines don't conflict. I can see all the builds, any errors, and if any shrunk unexpectedly (oops something got defined out, but almost always a mistake makes an error). It does start to carry baggage especially once you write several configs. I need to come up with a patch system where I can patch all my configs easily. But at some poiint people may have their own and I don't want to break compatibility. Even just to change comments or propagate new options though, a patch system would help already.

And then if you change options you need to do things like add preproc code (away from the config file) to check if the new option is defined, or provide a default if it isn't to keep compatibility with old configs. So far I'd say it's all for the better than the worse, but it does build a little weight.

Anyway, I don't know why you'd need extra hardware to flash (well, ok if they can't flash themselves.. can't they? I'm not sure).

The OTSM loss comes if you need an attiny85. Hopefully as time goes by the B revisions will run out. But who knows, maybe C was a special batch and they never retooled most of the line and are actually still making B's. Every attiny85 I've heard of has been a revision B and they won't work, well, not without the 200uF option, well I have other things tightened up enough, and we might be able squeeze on 100uF.

I am skipping the tiny85 in any future development. It is a royal pain to work with, it is massive and takes up the whole dang board. A tiny85 literally uses almost half the 17mm PCB space!

I will be going exclusively to the 841 if nothing better pops up myself in future builds. From what I read it seems to support even better sleep modes then the tiny45.

Hot off the press:

attiny1617

  • 16 kb program memory
  • An 8-bit DAC
  • 2 more PWM pins
  • Cheaper than the 841, 85 (67c in volume, vs. 69c, 73c)
  • 24-pin 4x4 mm QFN package
  • –40 to 125 C rated

Do not see them stocked in retail yet, but Digikey lists them for $1.94, Mouser for $0.94.

No idea on how much rework is required to existing firmwares.

:heart_eyes: :heart_eyes: :heart_eyes:

My pretty!

Well, I found the new MCU I will be using assuming that the code side of things is not too hard. There is also a 3x3mm version as well. Plus more then enough pins for anything we would want to do.

With this we should easily be able to get all the features we want and have room left over for future advancement as well. Still need to keep things compact naturally from the start but gives us some much needed wiggle room.

That whole self-programming thing sounds a bit more reasonable now if it is even possible. Although just programming the needed section of code or most changes is a must IMHO.

I updated the TA Bistro, it is in the same link as before in the OP.

Only change is the addition of a v1.2 version of the firmware, the modes are changed slightly to a bit better spacing and options IMHO. Particularly for low Vf LED’s. It gives a midrange mode that is much easier heat wise then full turbo in several mode groups.

I found myself wanting this in a few lights that were simply too hot in turbo and not as bright as they could be in the 7135 bank mode.

I might make one more change to the mode groups at some point, I wish I had made group 15 without level 4 as the first mode, just use moon and then skip to 1x 7135 as I prefer 4 modes on my lights, more just gets annoying IMO. Plus I like having all my lights the same to make it easier to know when I am in the highest mode in each one.