17mm & 20/26/27mm single-sided DD/FET driver release: A17DD-SO8 / A20DD-SO8 / etc

ToyKeeper, what was your conclusion on the effect of tweaking R1/R2 values (RE: offtime)?

I think the OTC decay is affected by far more than just the values of R1 and R2.

However, I’m still a clueless noob about circuit designs… so I’m not sure how to control the decay curve.

Last year I build a light with this driver and zener mod (S8 with XHP50, 2x18350 cells), with the normal 19.1K and 2.2K (I did not realise the problem so never worried about that), and the LVP kicks in at 3.6V/cell (resting voltage after LVP event, under load it must have been quite a bit lower) which is not that great but it is below half drainage so it is usable.

Did you notice any weirdness with offtime?

The first part is definitely true! With our current offtime setup there seem to be a lot of factors. I’m sure that there are many which I do not have a good handle on.

It does look like you did some testing which really made resistor selection seem important for the current OTC setup though, check your post #552. Does that still hold water as far as you are concerned?

I saw a few of Sharpie’s posts over in another thread RE: the A6 driver. After filtering out any confusion from those posts… These drivers have never been perfect and we’ve already discussed some of that stuff but it never hurts to rehash it again. It got the wheels turning in my head.

I’m saying this pretty blindly, but maybe a simple way to improve offtime consistency (if/when it’s a problem at least) would be to use a larger cap with a bleeder resistor. Whatever is bleeding through the ATtiny13A is doing so slowly. Moving to a 10uF X5R cap should significantly reduce whatever influence the ATtiny13A has over the cap and allow a bleeder resistor to become the dominant factor.

10uf with a bleeder would be simple enough to test on current boards.

For the record, using 19.1k for R1 and X7R 1uF for OTC is reliable enough for me, even at very high temps. It’s just when you get into TK’s mode reversing that you need the extra accuracy. 22k for R1 did give more issues, for whatever reason.

I’m having some problems with a 20mm zener modded driver I setup for an MTG2 / L2 combo. 4.3v zener on the pad and a 200hom resistor in place of the diode.

Driver seemed to work fine initially, but now it will randomly not turn on when I press the switch(including cycling modes, ie low~~med1>offhigh~~>turbo), will turn itself off while on, go super dim and then blink while on a moonlight mode (I don’t have moonlight programmed), really slow strobe on any brightness level at any time etc. Just basic random crazyness. Not usable at all.

Any suggestions on what I did wrong? I’m going to r2 the 200ohm resistor and reflow the board tomorrow, but I am thinking I might have cooked the tiny13 somehow. The driver worked fine, super bright, until I put a pair of powerizer 26650’s in the light in place of KK cells.

Possibly cooked the Zener? Please:

  • Take detailed pics.
  • Measure voltage at MCU pin 8 (Vcc).

Also what do you mean by saying that you are going to “r2 the 200ohm resistor” tomorrow?

Sorry, in a prior career r2 meant remove and replace.

I’ll pull the driver and measure voltage at pin 8 before I do anything

Sounds good. [Depending in part on the tools you have available] I’m sure that there are other things to check - I just can’t think of them right now.

What specific Zener are you running? 200 ohms is possibly a little low for really strong batteries and a “low” mode with MMSZ5229B I think (for example). Again - I’m pretty rusty on this information and I never did much with Zener modded stuff.

Diode I used is one of these

Your comment about the resistor made me test some things. With two KK ICR cells at 3.65volts each, the driver appears to work as normal.
With fully charged cells the driver acts crazy……I need to do some extended testing with the lower volt cells to make sure the driver is 100%, but I think it just needs something more than 200ohm.

There were more differences between those drivers than just the resistor. It seemed that the resistor was relevant, but not as big a factor as I had thought. To really quantify it, someone would have to build identical drivers with only that part changed.

Received my pcbs today from Oshpark ! Anyway , I’m still waiting for some components… :wink:

Hello guys and gals,

I'm pretty new to modifying and building flashlights and pretty much all I know about it so far has been learned from the majority of you guys right here. I've been lurking and absorbing info from this place for 2-3 years and repairing and modifying for a year or so. I'm getting way better and still learning and having a good time at it.

I started ordering the DIY kits from RMM a while back and have had really good luck with them.

I ordered a few of the MTN17dd kits and assembled 3 of them all at the same time in the same manner. (Guppydrv rev1)

The first one is operating fine.

The 2nd has no off time memory. It always goes to the next mode no matter how long it's off. I can program it like normal. I changed out the otc and no change.

The third one has no off time memory and it can't be programmed. It'll go into configuration mode but when i tap in the mode group I want it just keeps blinking in configuration mode till it times out never recognizing the mode group selection. It just stays in the default L-M-H .

I need help!

Hello guys , and sorry for being a noob (question is coming!)…

for this driver , what the following numbers on pwm should be ? on toykeeper’s starry-offtime

Also , is this designed for attiny 25 ? Beacause i get a memory overflow error

Only one of the two PWM channels is used on this driver.
So set the one array to numbers you like from 1 to 255, the other one will not be used.
(IIRC the first array is for PWM channel 1, which this driver is using).

Try something like this:
#define MODESNx 1,4,16,64,255

No idea about the intended target MCU.

What is your compiled size? Make sure the -Os compiler option is set.

Thanks for your help DEL.

I get this :

Error Program Memory Usage : 1088 bytes 106,3 % Full (Memory Overflow)

Data Memory Usage : 39 bytes 60,9 % Full GccApplication5 GccApplication5 0

That is close to fitting. You have to get the 1088 below 1024.
I do not use AVR Studio, but you should have a selection somewhere to ‘optimize compilation for size or -Os’. That should bring you in under the limit.

In AVR Studio right click on the name of the project (in the project tree on the righthand side) and click properties then head to ” toolchain / compiler / optimization / optimization level” via HarleyQuin here.