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

377 posts / 0 new
Last post
LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland
wight wrote:
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 Silly ), 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.

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

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

ImA4Wheelr
Offline
Last seen: 1 week 2 days ago
Joined: 02/03/2013 - 14:51
Posts: 7927
Location: SC

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.

Mike C
Mike C's picture
Offline
Last seen: 4 days 19 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2481
Location: Sweden

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.

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland
Mike C wrote:
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.

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.

Mike C wrote:
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.

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 Silly

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?

Mike C
Mike C's picture
Offline
Last seen: 4 days 19 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2481
Location: Sweden

LinusHofmann wrote:
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.

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.

LinusHofmann wrote:
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.

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.

LinusHofmann wrote:
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?

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.
LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

Quote:
LinusHofmann wrote:
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?

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 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! Silly

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:

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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?

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

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? Silly 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 Silly

-

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. Big Smile (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.

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

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

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

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

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

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 Smile

Cheers
Linus

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland
wight wrote:
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.

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 Silly

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland
wight wrote:
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.

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

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

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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… http://www.englishforum.ch/other-general/153200-comparison-swiss-electro...

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

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

wight wrote:
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… http://www.englishforum.ch/other-general/153200-comparison-swiss-electro...

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… Silly 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

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Mike C
Mike C's picture
Offline
Last seen: 4 days 19 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2481
Location: Sweden

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.

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland
Mike C wrote:
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 Silly

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?

Mike C
Mike C's picture
Offline
Last seen: 4 days 19 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2481
Location: Sweden

LinusHofmann wrote:
Or you mean just to see if the behaviour of the output pin is different in constant high vs PWM?

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.

LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland

Mike C wrote:

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.

Mike C
Mike C's picture
Offline
Last seen: 4 days 19 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2481
Location: Sweden

LinusHofmann wrote:
Using the Transistor as a power source/amplifier for the PWM signal should give us a good idea if that is the problem.

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.

wight
Offline
Last seen: 2 weeks 17 hours ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Mike C
Mike C's picture
Offline
Last seen: 4 days 19 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2481
Location: Sweden

wight wrote:
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.

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?

wight wrote:
The 7135’s are not “being run above maximum limit of 7v”

Oops, I forgot about Vf over the LEDs.
LinusHofmann
LinusHofmann's picture
Offline
Last seen: 8 months 1 week ago
Joined: 09/28/2013 - 08:27
Posts: 974
Location: Switzerland
Mike C wrote:
wight wrote:
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.
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?

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.

Pages