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

Vbatt was 7.7v, 5.6v zener and 200ohm MCU resistor on board.

I was using the crusty old driver pucks so I’m pretty sure something isn’t right.
Urgh, every time I do some circuit troubleshooting like this I realise how shit my measuring kit really is and it tends to get very expensive very quickly. Last time I ended up shelling out on a digital scope (which still hasn’t arrived :frowning: ) and this time it’s probably going to be a new multimeter and a bench power supply… :stuck_out_tongue:

I’m also thinking that instead of mucking about with these zeners and resistors I’d be much better off just sticking a 5.5v LDO or something on there to power the board.
Would make things much simpler and more understandable as well.

Ok, I got frustrated testing the transistor setup without the right equipment so I’ll hold off on that until I at least have my scope. Also going to get a decent RMS multimeter tomorrow so that should make testing easier.

In the meantime I flashed MikeC’s custom firmware to see if the MCU can supply enough juice to run all those 7135s when the output pin is simply set to High/ON.

The results are interesting but the answer to that question seems to be a fairly clear no.

Here we have the new test in dark (No PWM, Pin1 High) with the two faded comparisons overlaid. ( done at 4.3v and 5.6v Vcc with MCU PWM output).

The test without PWM is worse in overall performance compared to both of the previous tests with PWM. The best comparison is between the two 5.6v MCU tests (the highest maintained current graph, sorry for not labelling) and it’s clearly worse than that one. Starts off lower and drops fairly drastically after 2minutes, interestingly that’s also the point where the flicker would usually set in while using PWM and at the same time the current and output levels would tend to jump up a little on those. Without PWM that wasn’t the case and the driver current simply took a nose dive and so naturally did the output. On a positive note I didn’t notice any flicker during this test.

So the problem isn’t related solely to the PWM behaviour, what are your thoughts?
Cheers

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).