[WIP] 17mm DD+single-7135 driver / single sided / Dual-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.

I would test with a delay as the very first piece of code the MCU runs, before anything else. I’d do it to test if there is any change in the flash behavior. If no change is seen I would stop looking at code.

When I check signal traces with a DMM after hot air soldering everything on (beep on short circuit), I get short beeps when testing AMC traces to ground. If I get the beep or not depends on which probe (+ or -) I put on the trace. Could the flash you are seeing be a result of this behavior maybe? I don’t have any drivers or DMMs here now so I can say exactly which traces cause this, but this has most certainly been noticed by others.

Thanks for the idea. I put it on my list earlier today for the next time I have an affected light open, but I didn’t see it until after I had everything all put back together. Unfortunately, it doesn’t happen on any of my convenient test hosts… just on the lights which are kind of a pain to open and flash.

It’s possible I might not be able to trigger the bug with a pre-delay, since that gives the OTC extra time to change its charge, which might prevent the ability to change modes. But I’ll figure something out.

I originally posted this in the BLF Manker A6 thread, but it looks like this is the more appropriate thread.

I built many of Wight’s DD+7135 driver and never encountered the flicker issue. I saw the flicker with the Manker A6 driver. Comparing that with my home-assembled driver, I used a different MOSFET: PSMN6R5-25YLC instead of the PSMN3R0-30YL used in the Manker driver. I swapped the MOSFET in the Manker driver and the flicker disappeared.

Doing some research, I suspect the flicker issue is due to Cdv/dt induced turn-on.

When the FET is on in turbo mode, it causes the battery voltage to drop. When the FET is turned off in moon mode, the battery voltage recovers. This causes the change in drain-to-source voltage that triggers Cdv/dt turn-on. The white paper mentions that if the gate driver can only pull the gate down to 0.7V, then the Cdv/dt induced voltage is added to this 0.7V to make turn-on even more likely. I checked the ATtiny13A data sheet and the output low voltage is only guaranteed to 0.7V.

What makes matters worse is that the Vgs or gate turn-on voltage decreases when the junction temperature increases. So the longer the light is on turbo, the more likely that it will flicker when switched to moon.

Adding a pull-down resistor to the gate of the MOSFET, as Tom did, helps but does not completely eliminate the flicker. Beyond that, we can try the AC gate drive suggested in the paper by adding a capacitor in series between the MCU and the gate of the MOSFET; but this is more of a solution for the next driver design than a fix for the current driver.

The PSMN6R5-25YLC that I use has higher on resistance and so the turbo current will be lower. But will it still be acceptable? There are other parts in the same family that offer lower on resistance than the PSMN6R5-25YLC and lower stray capacitance than the PSMN3R0-30YL. Only by trial and error can we determine which ones are best. However, I don’t have the equipment (top batteries or thick probe wires) to do accurate current measurements.

Anyone willing to cooperate to find a better MOSFET for this driver?

What flicker do you mean?
The only thing I noticed with the BLF A6 flashlight is the following. If you are in turbo and use a short press to go to moon I see a very short flash and than a stable moon mode. Do you mean this short flash?

Yes he means that short flash.

Haven’t read the linked psdf files yet, but I Always appreciate Infos

whats the right equipment to flash this driver ?? /any recommendations from the pros here ??

In case you’re not using Windows, this includes some extra info and links to alternate tools and equipment:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/README

Has anyone received boards like mine? :~
They are v009 from the first post link.
I have never had problems with OSH park, how responsive are they to these issues?

wow - they don’t even look purple! OSH Park customer service is typically good!

is the BAT+ terminal pad underneath?

Yes, copper is underheath.
They really are purple, it is due to white balance of my phone with artificial (non-led 0:laughing: light (today it´s very cloudy here).
Thanks!

Yes, I've had the same problem, but think just once. Opened a ticket on it, and they explained they've been having this problem with Alex's board once in a while and not sure why. It does have to do where/how your batch is placed in the panel sent to the fab house. They were very accommodating and rushed a replacement batch sent free of charge. Still takes a week or two, but still great support.

I also used the masked ones - just had to scrape off the masking where I wanted to solder.