Flashlight Firmware Repository

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.

Ok, I’ve been trying to get this to work for a few days now. Everything compiles and flashes fine, but nothing happens when I actually try it.

So.

Instead of trying to get memory working (apparently difficult), how can I just have it so that STAR momentary starts in the first mode as soon as power is applied (hopefully simple) ?

I think all you need to do there is change the default value:
volatile uint8_t mode_idx = 1;

Unfortunately, that didn’t work. I even completely removed “0” from the mode order, still no dice.

This is a tough nut to crack, apparently.

Maybe I need to disable sleep mode somehow?

Edit: So I commented out the two instances of “sleep_until_switch_press()” Now I get light as soon as I apply power, but it doesn’t respond to switch presses anymore.

I took a look at it, and it seems there are two changes needed, not just one.

First, set this…

volatile uint8_t mode_idx = 1;

Then later, replace the first sleep with a WDT_on:

// Enable sleep mode set to Power Down that will be triggered by the sleep_mode() command.
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
//sleep_until_switch_press();  // <- this line is causing problems
WDT_on();  // <- but this line needs to be here

That worked for me, at least.

Hi,

I was wondering how do you all test your firmware? Do you do it in an actual light?

Is there a light that it’s easy to remove and replace the driver+emitter, ideally w/o tools or something? I’m thinking like maybe light with a pill with a retaining ring so it’s easy to pop the driver out and flash it then put it back into the pill and then put the pill back into the light?

Hmm… Maybe the older HD2010 is like that?

The reason I ask is that it seems like it’s hard to get the driver to behave the same way that it does inside a light vs. say on a bench?

Jim

I have a very cheap test rig:

When I build a driver, I first flash the MCU with battcheck. Then I solder/reflow all of the components onto the PCB and solder the leads to my power supply and LED. Next, run battcheck to get my adc values, and plug them into my chosen firmware. Then I flash the firmware, check it for functionality, and install the driver in my light.

If I’m lucky, I’m done. But usually I have to go back and reflash once (or twice) to adjust the turbo timer or dial in the mode spacing.

Hi,

That’s a cool heatsink… I’ll throw one in my cart next time I buy something from FT :)…

What about the switch/clicky? How do you have that setup?

I have a tailcap that I modified by soldering a wire to to the negative ring, and I hook up my bench supply to that, but it seems hard to simulate the click timing when everything is not fully in a built light. I don’t know, maybe it’s the ergonomics. or something…

I normally use just the head of a light. For button presses, I connect and disconnect power. Usually this just means tilting my thumb while it holds a wire to a battery.

E-switches are harder. I have one driver with a built-in switch though, so that helps a lot. And RMM sells extra e-switches which can be wired in.

I have a reverse clicky wired into the negative lead coming off my power supply.

RMM sells eswitches? I’ll have to check them out. I’ve just been soldering a small wire to the esw+ pad and then tapping it in the ground ring.

Thank You TK!

Just (almost) finished a super-simple UI for the X6R I’m doing for my grandfather.

The X6R is a dual-switch light. I am using a custom driver with 2 banks of 3*7135’s (6 total)

- Rear switch ALWAYS turns the light on high, Full on both banks (2.28amps)

- 2min turbo timer steps down to a hidden mode, 1 bank switches off (1.14amps)

- Side switch changes from high to low (PWM controlled) and back to high

  • Total 2 normal modes + the one hidden medium

That’s it.
All i have left to add is code that shuts the light off when the charger is connected. I’ll start on that tomorrow.

On the off chance that anyone else could have usr for this, here is my .c file, next to the original STAR momentary file. (original is on the left)

That is some interesting and large variation. All 7135s are obviously not created equal.
If the emitter makes a difference it is simply because the 7135s are not turning on fully?
Note that it may be normal for the tiny to have less trouble turning on one 7135 than multiple 7135s. I only looked at turn-on time with 8 7135s. The MCU output has limited drive current and it has to feed the combined 7135s gate capacitances at the start of each pulse. This is like shorting the MCU pin momentarily to ground until all these (very small) parasitic ‘capacitors’ charge up. Would have been great if we actually had a datasheet to know what we are dealing with.
If it is useful I can take oscilloscope screenshots some time to show the turn-on delay of the 7135s. Maybe compare 3**, 4**, 6* and 8* 7135 drivers.

This is my deluxe wooden light for testing :). At the moment it features an ISP quick connector soldered to a 105C to save the clip and frustration. The switch is a regular reverse-clicky from an old light.
The local 1000 uF capacitor is required to run PWM properly when hooked up with 1m leads to a power supply.

Scope shots would be cool. Comfychair published some a while back, but he and his site went down since then. Here’s one of his results though:

In any case, yes, the emitter matters. With otherwise identical hardware, an XM-L2 will light up at a lower PWM level than an old XM-L. It also depends on the type of 7135 chips; the 350mA ones behave a little different than the 380mA ones. And it depends on the number of 7135 chips… it seems like 1x and 32x light up at pretty low levels, but 4x and 8x might require something a little higher (maybe). I haven’t tested the number of chips very much though.

I’ve seen a few drivers light up at fast PWM=0, a bunch at phase PWM=2 or 3, and a couple as high as fast PWM=9.

Anybody know if it would cause long-term harm to the Attiny13 for it to receive 5.5v directly to one of it’s I/O pins? I’ve tried it, so I know it doesn’t fry immediately.

Not sure but could we just add a zener in line?

If necessary I definitely could (easily).

Pyro, you probably already know I’m talking about the X6R driver.

That’s why I said “we” :wink: I remember that you put a resistor pad for pin 3 does a resistor not work to bring it to safe limits?

Oh BTW liking the firmware you’ve tweaked for it will probably use it with mine.

Ooo that would save us a pin!

EDIT: Sorry, I understand now that wouldn’t work. Would still need to use pin3

The rating of the IO pins is tied to what you feed on pin 8 (Vcc).
Except for pin 1 (the reset pin), the ‘absolute maximum’ rating on any pin is Vcc + 0.5 V.
And the maximum rating for Vcc is 6 V.

(Datasheet 18.1)

But running close to a device’s absolute maximum rating is usually a bad idea.

The datasheet says this: