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

245 posts / 0 new
Last post
Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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

Lexel
Lexel's picture
Offline
Last seen: 56 min 43 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.  

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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. 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

Lexel
Lexel's picture
Offline
Last seen: 56 min 43 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

 

Lexel
Lexel's picture
Offline
Last seen: 56 min 43 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

 

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

LightRider
LightRider's picture
Offline
Last seen: 1 year 5 months ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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. 

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

Lexel
Lexel's picture
Offline
Last seen: 56 min 43 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

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?

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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. 

 

 

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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

 

Are you serious with that question?

 

Flintrock talking in his head wrote:

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?

 

 

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.

 

 

Lexel
Lexel's picture
Offline
Last seen: 56 min 43 sec ago
Joined: 11/01/2016 - 08:00
Posts: 5254
Location: Germany

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

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

I've helped you quite a bit (for free, for boards you're selling), and I will keep an eye out for this as well.

 

I will certainly not test for free and certainly not pay to test your boards with your hardware selection. I will test my boards for timing on various versions, like everyone else who has made new OTSM hardware or software configurations has done.  It takes literally 2 minutes to flash a version and say what blinks.  It takes hours to develop and debug the versions.  Thanks for helping.

 

It is certainly true that for now 1.3-r2 is the most tested and proven version for basic TA otsm builds.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

So, I am considering to make medium press to enter hidden modes but short press to cycle through them.  This wouldn't be until after stabilizing present builds.

 

I don't like making too many UI changes, because possibilities are endless and I want to keep close to consistent.  But med press back through all the hidden modes can be annoying if you want one quickly.  I haven't even though yet about the details of how to do it.  Doing it intelligently probably requires a significant change to the modegroup construction routine that went through a ton of optimization already.  [edit: ok really it just requires reversing the hidden mode definitions in all the modegroup config files, doing it that way is an API change though from the perspective of imagined mod-ers with their own modegroups, so it should come with a new preproc define to enable it, more of an issue the later it's done].

LightRider
LightRider's picture
Offline
Last seen: 1 year 5 months ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Flintrock wrote:

So, I am considering to make medium press to enter hidden modes but short press to cycle through them.  This wouldn’t be until after stabilizing present builds.


 


I don’t like making too many UI changes, because possibilities are endless and I want to keep close to consistent.  But med press back through all the hidden modes can be annoying if you want one quickly.  I haven’t even though yet about the details of how to do it.  Doing it intelligently probably requires a significant change to the modegroup construction routine that went through a ton of optimization already.  [edit: ok really it just requires reversing the hidden mode definitions in all the modegroup config files, doing it that way is an API change though from the perspective of imagined mod-ers with their own modegroups, so it should come with a new preproc define to enable it, more of an issue the later it’s done].

I very much like this idea of not having to medium press four times before getting to the desired function! Hope it gets worked out.

LightRider
LightRider's picture
Offline
Last seen: 1 year 5 months ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

@Lexel, if a board fails to opporate using v1.5, will it work if you erase and reflash with the same v1.5 firmware?

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Yeah, it's something I like about Narsil, although I had it mind before I found it in Narsil. My problem with Narsil though is in strobes, battcheck etc, it takes a second to realize what mode you're in, and by then Narsil locks you out and you have to start over.  1.2 second control lockout in custom modes doesn't work unless you've memorized them and your brain isn't engaged in something else.

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

LightRider, he said he flashed it a few times if I read right.  Rarely bad flashes happen, but it's rare.

 

What's clear, if the matrix is trustable (there wasn't a slight change in supply voltage, temp etc.. unlikely, but just making the conditions clear)  is there is a difference in hardware AND there is a difference in software.  And so I will DEFINTELY look on my end.

 

What we don't know is is the software difference very small and the hardware difference between his hardware and mine very big, with small variations within his hardware, or are all the hardware differences very small, and the software difference is very big.

 

The only thing I know in software that can degrade the performance a bunch are pin states, but they're set the same. I'll double check that in the simulator.  I'll do my part, but I only have one fully functional non-prototype OTSM board and I have to desolder it to test it.  I generally test features on my proto board, and just flash new whole versions to the light once in awhile to make sure it works.  And it does.

 

It's cake for lexel to flash out the otsm-debug values for both builds because building and flashing boards is what he does, and it would definitely help me out.

 

Flintrock
Offline
Last seen: 1 year 8 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Ok, so lexel didn't say he flashed it multiple times, my mistake.

 

Anyway, I just ran otsm-debug tests on 1.5 on my light.  Desoldered again just to test it.

At 4.2V I could get up 13 seconds of click time.  Should be enough.

At 3.1 V I got somewhere between 6 and 7.

 

At 2.9V,  I could get around 4s.

 

Now what this all proves is that a bit weaker cap should probably be ok.  But what it also proves is, 1.5 works fine on good hardware.

 

So, the issue status is presently changed to WORSFORME.

 

Lexel if you want to try to reproduce it and/or provide otsm-debug tests to potentially shed some light on what's going on on your end, that's great.  There's nothing more I can say from here since I cannot reproduce your issue. 

 

Pages