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

I haven't looked, but this bug sounds very feasible to me. I re-organized the defines several times, and the OTSM timing variables even more times. It was actually tested with an OTC driver in a recent prior version, but probably became broken with some "clean-up". I'll try to reflect this issue in the OP soon. Good fix.

Ok, so I see now he was trying attiny25, which I think I did test at some software version, so I'm not sure.

blfa6_emu , comment somewhere around page 4. BLFA6 emu was an attempt to make a stripped-down configuration that mimics BLFA6 and allows a potentially a couple of new features. I never quite got it to fit without getting rid of something though. It still could have its uses for people who are just used to the simple interface but want some minimal extra features in an attiny25. Like you can get a very similar turbo timeout/bump-up on the attiny25 version but with actual thermal "timeout". And it can use the redundancy trick for "fastclicks" or whatever it's called to avoid the RAM corruption issue. It's a stripped down starting point for customizing a relatively simple driver.

The report of it not working is with a MTN-17DDm, not a TA board. I have no idea if it's a software problem or hardware. Randomly cycling through modes without even clicking is very strange.

:person_facepalming:
:+1:

I can now confirm that tocirahl’s patch looks exactly right. This was a bug I thought I’d fixed, or meant to fix and forgot :person_facepalming:

At some point somehow I thought I’d surprised myself in figuring out that doing the define that way could actually work (would be nice). Then when I came back to reality I apparently forgot to undo that one (there were others). It’s definitely a bug, one introduced after I tested OTC, and the solution is the correct one. There may actually be some way to get the defines to re-evaluate retroactively, and actually I think I previously had a problem where that was happening unintentionally, but that involved more complex macro expansion and I really never fully understood it. It would be nice to put conditionals like this alongside the code, but never mind.

Version 1.3.2 Bugfix for OTC breakage in last release thanks to tocirahl for catching it.

http://s000.tinyupload.com/?file_id=86118170622813962762

-1.3.2 Bug fix for broken OTC timing, also updated the packit build target in the Makefile

Updated in the OP. Also note, as stated in the OP, the tested version (as in many or most of the builds were tested, not just OTSM) is 1.1 (1.0 is probably even more tested) Some glitches like this in newer releases are probably to be expected as I and others probably can't test every build with every release, and going forward that will probably require community feedback. If 1.3.2 doesn't work you, you might try 1.1, but please report back either way. KFulton, this advice might apply to you.

In the comments of the OTC wake timing defines there is also now a start to to more advanced timing method, not implemented yet. The idea is to run higher timing resolution up until the end of the short press, and slow it down after that, getting more fine grained timing control and saving cap performance too. It gets a little messy though and maybe it's not needed. Feedback from anyone trying higher timing resolution and shorter med click would be useful. I feel the default 1/2 s medium click is a bit too long, but 1/4 second might be too short, hence the need to double the timing resolution, to be able to make it 3/8 maybe.

To be a little more explicit here, the divider resistors are also documented there for series builds. I'm surprised if you got OTSM to work at all if you followed TA resistor values, but working and working well/reliably/reproducibly aren't the same either.

Oops, I forgot to rebuild the hex’s in the posted 1.3.2 release :person_facepalming: . The link is down now and there will be a 1.3.2-r1 link up in it’s place very shortly (if not already).

OTSM and zener

So it's been too long since I thought about some of these circuits. I dug this diagram that I made back up from the firmware development thread:

I'm liking this asci art for discussion. For future use, here's a full diagram of the standard TA layout (minus the LED circuit) with zener, I've changed the 5R resistance value to simply the R5 resistor label. I've actually never seen the circuit laid out as a full loop before.

Batt+ Batt-

|--| |-----|

| |--------*<-----| (tail cap LED, shorted by switch)

| |---------/ ----| (tailcap switch)

| |

| |

|---------BR----------------| (case ground plane, not equal to batt- when tailcap led is on)

| |

R5 |

| C1 |

|---------------||----------|

| |

|-----------R1---R2---------|

| | |

| Vsense pin |

(Schottky) V |

|--------------mcu----------|

|-------------<(zener)------|

Vcc |--------------||-----------|

C2

So, I had forgotten that TA's zener mod has a schotkey. I'm fairly sure early zener hacks didn't necessarily all have that. I also see that there is no balast resistance in parallel with the mcu, so that's fine.

So actually YES, I think OTSM could work with the zener mod, and that actually seems to be the context of the discussion I posted this figure in the first time.

The big question really is how fast and hard does the zener shut off as the voltage on C2 starts dropping from power shutoff. If it shuts down fast (for example 0.3V might be ok) and hard (<3 uA), then it should work the same as an LDO would.

I scrapped that build and ended up filing down the edges of the pill shelf so that a TAv1 would fit, but I still have the flashed/broken board. I will try the older build the next time I put together a S2+.

Just recently reviewed the BLFA6 config. There's nothing particularly special about it other than a different board layout. It doesn't even use the new thermal bump-up. It's basically just bistro with fewer modes and channels, and the 8 bar battery indicator. There is a possibility that some pin state settings are causing an instability in that layout suppose, but that's a wild guess.

The other thing though is that it is an OTC build, so certainly that was broken in the original 1.3 release, should be fixed in the latest release, and in the 1.1 release.

Yeah, if you felt like getting another data point it might provide a clue. I can't remember now is the DD17 driver you used identical to the original BLFA6 driver? Did you have to change the layout config?

It’s updated in the repository now.

One thing I am noticing in the BLFA6_emu is that the attiny>13 builds (the only ones that actually fit without removing a strobe or something) , the present version of the config does NOT use temperature step-down bump-up. It uses standard bistro "regulation". That's probably not how I meant to have it. I'll most likely change that in the future (already did in my development branch). Of all the builds that should get that feature by default, it seems this one should. I mean this feature was actually inspired by BLFA6's timeout in the first place. Oops. Oh well, not a problem until someone actually has it working, not to say that it's broken, we don't know yet, it may just be broken/not-configured-for KFulton's particular hardware, just don't know.

@KFulton Come to think of it, this may very well be your "bug". The bistro temperature regulation fluctuates the level up and down to try to control the temperature (I don't really like it personally, but it's all good because others do). Were you using turbo? Even if you weren't, maybe there's an issue with temperature readout, the default calibration, etc. One thing you could do try if you play with it again is going in the temperature calibration mode (menu 7), and clicking out during the initial 2-second low light phase. That should disable temperature regulation.

Bistro’s thermal regulation is pretty bad, TBH. It was barely sufficient for a single emitter in an X6v2 host, and probably not a good idea on anything with a higher power-to-thermal-mass ratio. I’ve made much better methods since then, but I haven’t tried to make them fit on attiny25 for bistro yet. I did at least put an upgraded method into Crescendo, but it takes a sizable chunk of the ROM and the adjustments are still pretty noticeable. The Crescendo regulation pattern looks like this:

Note: It’s normal and expected for the lumen output to rise a bit as the battery gets low, because there is less voltage difference between the battery and emitters… and therefore less heat. So, it can put out more light at the same temperature. And it aims for constant temperature, not constant brightness.

For what it's worth, I quite like the step down I've implemented. For anything but trying to get max lumens on a bicycle (changing wind conditions, undesirable to have operator intervention) I don't need anything more. As I've said before, my new method is intended to supplement TURBO modes, not regulated sustainable light levels. TURBO should go beyond sustainable and be available in bursts when you decide you need it. For turbo, presumably you're holding the light and in normal operation you don't even truly need anything on a decent quality light where the electronics won't overheat without the case getting hot. This thing provides a measure of protection in case you forget and set it down, while still providing the above, and the behavior will feel very similar to BLFA6, just auto-tuned to the thermal capacity of the light.

The new thing does this very very well in my opinion. I might just go ahead and make it default in classic and tripple-down as well if even the inventor isn't crazy about the old thing. Of course it's still not a regulated mode. It's a turbo protection.

Oh, and this is a nice plot. Well done.

Awesome, I didn’t remember that you upgraded bistro’s thermal code for bistro-HD. It looks like it does better than bistro in quite a few ways.

I’ve been meaning to merge the updates into regular bistro, or at least the parts which work on the old hardware, but I’ve been preoccupied with other projects. I was probably a ferret in a past life, because I like shiny things and my attention span is— ooh, what’s that shiny thing over there?!

If you ever get the urge to do runtime graphs, zak.wilson’s ceilingbounce app makes it pretty easy. I found it extremely useful when testing thermal regulation algorithms and a few other things.

Normally I don’t really care about thermal regulation. It’s easy enough to regulate the temperature manually. However, I’ve found that companies who sell lights don’t want to sell anything which could overheat when given to a monkey. So to make them happy I’ve spent way too much time trying to monkey-proof things lately.

BLFA6_EMU issues

I can now can confirm that 1.3-r2 BLFA6-emu was designed for people who embrace the unexpected, who like surprises, who are not frantically trying to control everything around them. If you are a free spirit like this, I will bring back 1.3-r2 for you. If you prefer to be more boring and control-freak like, and want modes to be actually predictable, you should use verstion 1.1 for BLFA6 for now.

I don't know what's causing this. 1.1 does work, but it has (non-problematic) quirks too. First, on first boot it starts in the menu, not horrible, but quirky, probably not too hard to track down. Second, I did get the same random mode change behavior with 1.1, but only when it running it still plugged into the usbasp. So that's interesting. One thing 1.3 did was "improve" pin state settings, and leaving it plugged into the usbasp is likely to pull floating pins up or down.... hmm. It's usually a bad idea to run that way, and often does strange things, but it's interesting that this time it does this particular strange thing.

1.3.2-r2 now has blfa6 still broken, but differently, so that may be a clue too. I'll have to track it all down. It's very likely either the pin state changes, thermal regulation changes, or changes to the fast presses code, as those are basically the areas with changes. It may not be isolated to only BLFA6, although I don't see any problem with tripple channel OTSM or OTC.

solved

I was initializing the default mode at startup but it has to be initialized after failing to read a saved mode. The failed read left it at 255. This resulted in a chain of undefined events that eventually led to an array under-read to set the level from some random changing piece of memory. The bug existed in 1.1, but other randomness resulted in it starting in the menu which actually fixed the mode_idx.

This was all fine on other builds because they used a different mechanism for first initialization, which is probably why I missed it.

The next release will include this fix, and probably not much more, so as to hopefully make a it a more stable release, not a more featured one.

Voltage read-out handbook: dividers, Vcc, "internal", LDO, demystified

Adding some sections to the manual in next release:

Appendix A. Voltage Readout Methods

Method 1, Classic divider (Non-OTSM, 1S or series):
Config options: READ_VOLTAGE_FROM_DIVIDER

Traditionally voltage is read across a voltage divider made from the R1 and R2
resistors. The ADC readout is made relative to the internal 1.1V reference.
In other words the ADC result is V_divider/1.1V * 255. This method does not
work for OTSM, because the voltage pin detects power off when voltage is below
about 1.5V. For this method, all divider voltages must be below 1.1, which
won't work for OTSM.

When to use: For any build without OTSM
Advantages: Works in 1S and 2S, 1 point calibration possible.
Disadvantages: Doesn't work with OTSM, requires a divider.

Method 2, inverted (aka "internal") reads (1S OTSM):
Config options: READ_VOLTAGE_FROM_VCC

This has been become known as "internal" voltage reading. It effectively just reads
Vcc, or the voltage on the supply pin of the mcu. However it does this
actually reading the internal 1.1V reference, but reading it referenced to Vcc,
essentially inverting the result. The ADC value procued is 1.1V/Vcc * 255. And
clearly Vcc= 1.1*255/ADC. It works well when Vcc represents the battery
voltage, ie in 1S.

When to use: Can use for any 1S build, but useful for 1S OTSM
Advantages: Should work pretty well with no calibration, and easy to adjust.
Can be used on small boards with no voltage divider.
Disadvantages: 1S only, Calibration theoretically more difficult to get exact.

Method 3 Vcc-referenced divider reads (LDO OTSM method)
Config options: READ_VOLTAGE_FROM_VCC
REFERENCE_DIVIDER_READS_TO_VCC

Like method 1, but references the divider read to Vcc. ADC result is
V_divider/Vcc * 255.

When to use it: This works for any LDO build, ie builds where Vcc is regulated
and can be used as a reference. It is only needed though for OTSM LDO builds,
but is likely to be better than Method 1 for any LDO build, due to the more
stable voltage reference.

Advantages:Most stable voltage reference can mean calibration-free.
Disadvantages: Requires regulated mcu input voltage (won't work in 1S)

Note, this may work on zener builds in theory, but depends on the stability
of the zener (for OTSM it also requires a quality schottkey protection diodes and
depends on the leakage of the zener).


Summary:
For non-OTSM builds with a divider the classic divider method is fine.
For 1S-OTSM or 1S with no divider or 1S for calibration free use, use inverted
reads (Meth 2).
For LDO-OTSM builds, use Vcc-referenced divider reads. (Meth 3)

Any OTSM build must have separate builds for 1S and LDO.

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).

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.