luxdrv - custom modes driver firmware with ramping

Thanks for that info Tido!

DrJones,

Thanks for posting your program. I flashed a generic 3x7135 board last night with your program and it worked like a charm. Using the highest PWM frequency you have listed and a Q5 XR-E I was able to get light using a PWM setting of 1. The next driver I'll flash is an 8x7135 NANJG 105C to be used with an XM-L in a Trustfire T2, assuming everything fits properly.

Thanks again for writing this program,

Kris

Interesting. Maybe those 0.4 µs pulses are not sufficient for 8 AMCs, but for 3...

What fuses did you use?

To be honest, this was my first time doing any Atmel programming so I had just installed a fresh copy of AVR Studio 5 and didn't change any fuse settings. The chip on the board is a low voltage version (1.8V min instead of 2.7), an Attiny13V.

Perhaps with the stock fuse settings it defaults to a slower frequency? I'll gladly check the settings when I get home tonight if you'd let me know where I should check.

Kris

Yes, with stock settings you should get 2.35 kHz PWM frequency.

I think the timing should be off in your setting then; it was compiled for 4.8MHz CPU frequency, but it runs on 1.2MHz. How does strobe look? How long does the beacon take between two flashes? How long does the 5-min timer run?

Edit... Then again, I don't know what stock settings the driver has... the above mentioned are the stock settings for new bare ATtiny13s.

I just looked at the code again and noticed that you had the values for the low fuses listed after the frequencies. I'll try to find where to change the setting and make it 0x75 to run at 4.8 MHz, then try the tests you mentioned.

EDIT: I'm installing AVR Studio 5 on my work computer as I type this. I should be able to find where the fuses are set once it is installed.

Kris

I run mine at 4.8 as well, and set the fuses this way...

avrdude -c usbtiny -p t13 -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m

Not sure if I got all of the fuses right, but it works :)

It turned out that my stock frequency was actually 9.6 MHz. I changed it to 4.8 MHz using the GUI in AVR Studio. This set the fuses to H=0xFB, L=0x71. I'm still able to get light at a PWM of 1, but it is quite dim. I can look directly at the emitter through an 8 degree optic.

I was able to test the other modes as well. The beacon is 10 seconds, the timer works out to a little over 5 minutes, and the PWM frequency seems to be ~8.5 KHz if the PWM is set to 1-31, and ~17 KHz if set to 32-254.

My multimeter doesn't like the strobe, so I can't give an absolute value for that. It did look pretty good though. If the rest of the timings are on then it must be pretty close as well.

If there's anything else you'd like tested I'll give it a shot.

Kris

I am curious if there have been lights whose EEPROMs have worn out, hrm..

C

I implemented ramping now; it's actually only 25 levels of brightness ramping up and down within 4s each (so you see it jumping); tap at the desired level and you get that mode fixed. It costs about 200 bytes, so it's getting full now... 880 bytes used (including timer).

It writes 25 bytes per ramp, wear leveling sure comes in handy here.

I'll play with it for some days and then post the code here.

Ramping, why didn't I think of that? So once it hits the right level, you turn the light off then back on and it goes to that level?

Yes... My mode order is currently

moon, mid, high, ramp, use ramped mode, strobe, beacon, timer

(can be changed of course)

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.