With OTSM you actually keep track of time and can say with certainty “the light was off for 0.73 seconds”. With an OTC you’re just taking a measurement of the capacitor which is fairly imprecise and will change depending on whether the light is hot or cold.
In addition to what gchart wrote, you get different readings depending on the battery voltage with OTC. If light temperature and the actual off time are both exactly the same you will get a different reading if battery voltage is 4.2V compared to if was 3.5V. If you only have a single type of off press in the firmware, not short off and long off doing different things, then OTC is reliable, tried and tested. I have short and long presses in my firmware, OTC is not consistent enough for that.
I find an old posting I made about the subject: Texas Avenger "TA" Driver series - Triple channel + Bistro or Narsil + Clicky or E-switch - The Ultimate open source driver! - #1389 by Mike_C
Thanks, that was interesting, I didn’t realize that the capacitors were that unstable with temperature and (apparently, from the linked thread Off-Time Memory Dependent On Altitude? - Resolved! ) with air pressure. There are stable types of capacitors but I guess they are bigger. I’d hope that resistors are pretty stable either way. You can measure the battery voltage to calculate the RC timing if R and C are known, and you can measure the temperature too, but maybe the capacitance change with temperature is not predictable enough to calculate. It’s still interesting to hear that OTC ends up being too imprecise to distinguish a short from a long button press.
Do you mean you use ULP (32khz clock) literally all the time, and the Anduril UI still works? Is there a reasonable way to switch out of ULP at least some of the time, when more CPU is needed?
There are more stable capacitors yes, X8L for example : 3% max change over 60°C. Though they still have initial tolerance, I see them at 10% from what Mouser has. Plus the DC bias, but that depends what value is needed. I suppose that battery voltage is something that could be accounted for since it’s known ?
Mike writes his own firmware.
IIRC the avr-1 has an internal RC clock that is calibrated at the factory. It’s still nowhere near as accurate as a crystal, but maybe it could be used to measure the OTC capacitance by timing the recharge when the light is turned on. Is accuracy better than 10% really needed to distinguish between a short and long press anyway? I’d expect short press < 150ms, long > 300ms, or something like that, where it’s ok for in-between measurements to not be definite. So 10% either way won’t matter.
I wonder if it’s possible to use the serial port as an accurate timebase to calibrate the other stuff while the chip is being flashed, since the baud rate will derive from a crystal clock in the USB gizmo. Maybe that gets too fancy if it is even doable, though. I’m presuming that putting an xtal onto the driver itself is not really feasible. It would be nice for some things, like turning on the light at a certain time of day. People do keep asking for that.
I use ULP all the time but with my own firmware, never tried Anduril. Switching clock is easy, not and issue for me unless I’m doing it during off press. So far I have not needed to switch clock from ULP but my firmware isn’t complete yet.
No, it won’t matter but I don’t really care, OTSM works fine for me so I personally couldn’t be bothered with all the above.
I can mention that my motivation to stick with OTSM is also due to the way my firmware is written. My firmware is for both off switch (clicky) and E switch (momentary), and it’s much easier to write support for this with OTSM because it’s “real time” press detection just like E-switch presses. With OTC the off presses have to by dealt with on light start up after each press while the E-switch presses are dealt with in real time, two totally different press interpretation methods which just complicates things, at least for me.
And… they’re gone.
But they expect 6000 later this month and 36000 in October.
Edit : the 6000 lasted ~3 days, now they have 34800 in stock
Please help me to modify the RampingIOS-ConvoyH1 to read 2S(8.4V) battery on PA3(pin7) of T412 instead of the VCC.
Damn…There were 23k a few days ago but someone bought the lot.
I think it needs a voltage divider otherwise it’ll fry the chip. Does the driver have one on that pin?
The power for the MCU is supplied through a LDO and there are R1=82K and R2=12K voltage divider on that pin. The internal Vref = 1.1V is remained unchange.
I’ll post code up soon, I have another light that I did RampingIOS with: 2S using a voltage divider. Stand by.
I had cannibalized part of the BLF GT’s Anduril configuration to get the voltage readout in Anduril for my L6… but I lost track of where I saved that. Whoops.
Sorry that it’s not very well documented with comments; it was a copy & paste from a different driver. I commented some things, but you’ll still see old stuff in there like references to UT01.
http://www.ghart.com/blf/firmware/RamingIOS/RampingIOS-WurkkosTS70.c
Many thanks for your help. I shall look into the code and try to figure it out.
The code is too big to build for the T412 even it was built with size-optimized. Finally, I built the code in one channel successfully.
I encountered a problem that I already mentionned to Gchart in pm, but it happened a second time so I’m posting here, basically the DAC doesn’t output the right voltage :
And it’s hugely problematic, because due to the difference in current I can’t have a smooth transition between the two range in a two sense resistors topology, for example on level 2 0.55V, which is the minimum I use, I get 3mA instead of 8.6mA, which visually is a very large difference.
The first time it happened I reflowed another 1616 and the problem was gone, now it has happened again with another 1616.
What’s happening here, are they defective ? The dud rate for now is 2/6 which is just terrible.
Edit : Normally the error is like +‐ 0.1mV on the lowest levels.
It is possible to be due of inaccuracy of DAC module. From datasheet I read that there is offset error in DAC reference voltage. There is possible maximum error over 20mV which is about 1mV at output at lower level. Why you not to try to use external reference voltage, just to see if problem is with DAC module or reference voltage source inside Atiiny1616.
I don’t know if that error is depended also from temperature, but from datasheet seems it is dependable of reference voltage range. Error specifications are on page 523 in datasheet.
But if there is a 20mV offset max on Vref, there should only be a 20/255=0.08mV error on level 1/255 ? which is basically what I get on the working ones.
I say working ones because like I said I usually get +–0.1mV, the two bad ones were both at 0.95mV instead of 2.2mV at 1/255 VREF=2.55V, which is even more strange, they’re bad in the same way.
I’ll check what is the offset at 255/255 with the good ones.