Flashlight Firmware Repository

2241 posts / 0 new
Last post
ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US

TK,

Apparently nickelflipper had an alpha of his NANJG ramping driver:

http://budgetlightforum.com/node/33897

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

Jim

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

ohaya wrote:
Could someone build the .hex for luxdrv and for STAR?

I’ve been able to build a .hex – just using the minidrv for now.

I’ve been messing around with the modes, and I was wondering what is the minimum value for that in the array? From the comments, it looks like minimum is 5, but is that the lowest mode I can get? If so, it still seems kind of bright, so how do they get those moonlight modes that are lower than that?


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.

ohaya wrote:
Apparently nickelflipper had an alpha of his NANJG ramping driver:

http://budgetlightforum.com/node/33897

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


Maybe. However, it’s only an alpha debug version and there is no source code available.
ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US

ToyKeeper wrote:
ohaya wrote:
Could someone build the .hex for luxdrv and for STAR?

I’ve been able to build a .hex – just using the minidrv for now.

I’ve been messing around with the modes, and I was wondering what is the minimum value for that in the array? From the comments, it looks like minimum is 5, but is that the lowest mode I can get? If so, it still seems kind of bright, so how do they get those moonlight modes that are lower than that?


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.

ohaya wrote:
Apparently nickelflipper had an alpha of his NANJG ramping driver:

http://budgetlightforum.com/node/33897

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


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:

Quote:
int main() { DDRB=2; //define PB1 as output TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz EEARL=4;EECR=1; uint8_t mode=EEDR; //read from EEPROM if (mode>=sizeof(modes)) mode=0; //check if invalid OCR0B=modes[mode]; //set PWM level

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?

DEL
DEL's picture
Offline
Last seen: 2 years 9 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

ohaya wrote:

Hi TK,

For the Dr. Jones minidrv, he has:

Quote:
int main() { DDRB=2; //define PB1 as output TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz EEARL=4;EECR=1; uint8_t mode=EEDR; //read from EEPROM if (mode>=sizeof(modes)) mode=0; //check if invalid OCR0B=modes[mode]; //set PWM level

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 12×7135 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.

ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US

DEL wrote:
ohaya wrote:

Hi TK,

For the Dr. Jones minidrv, he has:

Quote:
int main() { DDRB=2; //define PB1 as output TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz EEARL=4;EECR=1; uint8_t mode=EEDR; //read from EEPROM if (mode>=sizeof(modes)) mode=0; //check if invalid OCR0B=modes[mode]; //set PWM level

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 12×7135 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) × 380 × 12, that is 17.88mA at the original 9kHz PWM?

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

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.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US
pilotdog68 wrote:
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”.

DEL
DEL's picture
Offline
Last seen: 2 years 9 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

ohaya wrote:

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) × 380 × 12, that is 17.88mA at the original 9kHz PWM?

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.

SciFiFreak
Offline
Last seen: 1 week 3 days ago
Joined: 02/11/2015 - 21:43
Posts: 109
Location: Boise

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

DEL
DEL's picture
Offline
Last seen: 2 years 9 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada
pilotdog68 wrote:
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.

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.

DEL
DEL's picture
Offline
Last seen: 2 years 9 months ago
Joined: 06/28/2015 - 08:35
Posts: 559
Location: Canada

ohaya wrote:

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”.

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)

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

ToyKeeper wrote:
Well, that was ridiculously easy. I should have tried this sooner!

Step 1: Connect an LED to the DMM. I used an old XM-L T6.
Step 2: Press the DMM’s “FREQ” button.
Step 3: Shine a light at the LED.

Instant and precise PWM speed measurement! Smile


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,

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

pilotdog68 wrote:
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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

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

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.

SciFiFreak
Offline
Last seen: 1 week 3 days ago
Joined: 02/11/2015 - 21:43
Posts: 109
Location: Boise

ToyKeeper wrote:
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.

Halo...
Halo...'s picture
Offline
Last seen: 4 years 3 months ago
Joined: 12/15/2011 - 02:39
Posts: 3304
Location: Halo island

pilotdog68 wrote:
ToyKeeper wrote:
Well, that was ridiculously easy. I should have tried this sooner!

Step 1: Connect an LED to the DMM. I used an old XM-L T6.
Step 2: Press the DMM’s “FREQ” button.
Step 3: Shine a light at the LED.

Instant and precise PWM speed measurement! Smile


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,

Try a small solar cell in a mostly dark room. Will produce a larger signal and their response time is suppose to be fast.
pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

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.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US

pilotdog68 wrote:
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

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

DEL wrote:
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 12×7135 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.


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 32×7135 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 8×7135 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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

SciFiFreak wrote:
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.

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

Ish.

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

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

ToyKeeper wrote:
Are you trying to make it remember after power has been disconnected, or remember after the e-switch has turned the light to “off” mode?

In the former case, adding memory will involve making it read/write the mode in eeprom. Check the “store_mode_idx” and “read_mode_idx” functions in the base STAR code. Calling store_mode_idx is the only thing which will allow it to remember the mode across power disconnects.


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) ?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

pilotdog68 wrote:
… 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;
pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

ToyKeeper wrote:
pilotdog68 wrote:
… 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.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

pilotdog68 wrote:
ToyKeeper wrote:
pilotdog68 wrote:
… 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.

ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US

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

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

ohaya wrote:
Hi,

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

I have a very cheap test rig:

Quote:
I have a cheap XM-L mounted to one of these:
https://www.fasttech.com/products/0/10001927/1163600-353510mm-aluminum-h...
The screws are the perfect size for a 20mm mcpcb.

Then I use one of these as a makeshift pseudo power supply:
http://www.banggood.com/DC-LED-Digital-Controlled-Step-Down-Driver-Power-Module-p-910096.html

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.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ohaya
Offline
Last seen: 2 years 7 months ago
Joined: 03/16/2013 - 19:01
Posts: 5337
Location: US

pilotdog68 wrote:
ohaya wrote:
Hi,

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

I have a very cheap test rig:

Quote:
I have a cheap XM-L mounted to one of these:
https://www.fasttech.com/products/0/10001927/1163600-353510mm-aluminum-h...
The screws are the perfect size for a 20mm mcpcb.

Then I use one of these as a makeshift pseudo power supply:
http://www.banggood.com/DC-LED-Digital-Controlled-Step-Down-Driver-Power-Module-p-910096.html

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…

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 days 2 hours ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

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

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.

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

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.

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/30/2013 - 23:31
Posts: 6420
Location: Held against my will in IOWA, USA

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)

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

Pages