Flashlight Firmware Repository

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.

In hopes it’ll help me actually get stuff done, I posted my todo list at the beginning of the thread:

Help and encouragement are welcome. :slight_smile:

The repository is currently using bzr + Launchpad instead of git + Github, but migration is still possible if a majority of the people involved want to switch.

I realize git won the DVCS wars, so bzr is definitely not the most popular choice. Launchpad now supports git though, so it’s also possible to use git without actually moving to Github.

As for Launchpad vs Github, many of their features overlap but Github is organized per-person while Launchpad is organized per-project, Github has some wiki-like features, Launchpad has much more extensive bug/task tracking, and there are a variety of other significant differences.

In any case, the options are on the table but would need a majority in favor. So far, there has been very little interest in revision control and project management tools, so I’d be happy with pretty much any system as long as people used it. I’d much rather review merge proposals instead of pulling files from forum posts, pastebins, and dropboxes…

I’m an avid github user. All my personal code is on it and all my code for work is on it as well. I’m biased, but when I found the Launchpad site it took me too long to find the source code. To me that’s the number one feature of a code repository - SHOW ME THE CODE. With Github a project might be under a user, but there’s no limit to the number of contributors you can have. Also it’s distributed so anyone who wants to do their own thing can fork off of the main repo and it doesn’t affect that main repo in any way. Maybe the code gets merged back in, maybe it never does. Github also has organizations (that are free to create) for projects that turn into a real community effort. A lot of projects that start out under one person’s account get transferred to an organization as they take off.

That’s just my opinion but I haven’t actually contributed any code yet so I consider it fully without merit or standing. I’ve got a lot of ideas though, and debuggers recently delivered and a sack of Nanjg 105c’s on a slow boat from China headed my way. I’m fully cognizant that there’s nothing you can’t do on Github, Launchpad, Gitlab, etc and I will get source code from wherever the developer chooses to share it. When I have something to share I’m putting it on Github.

From what I recall of its early days, Github started as a simple place for individual people to share git repositories. Other features were added later but weren’t as deep a part of the overall design. So, it excels at “show me the code”. Launchpad was designed more as a full-featured large-scale project management platform and a replacement for older systems like Sourceforge. Designed specifically for facilitating Linux distro development with thousands of contributors and complex relations between individual component projects built together into a whole. Its broader focus makes the code somewhat less front-and-center.

Both are good tools, though their styles are very different.

Git and bzr are functionally and conceptually almost identical. The main differences are a matter of interface. However, there is one significant conceptual difference — bzr has a concept of a “mainline” but git does not. This explains some of the consequences of that: Merging in bzr: The git approach vs the bzr approach

In common usage, git is dramatically more popular. They use different terms for the same concepts, which can be confusing. Git puts all the heads or tips into one directory while bzr defaults to one directory per head and one head per “branch”. Git prefers to wrap or reimplement common tools for use on a single directory while bzr encourages using stock tools on separate directories. Bzr supports git as just another pluggable storage back end. Git favors fast-forwards and implicit merges, while bzr favors explicit merges.

For BLF purposes, the technical differences are mostly unimportant. It’s primarily a matter of what the participants want to use.

Soo, the attiny25/45/85 has a useful extra feature (not available in tiny13) that I’ve been meaning to bring up. Tiny25/45/85s can measure their 1.1v bandgap reference. And this is really useful to us because by setting the ADC reference to vcc and measuring the 1.1 bandgap we can calculate the battery voltage. Of course it’s backwards from how measurements are normally done (use a known reference to measure an unknown) but it doesn’t matter.

Looks like setting REFS[2:0] to 0bX00 will select vcc as ADC reference, and setting MUX[3:0] to 0b1100 will select the 1.1v internal bandgap as the voltage to measure.

Apologies for letting time slip by, not bringing it up sooner.
I would have posted this in the attiny25/45/85 thread but it seems to be occupied with other things at the moment.

Hmm, interesting. So if I understand correctly, we could free up a pin and maybe remove two resistors on 1-cell tiny25/45/85 drivers? And this wouldn’t work on zener-style drivers because VCC is artificially capped?

In exchange for freeing up a pin and potentially removing a couple components, the voltage resolution would be decreased somewhat… but we’re already getting ~4.5 ADC units per 0.1V, so we have some resolution to spare right now. And it’s currently only using 8 of the 10 available bits of precision anyway.

Is this more or less correct?