I like these as well. Two switched gives incredible versatility, but it can also be very simple for newbs, depending how you set up your FW. I was really excited for the X5R from eagleeye, but I haven’t figured out a way to get one of our drivers in it yet
Nice one! I am kind of neurotic about my full 7135 modes :laughing: .
For the LDO/D1/C2. You can get away with only C2, up-sizing it to 1 uF or 2.2 uF.
A 100 nF C3 beside the MCU would be a luxury for what we are doing.
I did not even consider D1. Should select an LDO that limits reverse voltage at its output…
Ok, that makes things a bit easier, still gonna be interesting actually routing the traces though.
The LDO I was looking at using before (actually ordered a few at some point), did indeed have built in reverse voltage protection, so I could possibly use D1 as some kind of jumper to select which one you will be using. Leave D1 off and the LDO is the input voltage, install D1 and it bypasses the LDO.
I think RMM did something like this on the SRK FET drivers IIRC.
I thought mine were coming a couple days ago but when I got the package I realized it was just a few of pd’s tail light rings. (No offense PD 
) Anyone able to test one of these yet? Mine are now in the mail for realz.
I tested a few now including the one in the OP/a few posts up. TomE said he got one built although not sure if he did much more then that.
Besides needing to re-calibrate the LVP in the tripledown firmware for the 22k R1 resistor, it is working great for me. Gonna build a triple 219C S2+ soon that will be the true test for it. If it can handle that it should be able to handle basically anything.
The L2 with XP-L HI is pulling ~5.75 amps, so it has no problem delivering the power thats for sure, that is with the “worse” NXP FET as well, running low on SIR800/400’s so been using up my supply of NXP’s for the single emitter lights.
Sorry if I missed something or hibga have changed
Soda can lights have that sweet parallel setup of the cells.
Is there a way your 46mm driver can be used plain simple like that too?
If indeed the FET+1 is going to be abandoned for a different setup and Tom is going to work that into Narsil I would very much like to see a big driver capable of running in parallel.
Maybe some bridges to connect and extra pads or tracing to allow use of 2,7-4,2V input parts only?
don’t shoot me if I am not even know where the nail to hit on the head is please
Oh and +1 on the text below
Well the Q8 driver seems to be set but as an after market option I still plan on knocking out a 46mm version of the Avenger at some point. Really depends more on what happens with the Q8 and Narsil going forward so I can plan it out properly.
The driver in the OP would work fine in a 4P setup as it is with a bridge across all the contact pads. That was already designed into it by either a solder blob or by using 0805 0 ohm resistors.
Or the best option for a 4P setup and what I would do it use a copper contact plate like I used in my other SRK drivers. This would connect all the pads and improve the wear resistance at the same time.
This is the nice thing about separating the MCU and LED ground’s in this case. You can adjust the cell setup without any changes needed to the driver itself besides how the contact pads are setup.
Although all of that said, I think I would just swap to indivdual MCPCB’s so I could wire the LED’s in series and run the driver in 4S. This should improve the overall power delivered to the LED’s since there would be much less voltage drop.
Realy? You would do 4s over 4p? I can’t recall but I feel I’ve read 4p would be superior. But maybe it depends on many factors…
4P is only superior due to old fears along the same lines of needing to use protected cells in every light you own because they could explode if not. And it can use 1-4 cells at a time instead of always needing 4.
In every other technical standpoint 4s is superior. Why do you think that all the big manufactures setup their lights in series and virtually never in parallel?
Voltage is much easier to deal with then current. 16 volts no problem, 16 amps? Well you better have things done right with thick wires and traces all around.
To put things into perspective, 16 amps is more then a typical household circuit is rated for, so if you tried to run the Q8 through your circuit breaker it would pop the breaker (don’t try this obviously).
The prototype Q8’s are pulling around 16 amps for 4x emitters. So about 4 amps per emitter.
A single emitter and cell should pull 5+ amps due to less voltage sag in the circuit.
So in 4S setup a Q8 should pull 20+ amps without any other changes.
Thanks a thick contact ring, should have known that you were going to say that
There seems to be a wish to process on the Q8 with TF, the engineer even emailed on Saturday so let’s hope things can go faster from now on.
On a side note, yes using less then 4 cells still feels special for me in a 4P light, oh how I hated toys and things needing 4 batteries and only having 2 or 3 as a kid. This could be a reason for the intense feeling of joy operating a light with empty spaces in the tube 
I wired up the 22mm board from post #153 for testing - 2 long LED wires and a switch. created a new project called NarsilTriple, and created 7 mode sets, from 1 mode to 7 modes for supporting the triple PWM channels. I made the changes, in theory, to support the 3 output PWM channels like bistro_tripledown does, and updated all the uses of setting outputs for blinks, etc. to the new 3 channel setup.
For ramping, I cheated for now -- zeroed out the ramping table for the 7135 bank. Mainly I just need want to see if regular mode sets work with the new 3 PWM support. Just programmed the 85, gonna go try it now. Wish me luck!
Good luck! Can’t wait to see this come to reality.
This would complete my goals for these drivers as a do anything FET based driver. Although I do think I would add another 22mm+ version with an LDO for the larger boards, plus finish up the 46mm version.
So basically it would handle any flashlight up to a 30mm driver, Clicky, e-switch or dual switch, regulated and FET modes, thermal regulation (on the clicky for now at least), zener for use in multi cell lights and LDO on the larger drivers.
I am quite happy with how these are turning out.
O-K, it basically works! 
Wasn't bad - first time. Well actually, the first time it was flaky bad, looked over the code cleaned up some things, but mostly comments, naming, etc. Then went to dnld again, and dang -- it hit me! I downloaded the old Narsil, not NarsilTriple. I forgot to create a new BAT file to do the triple download... 
So, I think what I proved;
- no prob w/single 7135 PWM's and full (moon mode, partial, max at 0.35, etc.)
- full bank for 2.8A definitely works
- PWM for the FET and max works - did ramping and could get bout 3.5A max, and get a little less by backing off ramping a bit
Didn't try PWM's on the bank yet because only one mode set uses it - the 7 mode group - easy to try though. Current mode sets are below. I roughly assume full single 7135 is about 10%, and the full bank of 8 7135's is 50%. This makes sense if you have about 1,500 lumens max on a full FET, and the bank of 7135's is about 750 lumens. I've have to gen'ing a ramping table for 3 channels. This might be some trial&error til I get one that looks good - need to test in a real light.
I totally disabled (commented out) the on-board LED support for now.
// 1 mode (max) max
PROGMEM const byte mode7135Set1[] = { 0}; // for single 7135
PROGMEM const byte mode7135sSet1[] ={ 0}; // for 7135 bank
PROGMEM const byte modeFetSet1[] = { 255}; // FET only
// 2 modes (7135-FET) ~10% max
PROGMEM const byte mode7135Set2[] = { 255, 0};
PROGMEM const byte mode7135sSet2[] ={ 0, 0};
PROGMEM const byte modeFetSet2[] = { 0, 255};
// 3 modes (7135-7135s-max) ~10% ~50% max
PROGMEM const byte mode7135Set3[] = { 255, 0, 0};
PROGMEM const byte mode7135sSet3[] ={ 0, 255, 0};
PROGMEM const byte modeFetSet3[] = { 0, 0, 255};
// 4 modes (1.2-10-50-max) ~1.2% ~10% ~50% max
PROGMEM const byte mode7135Set4[] = { 30, 255, 0, 0};
PROGMEM const byte mode7135sSet4[] ={ 0, 0, 255, 0};
PROGMEM const byte modeFetSet4[] = { 0, 0, 0, 255};
// 5 modes (1.2-5-10-50-max) ~1.2% ~5% ~10% ~50% max
PROGMEM const byte mode7135Set5[] = { 30, 120, 255, 0, 0};
PROGMEM const byte mode7135sSet5[] ={ 0, 0, 0, 255, 0};
PROGMEM const byte modeFetSet5[] = { 0, 0, 0, 0, 255};
// 6 modes 0.8-2-5-10-50-max ~0.8% ~2% ~5% ~10% ~50% max
PROGMEM const byte mode7135Set6[] = { 20, 110, 255, 255, 0, 0};
PROGMEM const byte mode7135sSet6[] ={ 0, 0, 0, 0, 255, 0};
PROGMEM const byte modeFetSet6[] = { 0, 0, 0, 0, 0, 255};
// 7 modes (0.5-2.5-5-10-25-50-max) ~0.5% ~2.5% ~5% ~10% ~25% ~50% max
PROGMEM const byte mode7135Set7[] = { 12, 63, 150, 255, 255, 0, 0};
PROGMEM const byte mode7135sSet7[] ={ 0, 0, 0, 0, 120, 255, 0};
PROGMEM const byte modeFetSet7[] = { 0, 0, 0, 0, 0, 0, 255};
Looks like the next thing to do is combine LVP and switch on Pin 7 to get the indicator LED back on Pin 2
Hhmm.. I know Mike ?? did that, or something similar, but didn't look into it in detail. Thought he mentioned it required his board design? Do you know if anyone did this on one of our std boards? I can see where possibly there's no conflict - only do a A-D conversion to read the voltage when the switch isn't pressed, or hasn't been pressed for a while - some sort of logic like that, I'd think. Then maybe just sharing the switch with the R1/R2 pair could electrically be done?
Another option is getting rid of R1/R2 and using the internal ref, ala Dr.Jones. Or, using the Atmel dev kit, then you can use pin #1 as an I/O pin -- some options...
MikeC did it, I want to say he combined LVP, e-switch, and OTC for dual-switch all on one pin. It “required” his board to work, but I’m sure you could air-wire it to test firmware if you were motivated. All it would really take is soldering your switch+ directory to the tail of R1 or R2
May be possible. Don't think he was 100% with it all though. Recall he posted his code/boards, but don't think it was fully stable yet. Would hate to get false low voltage warnings... Though, that's exactly what happened to me last night, using a flat top WindyFire cell in my modded H15 last night - it seemed to work at first, then went totally flaky, and batt check was working but showing low voltage levels. Turned out it worked fine when I simply added a solder blob to the top of the cell...
Worth look'n it to though, for sure...
Edit: even an intermittent false warning should be tolerable since we need several low readings in a row to trigger a drop.
Very nice, glad to see this progressing!
Far as the pins go, if the LVP could be moved to the internal reference and R1/R2 removed that would be my preference for sure. That would free up a significant amount of space on the boards on top of the free pin. Plus it sounds simpler to me then trying to combine a bunch of functions into a single pin.
Not to mention it would remove issues with low tolerance components used when china starts selling drivers based on these layouts (the triple channel general layout, not necessarily The Avenger drivers), it is only a matter of time based on past dealings.
That said I have no clue what the coding involved in either change would be.
Yea, I do agree - better bang out of using the internal 1.1V ref, plus reducing parasitic drain even further. It's been briefly discussed. I know DrJones uses it, so it's possible for sure, and don't think he said much about it being a PIA or anything... I just don't know where to start to try to implement it. I'll have to do some research on it.
I also tested the 7 mode grouping and confirmed PWM's are working on the bank of 7135's. So the firmware is 100% functioning, just not using the bank of 7135's in ramping yet.
Defining modes though in percentage of output is highly dependent on the light mod/configuration. Some lights have a max FET amps of 3.5A, others will have 20A, and everything in-between. So 2.8A may be 80% or may be 20%. Mode sets should really be tailored accordingly, if you want consistency from light to light. Ramping has a little more tolerance, but should still be tweaked for exaggerated cases. I'm using Narsil in a MtnE SRK 7135 driver, and it uses 380 mA 7135's, so the standard Narsil ramping table has a couple OFF levels in the transition from single 7135 to the bank of 7135's because 380's can't be run at the lower PWM settings, like 350's can be. If you like a low moon, should always use a 350 mA 7135 - I've been seeing even a PWM value of 1 works with the new design drivers, but suspect it will go OFF when the cell gets low.
Now I need to find an E-switch light with which to try one of these in…