wight catchup

Lexel · 2018-10-20T21:40:14.000Z

I also found a fix for OTC, odd but works

2S lights with buck or boost have caps making the OTSM tricky or impossible
Solution flash 1S firmware 1uF capacitor with 680kOhms in parallel

The key is to get the drain of the OTC decoupled by thermal variable self discharge which raises a lot on higher temperatures, also using X7 or even X8 caps in bigger physical size like 0805 which are a bit less temperature sensitive

Lexel · 2018-10-20T21:50:31.000Z

wight:

In no particular order:

various parties:

Welcome back + links

Thanks for the welcome back & for the flashlight & lantern links!

To all the folks who showed up during my hiatus: welcome to BLF I’m thrilled to think that anything I posted was still of use while I was away.

To all the folks who were already here - it’s really nice to see that you folks are still kicking!

MRsDNF:

wight catch-up. Now that bought a smile to the dial. Welcome back. For those that don’t know wight also built a light or two that defied the laws of magic. Must go find the threads for a refresher.

I think that you’re confusing my builds with yours.

Tom Tom:

I think I fixed the OTC design some years ago and made it consistent, defined, analysable. Instead of a capacitor just dangling in the breeze. But it seemed nobody at the time was interested. Or perhaps felt threatened. I could discuss, but only in PM.

There are several obstacles besides dangling. IIRC the ATtiny25/45/85 thread contains some work trying to compensate for temp & voltage. For 1s lights the voltage divider may no longer create a problem for the OTC, but for 2s lights w/ a Zener or LDO there will still be a voltage divider messing with drain on the OTC. I generally prefer to discuss things out in the open so that everyone can benefit, but with that said sometimes it’s easier to get the ball rolling in PM. Feel free to drop me a PM where we can get our thoughts together.

The capacitor recommended by Flintrock for the OTSM solution is expensive and it would certainly be nice to avoid it!

Flashy Mike:

OTSM is absolutely reliable, pretty simple to handle, no “raw assembly code” required! This is the proof-of-concept code I sent to Mike C on request almost 2 years ago. I would have given it to anyone here who had asked but sadly there was no interest.

Try it!

Thank you for sharing the PoC! Hopefully the idea will get more traction now with a compact demo available. :laughing: I don’t have a 25/45 right now, only 85, so I won’t be able to try it right away. I’ll try and pick up the necessary bits on my next parts order. Did you or Mike C look into component selection? Flintrock recommended a $1/ea capacitor w/ legs which looked troublesome for hand soldering/rework. A bulletproof offtime solution is worth $1, but less expensive is always appreciated, especially if anyone mass-produce a driver using this technique.

Boaz:

Joshk:

Hello. Who the heck are you?

Wight is so old …

he wrote the original low/high sos/strobe next mode memory driver

Boaz caught me. It was I who released that scourge upon the world. When my secret finally leaked I couldn’t face the forum for years!

Joshk:

I remember back when I joined, people were talking about the missing “wight”. Here’s my catch-up. Maybe I am wrong. I think the hobby has changed. As I understand, years ago the average person expected Alkaline/light-bulb performance, so showing them a lithium/LED flashlight was a mind-blow. Everyone had fun. Now there are lithium/LED flashlights on every retail shelf. And while it’s will always be possible to out-perform a mass-produced light, it takes more money and effort than ever to ‘wow’ the average person. The “Giggles” light for example is great for wow-ing people, but had to be built so absurdly big it’s hard to even think of an excuse to take it off the shelf.

The truth is that this was actually the situation long before I left. Still, there is a lot of bang-for-the-buck (as well as satisfaction) to be had with reasonable custom builds or customized budget lights.

Texas_Ace:

Good to see you back Wight, while our times here did not cross your work was what heavily influenced the TA driver series (with the work of PD68 and DEL adding there share in the mean time of course). I look forward to seeing what you cook up now. Getting the OTSM working with some viable firmware would be nice for the time when clicky lights are required for example. Right now the only firmware that supports it is a bit too buggy to make widespread use possible and dealing with the OTC is a royal pain, having to deal with this right now actually and think I might just revert to a non-OTC firmware in order to solve the problem.

Thanks TA, I’m glad that you carried to torch! I hope that I’ll do some cooking, but no promises on that front. Step 1: build a couple of working flashlights out of my piles of supplies.

Right now I’ve got to get my work space up to snuff. In the intervening years since I left the forum my flashlight stuff has been packed, repacked, moved, etc. I’ve got a new hobby area now but it’s been in use for (and is currently in use for) other projects. So in other words… right this moment I should stop reading forum threads and go clean up!

I have tested and sold about 100 OTSM drivers with a differet cheaper 50 cents capacitor, basically the good infineon FET and MCU make about 2/3 of the parts costs of FET+1 driver design

Still the OTSM firmware on some revisions caused me problems and possible some hidden bugs still present

Tom_Tom · 2018-10-21T14:47:21.000Z

A cap is just a cap. In this application. Really. There is no special magic, and obviously the cheaper the better, as long as they are good. And store energy reliably.

BTW, other things can also do that nowadays, maybe better, and might be worth looking at.

Whether 100 uF is the right value, I don’t know, but it is a nice round number.

Bye the way, Flashy Mike has just posted some OTSM code that looks interesting. It is beyond my abilities to venture an opinion, but it already looks much more plausible than Flintrock ever managed.

Ronin42 · 2018-10-21T22:07:48.000Z

I understand wight is back.

Welcome and thanks for the help before you left.

As for the rest I’m confused but happy because I know wight understands.

“wight is back, (A bump to BLF’s IP quotient)”

eas · 2018-10-22T03:23:03.000Z

Tom Tom:

Bye the way, Flashy Mike has just posted some OTSM code that looks interesting. It is beyond my abilities to venture an opinion, but it already looks much more plausible than Flintrock ever managed.

What are you talking about? Flintrock managed a full-featured Bistro firmware rework with support for OTSM and OTC that has been used successfully by multiple members of this forum.

I may be mistaken, but I don’t think Flashy Mike’s firmware has similar levels of adoption, at least not at this point.

Tom_Tom · 2018-10-22T10:34:44.000Z

eas:

What are you talking about? Flintrock managed a full-featured Bistro firmware rework with support for OTSM and OTC that has been used successfully by multiple members of this forum.

I may be mistaken, but I don’t think Flashy Mike’s firmware has similar levels of adoption, at least not at this point.

Go back to post #38 and read on from there.

Flashy Mike has only just shown us his code, so it’s hardly surprising that it’s not been “adopted” yet.

Lexel · 2018-10-22T20:29:56.000Z

I see no problem in easier and more reliable OTSM code

if the Off detection works well enough 47uF is more than enough, the discharge down to 2V takes way longer than you ever need for medium presses

on Buck and boost drivers the off detection is a problem as thiose got input capacitors, not sure how this can be handeld, but it srewes OTSM often enough depending on hardware

Flintrock · 2022-11-14T00:56:44.000Z

ToyKeeper:

The code supporting OTSM was tricky mostly because it relied on bare interrupts running raw assembly code. This made it extremely hardware-specific, and it also appears to have made the code buggy in some pretty unpredictable ways. I think perhaps the bare interrupts were less safe than Flintrock had thought, and may have had subtle unintended effects, but I haven’t tested to verify that. I just know that, whenever I tried BistroHD on real hardware, it exhibited a pretty wide variety of issues which were not easy to reproduce on purpose.

Early versions simply had bugs. 1.7.1 has been perfectly stable (without modification), although not tested on a ton of layouts, mostly TA and Q8, and some others on the bench. But there are some incorrect statements here.

The OTSM implementation itself (or really hardware either for that matter) has nothing to do with the bare interrupts. I make it very clear in the comments of that interrupt that anyone modifying the code a lot should probably make it not bare. I make it very clear that it's not safe at all unless you know exactly how those modifications will interact with said bare interrupt at the machine code level. There's like a 10 line comment about this with BIG FAT warnings saying it's DEFINITELY not safe. Not sure how much more clear I could have been. The reason for those bare interrupts had nothing to do with OTSM, and the OTSM bare interrupt probably isn't even the most unsafe one (since it never returns). It had to do with getting OTSM and as many other features as possible to fit on an Attiny25 using a modified bistro code. It saved something like 50 bytes just in the OTSM interrupt alone, which may seem like not much, but it's enough to add a couple of features. 50 here, 50 there, you've got 20% extra space on these tiny machines. That's all. Use of better chips like the 45 was actually only just starting to be a thing as I finished debugging that code. The 45 was still bigger and didn't fit everywhere the 1616 and such simply were not in use at all then. The goal was get OTSM into a TA triple down version of bistro (I actually really like bistro, even on eswitch, still better than other fancier things, most of which came after I started that. For extended outdoor use, knowing exact power use can be very important, and bistro just gives known mode selection) on hardware in use at that time, without rewriting a firmware from scratch, and I did that.

Anyway, the OTSM implementation itself works fine with the interrupts implemented normally (just removing the bare attributes). The early instabilities around version 1.4 had to do with pin states and watchdog races, not the interrupts. But bistro OTSM is definitely based around a poll-and-restart driver, which is what bistro was. It's not how you'd do it in other drivers. For all the talk though, is there another clicky switch driver existing using OTSM with near the functionality of bistro-HD, even all these years later? Flashy Mike had a couple of nice things, and if so, great! OTSM is indeed hard to get right, but clicky switch lights do still exist!

Regarding separating UI code from hardware, that's a big part of what HD was about and why it built so many firmwares, each from a choice of hardware layout configs, choice of chip configs, and other options all selected in one master config for each version. Not every single thing about the chips was abstracted, but as I supported more chips, I abstracted more. I remember thinking the 1616 would requiring abstractifying a couple of more things, where defaults could keep the old configs working fine, but I never had time for that. when I started HD, other firmwares were not doing this much. Narsil might have been, not sure exactly when it started or how much it was doing that yet. I love what I'm seeing in that regard now with the direction Anduril (2) has taken as well though.

I'm kind of remembering why I left this place, although to be honest it was just a couple of nasty people. Tom Tom was on top of the list, and wow, felt the need even to insult me unprovoked above when I wasn't even here, but that's exactly how I remembered him. Oddly he's attacked me before in conversations where we were not even interacting. I don't recall it ever being in regard to something that even involved him, or his work. It's just weird. I exaggerate the significance of that though. Mostly I just left because of my own time.

Anyway, bistro-HD still operates clickly and even e-switch lights just fine years later on attiny25/45 (and mostly like now 85 as the V versions should be available now) and it's still easy to configure on different hardware layouts, and already configured on most.

Flintrock · 2022-11-14T02:14:03.000Z

eas:

Tom Tom:

Bye the way, Flashy Mike has just posted some OTSM code that looks interesting. It is beyond my abilities to venture an opinion, but it already looks much more plausible than Flintrock ever managed.

What are you talking about? Flintrock managed a full-featured Bistro firmware rework with support for OTSM and OTC that has been used successfully by multiple members of this forum. I may be mistaken, but I don’t think Flashy Mike’s firmware has similar levels of adoption, at least not at this point.

I appreciate the appreciation. Flashy Mike actually implemented a proof of principle of OTSM before I did and his implementations were indeed nice. He and I and a couple of others (Mike C I think and Texas Ace some, more regarding goals) collaborated on initial brainstorming of how to make it all work, and it probably wouldn't have without him. I knew about his methods, as I recall using the ADC and I posted some of my own tests on similar methods (I did a LOT of tests of real power usage, etc, the super long sleep times lexel mentions are a result of that and optimizing the method). There was a lot of discussion between us. In the end it mostly came down to what worked well in bistro, with best power efficiency and the smallest code, without rewriting it from the top down (I ended up rewriting it from the bottom up, but in incremental working steps). Anyway, I recall he had some things working very nicely. I had/have nothing but appreciation for Flashy Mike and his work. He's credited in bistro-HD, and for very good reason!

I also learned a lot from a lot of wight's old posts!!! Maybe some year will be around at the same time, but the information stays.

Flintrock · 2022-11-14T04:25:35.000Z

Since this somehow largely turned into a beat on HD thread, I will clear up a couple of other bits of history here. Lexel above accused it of being a pain to use but at least three of his complaints have been tracked down to his own mistakes (in fact all known non-addressed issues were), including one where he failed to count to 20 properly when defining his own new modified 20-entry ramp table. The most disappointing is that Texas_Ace also piled one on above, and yet in spite of encouraging this project from the start I never once saw where he ever flashed it, and any bugginess he's referring to was not mentioned in the HD thread, just in off-hand comments like above, without any clear reference to anything specific. That seems odd and unproductive, and frankly out of character for him. If someone else does work that you encouraged and you want to criticize it, maybe actually try it at least and leave constructive feedback. Just leaving vague derision in random places seems kind of low-ball.

Texas_Ace · 2022-11-14T14:13:30.000Z

Flintrock:

The most disappointing is that Texas_Ace also piled one on above,

First, this thread is from 2018?

Second, where did I “pile on”? I have always made it a point to not attack anyone and even if I didn’t have that policy, trust me, there are people that would of been WAY ahead of you, I always liked you. lol.

If you are referring to the statement I made about the firmware in 2018 being too buggy, keep in mind that is a statement from 2018 and far as I remember the early implementations did in fact have some bugs at the time. There were several versions of firmware floating around trying to solve the issue as I remember, I have no idea which one I was referring to at that time.

Also keep in mind that was about the time I built my last clicky light, I never did anything else with it simply because I never worked on another clicky light. To this day I swapped some LED’s in my EDC and that it the most “modding” I have done since pretty much when that post was made.

Remember, I was working on lights destined for production in factories, even small bugs were a quick way to cause massive issues in a production environment so I was forced to be picky.

I am SURE it is working by now, I just don’t mess with flashlights anymore. I always thought you did good work, there are always bugs in the early days. It was nothing personal if I was even referring to your firmware.

I am sorry if I gave you the wrong impression or slighted you in some way, that was never my intention.

djozz · 2022-11-14T15:00:03.000Z

Not into programming but I believe that the Wildtrail D80 (with the help of TheOnlyDocc who went MIA after that) uses Flintrock firmware and I think it works great and flawless

Flintrock · 2022-11-14T15:33:13.000Z

Fair enough TA. It was a long a time, but, I quit working on it even longer ago. 1.7.1 was posted at Christmas of 2017, so 10 months earlier than your comment, and it still works. I developed in the open before that exactly to get this idea available for anyone interested and show proof of principle within a popular driver series, and ended up pressing on to make it actually I think a pretty robust build in that driver. Anyway, I didn't have anything against you in those days either, to say the least, and it's good to see you still around. The comment was a little sloppy, but it happens, so no hard feelings there.

Remember, I was working on lights destined for production in factories, even small bugs were a quick way to cause massive issues in a production environment so I was forced to be picky.

Yeah, ok, that's not helping, the fact remains you haven't reported any bugs in the HD thread (at all actually), particularly that I didn't know about and already fix. ;) But you clarified that, so we're good.

I took it farther than I ever meant to really, and wouldn't be ashamed if there were bugs (probably is SOMETHING), just didn't like the appearance of vague claims without specific reports.

In fact this all started in the "attiny development thread," and I did post simple proof of concept codes or snippets there I believe, I could dig one up, but I'm sure Flashy Mike's above serves quite well for that. He was in the middle of it all. It might or might not encompass everything I learned (tested) about pin states, fuses, watchdog details, brown out corruption, keeping voltage sense levels above pin stated threshold, shutting down quickly enough, etc which is relevant to the next point, but I'm sure it does work properly. The fact is the principle is simple, but there are a lot of details that do really matter.

And on that note, to close the loop on a technical point that Tom Tom raised above. The cap is certainly not just a cap with a value. That's completely wrong. Many caps perform MUCH MUCH worse than their nominal specs at the temps we run lights at, which was the whole OTC problem to start with. I don't recall now if that's reduced capacitance, increased leakage, or I think a lot of both. A 100uF ceramic cap will do much worse than a 47uF tantalum cap as I recall, once heated. I tried a stack of ceramic caps I had as my first experiment. I ran real test on sleep power consumption, estimating current draw and times for pin state reads, ADC reads, etc, and checked capaciticance specs for real temps involved. In the end it's slightly overkilled indeed. I got over 10s (I think 12 even) of sleep at room temp, after optimizing a lot, figuring out the V-chip issue, pin state details, etc, but that's with only 1/4 second timing resolution and room temp. It will drop almost in half at 1/8s timing resolutions (twice as many wakes), and heat still impacts this cap too, just less. That said it's still certainly plenty safe, and I know lexel used some cheaper caps with some luck. I specced it for modders. If you're spending 10 hours ordering parts for building a light, no point saving $1 on a cap. I think the right way to go cheaper is just with a lower capacticance, tantalum cap, but even then, possibly not just any random one.

I also noticed you echoed the point about "universal drivers:

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/Flintrock/bistro-hd/configs

It took me literally about 3 minutes to modify a configuration for the Q8 version (the last one I added), and it flashed and worked. It's what HD was all about. Of course it was still one UI, but mostly only because that's all I included.

Texas_Ace · 2022-11-14T15:48:09.000Z

I will be honest, I remember you working on the OTSM and I remember trying an early version that had some bugs. After that I remember you kept working on it but I could not keep up with the development and figured I would try it again after you had the bugs worked out and I worked on another clicky light.

Sadly that day never came since I only worked on e-switch lights after the GT and then stuff happened that caused me to basically quit flashlights entirely.

I had always planned on updating my EDC with a OTSM firmware but still have not felt like doing it since it works good enough for my needs as it is.

Rest assured, it was nothing personal and I did appreciate your work on the firmware. Life simply happened and I never had a chance to actually try the updated firmware.

Flintrock · 2022-11-14T15:48:42.000Z

djozz:

Not into programming but I believe that the Wildtrail D80 (with the help of TheOnlyDocc who went MIA after that) uses Flintrock firmware and I think it works great and flawless

Glad to hear it! This is what I saw. And again, it's not like my personal worth hinges on this in the slightest. I just felt a lot of things were getting said forming an image without an actual truth behind it.

Texas_Ace · 2022-11-14T15:49:14.000Z

djozz:

Not into programming but I believe that the Wildtrail D80 (with the help of TheOnlyDocc who went MIA after that) uses Flintrock firmware and I think it works great and flawless

Very nice, I was sent one of those awhile back when I was working on the WT90 and it does indeed work great! I always wondered what firmware/driver it used but never pulled it apart.

Flintrock · 2022-11-14T15:54:26.000Z

Actually, writing this all now, I do have to say, I wonder how well a tantalum cap would do for OTC... It would be a little funny if in the end the thing that made OTSM work would actually just make OTC work anyway. Still OTSM is far less finicky, not bleeder dependent, no calibration, etc, once you do setup the software details, so personally I'd still prefer it. But actually a tantalum OTC might do pretty ok.

Texas_Ace · 2022-11-14T15:59:13.000Z

Oh, I am sure that the OTSM is far less finicky and works better, that is why I was so big on the idea back in the day

I just never had a chance to try the finished version.

tantalum caps would improve things, IIRC someone tried this and it was a lot better but did still vary from driver to driver due to variances in the MCU’s parasitic drain IIRC. In fact I think I ordered some of the caps to test but once again, never had a a reason to do it.

thefreeman · 2022-11-14T16:10:58.000Z

Flintrock:

Actually, writing this all now, I do have to say, I wonder how well a tantalum cap would do for OTC… It would be a little funny if in the end the thing that made OTSM work would actually just make OTC work anyway. Still OTSM is far less finicky, not bleeder dependent, no calibration, etc, once you do setup the software details, so personally I’d still prefer it. But actually a tantalum OTC might do pretty ok.

How about X8L capacitors ? Like this one for example

5% initial tolerance, about 1% between 4 and 3V, ~1.5% between 0 and 60°C
Would it even need calibrating ?

Flintrock · 2022-11-14T23:27:46.000Z

thefreeman:

Flintrock:

Actually, writing this all now, I do have to say, I wonder how well a tantalum cap would do for OTC... It would be a little funny if in the end the thing that made OTSM work would actually just make OTC work anyway. Still OTSM is far less finicky, not bleeder dependent, no calibration, etc, once you do setup the software details, so personally I'd still prefer it. But actually a tantalum OTC might do pretty ok.

How about X8L capacitors ? “Like this one for example”:KEMET K-SIM 3.0 5% initial tolerance, about 1% between 4 and 3V, ~1.5% between 0 and 60°C Would it even need calibrating ?

Probably. As Ace reminds me, even parasitic drain of the MCU impacts it, and I'm now recalling this maybe even produces some of the temp dependence. Been awhile, but the R in that RC of OTC is I think entirely uncontrolled? OTC isn't in my circuit diagrams explicitly, but that's how I remember it. He's probably got it correct, better, but still not great. I didn't actually use many OTCs personally though. I had maybe two lights with it, so not a lot of data points.