Flashlight Firmware Repository

TK,

Apparently nickelflipper had an alpha of his NANJG ramping driver:

Should that be in your repository (you were on that thread too :laughing:?

Jim

Ah, good. It looks like you figured out the build process.

The PWM values can go from 0 to 255, but the minimum depends on your exact hardware. For moon on a 7135 chip, I normally use a value of 3/255 or sometimes even 2/255, both running with phase-correct PWM. For fast PWM, the minimum will be a bit higher. For a FET driver, the minimum will be lower.

Maybe. However, it’s only an alpha debug version and there is no source code available.

Hi TK,

For the Dr. Jones minidrv, he has:

Is that 9kHz PWM considered “fast PWM”?

If it’s not, then would “1” or “2” work? [I guess what I’m asking is if there is some minimum value at which PWM stops working?]

Also, does the number of 7135s on the NANJG (in my case, there are 12 of them) determine how low the moonlight would be?

‘Fast’ is not necessarily fast, it is just ~double the frequency of the other option, called ‘phase-correct’.

Change
TCCR0A=0b00100001
to
TCCR0A=0b00100011
to get fast mode.

Phase-correct mode runs at 1/510 the frequency of the MCU clock.
Fast mode runs at 1/256 the frequency of the MCU clock.
(Both assuming your PWM clock pre-scale is 1 as per above.)

In theory the light output corresponds to the average current.
And average current = x/255 the full current capability of the 7135s.
(where x = your PWM setting)
In practice x has to be larger than 1-6, depending on the frequency of the PWM.
At 9 kHz, the 7135s only start to turn on after ~4/255 of the PWM period has already passed. This number depends heavily on cell voltage. At 3.4 V they may not turn on at all at 4/255.

For your 12x7135 driver you can approximate average current draw as about (x-5)/255 * 350 *12 at 9kHz.
And (x-10)/255 * 350 *12 at 18 kHz.

The 5 or 10 offset is to accommodate the delay of the 7135 to turn on at each PWM pulse.

It is a compromise, do you want high frequency PWM to avoid flicker and noise, or do you want to have more precise current control?
You can always run moon at 1-2 kHz and the medium modes faster.

Wow! Thanks.

I understand. So, basically, with that many 7135s (x12), and with 380mA 7135s, and set to 6, it would be average current of (1/255) x 380 x 12, that is 17.88mA at the original 9kHz PWM?

You also have the LED to worry about. Many simply won’t light up at all on 1 PWM, no matter how much current they theoretically are getting.

Yeah… that was what I was wondering/curious/messing around about, and whether it was even possible to get a reasonable moonlight with 12 380 mA 7135s. So far, from my testing, it seems like if I set the PWM to the point that the emitter lights, it’d have to be way too bright to be called “moonlight”.

Kind of. Your calculation is right on.
But it is very non-linear when you are at the edge of switching on the 7138s.
Your batch of 7138s may have slightly different gate characteristics, the MCU output as well.
And we are so close to the edge that the cell voltage makes a difference.
Something that worked for me was to bump the level by one at 3.6 V and again at 3.4 V.
The trick is to only go up with the bumping, otherwise you get a flickering candle.

With all of these firmwares being available has anybody thought about creating a library of functions? Would there be enough benefit in creating one?

That is not really the LED.
Try it at a low enough PWM frequency (below lets say 1 kHz) and any LED that lights up at 255/255 will also light up at 1/255.

The 7135s I looked at only start to turn on after about 2 us. They are only fully on after about 6 us.
So we want PWM pulses at least 6 us long to get semi-consistent operation.

If you want to accommodate 1/255 PWM that implies a PWM period of 255 * 6 us = 1.53 ms, or 654 Hz.

Easy test.

In the code above, select on the /8 prescaler for the PWM timer.
Then try 1/255.
You might not like the flicker, but it illustrates the point.

TCCR0A=0b00100001; //phase-correct PWM
TCCR0B=0b00000010; //pre-scale 8, so PWM at 1.1 kHz
or
TCCR0B=0b00000011; //pre-scale 64, so PWM at 140 Hz (should give terrible flicker)

Hmm, I just went to try this, and I am not having success. You just connected the LED+ to DMM+ and neg to gnd? My DMM has a Hz/% button, I assume that’s frequency,

LEDs aren’t very efficient sensors, so you might need to turn up the light you’re measuring to a pretty bright level, and hold it very close to the “sensor”. Also, it depends quite a bit on the DMM you use. The DMM I tried was a really expensive one, so I’m not surprised it worked so easily.

An actual photosensor should be able to measure much dimmer lights, but I don’t have one of those… so I ran an emitter in reverse. The efficiency is terrible, but it worked well enough for my purposes.

It’s funny you mention that. A couple days ago, I started exporting common code into header files so I can share it between different projects. It’s only the most basic stuff though, the things which have been identical in pretty much every project.

Making actual libraries is a much harder task, since on an attiny every byte counts. Libraries make it a bit hard to include only the specific bits of code you want, and hard to tailor that code to each project. But at least some things can be shared to avoid repetition…

The easiest thing to share is #defines. They take no room unless actually used. So, most of my headers are just #defines for calibration values, hardware abstractions, etc.

Maybe a compendium of useful functions, rather than a true library, is the way to go. You wouldn’t include it in your project but rather cut and paste the functions you want from some central, curated, repository.

Try a small solar cell in a mostly dark room. Will produce a larger signal and their response time is suppose to be fast.

I’m wondering if maybe my DMM doesn’t have the right frequency range. Its a Klein MM200

Unfortunately I don’t have a photosensor or solar cell.

It looks like the setting on the DMM can be either frequency or duty cycle? Maybe you need to push one of the buttons to change it to measure frequency rather than duty cycle?

It says that the display should show:

% > duty cycle
Hz > Frequency

Jim

FWIW, ohaya, I recommend measuring different values rather than trying to calculate what it will do. Try a PWM level, flash it to a driver, and try it with a full and an empty cell. If it’s too low, add one. If it’s too high, subtract one. Then try again.

At ~8 kHz, I have the BLF-A6 moon mode running at 2/255 on a single 7135 chip and it produces about 0.5 lumens. It decreases with voltage, but it’s not too bad… IIRC it drops from about 0.5 lm to 0.3 lm during the lifetime of a cell. On my attiny25 test host, I’m using 3/255 for moon on a single 7135, at 15.8 kHz, and it ranges from 0.55 lm to 0.34 lm (at 4.1V or 3.1V).

Sometimes even lower values work. My BLF-SRK with 32x7135 chips gets a moon mode at 16 kHz (fast PWM) with 0/255. Most FET-based drivers will also light up at 0/255 in fast PWM mode, but this level is highly voltage-sensitive.

FET-only drivers suck at moon mode; my last attempt with one of those went from ~3 lm (at 4.2V) down to 0.001 lm (at 3.6V) — even after I tried to correct for voltage by decreasing the off-time. So, at 4.2V it ran at 0/255 (16 kHz)… and then at 4.0V it did 0/128 (32 kHz), then at 3.6V it was down to 0/2 (~2 MHz PWM). It helped, but not enough. And I couldn’t bump it up to 1/255 because then it would go all the way up to ~10 lumens. At least it was neat watching the driver auto-adjust its output; it gave kind of a “soft turn-on” kind of effect.

Sometimes a higher value is needed. On a 8x7135 nanjg with an old XM-L T6, I couldn’t get the emitter to light up until 8/255 in fast PWM mode (~16 kHz). Swapping in an XM-L2 cut the lowest usable value by quite a bit.

Dropping the PWM speed does help with stability though… which is why I use phase-correct (~8 kHz) instead of fast (~16 kHz) for moon mode on most lights. But I haven’t found it necessary to drop the speed below that.

Mostly it depends on your driver, emitter, and cell voltage.

That’s kind of what the current code repository is. :slight_smile:

Ish.

At least, it does provide a bunch of different code to reference, and most of it is freely copy-able.