[UPDATE:v1.7.1,Q8&1chanOTSM]bistro-HD, bistro your way. OTSM, eswitch(devel), Vcc reads, safe_presses, turbo timeout...

Flashlight Modding and DIY Parts
177

Build details explained

Several preconfigured builds are included. Many represent rebuilds of older
versions. Level of testing varies widely but many of the features included in
the builds are tested (a few aren't yet). All builds now include the new thermal control method. Most now include powersaving (Noah's torch: 40 days and 40 nights of moon mode).

default: This has no gauranteed setup. Probably will remain a Tripple build and
may have new features come and go. It's purpose is to be THE definitive
baseline configuration file, including all the latest build options (although
some will be commented out, but still there). If starting a new configuration
from scratch or studying the options, this is the one to look at.

II.1 attiny13 compatible builds (will auto build for attiny13 and above)

biscotti-HD:
Based on TK's biscotti,
Target layout: nanjg105D, 1-channel FET only
Limitations:
Very minimal, no OTC, no med press, noreverse, no hidden modes,
no muggle, no moon.
Features:
Includes turbo-timeout/bump-up in attiny13.
3 strobes, 4-bar battcheck, LVP, OTC-less short-press detection.
HD Features:
Original biscotti included no thermal or turbo-timeout.
Extra room in HD allows TURBO timeout/bump up (like BLFA6) in attiny13,
or the new bistro-HD thermal step-down in bigger attiny's.
Corruption protection for OTC-less press timing makes clicks more
reliable. (SAFE_PRESSES)
Modgroups:
13 modegroups including strobe groups and reverse to make up for
minimal features.
Notes: There is no reason a BLFA6-emu-like build cannot be constructed for a
convoy board layout.

battcheck-divider: flashes adc channel for voltage read from divider using 1.1V
internal reference.


attiny25 compatible builds (everything els):

BLFA6_EMU-HD
Mimics BLFA6_emu code, but configurable with any bistro-HD features.
Target layout: BLFA6 2-channel FET+1, but doesn't fit on attiny13
Only for attiny25 and higher.
Limitations:
battcheck is "only" 8-bar version (by tradition), No OTSM in default
config (but can be for attiny25+)
Features:
Almost full bistro features: OTC, medium clicks, reverse, hidden, muggle,
moon. 8-bar battcheck. Temp calibration in attiny25+
HD Features:
Includes TURBO timeout/bump up (like original) in attiny13, or new thermal
step-down/bump-up in bigger attiny's.

Modegroups: Very simple, only 2 groups included, 7 modes and 4 modes.
Strobes and turbo are in hidden modes.


classic-HD
HD version of classic bistro
Target layout: BLFA6 2-channel FET+1, only for attiny25 and higher.
Limitations: No OTSM in default config (but can be)
Features:
Full-featured: OTC medium clicks, reverse, hidden, muggle,
moon. Volts+tenth battcheck.
HD Features:
Bistro-HD thermal step-down.

Modegroups: 10 modegroups, from 1 1o 6 modes, including strobe groups.
Strobes and turbo in hidden modes.

trippledown-HD
Essentially identical to classic but configured for a TA 3-channel
FET+7135s+7135 board. Uses original bistro tripple-down modes.

TAv1-OTC-HD
Essentially identical to classic but configured for a TA 3-channel
FET+7135s+7135 board, and TA's extended modegroups. v1 refers to version 1
of the TA boards.
Modegroups:
Includes TA's v1.3 modegroups, 26 modes in all including a two
added by me (HD has room for more)
See Tav1.3+ modegroup listing in Apendix below.
HD Features: As all before uses new thermal control.
Benefits from added space to get a couple of new modes.

TAv1-OTSM-HD
The flagship build. OTSM Uses large cap to run timer during power-off,
creating reliable, stable click-timing.

Target layout: TAv1 tripple with OTSM components (see details in manual),
1S only for this build.

Otherwise the same as TAv1-OTC, but uses "internal" (inverted) Vcc voltage
reads. This generally does not require calibration to be pretty close to
right.
HD Features: OTSM, Vcc read, HD thermal control

TAv1-OTSM-LDO-HD
Same as TAv1-OTSM-HD, but uses vcc-referenced divider reads needed for OTSM
in builds >1S. Works on LDO or zener builds if appropriate diode (or high
quality LDO) is used.
HD Features: OTSM, vcc-referenced divider reads, HD thermal control.


highly experimental builds

e-switch-noinit-HD:
This is an experimental build for e-switch support.
Layout: TAv1, 1-S or LDO, no OTC, standard TA divider
Features: standard bistro with TAv1.3+ modegroups
HD features: Eswitch, HD thermal control.
Note: almost completely untested

dual-switch-OTSM-HD:
This is an experimental build for dual switch, e-switch plus click switch,
with OTSM timing for the click switch.
Layout: TAv1, 1-S only version, OTSM parts, no OTC
Features: standard bistro with TAv1.3+ modegroups
HD features: Eswitch, HD thermal control,
adds dual-switch-noinit: Enables noinit timing control on clicky switch in
a dual-switch light.
Note: completely untested, Use the highest reccomended OTSM divider resistors
(or try a bit higher) to reduce drain during e-switch off. With 4kOhms ,drain
will be around 1mA which is about 120 days of power from a 3Ahr battery, but
voltage drops continuously over that time. Power it off with the
click switch when shelving it.

dual-switch-noinit-HD:
This is an experimental build for dual switch, e-switch plus click switch,
with no timing cap on the click switch.
Layout: TAv1, 1-S or LDO, no OTC, standard C2 is fine (not OTSM), standard TA divider
Features: standard bistro with TAv1.3+ modegroups
HD features: Eswitch, HD thermal control,
adds dual-switch-noinit: Enables noinit timing control on clicky switch in
a dual-switch light.
Note: completely untested

dual-switch-dumbclick-HD:
This is an experimental build for dual switch, e-switch plus click switch,
where click-switch does nothing (no mode change), light comes back on as it
was, like a long press with mode memory. Especially useful if e-switch is
set to not use mode memory, best of both. Requested by Lexel.
Layout: TAv1, 1-S or LDO, no OTC, standard C2 is fine (not OTSM)
Features: standard bistro with TAv1.3+ modegroups
HD features: Eswitch, HD thermal control,
adds dual-switch-dumbclick: Overrides all mode changes if click switch is
press--> just turns light off, and back on as it was.
Note: completely untested

dual-switch-turboclick-HD:
This is an experimental build for dual switch, e-switch plus click switch,
where click-switch always goes to TURBO
Layout: TAv1, 1-S or LDO, no OTC, standard C2 is fine (not OTSM)
Features: standard bistro with TAv1.3+ modegroups
HD features: Eswitch, HD thermal control,
adds DUAL_SWITCH_TURBOCLICK: click switch always goes to first hidden mode
(TURBO in this case).
Note: completely untested. Likely non-sensical, eswitch needs low leakage
but OTSM needs fast leakage, probably 1mA anyway.


4-channel-dual-switch
This is an experimental build for dual switch, and 4 pwm channels
Really it's just a rediculous concept demonstration config to prove how much stuff
can compile and still fit in an attiny25. The concept was actually tested a
little at some point though, with 4-channels certainly working, but calling it
experimental is an understatement.

Layout: quadrupledown, 1-S only, OTSM cap and parts,
4th PWM channel on OTC pin. E-switch and click switch both detected
on voltage pin.
Features: standard bistro with TAv1.3+ modegroups
HD features: Eswitch, OTSM, 4th-channel PWM, internal Vcc read, HD thermal control
Modegroups: Presently it's actually just setup with the 3-channel modegroups of
TAv1.3+, so it's not really even using PWM4. It would need customization.
Note: almost completely untested, would need a separate build for LDO version
(because it uses OTSM).

178

Have you tried 4-channel PWM on hardware?

I got it working in FSM, but the 4th channel is inverted and I haven’t found quite the right tweaks yet to un-invert it.

179

Yes, I tried it, although I don't promise that it works in precisely the latest build combination, but the code for it should be fundamentally fine. Yes I definitely had inversion problems at certain stages of developing a solution at least. This is precisely one of the biggest cases the simulator came in very very handy. You can step through tick for tick and watch what the timer ramps and matches are doing and see when the interrupts get called, and watch your portb values.

I don't recall all the details now, maybe it will come back to me. Just looking quickly at my code, it seems I set portb on compare match, and clear portb on max. That does sound pretty backwards and even seems contradictory to my not very clear comments for the interrupts, and I kind of recall being temporarily((and now again) confused by this. I'll see if I can get a chance to run the simulator in the next few days and try to remember what's going on.

Mostly unrelated, but the biggest problem in the end was getting the light to shut off. Again I forget the details, but there is some delay or jitter in the interrupt calls that makes full off not happen. So I passed a global (actually a general purpose register bit, to facilitate streamlined assembly interrupts) to the interrupt handlers that disabled them entirely for mode 0. I didn't test extremely low modes extensively. As I recall the timing error on the simulator was around 6 timer ticks, but the simulator runs I think at 1MhZ, so one could hope that's about 1 tick in the real world.

Wish I could remember this better, might soon.

180

I do seem to recall that my timer is counting down, not up, and that does explain the backwardness. The thing I don't remember is why it's counting down. I think this is configurable right? So did I configure it backwards for a reason? I don't recall.

Update: Well, I just ran the simulator, and it's definitely counting up (and the manual says it should). So ... hmm.. So let's define the question better. Did you copy my implementation and that's inverted or did you re-implement it and yours is inverted? I've got a test rig read to flash and can test this again very quickly as soon as I get to it. It turns out I'd forgotten, but the modegroups included do include a 4th pwm for testing still, so it's ready to test as is. I'll give a shot again soon.

In the end though, if it's inverted, reversing the interrupts is clearly the cure.

181

I implemented it last month sometime, and didn’t know you had one until yesterday. I’ll have to check how yours works and see if it resolves the issue I ran into. The inversion isn’t really a problem though; it’s just inconsistent compared to the other three channels. A bigger problem is that the lowest few levels appear less stable, but it sounds like you ran into something similar with inconsistent timing.

For my purposes it’s still fine… but if there’s a way to improve it I’d like to do so.

182

Yeah, I'm starting to wonder if the header file has the interrupt vector numbers swapped. It's worth a look at the header or the proprocessor output to see. No reason to stay inverted though. Just swap the interrupts.

I tried to compensate the low-level timing error and failing. In the end, the off-override was the way to do it. You save quite a few bytes by keeping these interrupts in carefully crafted assembly that doesn't touch any registers, and getting the override variable to work with that was fun. The trick is that if you use the machines gpio registers (which aren't normally used for anything) that you can do conditional logic with them without first copying them to working registers (which would clobber something in the interrupted process, which would thus need the usual full stash and restore mechanics the compiler performs).

183

Well, the header is fine. It's also possible that my interrupts are just backwards and broken now. In the end I used timer1, non-phase, which should be pretty simple.

184

So funny enough, my interrupts were reversed. I think I know why now too. I remember switching this from some testing last minute and thinking it seemed wrong. It was, that test was flawed too.

Anyway, I'd never tested with a proper driver (just a resistor from the mcu) until now. With a 7135, I just tried a moon level of 4/255 at 16khz. It works fine. I didn't test down to 1. 255 works too and everything in the middle. So I'll be swapping the interrupts back as they should be in the next release.

In the end though, no, there's nothing inverted about it. It works the way I'd expect it to (which just happens to be wrong presently).

185

version 1.4 posted,

* 1.4 Enhancements:
* Applied TEMP_STEP_DOWN to all configs as default now, replaces bistro thermal regulation.
* Added an eswitch-TA-HD build (hunh.. why wasn't that there before?). Experimental single e-switch build.
* ALthough dual-switch-noinit should also work on a simple e-switch light.
*
* Added safe_presses to dual-switch-noinit-HD
*
* 1.4 Bugs fixes, cleanup, etc:
* Fixed bug in 4-channel PWM.
* Fixed bug where fast presses wouldn't time-out in a strobe mode.
* Fixed mode_idx initialization when FIRSTBOOT wasn't used (Kfulton's BLFA6_EMU random-mode bug, first exposed in 1.3)
* Arranged for safety check to prevent corruption etc from potentially resulting in getting stuck in non-existent override mode.
* No code-size cost for this check! Corruption may still cause an un-predictable brightness level, but will reset on next short-click.
* This is actually a secondary guard for the BLFA6 random-mode bug and other similar problems.
*

186

Hmm I got drivers with odd behavior

it has extremly low timing for the medium press
ist almost impossible to do short clicks

I checked the 47uF voltage it falls slowly when the switch is pressed
also all parts were checked and the solder pads soldered by hand again

Then i tested another Driver with v1.4

It seems the newer versions of OTSM hex make this
the old v1.3 from march works well

187

Thanks for the feedback. I found the problem. I accidentally sneaked in an incomplete part of a new feature that I thought I'd commented out. Simple fix. I'll release an update 1.4.1 along with a new 1.5. In a few minutes.

This actually confirms to me that I should finish that new feature. I actually almost like this new timing (it's exactly twice as fast for short-med threshold, although it wasn't exactly meant to be). The new feature is supposed to allow it to be right in between those two speeds without losing much cap time. Of course the actual speed would still be adjustable, just more resolution for the adjustment. Well no complaints about the old timing, so probably not a priority still. With twice as fast I could just BARELY manage a short click with double-clicks, if I tried very hard. To me, that's almost perfect, but a little too fast.

188

Posted version 1.4.1 (just fixes the timing bug) and 1.5 (fixes many bugs in e-switch build). I tested timing on both, they're working much better.

189

Dedicated Q8 build

Updated to 1.6 with addition of a dedicated Q8 build with a new layout, customized mode ramps and an indicator. Tested on a Q8 mockup. I'd consider 1.5 more stable at the moment for other builds. Please try 1.6 though.

/* Latest Changes
*
* 1.6 Enhancements:
* Includes Q8 specific eswitch build for FET+1 and indicator LED "bistro-eswitch-Q8-fetplusone-HD.hex"
* Ramp matching is designed specifically for the Q8
* Light is off with switch pressed. Long-press off. Indicator/locator acknowledges off press.
* Adds a new Q8 layout and adds the INDICATOR_PIN layout define, and USE_INDICATOR config define.
*
* Bug-fixes : Fixed corner case that would cause high off-drain in dual-switch OTSM config.

190

Instructions for single-point "Internal" read calibration using battcheck.

I kept meaning to add the math arithmetic to the comments in fr-calibration.h, still didn't. The issue with calibration is that the voltage references on these chips have a big tolerance.

But to calibrate the inverted ("internal") READ_VOLTAGE_FROM_VCC method used on 1S OTSM builds, you can run the battcheck with a full battery and it will flash out an adc reading, let's call it R

example strobe.. 7 ... pause strobe : R = 70

strobe 7 ... 2 strobe: R = 72

The goal is to get the internal reference voltage (which I should probably just flash out, but...), so

V_ref= (Vbatt-0.2)*R/255

R is the ADC readout and the 0.2 is a correction for the diode and may depend on your diode.

So that's it, get R from battcheck on a full battery and use 4.2 for Vbatt, plug into your calculator and you have Vref.

Place the Vref value in fr-calibration.h (#define reference_V) , and recompile.

So for example if you had a 4.2V battery and battcheck flashes 75 you get

V_ref= (4.2-0.2)*75/255 = 4.0*75/255 = 1.176 V

I will add this to the manual and comments for future reference.

191

Regarding the Q8 build. Staring at it and observations about the light a little, the modegroups are maybe tilted a little too much toward the low side. The ALL7135 equivalent is set at about 15% of output, and it seems like it should be closer to 25 probably. Also modegroup 17 has two equal modes, oops. I'll probably either bend the ramps or modify the modes a little to fine tune it for the Q8.

192

Posting here for those following. The Q8 build is still untested, and the first problem is found. It's setup for a voltage divider but the Q8 doesn't have one. It's a 4 keystroke fix and will be in the next release. That release won't come until after I get a chance to test it in an actual Q8.

If anyone playing along compiles themselves the fix is just to comment out the divider read option and uncomment the vcc read option in the Q8 config, and recompile.

193

I ran into problems with v1.5 on 1S boards
one 1/3 drivers the timing worked, the 2 other did not work medium presses

194

Thanks for testing it and for the feedback.

So you've got the exact same software and different hardware and you think it's a software problem?

It's not completely impossible for that to be true actually, but it's far from likely.

Do they all work on older versions? You are using a different cap from me, and for the small LDO boards you're not using a diode, something I've never tested myself and it depends on the LDO quality as you've seen. Is this an LDO build? Does it have a diode?

It's possible that you're right on the edge with your hardware, and some work and some don't. Watchdog clocks have a little variation. Capacitors have a little variation (20% actually for yours), etc. My hardware has TONS of room to spare, but if your hardware is marginal, then this can happen.

Have you ever gone through the exercise of determining how much extra cap time you have? Voltage measurements are one way, but the most reliable is to use the OTSM-debug config option and compile.I probably should document that better, not that anyone will likely read it. Then on every click press it will flash out the number of sleeps that occurred. For long presses you'll either get the number or a 255(or maybe nothing instead of 255). No blinking at all or 255, means it lost power. A number (in quarter seconds) means it was still going. So you can see what the longest click possible is.

Did you try them with an earlier version? Even if the answer is yes and they worked, it doesn't change the possibility of things being right on the edge, but it gets more interesting. I have tested timing on 3 boards with >1.5 builds and they all work. 2 of those were OTSM and one was e-switch, which never runs out of power. Anyway, let me know if and which earlier version worked.

If you're using different hardware though, you really should go through the exercise of running that test.I haven't invoked that config option in awhile, so let me know if it's not working. There's a chance the debug blink-out got moved to early with some changes.

All this said, there is a known bug (that I'm zooming in on slowly I hope) that causes very occasional instability, that was introduced somewhere recently I think, I'm guessing maybe between 1.4.1 and 1.5, but, although it does present strangely, never anything remotely like what you're describing. Still if 1.3-r2 works for you, great. (I may re-post it soon).

I'll take note though and keep an eye out for poor timing performance.

195

it was normal 1S builds
same hardware as usual

flashed v1.3 on them after v1.5 failed and it worked flawless

I did one v1.3 on 2S with diode after the LDO and it worked fine

196

hmm,

Same hardware as usual still doesn't tell me if your hardware is on the edge of working or not though.

How does 1 work and 2 don't? It's the same software. It's very strange. If they all have room to spare, that would be interesting to know.

However, 1.3-r2 is still the most stable build for basic OTSM and I'll repost it when I get a chance. Maybe when I fix the other bug we'll see if it fixes your issue too. I don't see how, but I don't know.

I'm zooming in on the other one.