BTU Shocker Triple MT-G2 with a twist -- Aiming for >100Watt ~9000Lumens -- With external 2S power pack, handle etc...

I’m not surprised that it didn’t fix the performance problem, but I am surprised that it appeared to fix the flicker issue. JonnyC checked w/ a scope to be sure that there 255 gave a full duty cycle (no off time). I think JonnyC mentioned using a really basic scope so maybe it was a DSO Nano or something, it’s possible that it just wasn’t fast enough. I’ll get around to checking with my scope. :frowning:

For now I say pickup a 5.0v LDO. Those should be much cheaper and more plentiful than 5.5v ones. 3.3v and 5.0v are both standard voltages used in the electronics industry. The normal ones we use are SOT23-5, which is too small for most stripboard but you can probably make do by chopping up the stripboard/copperclad with an X-ACTO knive. Or maybe find a larger package to work with for testing. You can also just use the LDO section of this board, but I doubt that you want to wait for OSH Park. - 17mm++ single-sided / DD driver w/ low parasitic drain for e-switch lights: AxxDD-SO8+LDO

I suspect there might be a difference between PWM behaviour in optimal conditions with a light load vs when the MCU get’s loaded down and is running at higher temperatures.

I quickly scanned through the Atmel Attiny13A datasheet again, specifically the high temperature amendments and the output current supply stuff at 5v. I couldn’t really find anything that showed a potential problem when matched with my operating conditions. Certainly it seems to deliver a measurably lower output voltage and current as the temperatures goes above 100degrees but if the 48x 7135s really only draw a combined current of 9.6mA (using the max datsheet iQ values of 200uA @ 100degs ) then none of it is anywhere close to hitting the limit even under extreme conditions. I could be reading it all incorrectly though, and only studied the more understandable graphs, 80% of that document makes my head spin… :frowning:

Or maybe the 7135s draw a lot more current than the datasheet implies?…too many maybes at the moment.

-

Next up I’ll swap over the Attiny for a new one, just to eliminate any chance that it’s down to a bad or damaged unit.

And then with the new Multimeter I’ll tap into the clicky circuit and measure how much current the whole driver draws. Maybe that will give us a clue as to what is going on in there.

I was also contemplating whether I had a bad connection or high resistance somewhere on the clicky circuit resulting in a lower than expect input voltage at the MCU. But that all checks out well with my crappy DMMs.

-

Thanks for the tip, I ended up finding a 5v sot-89 LDO capable of 200ma. Should fit nicely on the empty 7135 slots on my MCU board. Just need to scrape up some old traces and wire a couple new ones.

I think it’s reasonable not to trust the datasheet for these heavily cloned devices.

Good thinking.

I’m not sooo surprised that the flickering didn’t appear as before. With PWM 255 there is some “switching” going on somewhere, and heat may well affect it. Scope measurements under optimal conditions might not apply to a light like this run for two minutes.

Anyway, thanks for testing the constant on firmware, it’s helpful for me too.

I can’t be 100% that the flickering was completely gone, but it certainly didn’t draw attention to itself as much as before.
Strongest flicker was noted when doing the 5.6v MCU test, no sure what that means but the behaviour tends to be pretty consistent between runs.

Well guys, seems the little 5v LDO has really done the trick.

I slapped it onto the MCU board replacing the 5.6v zener and resistor. Hooked up my new DMM to the trigger circuit to measure driver current and ran a test (still using Mike’s firmware with output pin set to High i.e no PWM). The results where perfectly regulated output current at 8.3v iCharger voltage, just like the MCU-less runs!! :bigsmile: :party:


(Here’s the little fella on the board… I’m struggling to still call sot-89 parts little at this stage :P)

Of course I’m a plank and forgot to turn off the cooling fan before starting the test. So I’m setting it up again now and flashing my normal firmware back to the MCU to get some like for like data. Fingers crossed it works as well with the PWM back on.
But I can tell you for sure that the influence of the fan did not make this much of a difference to the drive current. It’s a bang on a perfect match to the MCU less test, flat and steady. :slight_smile:

-

Also interesting are the driver current draw results.

The driver drew 23.9ma at the start of the test and that rose to 24.89ma by the end of the 6mins. Which doesn’t seem all that high to me but I guess it could be quite a bit higher than what the Zener mod 200ohm resistor is intended for. I calculate there to be a voltage drop of 4.975v across that 200ohm resistor with this current draw!
So that doesn’t seem to leave much of an input voltage for the MCU to power itself and all those 7135s. I suspect that could be part of the problem, but let me know what you guys think.
It’s still not a clear red flag but I’d have to check the Attiny datasheet at an input voltage closer to 3v to see where it starts to struggle.

Please correct me if my weak understanding of how the Zener mod works is tripping me up here.
Resistor drops the voltage to the MCU based on it’s current draw, and the Zener is like a safety blow off valve which bleeds off unsafe voltage spikes should the current drop too low at the MCU. Is that right?

If that’s how it works and the higher voltage drop is the cause of the problems I don’t however know why swapping the 4.3v zener for a 5.6v one made any difference at all… :~

-

In any case this is really looking good with the little LDO, i’ll post up a graph with the proper test in a bit.

Yup, standard firmware with PWM (phase correct) works just as good! :slight_smile:

Awesome, really pleased with this. Looks like this is the solution finally!

Here’s the graph compared with the other MCU tests I ran, I’ll save myself the bother of pointing out the differences, they’re not exactly subtle… haha :wink:

-

Interestingly the driver looked to be drawing a little less current when operating under PWM (phase correct) compared with the constant on firmware.
Although that could be margin of error stuff between the two tests.

Here is the driver (mcu) current plotted against heatsink temperature.

Amazing effort and loved the team work. I see the lines going up and just think of temperature rising.

This sounds great!

23.9mA total sounds a little high to me. The MCU and LDO shouldn’t be eating up 3.9mA I think (I could be wrong, I’m not going to go check right now. They’d be close at least.). The Absolute Maximum Rating per pin is 40.0 mA, and we’re far away from that. 20 mA is the normal rating though, and you’re probably sitting right on that mark. Adding additional 7135’s beyond what you have now is probably not a good thing to do. That’s all I’m really getting at, just thought I’d bring it up while we’re on the subject.

Your understanding of the Zener setup is a little flawed I think. That’s OK, I have trouble with it too. The Zener will dump all excess voltage beyond it’s rated (reverse) voltage. The problem is that the Zener is practically an electrical short for all that energy, there’s no limit. So we add a resistor of the appropriate value to limit the amount of current which flows. Note that the Zener we use is only rated to dissipate 500mW (0.5W).

I am actually not familiar with all the considerations that are made when choosing a load resistor the correct way. Here is a resource with some text on the matter: Zener Regulators

OTOH, here are a couple of calculators with no writeups:

http://www.rcrowley.com/zenerreg.htm

They all seem to agree that a 48 ohm resistor is required if a person plans to operate a 4.3v Zener with an input voltage as low as 6.0v and providing 25mA. Or around ~110 ohms would be required at 8.4v. No wonder the thing didn’t work. … that said, I’m not a huge fan of the Zener and I’m happy to see you move away from it to something a bit easier for us to understand.

The calculators show that about half the energy is dissipated in each component (Zener / limiting resistor).

Yep really appreciate the help all round, couldn’t have worked through this without some great comments from you guys.
Oh and pah! With the drivers working properly this thing “barely” gets warm in general use, needs more AMPS! :wink:

-

Yeah and that would mean the 7135s are drawing close to double what the datasheet claims. Good to know :slight_smile:

I knew I had only half the story when it came to that Zener. Thanks for those links, I see there’s a little more to it than I thought.
I think I remember seeing someone use a 100ohm resistor instead of the 200, quite possibly a smart person who knew what to look out for and did the calcs before running higher loads. :stuck_out_tongue:

So now that we’ve swapped two components for a little black box of mysteries that poops out 5v.
All works great…except my Offtime memory timing is WAY out, it takes like 30seconds+ to store the last mode. Need to tweak that, hopefully I can simply tweak it far enough in firmware and not have to resort to a smaller cap.
And I’m not even going to hazard a guess as to why this is suddenly the case :stuck_out_tongue:

Err, now that you mention it… what are you doing as far as capacitors? Are you following the guidelines in your LDO’s datasheet for input and output caps? Otherwise you may get unpleasant surprises when you attach this thing to a battery instead of your PSU.

It’s been running on the batteries a fair bit now without catching fire… :stuck_out_tongue:

It does suggest using 1uF tantalum caps on input and output. I didn’t bother with them, could that be causing the memory weirdness?

Torex LDO 5v

Interesting: sure enough, those caps are “suggested”… typically the datasheet demands at least 1uF on the input side.

I do not think that the lack of caps is causing the memory weirdness. (I’d say it’s the lack of easy paths to GND from MCU Vcc.)

Still, it can’t hurt to install those caps. This encourages me to scope an LDO such as LT1761 with 1uF on the input and nothing on the output feeding an ATtiny13A (and whatever) and see what the performance is. Maybe it won’t be that bad.

Done and done. :slight_smile:

Obviously can’t check to see if it’s actually working better but for what it’s worth it still works great! Now to tweak that memory timeout, and then…BEAMSHOTS! :slight_smile:

Here’s the lineup ready to do battle. Don’t have many big lights to compare against but the comparison to the 16Amp Apex 5t6 (NW) should give some idea of the flood performance.

Of course I also need to run another test with the batteries instead of the charger and see how it does, that should be interesting.

Hanging for this battle since the start of your build and very excited to see the results

Just for the record… (especially since it worked anyway) I’m told that those caps should be very close to the components they decouple. Without a scope on it I have no idea whether they were even needed in the first place. (eg I have no horse in this race.)

FWIW on the offtime memory thing I’ve been meaning to write a post about it, but I recently had to crank the value to 240 in order to get what I thought was a reasonable offtime period. I started at 145 and got something like 3s, then 200 and that was still no good, and 240 is acceptable.

You know, I’m probably going to finally get my scope in the mail when all of this is working and done, then won’t have a need for it again for like a year, urgh… :stuck_out_tongue:

I assume 255 is the limit on the timer there just like the turbo timeout?
I’m a bit worried about that since it takes SO long to store right now, it’s basically next mode memory unless I set it aside for like 30s to a minute. Will see how far I can adjust it.
Otherwise I suppose I could parallel a resistor across the capacitor to drain it quicker or find a smaller cap?

I haven’t tried, but I think the difference with a smaller cap will not be very large. The parallel resistor is probably the way to go. 255 is the limit. The trick here is that we charge the cap to MCU Vcc, then we discharge it for a while (off time), then we compare cap voltage vs 1.1v (internal Vref).

Happy to see the results! Good work indeed. If I understand correctly, you are currently using the LDO to feed the MCU instead of a zener and resistor? You’re not using the MCU to trigger the LDO as a “gate opener” for the 7135s?

All though I like LDO solution (if I understood it correctly), using a lower valued load resistor for the zener could have solved the issue?

Yes the LDO supplies regulated 5v power to the MCU. The Attiny13A is still the only thing supplying power to the 7135s.
I was actually just going to use the LDO to provide a more understandable power source for testing the transistor but it solved the problem directly.

And yes, I believe as Wight said using a resistor with the recommended value based on the required current draw would have worked just as well. Haven’t tested that though since I also prefer the LDO approach to the zener.

-

I’d be very interested if you could do a similar kind of test on your M6, see if there is a noticeable difference in the output current behaviour between the standard zener approach and a 5v LDO. Or just by using the correct value load resistor along with the zener. I’m assuming you used a standard 200ohm resistor as well on your driver?

If you don’t have a current meter that can go to 18A you could just measure voltage drop with your DMM across a current shunt and calculate it that way.

Cheers