I use 0603 exclusively in my drivers as I want to utilize the space as much as I can. I also bend pins on the MCU, put the MCU where the spring usually is (for space and easy access to flash the light without full disassemble) and cut of the tabs of the 7135s to make them shorter (custom Eagle library part). One of my drivers where I’ve done this: Mod: My take on the convoy S series with side switch mod.
I did a design with 0402 sized components but they where to annoyingly small for me to work with, so I’m sticking with 0603.
Has anyone built this driver with a second stacked 7135? Adjusted the modes to use the pair of 7135’s for more modes of non-FET power? (more efficiency)
Not physically stacked that I am aware of but with more 7135's. The single 7135 was basically a method to achieve a regulated "Lo" that many complained was either "to the moon Hi" or a "subterranean Lo".
Wight and PilotDog68 both have drivers with more than one 7135
I dunno. With 4 or 5 nice well spaced modes, only 1 mode (32%-40%) uses PWM's on the FET typically. The lowest 3 including moon use the single 7135. One full 7135 mode does like 120-170 lumens roughly with a good NW or CW LED, good AR lens, so that's like 10% typically.
4-5 modes are my favorite settings. Adding another 7135 has no advantage that I can see for a 4-5 mode set.
Am I missing it, but is a FET+1 OSHPark driver available anywhere, from anybody in 20 mm size? Anyone have an interest in making one if it's not around?
I really miss this wight FET+1 driver in a 20 mm size...
Oh thanks PD68! I just looked at my OSHPark order history - did order these boards back on Nov 7th(silly me ).... I ordered 22's, 20's, and 17's. K, I know I need the 20's for a couple of projects, gotta get organized better..
One of these drivers, loaded with the BLF A6 firmware, acts like it has next mode memory. Anytime I cut power, it moves forward. Does not appears to be related to time spent off.
So, in moon mode, click off for 10 seconds. Turn on, it is in mode 2. Click it off for a few minutes, click on, mode 3.
etc………
Suggestions on what to change? I have a stack of these that work. This one I reflashed, and replaced the OTC.
I have the same problem in one of my drivers. I think I need to run offtime-cap on his driver and adjust the settings in the firmware. Hopefully this solves the problem.
Usually that indicates a hardware problem, but the offtime-cap.hex firmware can at least help diagnose things.
I measure the OTC a few times at 0.5s, 1.0s, 1.5s, 2.0s, and 3.0s. This provides a good estimate of the discharge curve, and the values can be plugged into code to select whatever timing you like. Here’s a graph of three different drivers measured this way:
The blue line is close to ideal.
Of course, if you get 255 every time, the OTC isn’t working at all.
I didn’t read all 286 posts… but perhaps this can be useful:
The stencil for Attiny:
actually, when I was starting with attiny85 I learned that the legs can very easily be bent downwards, it takes probably less than 1 minute
That means that the actual footprint for the attiny13/attiny85 can be smaller than official contact pads spread - if you bend the legs downward - the contact pads can almost all be under the MCU itself, not extending so wide around it.
If you test with TK’s firmware and find that it’s simply discharging extremely slowly for some reason you could add a pulldown resistor from the MCU (ATtiny) side of the OTC to GND. High value, maybe 100k or something (I don’t know).