DEL’s BLF driver DDm-17 [rev04b][tried & tested] just got in - about to build the driver. since there is no OTC, which firmware should I use with clicky lights?
Thanks.
edit: …and which fuses should I set on an Attiny85?
edit 2: I should’ve been more clear - I don’t need a memory mode, just any firmware that would work with this driver and a clicky light.
I've enabled and used brownout detection in the past for clicky lights. Thought it worked well for me, but haven't fiddled with that in quite a while. Maybe DEL could add some to this.
Edit: for a clicky, shouldn't need an 85, you could use it if you have nothing else. A 25 would be easier - don't need to bend the pins for example.
Required fuse settings are (mostly) determined by the firmware and the type of MCU.
The go-to tool for fuses is this:
http://www.engbedded.com/fusecalc/
You should not need BOD for a clicky light. The clock-speed fuses do need to align with the firmware though. Popular choice for the 85 is 8 MHz. I run at 1 MHz, with the implication of lower PWM frequencies.
tiny25-85 8 MHz fuses:
-Ulfuse:w:0xe2:m -Uhfuse:w:0xdf:m -Uefuse:w:0xff:m
tiny25-85 1 MHz:
-Ulfuse:w:0x62:m -Uhfuse:w:0xdf:m -Uefuse:w:0xff:m
For these boards you need a firmware that uses the ‘noinit’ method of differentiating between long/short presses (or use on-time memory…yeah not an option). There are several options, including Biscotti from TK. But it should also be a two-channel driver, to make use of the 7135.
My firmware does not have any memory or button-programmable functions, but it is relatively clean and concise. I do not mind sharing the source or hex if you are stuck.
First of all, thank you for the input!
Current status - I managed to assemble the first board:
- used an attiny13 instead of 85 because I don’t need too many features initially and also couldn’t find the firmware (can reflow another MCU if required)
Annotations:
2) I can not flash the MCU when it is soldered onto the driver. Tried different MCUs with the same result, avrdude only flashes when I take the MCU off the board and reflow it onto it again afterwards. I didn’t initially notice this or saw this as a problem because I normally flash the MCU before I reflow it.
Did I do anything wrong for the board to come out like this?
3) without any bypasses the light does about 3.9A on a somewhat empty 25R cell and a CW XML2 U4, which is great.
4) For R1 I used 19.1 KOhm instead of 22 KOhm <- is that an issue? I ordered a huge resistor kit and it doesn’t have 22 KOhm .
(driver looks so “wet” because I sprayed ethanol for cleaning, looks much better now)
This was also my first full driver assembly with a hot air reflow station. It was very challenging because I set the fan too high and all parts flew away 
:person_facepalming:
Biscotti is for 7135 boards - only 7135's, no FET, so just one output channel. DEL's board is a FET+1 so you need to use firmware that supports FET+1 drivers, meaning two output channels.
You should be able to re-program the MCU once mounted. Couple of causes - clips is not making good contact on the 6 pins it needs: Pin #'s 1,4,5,6,7,8, or couple pins have a short, or a pin is shorted to ground. We had discovered if pin #5 is shorted to ground, can't program it then - those finicky Convoy drivers that had Biscotti on them were like that.
Might want to check for shorts, if you didn't already. some times I find shorts from a good macro picture - easier to see in the pic than by eye, even with using a magnifier. A must is great vision, or good light and magnification (I'm old so I use good light and magnification 
).
Dunno bout ethanol, but Isopropyl alcohol is our best friend - use it everywhere, use it by wiping, brushing, etc. Cleans but not caustic to anything pretty much. get the 91% stuff - many drug stores carry it - one 12 or 16 oz. bottle will last years and it's cheap.
Ohhh - must clean the pins with isop. alcohol before clipping. It's a "Must Do" for me - I've had too many issues when I don't. I use a fairly stiff nylon brush, kind that comes with electric shavers for the boards - exc. job in cleaning them up.
For flat open surfaces of boards, wire solder connections, etc., I cut up paper towels in small pieces, then I put the isop. alcohol in a little squeeze bottle, couple of drips on the paper towel, and wipe stuff down. You'll get some paper filaments but if it's getting too much, use the brush. Most of the time I'm using paper towels though - when dirty, throw away - no big deal.
What Tom said 
. Biscotti should give you modes though, it is just treating the FET as if it was a bank of 7135s and ignoring the 7135.
I once had an issue where I had to remove the MCU, clean up the pads and reflow it. But normally there is no issue flashing in place.
19k vs 22k is not a problem. The voltage table / voltage cutoff values should be adjusted in firmware to suit, otherwise it will read a little high.
Are you able to adjust and compile C files? If not, let me know the modes you need and I can prepare a HEX file for you. Will only get to that tonight though.
By default I have 4 solid modes and start either full DD/FET (mode 0) or full 7135 (mode 1, need to double-click from start to get to mode 0 in this case). Mode 2 is 25% 7135 and mode 3 is 1% 7135. Then voltage 10s+1s blink-out, then a few beacons, then back to start mode. Timed and temperature (tiny25+85) step-down for mode 0 and low voltage. Turn-off for low-low voltage. Most parameters adjustable/select-able at compile-time.
DEL - maybe you can help. Was gonna pm you, but might be worth discussing openly. I'm doing battery voltage monitoring, single cell, using the internal ref, not R1/R2. I'm seeing consistent problems though, and not sure if it's related to this method or not.
For a low battery level, I'm using 3.0V to drop output, and 2.8V to cut it off completely. I got couple batteries in the 3.3V and 3.4V range, and after 6 seconds on high amps using the max FET, it's triggering the 3.0V cutoff, dropping output. Same cell, same light if i switch it to blink the voltage, it blinks 3.3V. Sometimes starts at 3.1, then 3.2, then 3.3 settles in.
If I run the same cell at roughly 50% PWM output on the FET, no problem, still runs. If I bring it up to ~75%, it drops out in ~12 seconds.
So, seems like the battery drops voltage, or we measure a lower voltage while it's putting out high amps, triggering LVP prematurely. Or is it prematurely? Is there something wrong goin on here? Do you think it would work the same way with R1/R2 reading? Haven't tried it yet.
Reproduced it on two cells so far - cheap 18650 2200 mAh rated, and a BASEN 26650. Didn't try known good quality cells yet.
More testing to come...
Hi Tom,
That sounds normal to me. Short answer: Cell internal resistance and cell sagging under load.
Long answer:
Lets say a good cell has 30 mohm internal resistance when fresh, maybe 100 mohm when low. A cheap cell can have 2-3x these numbers. There are also the circuit resistances: Springs, vias, pcb tracks. Lets say another 10 mohm for an optimized light. So we have 110 mohm total in the circuit with a good, but low, cell. When you measure a stand-alone cell there is no current flowing, and you do not see the effect of these resistances.
Ohms law: Vdrop = I x R. At low current you do not have much voltage drop and the driver would measure close to what you measure outside of the light. But lets say you still manage 3 A when going DD with a 3.5 V cell. At 3 A you will have a voltage drop of 3 x 0.110 = 0.33 V. And so you only get 3.17 V before D1, and about 2.9 V after D1 (but I think you are correcting for the D1 drop). Switch to a lower mode and the voltage at D1 jumps right back up. All of this ignoring the sagging of the cell, not sure how big this effect is with Li-Ions.
Ballpark numbers I know, but the reality should not be that far off.
Just got one of these into a cheap SRK. Had to sand off all of the ears to fit so not convinced of their utility, but it turned out pretty nice.
Ohhh, ok. So sounds like this effects us all. I don't think any of our open source drivers try to compensate for this? Don't recall seeing it at least. I always thought something like this was going on, so maybe it was discussed, just can't recall when/where. Might try searching or posting in a firmware thread.
Thanks though for the detailed description!!
Would you think it's worth trying to compensate for? Seems like you would have to model what's going on, specific to the light, maybe cell.
Yep, sounds like voltage sag, the voltage will sag more when the cells are almost empty then when they are fresh as well.
If you hook it up to a power supply with a constant voltage you can check the function that way.
TA - glad you saw this. What do you think - is this is a real problem across all our drivers? I haven't really tested for this before - real cells driven hard, comparing to our set low voltage limits. I usually only test with blinking out voltage levels, but that of course is not realistic because the main LED is off.
I've been seeing hints of this behavior for a long time now - once in a while I seem to get a LVP drop in output when the cell is well above the drop setting (3.0V to 3.2V for example).
Edit: Dunno, but I seem to recall something about taking ATD voltage readings with the light OFF, time slicing, but that would make a flcker visible I would think.
Personally it doesn’t bother me and I see no reason to adjust how we do things to compensate for it. And you know I love extra features.
As I see it when the voltage sags down to a point that the cell is reaching the step down point, it is time to step down anyways. The only reason a light would be that low is because you either need every last little bit of runtime you can get or because you are not aware that the batteries are getting low. In either case stepping down is a good thing IMO. It extends runtime in the first and lets you know that the cells are low in the second.
Plus the voltage sag will be reduced after the stepdown and give you a fair amount of runtime before the next one/ Thus giving you a more gentle step down overall and thus more warning before you are out of light. I prefer this to a setup that would maintain full power until the cells are totally empty and then drop down to moon inside 5 minutes with no warning and without giving me the chance to turn the light down manually to extend runtime.
Overall, I think it is working exactly as it should.
EDIT: What TA said
Hi Tom,
Most cases I am not sure it is worth compensating for it? As it is now it is ‘safe’: A light will step down too early in a high mode - As opposed to running the cell down too low in a low mode. Personally I do not mind this, it is a heads-up that ‘hey - your cells are getting low, stick to the low modes if you do not want to end up in the dark’.
But you probably do have a few ‘special’ lights where this can pose a problem .
One option for anything but DD: When we PWM the FET we are alternating between no current and DD current, creating a square wave for the ADC to interpret. The cell no-load voltage is represented by the top of this square wave. We just need to capture this top value reliably, instead of the average value, and use that for LVP.
For full DD, or even close to full DD, this would not work and there would have to be a manual fudge factor for cell impedance, or the cell+circuit impedance calculated and stored (which is easy to do with a DD+1 driver).
Increasing C2 will also tend to keep the top value at Vcc. But again only until we approach full DD.
We are talking about the yellow trace below (a 4P 30Q setup, so low cell impedance and not much of an amplitude on the square wave):
is it possible to take a ADC reading during a particular part / both parts of the PWM? I actually was curious about this for another idea I have had floating around my head.
I did some research and it looked like the adc could technically read just barely fast enough to do this, the question is, would it work in the real world?
IIRC the fastest reliable ADC readings were around 50ns (microseconds? whatever is below milliseconds).
Yea, I had the same thoughts myself - it's not totally bad, stepping down in small steps is the best way to go because the cell recovers. But the "German" in me says there's something wrong with this, too imprecise, too dependent on other factors like the internal resistance of the cell, components, springs, wiring, etc.. Just don't think there's any practical way of doing it better.
Sure you could take amps/cell into account. Guess a really bad case would be using an older single Pana 18650(A or B) cell (or China cheap one) in a BLF Q8 at high amps. Wonder how much voltage sag there really would be.
The ADC supposedly can run up to 200 kHz with decent accuracy, but not sure how we can synchronize with the PWM.
Depending on what you want to do, that might not be necessary though. You just need to sample at more than twice the PWM frequency to avoid aliasing.
Should have used a real camera, but anyway…
Step 1: Paste it up
Step 2: Pick and place
Step 3: Flow it
Step 4: Enjoy. These are are the ‘new generation’ SRKs. Same old crappy mcpcb and LEDS, but decent machining and fit.
DEL, those look really nice!
Nice work DEL on those boards!
Little more about the LVP issue, I'm seeing 0.3V to as much as 0.4V voltage sag, so if I use 3.2V as the low level, and 3.0V as the critical level as is now in Narsil v1.3, then as high as 3.6V, LVP will start kicking in. This wouldn't work out very well. I'll have to stick with lower thresholds.
Looks like TK currently uses 3.0V and 2.7V right now. I thought I read a post from her though saying these thresholds were too low from some protected cells - the protection circuit gets tripped on some relatively high.
At a minimum, I'll have to change Narsil to again lower the threshold to account for this sag.