Musings on the FET+1 and lighted tailcap.

Flashlight Modding and DIY Parts
21

I really tried but I don’t even know if my thoughts are making sense so I let it go for now. Maybe I can re-read again a few times later to make more sense of it.

Thank you sharpie for bringing attention to the matter, I don’t know why others are spamming what could be a very informative thread where new improvements could be made with drama when they have nothing to contribute nor do they attempt to understand the context of the subject matter. (wight excluded as I don’t see his posts as derrogative meaningless spam, but possibly a lack of communication via impersonal internet pixels) It really just puts a bind on a guys like me flipping back and forth sifting through their trash to find the information I need.

I am looking to keep it simple, so I will order a couple old revision 2 led 2 resistor pcb’s in hopes that I might someday actually do something useful, that works properly.

I’m so out of my league here. I have to try, rather fail than give up.

Your saying that I (we) need to know the resistance in the tailcap (overall regaurdless of led selection and quantity) to know what value resistors will need used in place of R1/R2 |OR| which value 1/8W resistor needs jumped from positive spring to ground ring on the battery side?

I have tried a few different resistors on the spring side, lately I have been stacking on C1 but either way it is the same deal with mode switching when hot, so I think swapping R1/R2 would be the ideal way to go about it.

So if I was to change resistor values for R1 and R2 it could potentially bleed enough current to match the needs of the tailcap leds, and at the same time work as a voltage divider for the MCU?

What I am thinking you are saying is that we need to bleed off, as close as possible, the same amount of current that the leds need to stay lit, so the power is being used and not backfed into the caps/mcu causing malfunctions?

Let’s say I am using these leds:
http://www.digikey.com/product-detail/en/150080BS75000/732-4982-1-ND

With a Vf of 3.2V, > and looking to run these leds at .08 mA < subjective, rated 145mcd@20mA.

12,500 ohms total

I am lost.

MattLward
“Oh, I like where this discussion is going. I have been going back and studying basic electronics, have not had to since university in about 1985. I like the PFET idea, but I am not sure there will be enough room on a 17mm driver. Please continue to explore away.”

There is a couple MM height in most pills we could take advantage of. If there is room for traces on the board it could be possible to eliminate the heat tab trace since it’s already connected through pins, and stack a pFET 180* on top of another component bending the legs, you’d have to use a to-220 package or something with legs.

22

Zoom, Sharpie seems like a pretty sharp guy, I’ve said as much in several threads. I think we all appreciate his input.

That being said, I can’t imagine I’m the only one who finds his tone unpleasant.

I look forward to the driver Sharpie designs, and I mean that. In the meantime I hope he cools his jets just a bit so we can have a discussion that doesn’t involve derisive and condescending comments.

23

sixty545 have already done that and mentioned in #178 How To Build a Flashlight With Perfect Modes (picture heavy)

24

I do think that a simple RC network would give much more control over the discharge of the OTC, now it is possible that discharge issues due to lack of direct grounding could be part of the issue. When I first started building and looking at drivers I assumed there was a direct ground path, did not even look at that for quite a while. However, there does seem to be a strong heat component. I have a very hard FET driven triple that is in a tiny package with a large copper heatsink, that light will work perfectly when disassembled and all parts connected with largish gauge wire. But, when assembled and driven at full power and allowed to heat up for 45 seconds or so the OTC completely stops acting as it should. The head of the light gets very hot, not to hot to touch but uncomfortable and I would suspect if not stepped down it would cause damage to the LED or the driver within 3 or 4 minutes.

Please keep this thought train going, maybe we will get a good re-design and a next generation driver out of the process.

Matt

25

I’m one of those that just creates the PCB in Eagle without a circuit diagram. A circuit diagram does nothing for me. I can understand how it all connects much better by looking at traces and components on a board. I believe wight uses a circuit diagram in Eagle, but may have not published it. It’s really a common circuit that can be found in many forms all over the forum however.

If you want to do prototyping on a breadboard, that’s great! It allows faster progress than waiting for Oshpark to deliver a bunch of times. However, keep in mind if the solution doesn’t fit on a 17mm circle in the end, it doesn’t really solve the problem.

26

Nice ideas, maybe you should have made some points on actual connections of the schematic…its painted correct and I can easyly follow it but only because I knew how it is before.

I don’t see any problems with the minimalistic design we have. I have dozens of Fet drivers like others and they work very stable.
I don’t see the advantages of the pfet in this application.
If you want to make something switchable with a Fet than I would prefer switching of the bleeder when the light is switched on.:wink: so freeing up a pin sounds good:)
I even used higher values for r1 and r2 to reduce standby current in momentary switch lights…

The only real “problem” I see besides the low bleeder is the “heating Otc cap problem”
With measuring temperature in the newer drivers the heating problem could maybe handled via software.
As for the minimum count part if additional parts make real improvements there would be room on the underside of the driver. In former times most drivers had components on the underside, just since wight did his magic with squeezing all the parts on the top we have the luxury of the one sided super driver.

27

Hmm that’s very interesting

28

Well, I personally already use the underside of the driver.

29

If you look at the two drivers in my sig line, I upload a screenshot of the pcb in Eagle. I find those very easy to follow with the low part count on our drivers.

30

That’s basically how your OP diagram would look to me if I didn’t already have the circuit memorized. The 5ohm decoy resistor is my favorite part.

31

out here, there be dragons.
post with extreme caution

AAAHHHHH ! You burned my face off !!

32

First off, no, I can’t contribute anything helpful, it’s over my head.

But I’d be interested to read what you found out about the OTC.

33

That’s one way to become famous.

34

I just found this thread and am trying to catch up on what’s in it… I keep running into a distraction though.

Regardless of the intent, it seems commonly perceived that Sharpie’s communication style is … abrasive, to put it mildly. I mean, I pretend to be a literal goddess, and even I find it condescending.

Sharpie, is there any chance you might be willing to tone that down a bit? It would be much easier to focus on the on-topic technical issues without all the salt being tossed around.

35

Or, to say the same thing more light-heartedly…

That’s very interesting, but this forum consists mostly of humans. I know, I know, it’s weird for me too. But I find it’s much easier to get things done when I try to speak their language.




36

pretending to be a goddess !!! I think not !!!
then who did the magic OTC ???

This is just one flashlight user’s opinion, but I think sharpie is pretty cool.
I think sharpie is Spock with a Glock.
Well…. you know what I mean.

37

I think Sharpie was trying to get the thread back on track (in perhaps an amusingly robotic way).

I think it’s safe at this point to move on and stick to the point of the thread.

This is a flashlight forum after all… :slight_smile:

38

OMG, that idea is amazing. Is that possible? That could totally fix the high-moon-power issue…

I’ll have to find the post with details, but Mike C freed up a couple pins by combining voltage with e-switch and OTC. It was a bit touchy … but it worked. We might be able to do something similar. OTOH, a FET+1 with clicky switch still has one pin unused.

It’s theoretically possible to work around OTC heat issues in software, but I expect it to be complicated and fragile, requiring much more tricky (and dynamic) calibrations than anything BLF has used so far. And the problem is extremely hardware-dependent — Manker’s drivers have much worse heat symptoms than RMM’s drivers do, even though they have the same logical design. RMM just makes them better (much better).

I tried to use software to work around FET-only moon modes sagging at low voltages, a somewhat similar issue. And it kind of worked, but… it was far more effective to use a different hardware design instead (FET+1).

The OTC drain behavior is a hardware issue, and it’s probably best addressed in hardware.

39

Oyster?

Man most of this thread is over my head. I’m having fun trying to figure it out though, carry on….

40

Good work so far, I think. Don’t forget to look at the ATtiny13A datasheet when considering this stuff. Mostly the ATtiny85 seems to extend the feature set, so for example the ATtiny13A does not feature a 2.56v internal ref, only the 1.1v one. Note that it’s also worthwhile to mention what product’s datasheet you are referring to: you mentioned a paragraph and revision but not the product. I was genuinely lost for a minute.

Let’s “dumb this down” a little so that other folks can participate a little easier - and I can make sure that I’m on the same page. ;) Sharpie has spent some time on the issue and located the best available information in the datasheet telling us what we already knew (including Sharpie) the OTC is draining through the un-powered MCU at an undefined rate. This is undesireable, we wish to drain the OTC at a defined rate so that we can time it consistently. Here is a boiled down version of what I think Sharpie has come up with:

  1. Place a blocking diode between the “OTC pin” on the ATtiny and the the OTC. This prevents current from flowing back through the MCU while the circuit is powered off. The result is that (a) the OTC does not drain through the ATtiny or anything else (b) we cannot measure the OTC using the ATtiny because the diode blocks that too!
  2. Place a high-value resistor between the OTC and the ATtiny (call it Rmon). Now the OTC can be measured but the drain path for the OTC is now OTC~~Resistor~~>ATtiny, exactly what we were trying to avoid!
  3. Place a drain / pulldown resistor in parallel to the OTC (call it Rotc). Use a high ratio so that (in Sharpie’s example) Rotc = 1/10 of Rmon. This way most of our current should flow through Rotc (the drain resistor), allowing us to better control the rate at which the OTC is drained.

I think that this is good progress and the lowest possible parts count a worthwhile OTC improvement can have.

The biggest hangup here seems to be our Iil and Iih range during measurement. At 1uA across 1Mohm we are talking about a drop of 1v, but at 0.05uA across 1Mohm we are talking about 0.05v. That seems like a potentially big deal to me. In fact, if we look at section 17.8 in the 08/2013 ATtiny85 datasheet we see it mention that “The ADC is optimized for analog signals with an output impedance of approximately 10 k-ohm or less”. We’d be way out in left field compared to that. Any thoughts on this?