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

505 posts / 0 new
Last post
ImA4Wheelr
Offline
Last seen: 3 weeks 4 days ago
Joined: 02/03/2013 - 14:51
Posts: 7918
Location: SC

Any one have the Eagle files for this driver? 

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

finges
Offline
Last seen: 2 days 6 hours ago
Joined: 11/19/2014 - 14:50
Posts: 495
Location: Germany
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 01/12/2013 - 14:40
Posts: 10107
Location: (469219) 2016 HO3

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”.

Microa
Offline
Last seen: 1 hour 4 min ago
Joined: 06/29/2011 - 21:20
Posts: 236

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

ImA4Wheelr
Offline
Last seen: 3 weeks 4 days ago
Joined: 02/03/2013 - 14:51
Posts: 7918
Location: SC

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".

Werner
Werner's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 10/19/2012 - 15:00
Posts: 3679
Location: Germany

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.

ImA4Wheelr
Offline
Last seen: 3 weeks 4 days ago
Joined: 02/03/2013 - 14:51
Posts: 7918
Location: SC

Thanks Werner Smile

vestureofblood
vestureofblood's picture
Offline
Last seen: 22 hours 32 min ago
Joined: 08/17/2012 - 15:21
Posts: 1840
Location: Missouri

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?

In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not.
http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.

Tom E
Tom E's picture
Offline
Last seen: 7 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 12408
Location: LI NY

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.

pilotdog68
pilotdog68's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

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?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Tom E
Tom E's picture
Offline
Last seen: 7 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 12408
Location: LI NY

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.

seasam
Offline
Last seen: 3 years 5 months ago
Joined: 01/31/2015 - 13:15
Posts: 189
Location: GA, USA
Tom E wrote:

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.

http://budgetlightforum.com/node/32506

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.

Tom E
Tom E's picture
Offline
Last seen: 7 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 12408
Location: LI NY

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

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 01/12/2013 - 14:40
Posts: 10107
Location: (469219) 2016 HO3

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. Sad

Mike C
Mike C's picture
Offline
Last seen: 14 hours 36 min ago
Joined: 01/22/2014 - 08:03
Posts: 2382
Location: Sweden

I haven’t been keeping up, first time I’ve read about this issue. Good to know before I start on my 8 × 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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 01/12/2013 - 14:40
Posts: 10107
Location: (469219) 2016 HO3

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.

Tom E
Tom E's picture
Offline
Last seen: 7 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 12408
Location: LI NY

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 01/12/2013 - 14:40
Posts: 10107
Location: (469219) 2016 HO3

Tom E wrote:

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.

Mike C
Mike C's picture
Offline
Last seen: 14 hours 36 min ago
Joined: 01/22/2014 - 08:03
Posts: 2382
Location: Sweden

ToyKeeper wrote:
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.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 01/12/2013 - 14:40
Posts: 10107
Location: (469219) 2016 HO3

Mike C wrote:
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.

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.

dthoang
Offline
Last seen: 10 months 3 weeks ago
Joined: 10/09/2014 - 13:30
Posts: 319
Location: Austin, TX USA

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?

one year rookie

finges
Offline
Last seen: 2 days 6 hours ago
Joined: 11/19/2014 - 14:50
Posts: 495
Location: Germany

dthoang wrote:
So the longer the light is on turbo, the more likely that it will flicker when switched to moon.

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?
Werner
Werner's picture
Offline
Last seen: 2 months 2 weeks ago
Joined: 10/19/2012 - 15:00
Posts: 3679
Location: Germany

Yes he means that short flash.

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

jack-bkk
Offline
Last seen: 1 year 6 months ago
Joined: 04/15/2015 - 01:29
Posts: 435
Location: Bangkok

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

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 month 1 week ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town
jack-bkk wrote:
whats the right equipment to flash this driver ?? /any recommendations from the pros here ??

http://budgetlightforum.com/node/29684

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 34 min ago
Joined: 01/12/2013 - 14:40
Posts: 10107
Location: (469219) 2016 HO3

jack-bkk wrote:
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/he...
Pablo E.
Pablo E.'s picture
Offline
Last seen: 2 years 9 months ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)

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?

tech
Offline
Last seen: 3 months 1 week ago
Joined: 12/03/2015 - 15:04
Posts: 374

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

is the BAT+ terminal pad underneath?

Pablo E.
Pablo E.'s picture
Offline
Last seen: 2 years 9 months ago
Joined: 08/08/2015 - 13:54
Posts: 234
Location: Spain (GMT+1)

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

Tom E
Tom E's picture
Offline
Last seen: 7 hours 11 min ago
Joined: 08/19/2012 - 08:23
Posts: 12408
Location: LI NY

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.

Pages