luxdrv - custom modes driver firmware with ramping

I'd gladly test the brightness ramping code when you post it.

Kris

I'm currently not happy with it: Occasionally there's a glitch when trying to lock the ramped level; when unlucky, the power goes out while writing to the EEPROM, the erase cycle gets through, but not the write, resulting in a wrong PWM level.

I wonder if brown-out detection could help here (I didn't activate it).

I think I want to rewrite some parts of the code. Might even save a few bytes.

Well then, here's a new version with ramping. It's considered beta.

Download: luxdrv v0.21 with ramping

EDIT: Uh-oh, a bug... inhibited the correct mode change on fast taps when ramping.

Download: luxdrv v0.22 with ramping

Well, I used it for a while now and I like it, so I updated the 1st post.

I recently played with a light using an unmodified Nanjg105C - I guess I'm already too used to the smarter firmwares like Tido's or mine to be happy with that. ;)

I'd be happy to get some feedback from you.

I'm wondering would it be possible to use Attiny13 and 7135 based drivers in different way. Idea is to make use of more attiny13 ports for "enabling" individual (or more than one) 7135 chip via vdd pin and thus avoid using pwm completely or just use it for low modes when only one 7135 would be enabled. This would also require hardware modification of driver by cutting traces to vdd pin and connecting them to previously unused attiny ports. For example on 4*7135 driver we could have a configuration with this modes: low (1x7135) / med (2x7135) / high (4x7135) with 3 ports. Since I have very little experience in programming I'm not sure if this is even possible with attiny13...

As I already noticed in post (https://budgetlightforum.com/t/-/1698#comment-97001) that some AMC7135 drivers use PWM even ih high mode, but if I understand correctly when using luxdrv or BLF-VLD level 255 means that practically no pwm is used since duty is 100%.

That would be too coarse, because even a single 7135 still delivers 350mA, which produces quite a lot of light. There would practically be no low mode. But there is an solution to that...

I have an 8x7135 lying around, where only one of the 7135s is driven by PWM. The other 7 are divided into three groups (1, 2 and 4) which are controlled by digital I/O. This extends the PWM-range by 3 bits, which means that it can go from a very low low (~1.4mA) to a whopping 2.8A. As a side effect the LED's efficiency increases marginally at low levels, because it only sees pulses of 350mA, not 2.8A.

Excellent, that's what I had on mind ("avoid using pwm completely or just use it for low modes when only one 7135 would be enabled").

Did you make modified program or was it "off the shelf" like that ? Managing modes in this way improves efficiency and there is no pwm on all but low modes. If I understand correctly only possible downside is lack of strobe/sos modes in higher power (i presume they are possible to obtain in single 7135 mode)

I simply made an experimental branch for the BLF-VLD. It just took some fiddling with the set_pwm function, so all the disco-modes still use the max. light level. The only mode restricted to the true PWM is the fading one. Expanding it to make use of the extra three bits just ate too much program flash.

If I ever get around to release another BLF-VLD version, this will be included.

Still no feedback for the ramping? :(

Did I mention it's roughly visually linear? (the steps are a bit higher at the lowest levels)

Switching individual AMC7135s: I had thought about that, too, but finally came to the conclusion that I don't want to do hardware modifications, since I mod quite some flashlights with this driver - too much hassle for all of them.

Currently testing my new version with battery monitoring:

  • Ramping down at ~3V (halving brightness every time the voltage falls below ~3V, down to level 6)
  • In beacon mode, anumber of blinks shows battery level in ~0.1V steps, like sixty545 suggested.

Will publish code when I'm happy.

I would like to say thanks for making your code available, I was able to modify your code to achieve my ideal UI (3 modes with memory, moonlight, med, high) by experimenting with your code, an accomplishment I could not achieve with Tido's code, as the extra functionality he built in resulted in complexity that went way over my head. Nothing quite like flashing the code to the driver for the first time and having it work.

You mentioned that you might be working on battery monitoring, and I for one would be very interested in seeing sample code for that feature that is compatible with your existing code (if possible). I hope to be able to write my own eventually but this is my first exposure to programming other than a single semester of C++, and programming for uC's is a very different thing.

My ideal driver would have the 3 modes with memory (which I already have thanks to your code), as well as battery monitoring that would reduce the pwm level once batt voltage is sensed as 3 volts or less for at least 2 seconds. It would be ideal if the max pwm level allowed would be the medium mode level PWM value, while still allowing selection between the medium and low levels when low batt voltage warning is activated, locking out only the high (255) level. Is this possible, or is it easiest to ramp-down to a single PWM value once the warning is triggered?

I think ramping down the pwm duty cycle is a much more practical way to warn of a low battery than constant blinking, which to me makes the light hard to use once the low-batt function is activated.

Any help would be appreciated, thanks again for sharing your design, your code has allowed me to achieve a moonlight level on my XML lights, which makes them much more useful, as the lowest level on the stock 2.8amp drivers is much too bright for close work at night.

I'm impressed that you can simply program the driver to deliver whatever levels desired, to suit the application.

Tiny host, no problem. The XM-L only gets 1.4A. P60 needs to run for an hour ? 2.5 amps it is.

I would guess that the components on a 8x7135 setup running at 1.4A would run cooler than a 4x7135 doing the same. This could potentially promote driver longevity on what are essentially bargain controllers.

Could you please describe the physical mods needed to accomplish this? Thanks.

I dug it out from my Someday-I'm-going-to-finish-this-thing box and have to admit that I've been lying. It's only a 4x7135 101-AK. Nevertheless, the principle is still the same.

The pink circles show where I have cut the traces connecting all the chips' enable inputs to the MCU's PWM output on PB1. The 7135 marked with the green dot is still connected to it via the original trace. The one with the red dot is connected to PB0 by the tiny piece of enamelled coper wire you can see on its rightmost contact pad. The 7135s marked with the blue dots are connected to PB3 (The wire is threaded below PB5 to reach PB3). The stuff on top of the MCU is a capacitor/diode/resistor circuit for click-detection, connected to ground and PB4.

I always wanted a driver of this design. Hope it doesn't stay in the Someday..box for too long. Whats unfinished, the program?

Really cool greenwire work.

I built it as a proof of concept. Everything works, it just doesn't do anything that about half a dozen other drop-ins lying around here can't do. This may be useful with 8x7135 driving an XM-L, because it's the only way to get a really low low, but I'm not a huge fan of using linear regulators with such a low Vf LED. There is just too much wasted energy.

Hi Tido,

If not 7135 linear regulators, then what do you suggest for current regulation of a low Vf led in a buck configuration? I am curious to know what else is out there for constant current regulation.

Thanks very much for the pics.

Excellent work.

I got my drivers last week and found that Kaidomain had substituted the new "no-name" 8*7135 V2 drivers for the AMC3175*8 drivers I had ordered. I'll keep them as I can still use them, but I had to scramble to find anyone who still had the older AMC drivers. I did place an order at Lightmalls -- haven't used them before so I'm crossing my fingers.

Has anyone determined if the new V2 drivers can be programmed?

Wow, this is way over my head... it'd be nice if one of you guys offered custom programmed drivers for sale. I'd love to have H,M, and strobe as low is useless for my bad night vision.

Rich

First of all, thank you DrJones for all the programming work. Way out of my league!

+1 to finding one of you that might want to program for others. I can add 2+2=4, but it usually takes me about 3 tries..... Each time I do it!

So, have any of you Tido, DrJones or any other wizards, thought of doing boards for others?

I'd like to have a real current regulated buck driver fitting in a 16mm pill that can be powered by a single LiIon cell (being able to also handle two would be a BIG plus). Unfortunately there doesn't seem to be any one available that fits the bill.