E-switch UI Development / FSM

You could also maybe drive those from the aux LED pin, using the existing facilities for that. Maximum power is lower though, like maybe 30 mA instead of 350 mA. And it’s not really dimmable except for high/low/off. But, for designs like this, I recently added some support for making the aux LEDs and main LEDs mutually exclusive, so it won’t have both on at the same time. It would still be a little awkward though, since that would mean the aux LEDs are only on while the driver is asleep, like in “off” mode or lockout mode.

Ideally I want to drive the Yuji off the 7135 channel, changing the ramp to accommodate them. They will be a pre throw warm flood. They will also serve candle mode.

The niggle with them is they really only like 30ma each so the PWM values will all be low. I am guessing MAX_1x7135 should set the max 7135 PWM value for the strobes?

Yes sir, 5mm 3200k :slight_smile:

The MAX_1x7135 value determines which ramp level is the highest before the FET activates. It does not determine the PWM value.

If the emitters can only handle 30mA each, and there are three of them, it may not be a good idea to drive them with a 350mA chip. Even with PWM to reduce the average current, the momentary current will still be about 4X the safe level.

But if you try it, it looks like the 7135 part of the ramp should max out at 65/255. (3 * 30mA / 350mA) * 255 = 65. So, after calculating a ramp, multiply all the 7135 ramp values by about 0.257 to scale them down to the desired ceiling level.

Or you could maybe replace the 7135 chip with something lower-powered
 or put a lower-powered chip on the aux LED pin and treat it as a 3-channel driver.

What does FSM stand for?

Frightening Spaghetti Monster.
Or Finite State Machine.

That is better answers than Wiki gave me. :+1:

Do these drivers have the voltage divider resistor? There are two resistors clearly shown on the fourth picture. It it near the 7135 chip or on the opposite side?

Finite State Machine, or [F-word] Spaghetti Monster.

Why? Because it takes the mess of spaghetti code typically associated with low-level firmware and locks it away in a box where people don’t have to care about the monster inside. Instead it presents a more user-friendly interface in the form of a finite state machine, because that’s typically how people describe flashlight UIs. A finite state machine is basically a flowchart.

Suggested F words include:

  • Flashlight
  • Flying
  • FSM
  • Feisty
  • Filthy
  • Fabulous
  • Funky
  • Fancy
  • Fetid
  • Fortuitous
  • Frightening
  • Flirtatious
  • Flimsy
  • Frustrating
  • Formidable
  • Flaccid
  • Fantastic
  • Feculent
  • Friendly

Or people can probably think of a few other choice F-words. :wink:

Yes, the one labelled R1, connected to pin 7, is along the path which allows current to leak. Removing it would stop the leak.

For BLF-A6 and Bistro, this is a good thing. The offtime measurement depends on current leaking out at a predictable and high enough rate. And for multi-cell serial lights it’s necessary to scale voltage down to a usable range. But for single cell e-switch lights it’s not desirable.

Those banggood drivers don’t have a tiny85 though, so they can’t run FSM.

Thanks TK for all the explanations. I have put Attiny 85’s on a couple of these drivers and run the eswitch between pin 2 and earth.
When I read through these posts I feel like a Friggin Scared Moose. :stuck_out_tongue:

I figured that what else it could be while laying in bed thinking about this. Too far into this hobby where this ends up happening


I would definitely need to test this on the bench with the PWM to see how it behaves. I have seen a test of these where at 120mA they start to go blue
 Are there lower power 7135s?

There should be lower-power chips of the same general type. I’m just not familiar with them.

Lots of code updates lately, though most of them aren’t UI changes. Most are to keep code cleaner and more manageable, splitting hardware-specific bits out into their own files and such. This way, new drivers can be added more easily with less clutter. Drop in a hardware layout definition and a UI config file, and it should be pretty much done.

Due to the way the C preprocessor works though, it does typically still require adding a couple lines to the main source files. But the changes there are a lot smaller than they used to be, and easier to read.

Anyway, I paid off some technical debt so I’m done for the evening.

:+1:
Thanks TK.

@TK
I couldn’t compile the latest anduril r344 for BLF Q8 in Atmel Studio 7.0
Got this error: #elif with no expression anduril.c Line 72

But it was an easy fix by changing:

#elif FSM_BLF_Q8_DRIVER
to
#elif defined(FSM_BLF_Q8_DRIVER)

Thanks TK for all your awesome work!

Oops, that’s definitely a typo. Fixed.

I wonder how it even compiled like that. I’ve been using a script lately to build every supported version every time instead of doing just one, and the Q8 version built and worked normally under gcc 4.9.2. But it looks like it really shouldn’t have worked


Since it’s a thing people might want, and since I think Lexel may have been requesting it, I took a moment to make a Werner-style momentary UI, side e-switch plus tail clicky-switch.

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

The short version is:

While completely off (power disconnected):

  • Click tail to turn on at memorized level.
  • Hold e-switch and click tail to enter utility mode.

While on (regular “on” mode):

  • Click tail switch to turn off.
  • Click side switch to go brighter.
  • Hold side switch to go dimmer.

In utility mode:

  • Click side switch to go to regular “on” mode.
  • Hold side switch to go turn on at lowest level.
  • Double click side switch to turn on at highest level.
  • 3 clicks: Battcheck.
  • 4 clicks: Ramp config.

Battcheck mode: Blinks out battery voltage.

  • Click to go back to utility mode.
  • 2 clicks for tempcheck mode.

Tempcheck mode: Blinks out current temperature in C.

  • Click to go back to utility mode.
  • 2 clicks for battcheck mode.
  • 4 clicks for thermal config mode.

Thermal config:

  • During first “buzz”, click N times to set floor level to N out of 150 total levels.
  • During second “buzz”, click N times to set ceiling level to 151 minus N.
  • During third “buzz”, click N times to set number of total brightness steps.
  • Each “buzz” can be skipped to leave the value as-is.

Ramp config:

  • During first “buzz”, click N times to calibrate current temperature to N degrees C.
  • During second “buzz”, click N times to set thermal ceiling to 30 C + N.
  • Each “buzz” can be skipped to leave the value as-is.

Includes LVP and smooth thermal regulation, copied directly from Anduril.

nice

Is it possible to change the brightness of the low level of the indicator LED in the code. I have found nothing. Thank you

Nope, that is set entirely in hardware. It depends on the indicator LED Vf, the battery voltage, and the resistor(s) between them. Note that, in low mode, the attiny’s internal resistor is active, which is why low mode exists at all.

The code can’t change this, because the MCU is asleep and not executing any code. The PWM facility isn’t active.