Yes slaving just means using negative and positive contact points on the back of the driver (after wiping it clean) and wiring them to the negative and positive contacts on the next driver. Nothing on the original driver is used at all so it’s not doing anything really. (well I do save the parts in case I need them for something else)
Yes both have to be the same mode. I messed up one and forgot to solder the third star. It was pretty funny how it worked.
To be honest I didn’t know if I would actually double the amps or not. I was afraid they would somehow sense the amps and shut off at 3amps. But they didn’t!! I don’t know if this will work with all drivers or not.
Now I’m wondering if it would work to run a MT-G2. Unless someone stops by and tells me it won’t work, I’ll probably try one on a SRK. I have a good reflector for them that fits in the SRK. It’s for a P7.
Ok - so this is pure, true parallel drivers. Battery + split out to the 2 drivers, Battery - (ground) to the 2 drivers, output LED + and output LED - of both drivers going to the LED.
Effectively this results in the same voltage getting to the LED, but adding the amps up for each driver. Hhmmm. Thinking heat related issues of the 7135's is better because spread over 2 boards - more paths, as opposed to piggybacking on 8 chips to one board. Not sure about the relationship of volts/amps. I would speculate since the LED is getting high amps (about 6A), that the Vf would be driven a little higher too, so not sure if it would help in lowering overall driver/circuit resistance -- can't be sure. Think comfy and others may know this - understand a whole lot better.
This true parallel wiring of drivers is opposed to the Nanjg master/slave wiring, which basically uses a second Nanjg as a farm of 7135's to effectively add amps to the primary Nanjg. This is the master/slave relationship I understand. The "contact board" technique I didn't think was called master/slave, because when the original driver is used as a "contact board", nothing electronic is used off the original driver - it's just used to contact with the batteries and provide the + and grounds contact points.
Another variation is using the power (generated output) of the original stock driver, and using a "slave" board to control the output via it's own PWM (mode control). This design I think is specific to the original driver, and this is what comfy and werner have been working on with a couple (at least) lights.
So I think you came up with a 4th variation here.
Edit -- Wait... If both driver put out PWM's, it's impossible to time sync them?? So mid, low modes would be kind of funky?
As for PWM, I’m not a person who is sensitive to it. But I just went and ran the shower to check it out against a stock C12. The C12’s PWM was way more noticeable to my eye. Maybe when they are out of sync it’s not as bad because one driver stays on so there is no actual “off” for that tiny bit? So I guess it would be faster but less noticeable. I don’t know what effect this would have on someone who is sensitive. Might be good might be bad. We would have to talk someone who is PWM sensitive into trying it.
I took the light out and played with it last night while it was snowing and didn’t notice the PWM at all. But, like I said I’m not sensitive to it so I’m not looking for it.
Using two drivers in parallel, while both still have functioning MCUs, can cause problems. If you've ever had two identical lights with identical drivers, set them to strobe, and let them run a while, they go out of sync. Like a twin engine boat with the throttles not set right. No way around it, it's caused by just the slight variation between the cheap parts used on the drivers. The real problem is in the lower modes. If your low mode is 15% PWM, it'll be fine when both drivers are on at the same time and off at the same time, but when they get out of sync the light output will cycle around bright and dim and all over the place.
Best to only have one controller for all the boards. All the common small drivers just use one output pin on the MCU to drive the thing that regulates the current (whether that's a 7135 or a SOIC8 FET or a TO-252 FET, they all use a PWM signal to control what the LED is doing), you just have to find which pin it is and add a jumper from the brain board over to the dummy board that's had the MCU removed. With common drivers it's easy, they've been poked and prodded enough that all the pins and traces are well known already. With others it's just a bit of poking around with a DVOM.
The slave/brainless drivers do not need any connection to BAT+, all these drivers only regulate through the negative path, between LED- and ground (and any fancier driver that doesn't work like that shouldn't be used for this anyway). At high currents (and why else would you do this?) running the BAT+ through a driver's PCB can be a restriction; the brain-board only needs a tiny bit of BAT+ to run the MCU, nothing else on the board uses any positive voltage at all. Run the main LED+ wire around the drivers and straight to a big fat connection to the battery, then split off that point with just a small wire to feed the single MCU.
This is, essentially, a master/slave setup just like two 105Cs. Just that 10 of the chips happen to be on a board that's not a 105C. All the pins and traces do the same things. (the red wire from the BAT+ pad to underneath the 105C is only there to feed the MCU, it has nothing to do with the BAT+ to the LED at all)
This is all you need to do if you want the easily programmable attiny with a nice UI to control a totally different driver:
Thanks for the info Comfy. How long does it take for the PWM to get wonky? I have this one sitting here on low right now for about 10 minutes and it’s just a nice steady low. Did I just get lucky with this particular driver? I’ll leave it running and see but so far I can’t notice anything wrong with it at all.
There can also be a spread between the time measured for a half-press, if you always stay inside the window for both drivers when changing modes it'll be fine but if by chance you get too close to the time limit one can change modes while the other one doesn't. The issue with 'potential problems' is that it may work perfectly fine, right up until it doesn't...
Thanks again, I’ll keep this thread updated and post if I have any problems. I messed around with it quite a bit and now I’m giving it goofy half presses and still no problems. Supper fast changing, clicking it on and off rapidly over and over still no problems.
This is the driver I’m using. I jumped one of the three resistors on the bottom. Between the three the registered something like 6.7 before jumping them.
Thanks OL - this takes the guess work out of the wiring. I like the idea of running the battery + directly to the LED(s), so there is no flow through high resistance traces on a driver. Also, the way it looks, the slave 7135's should have better heat dissipation paths than if stacked all on one board because of the additional tracings and wiring of the slave board?
I was also gonna say that it works great with an MT-G2. I've done it in a ZY-T08 and I think that Old-lumens has done it with several of his builds (including the recent Courui MT-G2 mod).
I believe it helps. It sure couldn’t hurt. I have come to the point where I don’t want to stack any more unless absolutely necessary and if I do, then I want a copper wrap to help with the heat.
The drivers are in parallel. The batteries are in parallel series only because I need the voltage thru the chips. Otherwise, as long as the drivers are master slave, the batteries can just be parallel for a 3.xx volt led. The master has the zener mod, to protect the mcu and the 7135 chips do need extra heat sinking. If not, the light gets dim very quickly, due to reduced 7135 output. The last time I tried using .010" thick copper sheet and wrapped the drivers, soldering the copper to the tabs of the chips and it seemed to help a lot.
