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

Yeah, ok, there might be some slashes that need to be rotated 90 degrees. Sure even simple things require making time to do it. It would be nice if there's a way to generalize it to work. Dos might even accept the linux slashes these days and I'm not sure the command syntaxes are different other than the .exe's. There may be some other details though.

It may be fine. I didn't base that selection just on the label specs though. I looked for something with good DC bias curves and good temperature derating curves. Neither are shown for that. I didn't take any chances on the prototype because I wanted to make it work, not leave myself wondering why it didn't. Of the two I'd be more worried about DC bias. Even if it's worse it will still work, it may just struggle more for example with very low batteries and/or higher timing resolution settings. Or, it may work just as well. 10V is pretty high, most DC bias curves don't fall too much before 30% of rated voltage, so it's likely to be ok. Half price is certainly nice.

Trying to catch up on a few questions:

I'm not going to say it's impossible to get a zener working, but... I think usually you use a balast resistor to set a bias current on the zener right? If you skipped that and if the zener had low enough reverse leakage, maybe it could work, maybe (or I'm wrong and it's not even maybe). Anyway, I'm not taking credit for that mod. At your own risk.

Someone asked about blf emu issues... I can't say. I don't have any attiny13's and actually I never tested it on one. I think I did test an attiny25 version of it and had it working, possibly with a modified board layout to match my test board. Not sure what's going on there. hmm...

The 17mm and 22mm 2S just differed in the used LDO,
all other parts were exactly the same,
same firmware used

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?