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

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.

It would certainly be interesting to see for future reference, however I need PWM to work for this light so it’s not the most valid test to do right now. I also wouldn’t know where to start with tweaking the STAR firmware to get this to work.
But if you’re interested in sending me a hex file with the PWM pin configured to constant on I’d be happy to flash it to my MCU and run a test to see if it makes any difference at all.

On the transistor front, I just got back from distrelec with PNPs in hand. Will give it a go now, fingers crossed.

Ok, cool. I’ll get it done later tonight (gotta run). Could you PM me an email address so I can email it over? You should have it tomorrow morning.

Hex file sent. Interested in the result, and also your test with the transistor. Interesting stuff.

I’m curious about both tests as well. … although I fear that no news = problems w/ the PNP transistor test. :frowning: