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.
Yes, normally called a pulldown resistor.
If you didn’t see a difference after changing Vref, you made a mistake.
Things are coming together!
Pulldown resistor: Yep just soldered on top or in my case on the side of the OTC.
Temps: Yep temp measurements are taken exactly the same way using an IR thermometer pointed directly at the Heatsink fins, on high it now takes 6minutes to get to about 75degs C yes.
Board design: Is it an unforgivable sin to just use airwires instead of traces… haha… can imagine that would make things quite a bit easier 
Look forward to seeing your results on this in any case.
Lux: I’m using one of those cheap and crappy red luxmeters you can find on ebay. It does the job but it’s not particularly repeatable or reliable.
-
On the transistor front (couldn’t leave it be :P) I decided to measure current draw of the 16x 7135s on my test puck. Again just to verify how much they actually draw and play around with the PNP approach again. Surprisingly with the transistor driving the 7135s and measuring the current between the LDO and the transistor I saw a massive current draw of over 90ma!! Something not right there. Looking a bit closer and measuring current across the individual legs of the PNP I noted that the vast majority of this current was passing between the Emitter and the Base leg . The 7135 driver puck itself was only drawing about 7ma while the rest was being sunk into the MCU pwm pin. Makes sense since in 100% duty cycle mode the MCU is holding that pin low and without any resistor in place it’s drawing quite a bit of current. Not sure if that’s good for it, certainly it’s about double the max allowable output current per pin…
In any case I found that adding a 1.5k resistor between the Base leg and the MCU pwm pin allowed the transistor to still pass the full 5v onto the 7135s (i.e remain fully on) and reduce the total current consumption down to around 9ma. Much more reasonable. If the base resistance value is too high then the voltage on the 7135 side of the transistor dropped below 5v so that’s probably an indication that the transistor was no longer fully “on”.
I do remember coming across a calculator to work out max base resistor values for specific transistors, didn’t know what they were for at the time but now it makes sense.
In any case I learned something new about transistors today!
Yep pretty major one, turns out I never actually flashed my test version of the firmware with the OTC maxed out to 255. Or indeed the subsequent alteration of it to test the Vref… Urgh, thought I had moved beyond making silly flashing mistakes like this… 
I realised what I’d done after it was tripping me up for 30 mins now, I thought I’d zapped the MCU and broken it because it suddenly didn’t have any modes at all after updating my latest firmware to 255 timeout. Assuming that value had worked before on the alternative version and even been used to tune in the pulldown resistor. Really Dumb.
But at least now I have my pulldown resistor working and it was actually fine tuned on a firmware version that had the default 130 OTC values. Meaning I have an even better adjustment window than I thought, both up and down if needed.
-
LVC is also dialed in now to step down at 6.5v and start ramping off at around 6.1v. Should be nice and safe for these packs.
That explains it!
Don’t you just love that moment in a project when your light gains sentience and starts designing itself?
Mines just developed a permanent standby moon mode on one emitter…all by it’s self. I’m so proud…hah! 
-
Well, I checked to make sure I didn’t have a short between reflector and led -, or somewhere on the driver. So my best guess is that a 7135 chip has failed in a partially on mode. Anyone seen this happen before?
I guess that’s the risk of having the leds “live” all the time and relying on the 7135s to remain fully off when no power is applied to the MCU.
That is also the emitter that had the flickering issues before the LDO fix so maybe that one 7135 responsible for the flicker has been cooked half to death during all that testing. The regulators where certainly getting way too hot during those early test runs so I guess it’s not too surprising.
No way I can indentify or swap it out if that’s the case so I’ll have to live with this on-mode status LED. It’s the center one and everything so it almost looks intentional, haha
Well it’s either that or the light’s jealous of the thing in the background that’s been occupying my attention today
Oh my god those first 2 sentences made me laugh hard!!!
Damn. Its sb's Borgs at work. I feel your pain.
Did somebody say beamshots?
I’ve paid much more attention lately when running my light and have noticed some flickering also. Thought I’d let you know as earlier I had not. I’m going to try lowering the value of the resistor and see it it makes a difference, at least while I’m waiting on my new PWM-less driver som OSH Park.
That’s very interesting, yes please let us know what affect a lower resistor has. #
And I’m very sorry that all this talk of flicker has caused you to notice a subtle issue that you may not have ever seen without looking for it…very sorry
Haha, don’t be. I’ve learned quite a lot from following your thread. If all I have to do is easily swap a resistor I will have greatly benefited from your issues. I’m going to do the firmware test with constant on/high first, just to see if my flickering can be hammered out without PWM as my PWM-less board is in production. I’ll be adding a lower resistor anyway of coarse, but it’ll be interesting anyway. If it works I could just recode the software to do constant on/high on my highest mode and PWM the others until my new board arrives, but will do both tests anyway. I’ll be adding the test results in my own thread when I get ’em done.
Yes if you’re light is anything like mine, the constant on pin should eliminate/reduce the flicker. BUT at the the expense of lowering the driver performance even more! In my testing the runs with your custom firmware where the worst performers overall. So if MCU current supply is also the issue on yours then simply changing the resistor will solve all the issues in one.
High (100) with fast PWM shows absolutely nothing but a constant solid output when I scope these STAR drivers, confirming what Wight and JonnyC and all those have said. So with the right power supply in place (modified zener or 5v LDO) there’s not going to be any difference at all between setting the pin to ON or PWM 100.
Cheers
Linus
Interesting stuff! I also look forward to your results!
I decided to just try and solve the issue instead of doing the experiment with the firmware (which would result in performance loss), so I soldered on another 200 ohm resistor to get down to 100 ohm (didn’t have anything else lying around). And it solved the flickering… At least for as long as I had it on, which was a lot longer than the time I had to wait to see flickering. I did not re-charge the cells between the tests.
So… my flickering was a quick fix, thanks to you and wight. Basically you guys did all the head-scratching and testing, and I’m just taking a free ride. So I extend my gratitude, thanks guys 
I’ve got 50, 75 and 100s on the way with my next component delivery, I’ll run a few calculations through the zener calculators wight provided and see what I end up on using, but lowering the resistance certainly seems a must.