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:
OTC is charged to Vcc as Mike C mentioned.
Changing vRef takes time and seems to cause incorrect readings - I believe you may have to take and discard a minimum of one reading, maybe 2, in order to get the vRef change working correctly. And that has to happen every time you make the change. I am not super knowledgeable on this subject. The most simple thing is to permanently change vRef and use a different (appropriate) voltage divider ratio to monitor battery voltage. (eg change R1 or R2 to a different value)
The latest PNP transistor modes-issue is possibly caused by that particular transistor’s performance characteristics together with the high freq PWM. IIRC Phase Correct PWM should be 1/2 the freq though, so I’d expect at least a small difference. For testing please drop PWM freq drastically using the divider or prescaler. See HarleyQuin’s post over here, #174 - STAR Firmware by JonnyC - Source Code and Explanation - try for ~1khz or ~200hz or something.
I don’t know the cause of the memory issue w/ the PNP transistor.
Purpose-built current shunts can be purchased cheaply on eBay etc.
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.
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.
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.
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.
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.
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
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.
Look forward to seeing your results on this in any case.
