Flashlight Firmware Repository

Same thing I noticed wen using the tripledown drivers. I did not notice it on the Avenger drivers, so pretty sure it is due to the voltage spike that DEL discovered.

Ahh. Ok, that makes sense then.

Does it? I’m not seeing the connection between the “soft start” and the turbo->moon flash.

And aren’t you using the TripleStack, LR? The stack has the same updated circuit as the avenger boards, different from the older TripleDown

I’ve been using a scattered collection of drivers. I havnt noticed this on the triple stack.

The preflash only happens when going quickly from a high mode to a low one, with a brief period of power disconnection between. So, it normally only shows up when going from turbo to moon with a short press.

The difference soft start makes is that every clicky mode change goes briefly to moon before ramping up. So, it would happen while going from medium to high, high to turbo, and turbo to moon. It blinks for a tiny fraction of a second before the ramp-up starts.

I guess it happens on other drivers too, without soft start, but it’s not noticeable because the next mode is brighter than the previous one (so a preflash isn’t significantly different than the intended output mode).

Just so you know PD, I am not saying you did anything wrong with the tripledown at all, it is a great design. Heck I can’t say anything seeing as I copied it for the TA drivers.

It just happens to be the one I am using that doesn’t have the new DEL components and the TA drivers do.

Interestingly I get the flash in all modes, although it is not as noticeable in the high modes since they are already so bright. Just a flash slightly longer then a single bike flash and apparently using the FET or bank of 7135’s even when they should not be engaged.

It is not a big deal, just something kinda odd.

This might be what I am seeing as it does happen with every mode change.

No worries, I’m just trying to understand. I’ve only experienced the Turbo-moon flash on one driver and even then it only happened once or twice. I guess I should count myself as lucky.

Likewise the soft start was never my cup of tea, so I should be even less worried about that.

I have a set of the SS/Cu X6/X5, and they are probably the least used of any of them. The X5 has never seen a battery, and the X6 had one for all of 2 hours. So I’m hardly an expert on bistro.

in the biscotti.c
I’m only uncomment #define ATTINY 13
and flash wth this: avrdude -c usbasp -p t13 -u -Uflash:w:biscotti.hex -Ulfuse:w:0?75:m -Uhfuse:w:0xFF:m
Yeah, that’s a mistake. Incorrectly written FUSE :slight_smile:
0?75
In the first mode PWM frequency 2kHz in the second 17kHz


No, they are 35% and 50% (really 46% and 49%). Yes, they are too close. I use #define RAMP_FET 1,9,34,61,99,137,255 and it works fine correct on all my 6*7135 drivers.

It’s funny you mention that. I put it in originally as a ramp test for later use when going between modes on an e-switch driver, then forgot to take it out before other people tested it. Was going to remove it, but they liked it so much they insisted it stay.

It wasn’t originally supposed to be there. :slight_smile:

In bistro, is there a way to have modes outside of the loop? Like make my own special modes?

For instance, in the S8 that is linked in my sig, I have two white LEDs and a red LED. I have a low and high on the red, and a low-med-hi on the white. Normally I have the UI go: Low red>high red>Low white>etc. But if I am in turbo white and LVP kicks in, I don’t want it to jump up to high red after low white. Is there any way to specify these Red modes outside of the normal Ramp table?

I thought about specifying them after Turbo in the table. So if Turbo is mode 20 in the table, then make the red modes #21-#25 or something. But then if LVP kicks in when I’m in a red mode, it will jump to Turbo first and that’s no bueno.

Would it be easy to make my own special modes that aren’t in the ramp? Or maybe to change LVP so that it steps down to set values outside of the Ramp table? (I assume that would not be simple to do.)

You could put them in the hidden modes, far as I know you can put any mode you desire in the hidden modes. So you can enter mode 6 for example and it will come up in the hidden modes. Obviously just have some modes setup for what you want in the ramp table.

I’m not sure what you’re saying TA.

What I would like is that the lowest mode is Red low, and use that as my moon that I can toggle on and off. Then advancing forward it goes to the white modes, and reversing backwards it goes to high red first, then to batt check.

I’m just not sure how to put high red so that I can specify it as a mode, but not in the ramp table so it never comes up when I’m ramping down in LVP

You could put high red as the last mode in the ramp table. Then LVP should not touch it.

Although you can also define a custom mode, although not totally sure how to do it. That would be a question for TK or Tom. I am actually curious on that as well, I could see other uses for custom modes.

I did define some custom strobe modes but I just copied and pasted the code so not exactly sure what did what.

But then it would step down from red “high” (which is actually only about 200ma) to turbo in the LVP logic, right? I might just do it that way anyways because I rarely let my cells get low enough to trigger LVP.

Correct, if it triggered LVP while in the red led that would happen but that would be a VERY low battery.

I know it is pretty simple to define a custom mode out of the ramp table, I have done it, just not sure exactly what it was I did that made it work. Although for a 2 LED light some firmware meant for it would be best obviously.

:wink:

I actually started on a solution to that a couple weeks ago. It’s described (with some incomplete code) in this comment: Flashlight Firmware Repository - #947 by ToyKeeper

It shouldn’t be all that hard to finish, but I was waiting to see if you liked the idea.

Basically, instead of assuming that LVP should follow the ramp while stepping down, it defines another “stepdowns” array stating what the “next lower” level is from each item in the ramp. That way, it’ll handle the red-only, white-only, and combined modes with entirely different stepdown patterns. Does that sound like what you’re looking for?

Well, I was fully prepared to just set max red as the last mode in the ramp and just avoid draining the cell to LVP level, but a better solution would be welcomed. I definitely still need temp monitoring (or just a timer, I rather like the traditional turbo timer that can kick buck up on command). Sorry I missed the earlier post. I’m not sure how I did, it’s pretty big. Maybe it’s my recent lack of sleep, but I didn’t really follow what you said there.

This:

… This sounds good though. I wouldn’t need the combined outputs for this build, but for other types of applications it may be nice. Just as long as I can figure it out :blush: