It would seem that your OTC is really good for some reason. Going to a smaller OTC will reduce the click timing. Although watch out that the timings don’t get too fast when hot. I have found that the caps that have longer timings when colds can sometimes have much shorter timings when hot.
This entire ordeal is why the OTSM was brought about in the first place. Hopefully I will get ti play with that myself eventually.
Or use Crescendo which IIRC don’t use OTC?
Very interesting, I didn’t take the time to really think it out but this doesn’t surprise me. I was worried that sensing the ground could lead to “backwards readings”. This is not a problem but it does lower the resolution as you noted.
The driver being powered while testing the voltage is what is causing the issue obviously. Sadly there is no way around that.
The 841 MCU has a 2.xV and 4.xv voltage reference, these could prove useful although from both of our testing an LED with a significant amount of light input seems to put out around 2-2.5V.
The nice thing is that we only care about on or off, so as long as the difference between those is large enough it should be good enough for programming as you proved a few posts later.
I am really surprised that the black screen numbers were so close to the white screen, that doesn’t make a lot of sense. Was there any light leaking into the reflector from the room? That is an issue that will need to be figured out.
Running a very crude test on my computer monitor with my lux meter, a dark screen had a lux of about ~5 (most of that was most likely leakage from the room) while the white screen was close to 100 lux.
That much of a difference would be very easy to use, strange it didn’t work that way in practice.
I am also a fan of having it be completely programmed from a screen. If you could adjust all the important variables from the screen programming then there is no need for much else.
The only menu option I would like to remain would be muggle mode and/or 1 optional mode that could be programmed as well, giving you the ability to switch between 1 or 2 modes as needed, there is no need for any other menu options besides programming mode IMHO if you can fully customize the setup with screen programming.
Now a quick list of items I would like to see be programmable are as follows:
Mode group - the number of modes and the mode level
Hidden modes - the number of modes, the order they are in and what they are.
voltage compensation - This still needs to be figured out how we are going to do it obviously but if we go with a basic voltage compensation setup these should also be adjustable
Thermal regulation settings - temperature, stepdown timing / smoothness
Low voltage settings - start of ramp down, how fast ramp down happens, cut off voltage and the ability to override the LVP can be enabled or disabled
Basically all the defines in bistro when you get down to it. If we are going to do this (well, when I say we, I mean ya’ll, 
I am just the idea and big picture guy when it comes to coding), we might as well do it right.
It would be amazing if we could get this firmware perfected and then get a driver design figured out for these low Vf LED’s and then get them made in bulk for cheap, giving us a go to driver option going forward. I am sick of hand building drivers after building a 100+ of them.
Oh, there needs to be some kind of safety net built into the firmware so that if the flashing process fails for any reason, the light will still work and revert back to a usable / reprogrammable state no matter what. The last thing that we would want is to brick the MCU if the light gets knocked off your phone while programming.
It is an e-switch firmware, it doesn’t need an OTC. If you have an e-switch light then that or Narsil is what you should be using anyways.
Crescendo is for clicky and uses ramping. I use it in an S2+.
I just posted up the firmware and build specs for an LDO version of the bistro-HD with OTSM, for the TA LDO board of course. Fitting the voltage sense in on the same pin as OSM is a squeeze, but it should work out fine. So that should cover the basics with OTSM now, and I think make a full OTC replacement option in the TA series.
https://budgetlightforum.com/t/-/44344/72
Also include a Lexel option 3 dual switch build. Option 1 will be coming shortly. All the dual switch stuff is a bit experimental. Honestly, kind of like, yeah, these options should work.. I'm pretty sure. I'll get dual switch light soon.
Found a strange compiler optimization behavior, saved 10 :P bytes after working around it. Maybe I'll write about it in a separate thread.
Give it a bleeder resistor. Or if you already have one, give it a lower-value resistor. The lighted tailcap pulls current through the driver, which keeps the OTC from draining, and a bleeder bypasses that.
Yeah, the whole point of Crescendo is that it brings ramping to clicky lights. 
However, if the OTC is draining too slow, there’s a good chance the SRAM will decay slowly too. It doesn’t hurt to try, but I can’t guarantee it’ll work. Lighted tailcaps interfere with both offtime methods.
Thanks for the advices. I will try one of them!
I'm pretty sure lighted tailcaps don't cause trouble with OTSM. We discussed this much before. I have to rethink it again. The issue is just making sure the pin voltage falls low enough in spite of some residual current flow. I'll have to scratch my head on it again, but the conclusion I remember is it will work. The whole great thing about OTSM is if it works, it works. None of this speeds up and slows down or breaks when tail cap resistance changes by 10% stuff.
Maybe I'll have to bring crescendo into the fold.
Ah, I read too quick, yeah with the lighted tailcap the issue is the bleeder resistor not the OTC.
First turn the tailcap current down, this generally fixes it. I find that a 560ohm bleeder combined with less then .3ma of tailcap draw works well in most cases.
Ah, I have not had time to look at that firmware, I just assumed it was an “official” release of your e-switch ramping firmware.
Totally cool that you have ramping working on clicky drivers now, this was one of the items on my bucket list for driver features. I have really grown to like the ramping since trying narsil. It is not for everything but it is great for general use lights.
I'd like a general use zoomie with a "ramping" ring adjuster.
I used 22K resistors at tailcap for each led pair, and 1K bleeder. Maybe that is the problem.
Inverse readings really aren’t a problem as long as there’s enough difference between high and low and it knows which direction to expect.
No, from a screen I’m only getting up to about 0.3V maximum. To get 2V or more, I have to shine a much brighter light at it. So, for screen-based data transfer, it only has up to 0.3V to work with. This is also why the black and white measurements were so close. On my phone with the brightness turned all the way up, they were 0.22V apart. On my computer screen, they were 0.11V apart. The black value is what it is because that’s effectively the origin, and increasing amounts of light count down from there.
So, if it uses this method, the app will need a note telling people to turn their screen brightness up before trying to flash the light.
I was thinking it would probably still use a bunch of fast presses to enter programming mode. It would “buzz” a bit at the beginning, and if you click during the “buzz” it would toggle muggle mode (or otherwise switch between two mode groups). But if you let it go farther, it’ll wait for visual data.
To keep things as simple and small as possible, I’m thinking all the intelligence should be in the app, and it would send a copy of eeprom to the light to be stored directly. Then next time you turn the light on, it has completely new settings.
If you get a bad transfer, just try again. It’ll still let you access config mode regardless, by doing a bunch of fast presses, even if the settings are totally jacked.
That’s what I’ve been using as my test case while I get the basic operation down. And that’s all it does at the moment; send 8 bytes which go directly into a mode group table. The modes can be any type or level in any order. So, this already works.
To extend things further, I think I should probably split eeprom into the following:
General options:
Mode group options:
Mode group array:
So that’s somewhere around 32 to 64 bytes. It will definitely require attiny25 or higher. And the data transfer will probably be 1 byte per second or slower, so it’ll take a while to run through the process. At least it’s just click-and-wait.
Oh, and the driver flashing process will need to include a copy of eeprom, to fill it with default values. Normally I skip that part of flashing, but it’ll be relevant for this. And the entire first half of eeprom is still used only for wear-leveling for mode memory.
Integrity checking will significantly increase the amount of ROM required for the code. I’ve been avoiding it so far. However, I did at least make sure that config mode can be accessed again no matter how botched eeprom gets. Most of my testing has literally just been waving another light at it, which has predictably inconsistent results. But I finally made a tiny pygtk program to blink the screen, and verified that the light can read and blink back the correct values. I guess technically this means I added a binary-to-decimal conversion mode on my flashlight, since it reads in 8 bits and blinks out 3 decimal digits.
So, the basic idea is working… and it works on tiny25… but I’m still not convinced it’s really any better than what Crescendo does — a ramp, a memory toggle, and some blinkies you never have to see if you don’t want to. Complexity has a hard time beating simplicity.
I got a little time to put together the Texas Commander finally. It is already a bit outdated due to these latest advancements but people can see what an opamp driver would look like. I think there is a future for this style driver, just in a different form. The FET wound need to be mounted to the mcpcb to heat sinking for it to work properly but it is a very viable option for high powered drivers without some other linear components coming on the market.
Oh, I still have an unknown which might be relevant.
Is there any point trying to measure from LED+ instead of LED-?
I picked LED- because, when the LED is off, it’s not really connected to anything else. Comparing LED- to VCC seemed more likely to produce results than comparing LED+ to VCC.
If I understand correctly, LED+ and BAT+ are literally the same thing, and the VCC I’m using for reference should also be the same (on single-cell drivers). So if I tried to measure that, wouldn’t it always just get a value of 100%?
Strange you are getting such low readings. What LED are you using? Does it have a reflector? Even just in the room lighting I was seeing almost .5v IIRC if the reflector was aimed torwads the light. I know from past readings that the lux meter generally reads about ~25 lux in this room, much less then my screen did. It should be about 2v on my screen by these numbers.
Perfect! Exactly what I was thinking!
Good start, I would like to personally see the ability to adjust more then just toggles on some of these, for example the off-time press I would like to be able to adjust the timing as well.
Same for the thermal regulation, adjusting the timing would be very handy as a triple S2+ running 18A needs very different settings then a XM-L2 in a C8.
It would be ideal if almost every variable / Define could be adjusted with the programming mode. In order to keep programming times down could it only send what you want to change and it would just keep everything else the same? Thus if you just wanted to change the mode memory it would be a 2 second flash?
I am not worried about the flash time, I mean it will be a set it and forget it thing for 99% of lights. Although re-writing the whole rom everytime seems kinda useless if you are only making a small change. Not sure what is possible in this sense though.
I agree, it doesn’t need an Integrity check as long as it is setup to always re-enter config mode if the flash fails. I just didn’t want to get stuck with an possible situation where a driver is useless because of a bad flash.
First off I would really like to see ramping be a possible mode group option in this firmware, combining the best of both worlds. The idea would be to make a single firmware that could run 98% of flashlights exactly as 98% of users would want it to without the need for any of them to ever touch a line of code.
If we could reach this level it is possible that some of the manufactured would start using it and that would be amazing!
Beyond the feature list it would mean that we would not have to setup the drivers to be easily re-flashable and could use even smaller components. Thus allowing for even better designs in smaller packages. The end goal would be to create a driver so complete it would be worth having a batch of several thousand made to reduce the costs drastically and yet allow it to work in any light we desire.
As far as simplicity, I see it as a simpler firmware myself. Sure the back end is complicated but to the end user it should be simpler as they will only have to worry about 1 mode group, be it ramping or normal modes. They can also setup the light to do whatever they want and only what they want.
If the app to program it can be made fairly simple then anyone will be able to use it and setup their light as simple or as complicated as they desire.
Now by default I would say that the best option would be ramping but seeing as it is just code and adds no cost to the driver, why not pack as many features as possible into it while in there?
I am always a have my cake and eat it too kind of guy. If it doesn’t cost me anything but I gain something out of it, I am all for it.
In this case I do not see any downsides to the end user getting a light with ramping and ramping only vs a light with ramping and the ability to be fully programmed to whatever they want.
TK, since most mobile phones have a flashlight / camera flash capability, could you try using that? It should provide a much wider range of values.
I thought of this as well and without drastic driver layout changes there is no easy way to take the measurements from V+ while battery voltage is flowing.
The ideal setup would be to compare led V+ to led ground but that would only really work if the battery was disconnected.
Now if the voltage on the ground was simply too low then we do have an option as we shrink things. We could use an opamp to increase the voltage and thus make it much easier for the MCU to detect. This is an extra part though which is both space and money and best to not have it if we can.
I also agree that if the cell phone flash might be a better option then a screen. I saw some morse code apps for android so obviously the flash can be blinked, I am not sure what the limits are though.
Although I am still curious why your screen readings are so low contrast. I get a 20x difference in readings myself. I might toss a real LED on the screen and see if it agrees.