Flashlight Firmware Repository

The soft start bit ramps quickly from the old mode (usually “off”) to the new mode, using a very crude decelerating curve. So, it moves quickly at first then slows down as it approaches the desired level. It does this by sliding along the ramp, so it only works with a pretty large ramp, like at least 40 values long. The code is optimized for size, not accuracy.

In general, soft start is only visible when turning the light on, when it ramps from off to whatever mode is selected, in something approximating a constant amount of time. This makes the ramp more visible on low modes because it moves slower. Soft transitions can also be seen on LVP step-down. The intent was to use it for all mode changes on an e-switch light, but I haven’t made e-switch code with it yet…

Anyway, some drivers have a preflash issue, visible when going from a high mode to a very low mode. This is entirely a hardware issue and can’t be solved in code. For bistro, it’ll be especially visible because of soft start, because every mode starts low. It should look like a very quick bright flash followed by the usual ramp-up. It only happens when the previous mode was pretty high, and only if the power was off for a short time. It’s by far the worst on high-amp triples and quads. I forget what exactly caused it, but it took the circuit folks around here a while to figure it out and eliminate it.

The bistro code was initially designed with this in mind, but I haven’t actually done the rest yet…

Rewriting it to do everything with an e-switch would be a pretty big project though. Clicky switches and e-switches require very different code. I have a design in mind for an entirely new e-switch code base, intended as a foundation for others to build on, but haven’t really started on it yet. Have been talking about it for at least a year now and haven’t done it.

The basic idea is to build a flexible “finite state machine” driven by an event parser and callback system. People would create new interfaces mostly by putting data into a big table describing the various states, event types, and state changes. Basically, build a flowchart of the interface you want, and dump the flowchart into table form. Plug in small custom functions here and there as necessary, or some useful defaults will be provided too.

Once I have the code base working, the actual interfaces should be relatively simple without the need to write much (if any) logic code. Instead you’d just define a bunch of data in tables. Each position on a flowchart is a state, each arrow is a state change, and the label on the arrow is the event type. You define the states, changes, and events.

I don’t know what kind of MCU it will require, but probably a tiny25 or bigger.

That’s weird. A 8x7135 Nanjg 105D is what I used to create and test the code, and what Convoy is using in the new C8. I tried a few and they all worked, then tried the 3x7135 and 4x7135 and 6x7135 versions which also worked.

Did you change anything else in the code? That 1/255 value should be running at 1 kHz instead of 16 kHz, meaning it’s actually on for 16 clock cycles per pulse. (or was it 2 kHz? I should really measure it) Then the 15/255 value is running at 8 kHz, so it’s on for 30 clock cycles per pulse. The others are more straightforward.

Yes, but it’s a lot simpler and smaller to make no-turbo mode groups instead.

Easy enough, I already did that so I will just stick with that. :+1:

For stop-motion strobes, I generally do a turbo pulse for 1ms or 0.3ms, depending on the strobe speed, and then leave it off for much longer. The frequency is simple to calculate; a delay of 41ms (plus 0.3ms for each pulse) is 1000 ms / 41.3 ms, or 24.2 Hz. The speed will vary per-MCU though, especially on tiny13a.

I find that a 1ms pulse is a bit long for things like falling water, so I only use it for slower strobes. However, a 0.3ms pulse is both somewhat dim and a little unstable. This is because I’m still using PWM=255 for the strobe modes instead of using the pin as a simple on/off switch. That means each strobe pulse must last for a multiple of 256 frames, and I’m not synchronizing to the PWM counter so most pulses end up being 0.384 ms while some are 0.512 ms. Or maybe it’s 0.256 ms vs 0.384 ms, it’s hard to tell. Regardless, they’re short enough that the PWM cycles become an issue, and I’ve been meaning to fix it for ages.

If you prefer single-flash for bike mode, go for it. It saves space and might look nicer. I put it in the code for those reasons. :slight_smile:

So those values are ms? I could not tell if they were clock cycles or ms. That makes things simpler, although how would you set it to .3ms?

Yep, I swapped to the single flash bike strobe.

For the 0.3ms delay, I added a “delay_zero” thing in some projects. Look at s7.c or blf-a6/cypreus2 for an example.

I’ve built two drivers with where soft start caused a very slight studder when advancing modes. It would jump to a level close to the intended level and then reach that level. Reflashing with soft start disabled eliminated the problem in both lights and reappeared when flashing back to enabled. Just a weird observation.

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: