BLF17DD Info Thread - Reference

Thanks.

Suggestion for the thread Op: add specifications and features to the first post.

What are min and max currents for this driver/FET ?

The FET seems to be missing from the digikey shopping cart, what FET is it?

What s the zener diode mod used for ?

I'm with you vex! I'd love to make these drivers but I'm afraid to dive into the many pages of history to find out which resistor goes where and why and which resisors have become obsolete, so which pads are to be ignored in which board versions, etc. And I was even around following the whole story! TomE started this thread to solve this (thanks Tom), but still it has not become really straightforward for us 'electronically challenged' folks.

About your questions:

-it is a direct driver so the current in your flashlight has nothing to do with the driver, the current is a result of battery, led and various resistances in the flashlight. The only thing the driver does is switching on and off, to introduce pwm to get lower modes and when using an electronic switch to switch the flashlight on and off.

-I am curious about the current best FET as well, since the great Vishay FET has gone out of production.

-the zener diode is used in a 2xli-ion (8.4V) set-up to reduce the voltage for the MCU that can not handle more than 5.5V, e.g. a MT-G2 on a copper board performs great direct drive on two cells.

so which FET should be used then if the vishay is out production?

yep, there are fantastic projects on this forum, really fantastic open projects but they lack just 1% more effort, to keep all features and instructions on one place, i.e. in the first post, such as

features
specifications
known issues
bill of material
assembly instructions
known issues/bugs
changes list / release notes
credits
3rd party sw/hw used

I work in a corporation so we are drilled from day one to pay attention to keeping documentation in shape. I’m very motivated to do stuff but the info is scattered around, and it’s quite inefficient having to go through all the posts in a thread to gather all necessary info.

Yes, the problem is of course that this is all hobby, we're doing it for fun, and however useful it is, maintaining documentation is a pretty boring thing to do...

Absolutely, the info is free and it’s all for fun so there’s little incentive to maintain the first post with needed info, i’m just saying: for newbies on this forum it can be frustrating the amount of info/posts you need to chew through to get the info you need about a project. Of course when you’re a veteran you already know everything there is to know and you probably don’t even notice the missing info.

I use my own e-switch firmware, based on JohnnyC's and can choose what MCU pin I want the switch on - choices are pin #2, #3, or #5 I believe (see code below). Mine by default is on MCU pin #2 and I believe this is typical, most common. Since the BLF17DD has to be flashed with firmware, the pin definition is defined by that firmware, not the hardware. Looked through my pics and found this one with a BLF17DD built in a Convoy L4, and it clearly shows the e-switch wire on MCU pin #2. comfy is correct in post #74:

Here's part of the code header definitions in my e-switch driver. I added more comments than what was there originally. I'm a consulting software engineer with 35 years experience in software development, so know how important it is to have good doc and reference material. but also know there can be too much, redundancy can be a bad thing, and attempting to document things you really don't understand can be worse than no documenting. Sorry for the poor formatting in html:

//-------------------------------------------------------------------------------------
// Used for FET based Phase Corrected PWM:
//-------------------------------------------------------------------------------------
#define MODES 0,2,25,255 // 4 modes %: 1-10-100 (for Cheng - no strobe)

//#define MODES 0,12,64,128,255 // 4 modes %: 5-25-50-100 (for Kenny's Warsun, Y3 - no strobe)

//#define MODES 0,1,12,102,255 // 4 modes: %: ml-5-40-100 (for Michael G. w/strobe)

//#define MODES 0,1,4,16,100,255 // 5 modes

// RMM - used in a MT-G2 build (5 modes):
//#define MODES 0,1,4,25,120,255

// RMM - also used this set (6 modes):
//#define MODES 0,1,4,8,20,110,255

//-------------------------------------------------------------------------------------
// Used for 7135 based Phase Corrected PWM:
//-------------------------------------------------------------------------------------
//#define MODES 0,5,15,92,255 // 5=moonlight, 15=6%, 92=36%, 255=100%

// Original mode settings, used with Fast PWM:
//#define MODES 0,16,32,125,255 // Must be low to high, and must start with 0

//-------------------------------------------------------------------------------------

#define LONG_PRESS_DUR 21 // How long until a press is a long press (32 is ~0.5 sec), 21 = 0.336 secs

#define PWM_OPTION 0x21 // 0x21 for phase corrected (9.4 kHz) or 0x23 for fast-PWM (18 kHz)

// ----- One-Click Turn OFF option --------------------------------------------
#define IDLE_LOCK // Comment out to disable
#define IDLE_TIME 75 // make the time-out 1.2 seconds
// ----------------------------------------------------------------------------

// ----- Option Strobe Mode ---------------------------------------------------
//#define ENABLE_STROBE
//#define XLONG_PRESS_DUR 48 // 38=0.6 secs, 48=0.75 secs

// ----- Turbo Settings -------------------------------------------------------
//#define TURBO // Comment out to disable - full output, step downs after n number of secs
// If turbo is enabled, it will be where 255 is listed in the modes above
//#define TURBO_TIMEOUT 5625 // time before dropping down (16 msecs per, 5625=90 secs)
// ----------------------------------------------------------------------------

// ----- Voltage Monitoring Settings ------------------------------------------
#define VOLTAGE_MON // Comment out to disable - ramp down and eventual shutoff when battery is low

#define ADC_LOW 130 // When do we start ramping (3.1v), 5 per 0.1v
#define ADC_CRIT 115 // When do we shut the light off (2.80v)
#define ADC_DELAY 188 // Delay in ticks between low-bat rampdowns (188 ~= 3s)
// ----------------------------------------------------------------------------

/*
* =========================================================================
*/

#include <avr/pgmspace.h>
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <avr/eeprom.h>
#include <avr/sleep.h>
//#include <avr/power.h>

#define STAR2_PIN PB0 // Star 2, MCU pin #5
#define STAR3_PIN PB4 // Star 3, MCU pin #3
#define SWITCH_PIN PB3 // Star 4, MCU pin #2, pin the switch is connected to
#define PWM_PIN PB1 // PWM Output, MCU pin #6
#define VOLTAGE_PIN PB2 // Voltage monitoring input, MCU pin #7

#define ADC_CHANNEL 0x01 // MUX 01 corresponds with PB2
#define ADC_DIDR ADC1D // Digital input disable bit corresponding with PB2
#define ADC_PRSCL 0x06 // clk/64

#define PWM_LVL OCR0B // OCR0B is the output compare register for PB1

#define DB_REL_DUR 0b00001111 // time before we consider the switch released after
// each bit of 1 from the right equals 16ms, so 0x0f = 64ms

There's things bout the DigiKey shopping cart feature I don't understand - when I click on the link I have in the OP from July 12th, it clearly has a FET in it. It's very simple to follow the link, then click on the part and get all the specs DigiKey has on it - it's far more complete and detailed than I could ever document myself. It would be a waste to redundantly attempt to produce detailed specs on all parts here - DigiKey and the manufacturer's spec sheets are far more comprehensive - I totally disagree with any suggestion to list part specs here. Also I'm no EE so really can't cherry pick out the most important specs of each part. When I started to build these custom boards, my problem was first, the parts list, second - figuring out where to place the parts, so for these two major issues I think (thought) this OP addressed that. I'm totally open though to suggestions, but getting into general part specs and specifics on firmware seems beyond scope here, maybe it shouldn't be. I know somewhere there is a thread/google doc of a listing of all shared/public firmware drivers and mine is in that list - forgot where, but I should add that link to the OP -- if I can find it Smile. From there, there should be a ref doc/spec on each of those versions. I try to document my stuff in the header/beginning of the driver code - others do this as well, but I'm sure could be done better.

Unfortunately, changes have been moving along fast that I can't keep up with. New versions of these boards have been appearing, maybe being untested/tested, but certainly faster than I can buy/receive/build up/document here. The variations are endless as well.

Important: Just so you understand, the BLF17DD driver used in the above pics is no longer available - it's obsolete. The new one identified as V1.0 on the board, I do have but have not built one up yet and tested, so can't update the pictures yet.

Thinking of adding a section in the OP called "History/Background" where I attempt to doc how and why these boards came about. The "OSHPark Projects" thread doesn't attempt to address it. The thread that really started all of this was created by comfy - I know it's big and long and packed with lots of useful info, but not summarized well anywhere I know of.

Here it is: https://budgetlightforum.com/t/-/25164, but still think there's more somewhere...

Think I found the driver list/repository: Link for all known shared firmware versions: https://www.dropbox.com/sh/yjq5ahllbuqf1zh/0ZaizdmY-E (not sure how updated this is), but just looked at it and there's a wealth of reference material, not just firmware...

I must be confused over the various board offerings, with my CRS flaring up these days it’s tough to stay on track.

Sorry for any confusion, just my own spilling over into the thread.

There's also the problem of loads of people outside the US who do not have cheap access to Digikey or a similar supplier.

How about one sample build in the OP for a 17mm BLF-fet driver using just nanjg105C (qlite) components, a correct Oshpark board for that, and a FET available through ebay? I could make that sample but I do not have all the right components in house for it now.

Umm, think with the current V1.0 board, the parts match the Nanjg 105C (maybe?) - earlier versions did not match exactly (1 extra resistor I think?), and the eBay FET - do you have a link? I got my own stock of original FET's comfy first found - think still the best. I can no way do FET research - OMG: the amount of time and effort comfy spent on that is just incredible, and I'm incredibly grateful he did!

To me, the important thing of the DigiKey cart list is very specific details on the parts, including full DigiKey accessed specs. This can be used to get the same matching parts elsewhere. eBay sources come and go all too quickly - my only problem with linking them, and again, I'm not an EE and don't know enough to say for sure what parts can be replaced with something close or equivalent.

Ordered the programmer 3.3v/5v USBASP USBISP AVR 10 Pin USB Programmer 51 Atmega8 Ribbon Cable for sale online | eBay

Should be here by Wednesday. Saw one selling for 2 bucks in China.

Rig some wires to the chip. Don’t have time to wait for a good clip to come in

http://www.ebay.com/itm/1PCS-SOIC-SOP-8-Test-Clip-with-ISP-CABLE-MODIFIED-/171010515789

Thanks for the firmware dropbox Tom. I’ll see what I can do when it gets here! :slight_smile: Then I can look like that kid in the ad

This is a very DIY thing, if you want to source the parts yourself and assemble it and flash it yourself. It takes some outside research or prior knowledge to figure out what substitutions can be made (like, if you can't find a X7R 16v capacitor, should you look for a X5R 16v or a X7R 10v?).

This is a direct drive driver. It's job is to connect the cell/cells direct to the LED/LEDs as efficiently as possible, there is no regulation or limiting or anything else of any kind. You can use combos other than one cell/one LED, as long as the LEDs can survive being connected direct to your power source with no driver inbetween... 3 XML2s in series with 3 series 18650s, 1 MTG2 with 2 series cells, etc. Higher input voltages will require a Zener diode to limit voltage supplied to the MCU to 6v or less.

Here's the current parts list for the most recent board revision: http://www.digikey.com/short/dq403 Even if you do not live someplace where shipping from Digikey is reasonable, USE THAT LIST to get the part numbers and/or specs of parts used!

The board: https://oshpark.com/shared_projects/IHvO85FY

Capacitor on this latest version has been relocated from the original Nanjg spot between pin 8 & ground, to between B+ & ground. Same parts used, the pads just connect to somewhere different. (This is because with the 'hard' load the MCU's PWM pin has to drive (the big beefy FET instead of dinky little 7135s) the original Nanjg layout of capacitor & diode created a boost circuit, and MCU input voltage would rise above the shutdown point and create unreliable mode changing. The old gate resistor was a clumsy patch that eased the load and reduced (but did not eliminate) the voltage boosting. The cap relocation totally eliminated it, and the MCU now runs at battery voltage (minus the drop through the diode), as it should. If you'd like to see the investigation that discovered this, click here: https://budgetlightforum.com/t/-/27485)

U1 - Atmel ATtiny13A SSU (or SSH, interchangeable)

FET - N-channel MOSFET, logic-level gate, gate threshold as low as possible (most will be around or just under 1v), 'total gate charge' (Qg) less than 40nC, lowest possible Rds(on)at 4.5v

D1 - SOD-323 Schottky diode

C1 - 0805 ceramic capacitor, 10uF 16V 10% X7R

R1 - 0805 resistor, 19.1K 1%

R2 - 0805 resistor, 4.7K 1% (tip: the 4.7K resistor is the one that connects to ground on one end; the 19.1K is the one that does not have one end connected to ground)

'2', '3', '4' - these numbers correspond to the 'stars' from the original Nanjg board, NOT the MCU pins. For instance, 'star 4' is on MCU pin 2, and the official name for pin 2 is 'PB3'. Confused yet?

'A' - bridge the two pads to ground pin 2 when using some firmwares; install 1uF 0805 ceramic cap if using an off-time firmware; if using momentary firmware, connect one side of your switch to the inner pad.

'B' - return feed from the 19.1K/4.7K voltage divider

'C' - power feed to the MCU, from the polarity protection diode

very informative post comfychair. I thank you as a flashnoob.

Thanx confy! When I get a chance and get a V1.0 assembled, I'll update the OP with this info from your post.

Anybody have an idea how much more is this efficient with one FET comparing to using a few 7135 ?

edit: oh and it seems that 7135 is a linear driver, not a FET? Than it is going to burn the excess voltage as heat, that can be calculated then.
But with the FET the current&brightness will diminish as the voltage is lowered during discharge, right?
What is the typical FET voltage drop, to calculate the losses.

Both designs are current limiting, not current regulating and use PWM's for anything other than 100% Hi. They don't have any buck or boost that would lose voltage or current. Both are efficient, but I think the FET design would be considered more efficient because it's about direct drive as you can get. PWM based modes spike max current though, so if your FET based driver gets 5A on hi and a 7135 driver gets 3A hi, a 50% PWM mode on the 7135 based driver will be better than a 30% PWM mod on the FET based, because though they both are using about 1.5A, the 3A spikes will be more efifcient than the 5A spikes because the CREE LED's are more efifcient at lower amps. In implementation, not sure if the difference will be very significant, but it will be there.

Most of us want it both ways: super high turbo mode, but at least a couple of lower levels for more practical close-in uses. Any PWM based driver is less efficient at low modes, and even less efficient if it's max amps is higher.

That is wrong, a 7135 will regulate current.

The fet will be around 0.01 ohm resistance.

so what’s more efficient

1. strong FET requiring low PWM which is spiking current and driving LED in the inefficient work regime

or

2. weaker FET/7135 which is limiting current ?

Should a man (or a woman, child, or elderly) then not have more 7135 / stronger FET than he actually needs for the HIGH mode, because he is then driving the LED inefficiently high?

It depends on what level you’re trying to determine efficiency.

In any PWM controlled light the lower the amperage is on high the more efficient the system will be in the PWM modes since the driver only has to switch 10% of 3A as opposed to 5A for example. As TomE already stated leds are more efficient at lower amperage and thus the higher the max amperage the less efficient the lower modes will be since the LED is still receiving 5A but for only 10% of the time for example.

To answer your second question it is more a case of safety rather than efficiency when children and/or inexperienced people are involved since most FET based (direct drive) lights run extremely hot on max. I would stick to lower output, current regulated (7135) lights for people unfamiliar with such hot rods.

Yes - of course a 7135 is a current regulator, but in a typical Nanjg/Qlite 7135 based design for one cell and one LED, it can easily fall out of regulation, therefore run at lower amps. For example, I can build up a 5.6A Nanjg driver with 16 350 mA 7135's, but for a Panasonic B cell and an XM-L2 on copper, I cannot achieve getting 5.6A, maybe only 3.5A or 4.0A at tops -- it falls out of regulation -- is this the right terminology?