Flashlight Firmware Repository

I've done lots of 85's with my latest firmware - goes really smooth now, no hickups, but this is my first 25V using bistro. I used 25's back in the beginning though.

Got the new 11-08 version with the new fuse settings (e2, df, ff) and it's still working the same - always comes up in config mode. How is it supposed to start up? Is there a default mode set?

I'm confused, info is sketchy, TK doesn't seem to be around.

I think TK will be back next week. I cannot remember what planet(s) she was visiting but she is coming back soon.

Hi, I was temporarily tied up in Mordor, but now I’ve got a few days in The Shire to catch up a bit…

If it enters config mode, it thinks that fast_presses is greater than 15 (at least one of its four upper bits is set) and the OTC value indicates it was a short press.

So, this could mean that the OTC isn’t calibrated. Or it could mean that the mem decay trick isn’t working. I’d start by measuring the OTC values and then plugging them into a new build of bistro.

BTW, the weather in Mordor is nice this time of year.

I think I got a problem with the OTC cap - I added it later by hand soldering so maybe it got too hot, or bad solder joint. I'll try replacing it. Thanks!

If you want to you can add this firmware to the site:

I’m mighty impressed that you can get internet in the Shire. :smiley: Never looked like they had much in the way of technology, at all. I mean they don’t even know how to make or otherwise acquire shoes! They make the Amish look like the Jetsons.

It was the cap - bad solder joint. Once fixed, it came up in 4 modes, well 3 modes plus moon. Think that's the default?

On to the next problem - high mode flickers on for a moment than switch's right a way to the 1st mode. If a use a higher resistance cell, the problem goes away. I noticed this behavior when trying to get a tailcap amp reading, even on the weaker cell. Don't think I ever saw a problem like this - not sure, maybe bad ground. Something to do with high amps, not just FET usage... Dunno.

Update:

Ok, - got a Fix!! Added a 2nd 10 uF cap sitting on top of the normal one, and wholla! Problem goes away!! Details in Post #580 here.

I've used this type of fix before, on a 22 mm driver.

Yup, that sounds like the issue I’ve been trying to figure out. About all I know about it is to add a second or bigger cap though, or maybe add a little one between VCC and GND, or something along those lines. I’m really not an electrical engineer.

TK - so are you gonna go with the extra cap? Are you still researching it? Is this happening on the X6/X5 driver version?

I'm wondering if there's any other effects - reduced amps or any other flakiness. Have you noticed any side effects?

Update:

The other really annoying issue has been the bright flash/blink, switching from Hi to moon/low. I added back the 12K resistor across the FET gate and it seems to eliminate it. I made some code changes to zero out the PWM outputs upon init, but that alone didn't help. I left those zero settings in the code though, because the state it's in now is perfect.

I tried a lot of firmware tricks to try to eliminate the turbo->moon flash, but nothing seemed to make any difference. It seems to be entirely a hardware issue.

About the extra cap, I’ve been away for a few weeks and can’t do much testing. However, I should have a fix to test when I get back home.

Adding a 12K resistor across the FET gait (to gnd) seems to have fixed it perfectly. I tested it on the bench and the flash went away totally, completely. Then, made the same resistor mod to a wight FET+1 driver, ATtiny25V, extra 10 uF cap stacked, running my own ported version of what started as STAROffTime (OTC). Installed the driver in a new style Convoy L2 w/UCLp, de-dedomed XM-L2 U2 (oopsy!) U4 1C on a Noctigon and got:

EFEST 26650 4200 @4.21v - 5.24A tail

1636 lumens @start, 1608 lumens @30 secs, and 282 kcd measured at 5m (1062 meters)

So I'd say the resistor and cap certainly don't seem effect performance, so far so good.

Cool!! Thank you for the trobleshooting.

I’m sure this information has been laid out somewhere for the simple-minded, but I don’t understand all of the “include…… .h” all over the code. This must be the reason I’ve stuck with blf-a6 code from May.

Grab a copy of all the .h files, tk-attiny.h, tk-calibration.h, tk-delay.h, tk-random.h, tk-voltage.h and place them in the same folder as bistro.c or blf-a6.c. You use to need to have the files in a particular folder but TK changed that, I believe the files in her main repository now include that change. You actually don’t need tk-random.h unless you enable random strobe in bistro but no harm in just grabbing a copy of everything.

So i need to do something with those files every time I want to change one of those settings?

Only if the setting you want to change resides in one of the .h files. For example LVP values and OTC values are in tk-calibration.h.

Thanks for explaining. What was the reason for moving it to this format?

I’m going to avoid the change for as long as I can, I would have to completely change how I store/archive/flash my firmwares.

It makes some things easier. Sharing code among different firmwares, doing updates. Also once you get use to it, some things are easier when using it. Once you set the LVP and OTC values for a particular board, you make a folder for that board and drop the tk-calibration.h (and the other .h files) in there. Build bistro.c or blf-a6.c from within that folder and it will use the correct values for that board.
So if you have 4 board layouts that could use slightly different LVP or OTC values, you don’t have to tweak 4 different copies of bistro.c or blf-a6.c.

It was really easy testing new builds from TK’s testing repository. Grab a new bistro.c, drop it into the folder with my tk-calibration.h set up for my board and build.

I guess I can see how that can be helpful, it just doesn’t mesh with how I do things. One day I’m sure I’ll assimilate, but