I find it really helpful to have a couple alligator clips which lead to wire with exposed ends, so I can clip one to the ground ring and one to the spring and then hold the wires onto a battery for testing. Or hold them onto the battery and tap the clip against the body to test after putting the pill in. Or a variety of other methods, testing at each step like Tom E suggested. It really helps with determining what failed.
I’ve had some which fail after putting the reflector in, which is fixed by putting kapton tape on the back of the reflector. Yesterday I had one where the front half of the light worked but it failed after attaching the back. It turns out that one was a bad switch.
Last working configuration was with LED’s soldered to MCPCB, MCPCB soldered directly to the pill, lead wires soldered to MCPCB and driver, driver soldered into pill. But I didn’t test “extensively” after soldering the driver in place before assembling, so if it’s something that takes a bit of time to become damaged it’s possible it just hadn’t happened yet, but could have if I tested longer before assembly. My gut is telling me that something bad is happening in assembly when the carclo optic seats. The only reason I’m not more confident is that all 3 LED’s light and appear equally bright.
Could check the LED wires for signs of cuts at the openings - it's happened to me before. The silicone wires will get cuts thru the insulation pretty easy, and results can be intermittent, frustrating... Dunno - that might be a long shot. Hard to imagine scenarios where the Carlco lens might be causing a short. With the MCPCB soldered down, no chance of twisting. Could be some short relating to something on the edge, against the host body, again, long shot. Weird it happened with two drivers...
I actually trimmed them back when I reassembled with the second driver to make sure this wasn’t happening. When my son goes down for a nap this afternoon I think I’m going to replace all 3 LED’s and see if the second driver starts working(assuming it checks out ok after I remove it from the pill, if not I’ll try another one). If not I’ll be starting completely over with a new MCPCB, LED’s, wires, and driver all at the same time.
Not going to make anything on this build. Oh well, the risk of living on the edge.
That really is frustrating. I feel your pain. I've been doing this for a while and I still get crap like this that I can't figure out. I think that it happens to all of us, even if we don't post about it all the time!
I've built the driver today, but I'm having trouble getting modes to work. It's stuck on full output.
I have tried pull-up resistors from 10k - 220k between the Source & Gate of the P Fet.
I also tried a 100 ohm pull down resistor on the big N Fet, between Gate & Ground.
I'm wondering if I have something wrong in the firmware;
When you say to invert the PWM values, do you just mean that Highest mode is "0" & Lowest (off) is "255" , or is there something else I need to change in the firmware as well?
If I understand correctly, PWM=0 would be the highest mode, and PWM=255 would be off. Anything between would be, well, between.
If it’s stuck on maximum, is there a short somewhere?
Or perhaps is it always resetting to the first mode, unable to sense how long it was off? You might want to try an on-time based firmware to rule out that possibility.
I removed the P Fet (taking the driver back to a regular Zener-modded driver)to check operation, & it tested OK with mode levels(albeit reversed, now).
...But on further reading, I think what Richard is saying, is that the actual signal from the Attiny needs to be inverted.
I came across this info, but I'm not sure how/where to add it into the firmware.
Specifically, the following is what I believe needs to be changed;
---------------------
COM – Compare Output Mode
These bits are used to set the Output mode in various Wave form generation mode. For Fast PWM mode these can be used to achieve following output modes.
COM01
COM00
Output Mode
0
0
Normal Port Operation (OC0 disconnected)
1
0
RESERVED
0
1
Non Inverted PWM
1
1
Inverted PWM
-----------------
So I need to put a command in there to set COM01 & COM00 to 1,1.
...I think... :~
- edit -
The info I linked above appears to relate to the ATmega16 or ATmega32, but I basically need to do the equivalent to the 13a.
I would maybe take the attiny off and try some manual switching first with it powered up to make sure that it will indeed work. If you need a pullup resistor 30K-100K should work fine.
From the attiny13a datasheet:
In fast PWM mode, the compare unit allows generation of PWM waveforms on the OC0x pins. Setting the COM0x[1:0] bits to two will produce a non-inverted PWM and an inverted PWM out- put can be generated by setting the COM0x[1:0] to three
What did you do exactly? Did you use the driver like in the schematic with two cells in series(8V)? I am asking because I don’t see a voltage reducing element like the Zener diode in the schematics and so you would grill the tiny.
——
Jist some info you maybe have missed:
standard firmware enables a pull down resistor for the output so that always if there is no high output the FETgate will be pulled down to GND to stop current from flowing.
The pfet will be standardized let current flow with the standard firmware in 0 mode because it gets connected to GND with the internal resistor.
On a mode 255 it should be pull the pgate to VcC so it should stop driving the nfet gate high but then you need a pulldown(additional hardware resistor(that what the the software pulldown is on standard drivers))
Whatever was happening with the S6 I was putting together was burning up the MCU. I put a new one in the last driver I built and modes started working again. I’ve got a brand new triple XP-L dedoming, I’m hoping that this will be the last assembly.
I'm getting nowhere trying to make this dual Fet combo work.
When I removed the 13A from the board & powered it up (hooked up to a test XHP70) it defaulted to full on. The only way I could get it to shut off was to pull the NFet gate to ground.
I tried a few combinations of resistors on the Fet gates, but couldn't get a result that put the Fets in an 'off' position permanently.
I was starting to look at other driver ideas, as I'm wasting too much time with this, when I realized that in one of OL's recent builds, he was using an SRK driver to power 3 XHP70's;
How is the SRK driver different from the 17/20mm FET drivers, & what makes it work in this situation, where the 17/20mm variants won't?
I guess I asked the wrong question back in post#267; I was thinking that the NFet on the 17/20DD boards would not be able to power four XHP70's, which is why I asked about driving multiple Fets from the Attiny.
It was only when I started looking around for other driver options yesterday, that I saw that Justin had used an SRK Fet driver in his Triple XHP build (same components as the 17/20mm Fet drivers).
...So I'll go back to 'plan A' & just use a regular, Zener (or maybe LDO) modded Fet driver.
Thanks to the folks who have tried to help me out with the dual Fet idea, but I'm certainly not the guy to pull it off.
At least I have learned a little more about the circuits we are using here on the BLF DD drivers. :beer:
The triple XP-L S6 lives. Just goes to show, throw enough parts at a build and you can get it done even with problems. It measured over 3000 lumens at startup and about 2950 at 30 seconds. Modes work perfectly again after changing the MCU and using the new MCPCB and LED’s.
