17mm & 20/26/27mm single-sided DD/FET driver release: A17DD-SO8 / A20DD-SO8 / etc

Works like a charm! Thanks

https://oshpark.com/shared_projects/OODIn7Cf

Can somebody confirm this as a working zener-layout? (no workaround)

Does anyone happen to know what could be causing one of these drivers to change modes on its own?

I made 50 of these last batch and they all work fine normally. I had even used one of them with an eswitch in the past and it was fine. However recently I tried using JohnnyCs dual switch firmware with them and this is what I get.
https://youtu.be/vw5rxIBh7_M

It will just sit there and skip upward in modes at random on its own. I tried multiple drivers and even assembled a brand new one and the result is exactly the same. I tried both 6 and 12v configs too with no luck.

I tried using the default firmware from JC and TomEs eswitch one and they both skipped. I had used toms before too and did not have this issue so the only thing I can think is that I was shipped a bad batch of components. Problem is I have no idea which part could cause this :(


Any one got an idea?

Hhmm. I watched the video 3X, not sure wut could be goin on. It seems very periodic and relatively slow, I think... What kind of setup to you have there? Think I saw 4 cells in series, so 16V going into the driver? Wow... With an e-switch, I assume you are using an LDO?

The pace seems like LVP is kicking in, but it's going up not down... But if it's acting like a click is happening, I suspect something unreliable bout the switch input, but you are grounding it manually. Dunno, I'm no expert there in electronics. Maybe the voltage the MCUU is getting? If so, maybe the LDO that supposed to regulate that voltage? Again, I'm not sure exactly how an LDO works, but it's supposed to deliver the correct voltage to the MCU. Maybe you can check that voltage level on the MCU VCC pin #8?

Is this still the preferred parts list for a 1S V044 board?

http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=48a3801cb6

Thanks Matt

I've almost always only seen that happen when the driver is glitching due to a dirty VCC signal. How is your circuit set up?



By dirty VCC you mean like a trace that is too close to something else? By circuit setup you just mean a picture of the underlying traces right? If so I will try to do that tomorrow.


I also have one other pressing question if you don't mind.


I have tried to use firmware that has a strobe function with these drivers, and on both the 1 and 2 cell board the strobe and SOS sequences are very very slow. I have tried 2 different firmware's which I know to be good with 7135 boards and the result is the same.

Any idea why that might be?

When you're pulling high amps with an FET you can make the MCU glitch if the layout and components aren't just right.

About the SOS speed: there is no reason why the speed would be different on an FET driver than it would be on any other driver with the same MCU. Are you sure that you're flashing the same file and fuses?

Ya the firmware is the same and I tried it on like 5 boards. I know for sure the code is good to, its my Sport UI from DrJones.

I may pick up a few boards from you and try installing my components on that and see what happens. If all my problems go away then we will know where to look for the trouble.

I have been wondering if some drivers are too sensitive to RFI — it’s hard to test.
And with WiFi there’s plenty of radio noise around.

With the lens opening and wires from LED exposed there that could act like short little antennas, could electronic smog be a problem?

I’ve taken some dubious lights (LDCH-20 and LDCH-30 drivers with 1xNiMH) on long walks to see if their behavior jumping modes was any different.
Couldn’t really tell.

I suppose I could put them in a Faraday cage ….

I did not get an answer a few posts back and want to make sure before I order…

Is this still the preferred parts list for a 1S V044 board?

http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=48a3801cb6

Thanks Matt

preferred? No.

compatible? Yes.

I recommend switching the 22k resistor to a 19.1k version. Other than that, most people have their own preferred FET model they think is best.

I will need to run thru LVP setting in the firmware for that change?

I always recommend configuring LVP to each driver, but usually LVP is configured around 19.1k lately.

If you are able to flash firmware I would highly recommend flashing the Batt check firmware first. I’ve always had issues with it stepping down way too early or some odd behavior if I neglect to do so. This will give you the right LVP values.

Yes, the battcheck thing is highly recommended if you want it to respond correctly to low voltage or if you want it to have a working battcheck mode.

Flash battcheck onto the driver, measure a near-empty cell, measure a near-full cell, save the values to a file, run a script on that file, and plug the values into your target firmware. Then build and flash the target firmware.

For example, I measured my Convoy S7 at 4.09V at 3.15V. The ADC values were 179 and 136, respectively. So I saved those to a file:

readings/tk-s7.volts contains two lines:
179 - 4.09V
136 - 3.15V

Then I can run a script to calculate the ADC values it should see at various voltages:

(~/src/torches/trunk/ToyKeeper/battcheck/)-]> ./battcheck.py readings/tk-s7.volts 
#define ADC_44     193
#define ADC_43     189
#define ADC_42     184
...
#define ADC_22     93
#define ADC_21     88
#define ADC_20     83

You may need to change the format, depending on which firmware you’re using… but it should include usable values for everything from 2.0V to 4.4V.



Can you clarify what fuses are? Are they something that would be coming along with any of the open source trunk firmwares and are unique to each firmware, or are they something that is set inside AVR that is used for every file?

0xFF 0x75 are the standard fuses for most attiny13a firmware, including the dual switch firmware you've mentioned. I don't think it's the fuses.



I dont think it is either. I am starting to lean toward it being the layout on my board. I ordered some of yours and some of your components so I can try and pin down the problem.

I dug out a board I had of yours from a long time ago and it was still populated with mostly your components ( accept for some I had robbed) and it eliminated the slow strobe I was getting.

I needed a working driver with strobe asap so I did no other testing yet.


Ok, I am making some progress now.

I do think a dirty trace is part of my problem. Starting with the dual switch firmware.
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/JonnyC/STAR/STAR_dual_switch/STAR_dual_switch.c


Your board with my components does much better. I still get skips or auto changes but it cut it by about 90% on the 2 cell board. ( even mine worked fine with the 1 cell setup)

Using your boards and your components reduced this further ( another 5 % or so), but i could still get it to change modes on occasion just by touching the end of the switch + wire with my fingers.


What I am wandering now is this. Do you think that I might be able to reduce that over sensitivity by changing the firmware a little? I see that there is a place where the amount of time considered to be a "long" press can be changed. How about if I changed what is considered a "short" press or a click to be a few milliseconds longer?

Do you know which line of code would need to be modified to do this?

EIDT: Also is there a rampdown function for the turbo timer on this one, I did not see anything to set it?