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

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

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

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.

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.

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.

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.

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.

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.

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

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.

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

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.

If you feel like flashing 1.4.1 (not the same as 1.4) and seeing how it goes that might be helpful too. There was some re-arrangement of the timing code from there to 1.5 and 1.6 to make it more readable. But it’s still hard to read too much into any timing test without really knowing for sure what the hardware is able to do. Measuring sleep time capability of the hardware has been the standard benchmark for everyone trying OTSM hardware development from the start. It’s not that I’m saying your hardware is bad either, it’s just a matter of pinning things down and ruling things out. We’ve got a matrix that looks like this

                    Hardware:  1                   2
Software:                        
   A                              works            works
   B                              works            !works

And then I’ve got more hardware in category 1, three of very different builds.
So is that a software problem or hardware problem? I just don’t know.

Has anyone tried using Bistro with an Eswitch? What is your experience? Is it intuitive or awkward?

High light-rider. I'm the only one who has a version that actually works more or less right with e-switch. All except the q8 version are marked in the manual as highly experimental, and the Q8 was pulled from that category slightly prematurely.

So yes, I've tried it, if that counts. I like it just fine. It's simple. It's bistro. It's long click off, but unlike narsil there's no lockout on mode change, which I like. I can add shortcuts later, shortcuts on to turbo or memory for example (with med press or long press, or maybe double click even).

Unfortunately in some version after 1.3-r2 (not sure which one yet and I will repost that one shortly) there is a bug that affects both e-switch and OTSM (but is worse on e-switch), but those are also the versions where e-switch is most developed. The bug creates a persistant instability after some significant amount of click switching, likely because of a race (precision timing of the click to cause a problem) that locks the light or otherwise makes it misbehave (sometimes clicks still work, but it still misbehaves again after clicking), and requires detatching battery power to reset (twisting the tube).

It's a combination of a race and some kind corruption probably, and that can be a very hard combination to pin down especially since it's rare and I can't produce it in the simulator, but I'm getting closer, much closer. So once I get that fixed I'll release a new e-switch build.

I have a pruned down test build that for whatever reason manifests the bug more easily than the real build. I've been diffing it against 1.3-r2 and systematically testing partial reverse patches of all interesting differences. I've narrowed it down quite a bit. I don't have that much time though, so I'm chipping at it slowly.

Unfortunately with a bug like this, it's possible I'm narrowing down code that enables or unmasks the bug but maybe not the root cause. It's even possible that root cause existed in 1.3-r2. I've also ordered a cheap hardware debugger of sorts so hopefully that can help me understand the state of the machine after the bug happens. That's hard work to analyze (memory dumps, comparison with simulator, etc) , but could really pinpoint the cause. Slow going.

Hardware is still TA triple build

in TA topic for the driver are the parts listed
I just changed the C2 to this capacitor rest are parts you listed them

the FET is SIR404, but should make no difference

If I flash v1.5 and it does not work, then flash v1.3 and it works why should the hardware be the reason?

I never tested your cap. I'm not saying it's bad. It's unlikely it's bad, but it's not identical specs to mine and specs aren't testing. If I bought or tried a different cap I'd absolutely test it with the OTSM-debug.

It's also unlikely that software can somehow behave differently on identical hardware don't you think? The only way I can imagine is through ram decay to different values, but there is no RAM decay on OTSM medium presses. It's still powered.

So we have two very unlikely explanations. One of them must be right but which one? For all I know you got a bad flash on 2 of them. I'm not ruling out software as PART of the issue (there's obviously a hardware aspect to the explanation, and there's obviously a software aspect, which is mainly responsible? again, I don't know). It's just a pretty big mystery at the moment.

Are you serious with that question?

[quote=Flintrock talking in his head]

If you flash 1.5 on one board you made and it works, then flash 1.5 on another board you made and it doesn't work. Why should software be the reason?

[/quote]

We can ask that both ways clearly. Did you see the matrix?

Both of those 1.5's were bit for bit identical, so what was different in those two cases? Not software obviously. Is the software deficient in dealing with hardware variation... possibly, but the difference is clearly, certainly hardware. Is the software significantly worse in 1.5 but variation in hardware meant some hardware still barely worked? Possibly. Or is the software only very slightly different in 1.5 and hardware that was already barely working failed? You don't know. I don't know. You can guess, and might even guess right.

All the OTSM drivers I have build have components from the same reel, so there should be no different MCU revision or other bad hardware change

My guess there is something on the edge with never versions that made it fail or sometimes works
I downloaded 3 times newer versions of your OTSM after the May v1.3 and they had all issues not working properly

I can only tell you that there is something going on with non working medium presses when it comes to build multiple OTSM drivers

If you want to analyze it I could send you a driver for some compensation that works with 1.3 and fails with 1.5