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

I pretty closely skimmed your post (gtg for now!). I’ll come back and read it at a more leisurely pace soon.

In the meantime I wanted to say this: why are you looking at an external blower? It seems to me that integrating a blower inside the unused space of the battery tube makes the most sense. The concept of being able to convert back to a fully-handheld/no-external-batteries light seems like nonsense to me. This a seriously powerful build and will require a remote battery pack to be useful/interesting. You may as well treat it that way and install a blower internally.

There’s plenty of space in there. Here’s how I think it could go down (but I don’t own a BTU Shocker): If you modify how power goes through the head and into the battery tube & minimize driver size you’ll have enough room to drill/cut vents at the bottom of the fins. After that you route the power wires as far off to one side as possible (top side, towards the handle). Use a small blower with the intake facing the front of the light, then seal the tube around/behind it. Vent radially around the blower. You’ll only be able to fit maybe a 30-35mm blower in there, but I suspect that would make a big difference. You could also look at using an axial fan with a high static pressure in the same configuration.

That’s all my two cents and it’s not my build of course… it’s your show! I just noticed that you hadn’t mentioned considering this option and kind of wondered why.

Is an intercooler being incorporated with the turbo blower? If so this would greatly increase the density in the battery increasing efficiency and greater lumen output.

Great scott! You’re onto something there! I will of course be adding a heat exchanger sleeve to the spiral cable to keep temps and resistances at an absolute minimum. Keeping the electron charge pressures high and temps low will certainly improve total max lumens when the …erm… PWMs? hit the redline…or something :stuck_out_tongue:

Let me stop you right there! What’s this “sense” thing you’re talking about? I’m pretty sure I’m lacking it :wink:

An internal fan would probably work quite well in the shorty config as you say and keep things much neater, but there’s plenty of reasons I’ve gone this route (for now anyway, it’s a rough and ready first pass concept).

Primarily though I just liked the idea of strapping a large blower to the side of a powerful light, to me at least it looks pretty sweet hanging off the side like that. Goes with the modular/tactical nonsense design of the rest of the light. Not much actual sense involved in that decision and preferences can vary.
I had to seriously restrain myself from adding a second blower onto the other side you know! haha :slight_smile:

Apart from the sense deficiency I’m also lacking in machining equipment/skill so I tend to shy away from anything that involves too much external machining on the light itself. The thought of a lot of drilling into an anodized BTU pill or body (they’re getting rare as hens teeth you know :wink: ) without having the option of covering mistakes with a bolt head doesn’t sound particularly appealing to me.

Finally I do want to maintain some basic water proofing on the base light. It’s never going to go underwater unscathed but it should survive a quick drop in a puddle or sitting in some melting snow (for emergency cooling :stuck_out_tongue: ) without something internal going fizz. That’s also why I want the blower module detachable in case it’s raining outside or whatever. Not to mention if the external fan goes pop (don’t know how many million operating hours are on my particular sample since it came from a server) it’s a five minute job to swap it out.

Having said that the XLR plug on my current light isn’t yet waterproof but a bit of silicone on the inside grounding tab opening and an oring around the fixture will take care of that. I also have other unsealed lights and I hate the condensation issues you get on the inside of the lens when it’s cold outside. Can’t be having any of that here.

What I really like about the idea of an internal blower is a way of shifting some air directly over the driver components. But I think as long as I can maximize the heat sink path of the critical internal components to the pill then the blower will do a good job of removing a decent chunk of that heat from the surface. It’s not ideal because of the limited surface area but should do a decent enough job, especially to more quickly return the light to a safe temperature after a turbo stint. The light has so much mass that left to it’s own devices just sitting there it takes an absolute age to cool back down after it’s hit a soak at 70deg.

Thanks for the comment though, I’ll probably try an implementation of your internal fan idea (easy enough to try on the 3d prototype) and see how it could work.

Linus

Well well, I may have to apologize to the humble 7135s…

I just reconfigured the driver and ran a test with the MCU (Attiny13A) completely bypassed. I simply tapped into the MCUs positive voltage supply (4.3v zener controlled) and fed that directly in the Vcc harness controlling the 48x 7135s. This would force them into a constant-on (high only) mode of operation.

The results are very telling. WE FINALLY HAVE PROPER REGULATION!!! and at a much lower voltage overhead than before. :open_mouth:

-

This graph shows the results of running the MCU-less setup off the iCharger at 8.7v, faded graph is the older test at the same voltage for comparison. Everything connected up the same way.

I thought my current meter had locked up for a moment there, couldn’t believe what I was seeing, solid stable regulation for almost 5minutes! At the full theoretical current limit of 17.85A, with the MCU active I had to feed the thing 9.1v! before it would show me those figures and then it only maintained it briefly.

-

Of course I thoroughly verified my results with state of the art measuring equipment…

Yep, she’s flat alright :bigsmile: :wink:

SOOOooo Attiny 13A, what the heck are you doing?? But certainly you’re not switching those 7135s with enough authority or something else fishy is going on. Maybe the Attiny doesn’t like the heat? Need to study it’s data sheet a bit and see what could be causing this. I assume we can trust that the STAR firmware is doing a good job at 100% duty cycle? I can’t wait for my little Rigol scope to finally get here so I can have a better look into what’s actually going on on the PWM line.

Thoughts welcome guys, I’m a little stumped as to what’s going on once again. But the finger is firmly pointed at the Attiny13A at this stage…
I am rather pleased to finally see some regulation and more expected performance from this setup, it just too bad I had to lose all my lower modes to get there… :stuck_out_tongue:

Cheers
Linus

PS. I just checked and the annoying Warm up flicker is also completely gone running in this MCU-less configuration. Just solid stable output at much lower battery pack voltages.

Keeps getting more and more amazing

Bravo. Love your problem solving and thanks for including the second thing I understand about in this total build. Mines a fair bit longer though and not quite as straight.

Thanks guys, you think I should hit the MCU with the “measuring equipment” and see if it works better after? :stuck_out_tongue:

-

I’m totally delighted with the performance of this light at the moment, just been running down the batteries a bit outside. Granted there’s no modes so I have to aim it far away to avoid blinding myself, but the output is rock solid (not a hint of a flicker anywhere) and even with a pack voltage down by 7.5v it’s still kicking butt on the output, seeing 67klux @ 3.35m where as before it would have been way below 50k at turn on.
Before it was whimpering and output was noticeable down as soon as the pack dropped below 8v.

This is much more like what I expected to see.

Maybe the LifePO4s aren’t necessary after all…hmm, now I just need to figure out how to get my UI and modes back at this performance level. :stuck_out_tongue:

I think you could use a P-channel MOSFET driving the 7135’s with the ATtiny13A running the gate on the MOSFET. You’d need to invert the PWM for the modes, that’s not a big deal though.

That sounds very interesting, bit over my head at the moment though (just had to read up the difference between P and N mosfets). By invert the PWM you mean that 255 in the firmware would be equivalent to 0% duty cycle in the standard setup and 0 would be 100% duty cycle? Or is there something more complicated and “frequency” that I don’t understand yet. Hoping to learn a lot when I finally have a decent oscilloscope and can test/verify simple stuff like this.

First I’m wondering if simply increasing the supply voltage to the MCU from 4.3v to 5.5v will make any difference, that I can test easily enough when the parts for your linear driver arrive in a couple of days.

My thinking is that for whatever reason the MCU isn’t able to sufficiently saturate the gates of all the 7135 internal mini fets (please correct me if I’m using nonsense terms here :stuck_out_tongue: ), so they’re not actually fully on even when they shouldn’t be regulating (in the linear range I believe it’s called?) which leads to the large increase in voltage dropout because of higher internal resistance, which in turn leads to much higher temps and flickering and all the rest of the weirdness.

Of course it may just be that my particular MCU board isn’t working 100%, that’s the first thing I’ll try to eliminate. Flash up a fresh MCU and zener board and see if it makes any difference.

Your understanding of inverting the PWM is correct, 255/255 would be fully off and 0/255 would be fully on.

I won’t speculate much about the rest. As far as each individual 7135 is concerned it’s almost certainly a supply voltage issue (too low). As far as the MCU is concerned… I don’t know if it’s low supply voltage (and therefore low output voltage to the 7135’s) or limited ability to provide current (and therefore sagging / low output voltage to the 7135’s).

Cheers wight,

If this is indeed a problem with the Attiny13A and not just something I’ve screwed up, I wonder how many other high output stacked 7135 lights are running similarly below par and no one’s the wiser. Certainly on my other highly stacked 7135 lights I always just assumed a limited regulation phase or rapid drop in output current was primarily down to the batteries sagging, or temps. Maybe there’s plenty of room for improvement on some of these modded lights.

More testing is in order, hopefully I’ll get to the bottom of this. :slight_smile:

What an incredible build. Seems like there is some real good knowledge gained from it. Some day, I hope to read this novel of a thread from beginning to end.

As far as I know, PWM at 255 is never truly 100% on, only very close to it. And the ATTiny13as are definitely sensitive to temperatures, I used that for my temperature monitoring experiments, but I wouldn’t know how that has an affect in this case.

For my own triple MT-G2 I’m designing a new driver that will use all outputs on the MCU to use as simple ON/OFF to trigger chains of 7135s. Using four chains of 7135s will give a total of 15 selectable modes without PWM. I started looking at MOSFETs and all that and it didn’t take very long to realize it’s beyond me, so I’m just sticking with what I currently know how to use.

That’s interesting, something I’ll definitely be scoping out soon enough. I heard a while ago that the (I think) KD7135 or early Nanjg based boards had a firmware bug that ment they weren’t truly doing 255 at max output. So you’re saying even on something like the STAR firmware the output isn’t solid. Maybe this is what is getting worse and causing all the weirdness as the load on the PWM pin is increased.

You haven’t noticed any flicker at all on your triple mt-g2 as it warms up? Some comparative measurements from a similar light would be really interesting to see.

So you’re saying there’s a difference in output stability between an Attiny pin configured for PWM (even if the PWM is pegged at 255) and a pin set to constant ON output?
Edit: If this the case would it be possible to do a moonlight-special type of thing and just switch on a second output pin (for 100% mode) wired in parallel to the Vcc input of all the 7135s. Share the load between the two and reduce instability in the waveform?

I really don’t understand these little buggers enough. So much to learn :stuck_out_tongue:

I read your PWMless driver thread, but did you notice any unwanted behavior from the PWM-ed 7135s in your light (at 100%) that led you to making this design decision? Or was it simply about gaining efficiency at lower modes?

Can’t say I’m sure about it, wight’s comments on this will be far more valuable. From my understanding PWM 255 still is switching, not constant on. This switching may or may not be affected by high temperates.

I haven’t noticed any flickering at all on high modes. It does seem to flicker a little when I run really low PWM values, but other than that no flickering at all. But I have not run it for longer than the 1:40 hot potato test. I won’t need to in real life use. However, I haven’t looked straight into it though. Your idea of using welding protection is brilliant, I’d try it out if I had easy access to some.

No, not saying that at all. Just a theory based on your resent interesting discoveries. At PWM 255 my light has behaving well from what I have been able to see, but as mentioned I haven’t looked straight into it nor run it for longer than the hot potato test. My reason for wanting to try without PWM is only for efficiency in lower modes.

[/quote]

Ah ok gotcha :slight_smile:
The flicker only started on mine at around the 2minute mark, >50degress at the heatsink so well past my pain threshold of a hot potato test :wink:

-

With regard to the flickering, on mine it was pretty obvious just looking at the hotspot on a white wall with the light sitting still. Covering individual emitters with your hand will also help show it if only one is actually affected. The welding glass technique sounds like it would make it easier to see but I had a really hard time noticing it when directly looking into the emitters. Best way to check is just put the light on hitting a wall in your peripheral vision and do something else you should notice the stepping/flickering pretty easily like that.

It could well be that my extra Vcc wiring between the 13A and the 7135s is what is exacerbating the issues. Or maybe it really is my particular MCU board which is a dud. Gotta eliminate at least the dud board/chip theory first.

So I just ran another test on the MCU-less driver. This time with a low low input voltage of 7.7v. According to my original resistance loss predictions I should be just out of regulation at this stage.
The results are just lovely, so smoooth! :stuck_out_tongue:

The faded graph in comparison is the dismally awful performance of the MCU controlled driver with an input voltage of 8.1v! so this isn’t even a like for like comparison. Seeing how badly the light did at this voltage I didn’t bother testing any further down. The only benefit of the extra 0.4v overhead is right at the beginning when driver current and total output is higher, then it just proceeds to wobble and flicker it’s way downwards :~

Also interesting to see is how (I assume) the Vf of the LEDs or perhaps (less likely) the dropout of the 7135s seems to reduce a fair bit over the course of the test, resulting in a drive current that actually rises from 15.3A at turn-on to 16.4A at the end of the test. That may actually go some way to combating the output decline due to voltage sag of the batteries in this voltage range. Very interesting indeed.

-

Seeing these graphs just verifies why I was so delighted with the performance of the light last night. It just runs so smooth and output seems so stable compared to before, even when running the packs right down. I never really felt the urgh to top them back up, this thing just keeps on chucking the lumens! :bigsmile:

RE: PWM
Poor JonnyC has already explained this several times. Preface: no, you’re wrong about 255/255. The PWM behavior you’re talking about is only present in Fast PWM and only at one end of the PWM range. Inverting the PWM signal moves it from one end of the range to the other. JonnyC has it at the bottom of the range, so when using STAR configured for Fast PWM the 0/255 setting would not normally be fully off… except that STAR will put the MCU to sleep when it sees the value go to 0/255, so you still get zero output there unless you modify the firmware. (ToyKeeper has a modified version to take advantage of that PWM bug.) (Phase Correct PWM doesn’t do any of that stuff. It’s behavior is ‘perfect’.) I don’t expect any difference in output performance between a pin set for constant on and a pin setup for PWM 255/255.

RE: using multiple pins in the “moonlight special” style
This might help or it might not. Only 2 pins are available to do this. If the output limitation is “pin” based this could help. If the output limitation is “port” based this will not help. The “port” is a group of pins and on the small Atmels like the ATtiny13A all the pins are in the same port.

RE: flicker
Seems like the welding glass / goggles must be more useful when the emitter is the culprit. DBCstm was able to clearly see flickering cells on his MT-G2 with that method. He was even able to photograph them. So if the welding glass thing holds any value, maybe the value is simply having a better guess at whether it’s a damaged emitter vs driver problem?

Great points, thanks for that. I think I’m getting a clearer idea what’s going on inside the Atmel, I’ll go read through that STAR thread again.

Up to now I’ve mostly just left the nitty gritty MCU and firmware stuff to people who know what they’re doing but it seems that’s bitten me a bit here.
When you push things a bit too far and have to troubleshoot something like this it’s really important understanding how all the “lego” parts function and where the limits are.

-

Having said that…excessive stacking got us into this problem, so surely more stacking can get us out?! Right?

You think of using a P channel mosfet to solve the problem elegantly I start thinking in terms of stacking. :8)
Can I stack 3 Attiny13As on top of each other, flash them together and keep the pwm pins separated to feed each driver puck?…simples? :stuck_out_tongue: Unfortunately that’s the first solution that came to mind in order to deal with this kind of problem, haha :wink:

No idea if the flashing process can address multiple chips in this way, most likely not. But I don’t see why just having a trio of these chips flashed separately and running the same firmware wouldn’t at least solve the issue in a ham fisted way. Maybe I can airwire a few onto the MCU board if there’s no other option…that or actually learn to do this properly…lol :stuck_out_tongue:

-

Yes the Welding glass certainly has some uses, apart from the novelty factor of being able to stare directly into a 10k lumen source of course. :smiley: (can’t hold it there too long though, it get’s hot incredibly quickly!)
I just found that detecting a relatively minor fluctuation in the output wasn’t one of them. You COULD see the flicker if you looked carefully but seeing the result in the output was much more apparent. It’s not on the same scale of a visibly flickering emitter you get on some moonlight modes for example.

Certainly if an emitter has a bad segment it would be immediately obvious, it’s very handy to have a piece of dark glass lying around for that alone. Before moonmode drivers where common it was also a useful way to study how emitters and reflectors interact.

Definitely can’t flash like that. I can’t say that you won’t get a driver to work with pre-flashed MCUs which are stacked. Tolerance issues may come into play. Honestly I’m just not interested in stepping through what the disadvantages of a hack like that would be. Not my kind of solution.

How nice of farnell to send me a bunch of antistatic baggies today, how did they know I was running low on those? :slight_smile:

…oh…wait, there might actually be tiny components somewhere inside there! :open_mouth:

Ahem… yeah remember when I said how I thought those LFPAK fets are a “much much bigger package” than a 7135…well, yeah…not so much. They are properly tiny, can’t believe they can really handle all that current, amazing.

I also got some 5.5v zeners in this order so I will replace the 4.3v one on the MCU board and see how things stack up with a stronger input voltage. Fingers crossed.

The tests I’ve been running to try and track down the dropout voltage of my entire light have been producing really nice predictable results without the MCU, and performance is in another league altogether. It was seriously crippled before, not to mention that extra 0.5v or so being needlessly burned off in the drivers meant I was probably dumping up to 30watts of heat into the driver assembly alone! No wonder I had to over engineer the thermal paths so much, should have realized there was a problem earlier.


Like for like 8.1v Vin runs. I’m not sure if I would call this fully regulated or not. Currents don’t quite hit the magic 17.85A at any point but it’s close enough and very flat so I suspect it is doing something.
At lower voltages the light tends to start further below regulation and then rise up to flatten out at a steady current. If VBatt is really at 7.8v then seeing any kind of regulation here means I am very close indeed to the dropout voltage I predicted at around 0.8v for the entire light. Which is great.

…and at 8.3v, solidly regulated, steady boring graph. Just the way I like them! :slight_smile:

I’m still not 100% trusting the VBatt values but I’ve been measuring voltage drop across the wiring harness instead and that seems to be less prone to variation and weirdness. On average VBatt is about 0.28-0.3v lower than Vin. Thankfully the actual Vin values set by the iCharger are absolutely stable and repeatable so it doesn’t really matter.

Dropping down below 8v iCharger input, which equates to about 7.7v battery voltage and the the light starts to be noticeably out of regulation. There’s no longer much of a flatness to the current graph and it actually starts lower and rises up as the temperatures increase. See the 7.7v Vin (7.4v Vbatt) graph earlier in the thread as to what it looks like when it switches over. But the behaviour is nice and predictable everywhere, I may do some more tests to characterize the light fully at inbetween voltages but meh, it’s a bit of a pain.

At this stage I need to just focus on improving the performance with the MCU active. I have some great comparison data now at these voltage. If anything I do improves the MCU’s performance I’ll be able to see it right away.