Flashlight Firmware Repository

I just noticed something else. What would happen if I changed this line.

#define FAST_PWM_START 8 // Above what output level should we switch from phase correct to fast-PWM?


What would be the effect if I changed that 8 to like a 50?

The reason I ask is it seems to have reduced the whine of the medium mode slightly ( maybe I imagined it), but I am wandering if there will be any side effect? Like a flicker on med or something?

Phase correct is slower PWM. But different people have different tolerances for flicker. If this is for a personal light and your aren’t bothered by it then no harm.

In general, phase-correct PWM tends to be easier to hear than fast PWM… but it really depends on the harmonics of your exact build.

I’d like to see if the whining issue goes away with attiny25 drivers and a higher clock speed.

The loudest I’ve heard is actually a different issue… on my Cypreus (triple XP-L HI, FET+7135), it clicks every time it goes between off and turbo. So, the strobe modes make both light and (a bit of) sound.

Ya, part of what has me so stuck right now is the light body I am using. I finally gave up and JB welded the driver and insulated it with some foam in addition. There is still a little whine when its outside the host, but much less. However the body of this light is a very thin stamped metal that acts like a radio antenna when its installed.
http://www.flashlightmuseum.com/Rayovac-Flashlight-D367F-7-Cell-Sportsman-Hunting-Light-with-Leather-Strap-7D-1970

Very cool and retro looking, but man has it been a pain.

I have something strange happening. Can you see any reason in this code that the turbo timer would step down at 30 seconds in the first group, and not step down at all in the second group?

edit: here is a diff check. (Stock BLF A6 on the left, the FW in question on the right.)

I tried both “255” and “TURBO” to designate turbo in the mode groups, and i tried both 88 and 90 as the turbo timeout, but still the same results.

I don’t see anything which looks like it would explain that, but you might want to also remove the details for the hidden modes instead of just setting the count to zero. And I’d suggest setting channel 2 to 0 instead of 255 while on turbo, since the 7135 chip actually reduces output on turbo.

With those settings, turbo should be stepping down at 45 seconds, not 30 seconds.

I’ll try that. Is there some kind of clause in the FW that doesn’t trigger the timer when only the 2nd channel is at 255?

Turbo only activates when the first power channel (FET) is at 255. Here are some lines which explain why:

#define TURBO     255
...
output = pgm_read_byte(modesNx + mode_idx);
...
if ((ticks > TURBO_TIMEOUT) && (output == TURBO)) { ... }

So, it bases its actions on the content of the modesNx array. This gets pointed at either the first or second mode group’s FET channel.

I tried it with this one: https://www.diffchecker.com/zxnq3xvg

Still the same behavior. In the first mode group it steps down at 33 seconds, in the second mode group it doesn’t step down at all.
……………………….
Edit: For a sanity check I flashed the unmodified blf-a6 file and it behaves similarly. It steps down at 33 seconds in both mode groups. This leads me to believe I have a hardware problem. I’m going to try swapping the mcu.

Edit 2: Swapped the MCU and the turbo timer still behaves the same. However one thing has changed, I now have the dreaded Turbo-to-moon flash (Which I have never had with these parts before and was not there before the MCU swap.) Anybody have any ideas? I’m planning on starting from scratch with a whole new driver next.

BTW, you can modify the timing if you want. Change the value of DELAY_TWEAK and it should alter the timing of almost everything the driver does. In general, it should be clock-speed-in-MHz times 250. However, on common attiny13a drivers the actual clock speed seems far less than its spec’d 4.8 MHz. So, it defaults to 950 (3.8 MHz) instead of 1200 (4.8 MHz).

In your case, it sounds like 1300 (5.2 MHz) might be about right… which is odd. (45 / 33 * 950 = 1295)

About not stepping down in the second mode group, I don’t have an answer. It worked when you tried the stock firmware but not a modified one… but all the modifications looked fine.

I wonder if setting the 7135 channel to 0 on turbo might help. This should reduce the heat level of the driver and increase lumen output, and I wonder if maybe the MCU could be overheating. I’d also suggest making it blink on step-down, for debugging purposes, and set the step-down to be much shorter (again, just for debugging).

In the most recent attempts I did have channel 2 at 0 for turbo. Heat shouldn’t be an issue at all, I am doing these tests outside of the light on my desk, amp draw capped at 1.2amps.

Started from scratch and built a new driver. The FW in question does not work correctly on this driver either. I flashed a stock version of blf-a6 I had saved from back in May, and it appears to be working normally. The delay tweak of 1300 seems to have gotten the timing close to normal too. I know I am using a new spec C1 than I have before, could that be causing the issues?

I just saw something really obvious that I missed earlier. (It helps to be awake while reading code. :slight_smile: )

Turbo steps down to the second-highest mode. And by second-highest, I mean second-to-last. Your second mode group has turbo in the second-to-last position, so it steps down to itself.

If you have no hidden modes, there is no need to step down from the “hidden” turbo, so it should work better to simply reduce the index by one. Instead of this:

mode_idx = solid_modes - 2;

Try this:

mode_idx —;

I feel like I should’ve caught that myself…. I’ve had to change that a few times before.

Could you share your build.sh shell script? I assume from the output that’s it simple and straightforward but still.

Yes, it’s at the link in my signature.

FWIW, I added another published branch called “sandbox”, which holds stuff that has been checked in but isn’t quite ready for merging into the stable trunk yet.

https://code.launchpad.net/~toykeeper/flashlight-firmware/sandbox

For example, one extra in there right now is a s7.c firmware with its battery check mode changed to use a volts+tenths style readout. This style does work on attiny13a chips; it just takes enough room that I haven’t been able to fit it into blf-a6.c.

I’m debating whether to freeze blf-a6.c or keep allowing changes to it now that we’re post-production. I’ve refactored quite a bit of code shared between projects, including blf-a6, and am not sure whether to put the refactored one into the main branch or leave it in its production state. It’s both simpler and more complicated now, since some common functions moved into shared headers.

Hey all,

Are there any of the OS firmwares available that have an oscillating strobe? Not one that changes each time you turn it on, but one that changes frequently while its on?

I was going to ask about implementing this. I’ve read that a random strobe is much better at disorienting. Averaging around 12hz (?) but without always the same length flashes or pauses between flashes. This keeps the brain from being able to anticipate the next flash.
Does random require much resources from a tiny13?

I'm not aware of a strobe that does that, but certainly it can be done, just need to know a little about the randomness, constraints, etc. Any references for this? Great amount of detail and research explained here:

http://www.candlepowerforums.com/vb/showthread.php?356772-Police-Study-of-tactical-use-of-Strobe

Best reference I've found.