Flashlight Firmware Repository

Realtime battery status on a clicky shouldn’t be terribly difficult. Of course, it can’t display anything while it’s off. :slight_smile:

Details aren’t worked out, of course. And it’s hard to add more to STAR because it doesn’t leave a lot of extra room… but after removing things we don’t need any more (like solderable star support), there’s enough room to add other stuff.

Well I have a special use in mind. The driver will (almost) always be powered, but quick interrupts will be used to change modes.

I swear I knew you’d come up with something like this when I read your post #742. Must be a special kind of tailcap board again or some sort of on-on-clicky?

hey,

I’d appreciate some help. I played around with bistro, wanted to make a single channel version for a p60-drop-in with 105C-based-driver, that’s working so far. I know it’s also quite easy to make a 2-channel-driver out of a 105C by rearranging the traces a bit, that’s easier in fact. But with this Nichia I wanted to prioritize best as possible tint over efficiency, and a smooth as possible ramp. And that’s where my lack of knowledge comes to play. If I were to increase RAMP_SIZE to 128, would that cause any trouble? I tried to adjust both attiny.h and bistro; https://www.diffchecker.com/ow8bdznq; https://www.diffchecker.com/7rr33hvf. But that doesn’t seem to work right… What am I doing wrong?

To increase the ramp size, you’ll need to turn off something else to make room. The ramp itself can be calculated by level_calc.py. I’m not sure right now how hard it’d be to disable dual PWM entirely, but if there’s room you can always just leave the second channel at all zeroes.

I’m on a phone at the moment, so I can’t really do much with the code…

Thanks Tk!

Ramp was calculated with level_calc.py, 128 modes, I think I got dual PWM disabled completely, compiles (2022 bytes, 98,7 % Full, with AS6.2) and flashes fine. All modes ramp up, but Turbo gives two short flashes, little pause, than 100% const. Also the ramp with the modes that work correct doesn’t seem as smooth as the ramp of my X6 with dual channel driver and bistro with 64 mode-ramp.

The bottom end of the ramp will be less smooth with more 7135 chips on a single channel. The steps are bigger, and in the lowest modes those steps are pretty visible. Notice how it has a bunch of the same number at the beginning, then at the end there are 5 PWM levels between steps? A bigger ramp can’t increase the physical resolution of the hardware.

As for the highest mode blinking, I suspect that might be because the soft start uses a signed 8-bit integer to determine how far to ramp (and which direction), and your path from zero to full is one step too long for a signed 8-bit int. Perhaps try with 127 or fewer ramp steps?

hmm, now that you say it, it makes things very clear. Yery well explained, thanks. Maybe I should give a dual channel 105C a try.

I went down to 100 ramp steps, now it works when going through the modes normally, but reversing from moon to turbo still gives weird flickering. Since I have only forward clickies in my P60 hosts (that has to change) I will be ditching offtim3 anyways, however I still would like to find out what causes it.

I’ll have something shortly and will make my own driver thread. The code itself is not much different to current voltage reading code. It’s just run much more often.
Disclaimer: More often than Star. I haven’t looked into any other firmware than my own for quite some time.

Dear ToyKeeper,

I am building a 7.2V light which will be flashed the Baton firmware. Would you please educate me that the ADC_0, ADC_25, …. ADC_100 are used for.

Am I going the right way to modified the codes like this. The R1 is directly connected to B+, no diode in between.


Those values are used to control the realtime battery indicator lights, and to decide when low-voltage protection should start.

Rather than calculating with a formula, I find it more reliable to measure. You can do this by using the battcheck.hex firmware. Basically measure a full battery and a near-empty one, then use the battcheck.py script to calculate the values at each voltage, then plug those into the actual firmware you want to run.

Many thanks for your prompt reply.

I have omitted to read the README enclosed in the battcheck folder. I will try the battcheck firmware.

Thanks again, your Baton firmware is working great.

Excuse me. Would you please guide me how to run the Python scripts. My pc already have the Python 2.7.6 installed.

I have checked the ADC of my driver with my battery pack as following;
214 - 8.30V
175 - 7.21V
The battery pack was discharged to 6.07V and then recovered to 7.21V after removed the loading.
I have translated it to 4.2V, 214 - 4.15V, 175 - 3.61V and put them in file mydriver.volts as per your description.
However, I have no luck to run the scripts.

I don’t really know how to run these things in Windows. I tried Windows for a short while in the mid 1990s, but haven’t used it since.

You do bring up a good point though, that the voltage calculator should probably support voltage ranges other than the usual 1-cell li-ion configuration. This might be a little tricky due to driver sources assuming they’re running at 3-4 volts though.

What’s an easy way to post/share code? I thought I would share the variant of BLF-A6 I “made” today.

It’s for single channel drivers, has the specific header files integrated, and it has battcheck in volts plus thenths style. I know it’s nothing big, but a buddy of mine asked for it, and I thought maybe someone else finds it useful… Tested and calibrated it on a 105C 8xAMC7135 driver from Simon (Convoy) with added 1µF OTC from Star4 to ground.

Thanks FmC.

Ok so here you go: BLF-A6 single channel battcheck vpt

This should work, but might be good idea if someone with actual programming knowledge could look at it. I think it makes a hell of a driver out of a cheap 105C, without major modifications (just add OTC).

This was was tested and calibrated in an Eagle Eyes X6 host, spring to switch tailcap bypass, 8xAMC7135 105C driver from Simon Mao, spring bypassed.
OTC was Murata 1µF,0805,16V, X7R, soldered a bit strange

The .hex file can be found here

Anybody want to do a bit of work for me? I promise I can’t pay anywhere near a fair wage for your time, but I could send a few bucks via Paypal.

DEL previously helped modify blf-A6 so that Pin 3 could control the FET on my TripleDown boards. It didn’t look to me that it was a major change to the existing FW, but what do I know?

Job 1: Do the same thing with STAR momentary: make a “255” value toggle pin3 instead of the normal output

Job 2: Do the same thing with STAR dual-switch, as well as add dual-pwm support (that might be a bigger job?)

I think your knowledge of coding and all the driver stuff exceeds mine by far

I won’t even bother to mess with job 2 ATM

Anyways, I did this out of interest and for the purpose of learning something, maybe. I would be surprised if it works and if I’ve done it right. I have no e-switch host to test it.

But maybe it’s a starting point for someone who knows what he’s doing: :smiley:

diffcheck job1

EDIT:

I am sorry for posting such crap. This doesn’t even compile right. I had
#define TURBO 245
in there, and at least it compiled. Must have taken it out before posting. But anyways, it doesn’t work, I’ve tested it, goes 245 on channel 1 instead of driving the FET…

I recommend github.com for sharing code. That way if you need to make a change you always have the version history to go back to.