Flashlight Firmware Repository

What settings are you using for stop motion strobe? I could not totally figure out how you were calculating the pulse timing into hz so I just used the 10hz strobe and then each of the tactical strobe timing by themselves. Have not had a chance to try them yet other then testing though.

Far as the bike mode goes, like I said, I am of the mind that the single flash bike strobe is both safer and easier on drivers while still getting their attention. A single flash doesn’t instantly bring to mind a cop (and the inevitable check of the speedo and driving conditions to see if he is after you). Plus you are not likely to stare at it which means there is less chance of hitting it.

I also have not science to back up my side, just my personal feelings based on being a driver. Another user also had some good points about the german laws as well.

As a bonus if you went to the single flash you would free up space for other features.

The tiny25 runs at 8 MHz while the tiny13 runs anywhere from 3.6 to 4.4 MHz. So, to get the same pulse length it needs a PWM value about twice as high, at least on the lowest modes.

In both cases, it’s likely using phase-correct PWM to slow down the pulses by half, but that just means ~8 vs 15.6 kHz instead of ~16 vs 31.2 kHz.

So yes, it’s caused by swapping the MCU.

Also, if moon is on the third channel (pin 2 or 3), IIRC, the PWM speed is twice as fast again. So, it’d be running at 31.2 kHz. I never figured out how to slow down the 3rd and 4th PWM channels. But IIRC the driver puts the FET there, which should work out better since the FET can handle faster speeds and it eliminates whining sounds on the high modes.

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