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

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.

Looking good. Maybe a simple PNP transistor would also be a good option for controlling those 7135’s. You’d still have to invert the PWM though.

Hmm, ok, bumping up the MCU input voltage using a 5.6v zener didn’t fix the problem. Although it did make a difference it seems.

Have a look at this before and after graph. Both done at 8.3v with the MCU active, the only difference is the Vcc voltage (4.3v before & 5.6v after)

It’s still pretty bad compared with the MCU less target graph above, but it’s also not identical to the 4.3v version. Quite a bit different/better in fact (the output lux data isn’t accurate enough between test sessions to compare directly but if you look at the current it tells what’s going on quite well)

The shape of the current curve also looked rather familiar so I compared it with the data from the next step up in voltage that is at 8.5v.

It’s a much better fit, so I think I can tentatively conclude from this is that the extra 1.3v Vcc voltage has on average, reduced the dropout across the 7135s by about 0.1-0.2v. Certainly better but it’s still not working right, seems I’d need to drop at least another 0.3v to get it close to the target graph. Flicker was also back with a vengeance right around the 2.5 minute mark, but maybe even a tad worse than before actually.

Poor little Atmel just isn’t up to the task it seems. Looks like I’d better start studying up on p-channel fets :slight_smile:

Cheers
Linus

That sounds like it could be a single component solution? Is that right? I really have no clue when it comes to circuit design beyond the bleedin obvious :stuck_out_tongue:

Could be. I forget, does your switch interrupt power to the entire circuit or just the control PCB? (EDIT: eg does turning off the switch leave the daughter-PCB’s hot?)

Interesting,
Switch interrupts only the MCU power, ie it interrupts the positive line coming from the battery and going to the MCU board.
Battery negative is hard wired to the slave/daughter boards (ground ring) and battery positive is hard wired to the leds + if that’s what you mean by hot.

Hmm, now that I think about that’s OK. The PNP transistor would be used as a “high side switch”, meaning that it interrupts the positive connection, not the GND connection. The problem I was considering is that when the MCU is off, that would allow the PNP’s “Base” to float to GND. When the PNP’s Base is at GND the PNP will conduct from the Emitter to the Collector (yes, I’m staring at a tutorial while I type this ;)). When it’s conducting, the 7135’s are on.

Of course this would be a problem if we were putting the MCU to sleep like in a momentary setup. This would also be a problem if the power switch in your psuedo-clicky was only hooked to the MCU. In this case it’s fine, the PNP will get Vcc / BAT+ from the MCU board and the MCU board will be switched by your clicky. So there won’t be anything for the PNP to conduct, even thought it will close the circuit while at rest…

In other words, no problem I guess.

Oh man, I thought I had it sussed but now my brain hurts staring at transistor diagrams. Emitter, Base and Collector is really throwing me off, haha. Hardly intuitive terms…
Took me long enough to get Gate, Source and Drain the right way around when it comes to mosfets.

-

So on a PNP transistor the Base is sorta like the gate on mosfet right? This leg would be Connected to the PWM pin on the Tiny13A?
Except it’s behavior is opposite to the gate on an n-mosfet in that it will “turn off” the transistor when it is high. Hence the inverted PWM.

The Emitter is like the source and connected to the Vbatt positive on the MCU board?

And the Collector is connected to the Vcc pin on the 7135s?

Hopefully I have that the right way around. Really appreciate the help on this btw, this sounds very promising.

Unfortunately I just had a look through some old circuit boards and I only have one single NPN transistor…damn, testing this will have to wait until I can track down a PNP. :frowning:

I wasn’t joking about keeping a tutorial open when I talk about this stuff. It’s still open, so I’ll check it… yes you’ve got it right, as far as I know.

I don’t know if any of this stuff is local to you, but… Comparison of swiss electronics shops - English Forum Switzerland

I don’t think you need anything more than whatever random PNP you find at a local component shop.

Awesome, yeah I’m sure I can track one down.
Distrelec is not far from here and they have….urgh…only bout 20 million PNP variants… :stuck_out_tongue: It’s never easy with components is it…

Googling general purpose PNP transistor gave me this 2N3906
Only has a 200ma current limit though, that’s right about what the 7135s use isn’t it. Is stacking out of the question? Haha :wink:

I wouldn’t worry about it. The ATtiny13A is certainly not providing 200mA, this will probably be an improvement.

(and yes, in general components can be a huge slog.)

Why not do an attempt with the MCU simply writing constant high on the output pin instead of using PWM? This should be no different than using a transistor to “open” the 7135s.

Not sure I understand how that would me help get my modes back.
Or you mean just to see if the behaviour of the output pin is different in constant high vs PWM?

My understanding of wight’s suggestion to use the PNP transistor is that the transistor will take the load off the Attiny13A’s PWM pin since it will have no problem supplying the needed current to all the 7135s. Switching a single transistor on and off using the PWM pin is going to be much easier on the poor Atmel pin than driving all the 7135s individually and as long as I invert my PWM values I’ll maintain the same duty cycles and modes that I had before. Hopefully :stuck_out_tongue:

Hmm, tinking about this again now. With inverted PWM values surely I’d have to switch to phase correct PWM to avoid running into the strange “not fully on @ 100%” duty cycle issues. Since STAR has those at the bottom of the PWM range they be back at the top for me, right?

Yes. The problems you have been having have been on the highest mode? I guess you could say that you’ve done this test already by running without the MCU, but as my suggested test is relatively easy it could be used as a simple ruling out MCU controlled PWM, rather than ruling out the MCU altogether.

I wouldn’t be so sure that it’s the MCUs current to the 7135s that’s the problem, you might see the same behavior when controlling a transistor. If your highest mode (255) is a lot higher than your other modes, and the other modes are not an issue, it could be solved by re-coding the firmware so your highest mode is constant on/high from the MCU, and your other modes are PWM controlled. No need for hardware changes… providing the test is successful.

It’s just a different approach… I find making software changes much easier than hardware changes, and test as much with software as I can before trying out new hardware configurations.

Ah ok, I see what you mean, my first line of attack is hardware based so it’s good to have someone thinking along the firmware lines. I just don’t know enough on either the MCU hardware side or the firmware side to make a good call on troubleshooting stuff to do with the Atmel directly.

Wight says output pin set to constant on or PWM 255 would make no difference if the problem is the MCU as a current source.
Using the Transistor as a power source/amplifier for the PWM signal should give us a good idea if that is the problem. If it still doesn’t work right and it’s related to the Atmel getting too hot or whatever then we can go from there.

Actually I think the problems affect other modes not just High, High is just what I’ve been testing and heat seems to have a strong influence on the behaviour so that’s where it’s also most obvious.
I can’t be absolutely certain but my test run on Med (~30% pwm) also produced pretty poor/weird results with no regulation and some flicker. Unfortunately because of the difficulty of measuring current accurately with PWM I didn’t do any more comparisons at that level.

Yep, I guess it’s basically the same test but different approach. Interested in the results as I don’t know enough about these either, expect that the oscillators on the MCUs are largely affected by heat. But I guess current output from the pins could be affected too. It could also be the 7135s that are having troubles with PWM in the heat? They are being run above maximum limit of 7v, maybe this is causing the unpredictable results when heat becomes a factor?

Any how, feels a bit lame of me to give suggestions, don’t know much about these things either, but I am interested in your results as I currently have a similar configuration. I am however going for a PWM-less option. Maybe three MCU outputs to control chains of 7135s, and the remaining output to control a MOSFET configuration (got a couple I’m playing around with). That’ll give me seven 7135 modes and one MOSFET mode, all without PWM.

I don’t see that as the same test. There’s nothing wrong with doing either test, but they aren’t the same thing and they don’t tell us the same things.

The 7135’s are not “being run above maximum limit of 7v”, recheck the datasheet. Supply voltage must be 2.7-6v (it is). The other numbers pertain to the voltage difference present over the 7135… which is just a couple of volts here.

EDIT: For clarity, look at the block diagram on page 2 and compare that to the ratings (Absolute Maximum Ratings is mostly what we have). VDD cannot go beyond 7v and should not go beyond 6v. “OUT” cannot go beyond 7v and does not have an operating spec… note that “OUT” voltage is measured in relation to GND, hence it is simply how much voltage the 7135 is dropping in order to control the load.

If the constant high/on through the MCU test displays no problems, then you know it’s not the current supply from the MCU that’s causing the problem?

Oops, I forgot about Vf over the LEDs.