[WIP] 17mm DD+single-7135 driver / single sided / Dual-PWM

The voltagedivider consumes “standby” current so for electronic switch lights it might be recommended to use higher values like 100k and 22k as a standard…

Has anyone compared the so8 fets? Is the 0R9 one worth the dollar more?
What resistor Sizes are optimal for this driver 0805 or 0603?

For a single-cell light with a clicky button, a 19.1k resistor is the way to go. 22k also works, but it messes with the offtime capacitor.

Specifically, 22k pushes the offtime values to the far end of the measurable range, and makes the “off” timings very temperature-sensitive.

Any one have the Eagle files for this driver?

It would be nice to make similar boards available in other sizes.

Unfortunately not, but there are already some other sizes available. They use the same principle (FET+1)

[WIP] 10mm DD+single-7135 driver: double sided 10440 torture for Dual-PWM
[WIP] 12mm DD+single-7135 driver: double sided 10440 fun for Dual-PWM
[WIP] 15mm DD+single-7135 driver - single sided Dual-PWM compatible using 3.3x3.3mm FET
[WIP] 22mm DD+single-7135 driver / single sided / Dual-PWM / Zener

I’m not sure what kinds of files Eagle uses, but the OSHpark page linked in the first post has a link to download a zip containing a bunch of design files. gtp, gts, txt, dri, gbl, gbo, gbp, gbs, gko, gpi, gtl, and gto. Not sure what each one is, but maybe something in there will be sufficient?

The .dri file says it was generated by “EAGLE CAM Processor 7.1.0”.

Those design files are gerber files for the PCB manufacturing. The .dri file is the drill holes data of the PCB.

Thank you finges. I'll check those out.

Unfortunately TK, the Gerber files can not be used to create Eagle files (At least as far as I know).

I was hoping wight might have shared the Eagle files with someone before he left. It would take someone like me a boat load of time to recreate them due to my limited experience with Eagle. It would be cool if we shared the Eagle files. That way others could tweak them for their purposes and report back. It would accelerate board development. I know there is a thread were some component libraries are shared.

If anyone has the Eagle files for this or any other BLF driver that is Attiny 13a, and DD or 7135 based, it would be cool if you made them publicly available.

EDIT: Corrected spelling of finges name. My apologies. May take me a bit to not include an "r".

There Are eagle Files available for the early dd drivers(with the bigger fets). If i am remembering right warhawk has them uploaded to Dropbox or so…

Maybe send wight an email, he is currently making a pause from BLF so he won’t answer here.

Thanks Werner :)

Hey all,

I seem to have hit a snag with this driver. I ordered some boards from mountain, and assembled. Took Star_offtime firmware and enabled moon by default ( reversed the star logic) and also enabled the dual PWM. This all seems to work fine and I did get the lower moonlight mode I was after, but with one large hiccup.

I get a bright "preflash" every time I turn it on. Its only noticeable on moon and low, but I have never had this happen with the standard FET driver.

Does anyone have an idea what is wrong?

I see this all the time, in fact. I reported it early on and some responses were dismissive (no names), others were trying to help (Richard of course). Really haven't experimeted intensely, but tried a 100K across the FET input and got better results. On my last one (Rocher AS31), I tried a 22K resistore across the FET input. Clicked the thing like well over 100 times - seems like when I look for it, I can't reproduce it, but I've seen the flicker occur from time to time in actual occasional use. It's almost gone but still there... Frustrating...

In the OP's picture of the board, I put a resistor across the upper left pin of the FET and solder to the next 1 or 2 pins over to the right, so it's in between the input pin of the FET to ground. Tips were all from Richard - think he said to start with a 100K, work your way downward. Dunno effects, but the higher the resistance, the less effect on output maybe?? Forget... I assume the lower value, the more likely it will fix the problem. I think the flicker happens frequently with no resistor. No clue if the custom BLF A6 driver will have this same exaxt problem, but I've seen it on wight's FET+1 drivers.

If he bought boards from RMM, I think there are some differences vs the board in the OP.

This may be a dumb answer, but did you try switching between fast/phase pwm?

Yes, these are different from Richard's, but Richard was aware of the problem, so I thought he saw the same thing on his (not sure of that though). I didn't try switching fast/phase, but in an e-switch setup with my firmware, one click will go into moonlight in phase mode and the flicker occurs - maybe last mode was hi in fast mode though, not sure -- next time I could experiment with those transitions.

If I’m not mistaken we’re talking about having a gate resistor in the FET driver design? It sounds like Richard is trying to get you to put a resistor inline but I thought it was supposed to go between the ATtiny and the FET and not to straight to ground? I believe the gate resistor was dropped somewhere along the way in the design of the BLF FET board development to minimize parts count. I guess maybe this decision is now making itself apparent? I know that in my basic electronics book a gate resistor is mentioned as a good practice when driving a FET to minimize oscillations in the line. Er something like that.

Some of the best evidence of line behavior was lost in a post where an oscilloscope was used by comfy chair to measure the differences in line oscillations. The pictures of these results no longer appear unfortunately.

If I had more time I would re-make the board with a gate resistor as I have had some trouble in a few cases. Unfortunately not worth the hassle at this point as I don’t do the moonlight thing. I guess I could airwire a resistor to test, but I haven’t been able to replicate my problem again lately.

edit: oh right that was you in that FET post too Tom. hahah. but anyway, I still think that gate resistor is part of the puzzle.

Yes, the resistors I've been adding definitely reduce the frequency of flickers, so it's on the right trail.

I’ve been wondering what causes that preflash too.

As far as I can tell, it might have something to do with the OTC, because I only see it after a pretty short button tap. A longer press apparently lets the charge dissipate enough to not flash. But I also only usually see it if I’m going from turbo to moon.

I think I’ve seen this happen on the BLF-A6 driver, but a moment ago I tried it on the latest sample and it didn’t happen.

My OTC theory is un-tested. The theory is that maybe when we set the OTC as input, to measure its charge, it might deliver a burst of power to the output pin(s). Then when it’s set back as input, everything acts normally again. But this theory doesn’t quite fit since that should make it happen on every short-press mode switch.

Maybe it’s due to brownout detection or SRAM not decaying or something. A register could perhaps still have an old PWM_LVL value in it while the PWM options are configured, so maybe it turns on bright before it has a chance to turn the level down? But if that were the case, it should also apply to longer button presses; I’m not seeing SRAM decay until several seconds after shutoff when the OTC is charged.

So, short answer… I’ve seen it, and none of my theories really fit my observations. :frowning:

I haven’t been keeping up, first time I’ve read about this issue. Good to know before I start on my 8 x 7135 and FET driver, things like this can drive me crazy.

I guess this has been suggested before, but anyone tried putting a delay first thing on startup before initializing any of the pins? I’d put a delay just long enough to notice. If the flash appears after the delay, then it should possible to weed it out with code.

Just brainstorming, don’t have this driver or use that MCU to do any tests.

I just ran a few tests, and nothing I tried helped. What I tried was:

  • Explicitly set PWM_LVL and ALT_PWM_LVL to 0 at a few points: First thing on boot, just after the OTC gets read, just before and after the PWM registers get configured.
  • Move the OTC reading to after the PWM registers get configured.
  • Set OTC pins back to output immediately after taking a reading.
  • Set all ports as input immediately on boot.
  • A few combinations of the above.

None of it made the slightest difference; I get a flash every time I short-press from turbo to moon.

Oh, and none of my cheap test hosts (a light head with floating driver and extra battery leads) do the flash… I only reliably see it on high-powered triples. I’m also unable to reproduce the issue on a BLF A6 sample today, and I’m not sure if I ever actually saw it on one of those.

With the 22K ohm resistor in, I did over 100 ON clicks with e-switch firmware in a row and couldn't reproduce it. But I probably see it 1 out of 8-10 or so if turning ON from cold. I have no OTC's on mine. The flash I get isn't a bright one, but would be annoying in the pitch black I'm sure. I see it on fast clicks going into moon from OFF, and see it sometimes when press-hold to go into HI from OFF, but doesn't seem like a flicker, more like comes ON in a low brightness state before turning to full HI.

That sounds like the fast PWM=0 issue, where it never fully shuts off as long as the MCU is awake. It can be resolved by using phase-correct PWM instead.

Partly because of this, I use phase on the highest and lowest levels of e-switch lights. Or if it’s a smooth-ramping sort of light, I’ll either use phase on all levels or simply deal with the extra glow while I’m holding the button. Or put in special logic to force phase mode when PWM=0.

The flash I was testing earlier is something I’ve never seen on an e-switch light. However, I usually put a quick blink-on-power on e-switch lights so I can see when the battery connects.