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. 
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!
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… 
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).
Happy to see the results! Good work indeed. If I understand correctly, you are currently using the LDO to feed the MCU instead of a zener and resistor? You’re not using the MCU to trigger the LDO as a “gate opener” for the 7135s?
All though I like LDO solution (if I understood it correctly), using a lower valued load resistor for the zener could have solved the issue?
Yes the LDO supplies regulated 5v power to the MCU. The Attiny13A is still the only thing supplying power to the 7135s.
I was actually just going to use the LDO to provide a more understandable power source for testing the transistor but it solved the problem directly.
And yes, I believe as Wight said using a resistor with the recommended value based on the required current draw would have worked just as well. Haven’t tested that though since I also prefer the LDO approach to the zener.
-
I’d be very interested if you could do a similar kind of test on your M6, see if there is a noticeable difference in the output current behaviour between the standard zener approach and a 5v LDO. Or just by using the correct value load resistor along with the zener. I’m assuming you used a standard 200ohm resistor as well on your driver?
If you don’t have a current meter that can go to 18A you could just measure voltage drop with your DMM across a current shunt and calculate it that way.
Cheers
Welp, just maxed out my OffTime cap timer to 255 and it still takes around 12 seconds to store the mode! 
Time to do some calcs and find a suitable drain resistor for the cap.
This is now looking like a 4 component solution (5 if you count the airwire 
) replacing the 2 component zener mod… smart or dumb?
Right. That’s what I think, at least!
I wish I understood this behavior better.
I’m definitely going to try out switching the load resistor out for a lower one. Not sure I want to dig into the LDO if a lower zener could work.
Not sure what you mean with current shunt (not even novice level at electronics). Could you explain is if explaining to a dummy? Do you mean putting a resistor in series and calculating current through it with Ohms law?
Perhaps it’s worth having a look at at using VCC as reference voltage instead of 1.1V when measuring the cap level in the off time check? The ATTiny13a can use either 1.1V (as default in Star) or VCC as reference voltage in the analog to digital converter used in the off time check. I have never tried using VCC as reference voltage, I have never needed to, but how knows, maybe using VCC as reference voltage when doing the check will get you within a usable range when measuring the CAP level?
The line in the code is: ADMUX = (1 << REFS0) | (1 << ADLAR) | CAP_CHANNEL;
REFS0 set to 1 (as in Star) sets the internal voltage as reference (1.1V), setting REFS0 to 0 sets VCC voltage as reference. I didn’t read enough to make the call myself, but on page 92 in the ATTiny13a datasheet you can read a little about bit 6 (REFS0). You can also read a quick bit on ADC voltage reference on page 88. You’d have to read a lot more if you want to figure it out, or you could just do like I would, test setting REFS0 to 0 and see if you can toggle values to a usable result. Don’t know if this will work at all, just a suggestion after quickly browsing through how the analog to digital converter works. You might have to change more things in the code to get it to work too, I don’t really know.
Yep exactly a low value resistor and Ohms law, that’s how the current meter inside your DMM works. A current shunt is just another term for a very low value resistor designed for measuring large currents.
They can look like pipes soldered onto a PCB, basically just a segment of thick wire with a known and precise resistance.
Ah that sounds interesting, so you’re saying the OTC (off time cap) is charged to Vcc and that it can take so long to register because it has to drop all the way down to below the 1.1v reference voltage? I had assumed it was only ever charged to a low voltage close to the reference to begin with. Thanks, will look into it. It’s probably worth a shot to change what you suggest in the firmware and see if it’s any better.
-
I was curious so I did some more testing with the PNP transistor switching the 7135s. This time using a cleaner test setup and some basic 3 mode firmware.
(Turns out I did have a 70ohm short on the 7135 driver puck I was using for the last transistor test…doh! :~ )
I set it up with the 5.6v zener first but then switched to the LDO, behaviour seemed similar between the two but I only tested the simplified firmware with the LDO.
Overall it works but not 100%. First of all mode memory seemed to be broken so I switched that off along with LVC and just tested basic modes. Low modes (below normal PWM of around 50 or 200 inverted) don’t seem to register as lower. If I set up something like 10, 50, 255 (non-inverted) then the 10 and 50 are basically at the same output level, very hard to tell the difference by eye. Occasionally (maybe heat related) or if I pinch the transistor legs with my finger I can get the low mode to drop down further than medium but in general it seems to plateau at the certain point and not want to go any lower. Same applies to any kind of moonmode obviously.
I also noticed a behavior where switching to a lower mode caused a quick brighter flash just before it dropped down.
Medium, High and any flashy modes work perfectly though, so if this were a chinese driver we’d call it a day and send it to the assembly line…
I tested with both Fast and Phase correct PWM, made no difference. So unless I’m doing something wrong I don’t think this is a straight forward single component solution to driving a bunch more 7135s. Shame, I’m looking forward to scoping this test setup though and seeing what brings on the plateauing behaviour. I also neglected to add the filter caps to the LDO so maybe that had some effect too.
The off time cap has always been charged to VCC, and 4.3V after a zener is not that much of a difference to 5V from the LDO, so I’m not sure that my suggestion will make a difference, would be weird perhaps but worth a shot.
Only other thing that comes to mind is that the cap is receiving a charge when it shouldn’t. Did you have input and/or output caps on the the LDO? Maybe an input cap is supplying the MCU long enough to keep the off time cap charged for a longer time? Or the LDO itself? A short somewhere? Just thinking a loud, maybe worth considering, or maybe not.
I pretty quickly skimmed the last 3 posts, hopefully I didn’t miss anything critical:
I thought in the case with this light the battery voltage is monitored by a Turnigy voltage monitoring panel? And there are plans for a low voltage cut off circuit for the LiPos? This thread is too long for me to skip back and see if anything has changed, but I was under the impression that the Star voltage monitoring routine was of no interest here, meaning that switching vRef back and forth would not be needed.
Haha, don’t blame you for not wanting to go through it all, I hardly know what the plan is myself anymore
On the LVC, I actually have the appropriate resistors in the voltage divider to be able to do LVC (>6v input) in driver firmware. At least it worked perfectly before all this LDO business, that’s another thing I need to check.
Hmm I guess putting a drain resistor across the OTC could fiddle with the voltage divider in unwanted ways? Man this is getting complicated :S
The voltage monitor on the pack is just a visual thing at the moment, when I was planning it STAR wasn’t around so I figured I’d have to keep the driver very basic and do any fiddly stuff somewhere else. Things change all the time as I figure stuff out.
It shouldn’t but I ain’t placing any bets!
Anyhow, off time reading with vRef set to VCC is a one time thing. Once the OTC routine is completed vRef is switched back to 1.1V in the voltage monitoring startup routine ADC_on(), and no more switching is done until the light is restarted. There won’t be any switching back and forth, so I don’t see it to be an issue really. If you don’t want to risk getting faulty readings from the first readings just implement a simple delay before reading. Are you using/going to use the turbo timeout feature? It uses a tick counter, you could use the same tick counter to make sure you don’t do any voltage checking until 1 or 2 ticks have passed.
Anyhow, all you need to do to see if this is worth following or not is change one digit in the code and check what happens with the off time memory. I reckon this is much easier than mucking about with components, but that’s just me I guess.
Cool, will let you know how it goes.
For now I have another runtime test graph. This time running off the batterypack and doing 4 runs back to back with cooldown periods in between. Quite considerable cooldown periods of course.
Just to get a feel for how overall performance looks as the battery depletes.
The increase in temperature at the LEDs really has a nice offsetting behaviour against the drop in battery voltage once the light is out of regulation. Means even though the batteries are sagging more or less linearly the driver current isn’t following suit. Instead there’s a rather flat current graph during each 6minute run. It just steps down considerably each time the light is allowed to cool down to room temp again which reflects the actual state of the battery voltage and respective drive current at that point. Interesting.
These tests were run with the current meter and an extra deans harness before the battery pack connectors so I’m dropping around 0.13v @ 17.85A before it even connects to the true battery connectors in the pack. Although it doesn’t reflect the other readings during this test, the faint voltage graph is a representation of the actual battery voltage during the runs. In the fully assembled light I’d expect to have that extra 0.13v overhead and therefore see a longer period in true regulation. ie. It probably won’t step down to below regulation current as early as the second run.
I can redo the test with the fully assembled light and just compare output and pack voltages to see if that pans out. It should but you never know.
Very pleased with the maintained performance anyway, SOO much better than before.
Still above 83% of max output at the end of the 25 minutes of running makes this a very usable maintained output lumen cannon. As long as you only run high for blasts shorter than 6 minutes and keep temps to below 70C in general then you should be fine
Also not a hint of a flicker or a hiccup in all this running so it’s pretty solid this thing, handling the torture testing very well. Maybe it would be happy running up to 80degrees, but don’t really want to risk damaging the leds.
Cheers
Linus
Edit:
Wight: Just tested the transistor setup again with the 8x divider fuse and phase correct for PWM frequency of 1.2kHz. Low modes work much better as you said, got one working down to 15 pwm (240) so that’s fairly dim. Still noticing a weird bright flash (possibly 100% output) for a split second while switching between the lower modes though.
I’ll leave testing here, was interesting playing around with this. And it seems to be a viable approach so far, I’m sure with some better parts speccing and electrical know-how it can be made to work perfectly.
Quick update:
I tried changing the Vref in the code but couldn’t tell if it made any difference. Maybe I did it incorrectly? I didn’t test it particularly thoroughly before going after a hardware solution.
I set up a little test rig and tried out a bunch of different drain resistors to drop the charge on the OTC faster. (are these technically called pull down resistors?)
I settled on a 220kOhm resistor in the end, short click timing is now quite fast but I can always tweak that a bit further in firmware. Certainly anything that isn’t a very fast half press will now be stored and the light reactivated in that mode.
Phew, looks like this is the MCU board finally working right. Still need to fine tune the LVC but that’s not as critical at the moment.
Nice, looks like it’s coming together! A single pull down resistor is an easy enough solution. Is it simply connected parallel over the cap?
And also, the temps you have taken now, are they taken exactly as in post #240? It takes your light about 6 minutes to reach 70C? I’ve gotta do some temp testing on mine. Gotta wait though, I’m in the middle of redesigning my driver… again. Putting 48 chips on a single board with a separate channel for each LED and having 4 groups of them for the each of the 4 output pins on the MCU, all on a two layered board is quite a challenge. I got it all in with not so bad ground and LED- traces after a lof of work… and only then when it was all done did I realized that I could get a 30 day trial test of Eagle to make a 4 layer board design… so now I’m starting over again with 4 layers.
I’ve just got two additional M6 hosts in, so I’ll be building a new one with the new driver and do some testing. May I ask how you are doing your lux tests? What are you using? You may have posted this before, sorry if I’m a little too lazy to read through it all to find it.