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

Well, the precompiled one was compiled by me on windows, but it was never about windows, it was about the version of the compiler used in atmel studio 5.0. I'm pretty sure (not 100%) with exactly the same compiler version and same arguments windows and linux will give bit for bit identical binaries. The precompiled hex's were compiled with atmel studio 7.0 not 5.0. I forgot the compiler version number. On 7.0 the few times I checked, I got within a couple of bits of what I was getting on linux, with similar compiler versions.

Well that can well be the difference. The LDO needs a very low reverse leakage current. This is not being picky. The diode I first used was draining a bunch of the cap's capacity, and it wasn't a bad diode. I called out a different diode from the usual TA one for a reason. And I don't know, maybe some of the standard TA ones also work, but maybe they all don't. I think I have a note in the manual or maybe somewhere around post 69 about how low the reverse leakage current should be, probably ~ 1uA preferably when warm if I remember right, and many are much much much higher. You really have to look at the graphs for the temperature dependence too as this increases quickly with temperature on some parts.

A problem with this OTSM stuff is that the chinese budget builds are likely to run into problems if they aren't paying attention to specs.

I am building the drivers with the TA parts list, I ordered only 50 LDOs of one kind
So if I would add a diode you have listed for the 1S driver after the LDO this would fix the problem?

R6 and 7 are just 0 Ohm resistors

I know, right? It’s pretty bad. Those crazy emus are always going on about how they don’t have a problem, they can stop any time. I think we may need to stage an intervention.

Yes, the picture brings it all back, this was indeed the plan for existing boards. Yes, I think it should work. Untested of courses, but I see no reason why not.

In fact, search "R7" on the OP and you'll find that's exactly how it's written in the manual. There are other things written there about this build that you might find useful too.

Now I'll have nightmares of being chased by torch-wielding emu's.

But seriously. What is a “blf emu issue”?

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.