Indeed, the lack of resolution causes a form of additional delay and I’ve found that smaller steps make it much easier to get good behavior.
You can get much finer resolution by measuring the WDT clock against the system clock. They move in opposite direction with temperature changes. Works great on an attiny13a although it requires manual calibration there since there is no absolute reference. It seems to work the same on a 25 but I have not yet polished my code enough to be 100% certain. I’m hoping to find some time soon.
Using a ferrite bead in the R5 position was not a huge success. It does work, but a simple 4.7 ohm resistor still gives a better result. The pulse components we are trying to block are simply too low in frequency for the ferrite bead to be efficient.
I was also reminded last night why we need the ‘standard’ R1/R2 resistors values on clicky drivers that use the ‘.noinit’ method to discriminate long/short presses. 220/47 k resistors stretch the long press time to about 6 s. I would expect something similar for drivers that use an OTC. Something to consider if R1/R2 is eliminated.
Narsil has support for the noinit method for a 2nd clicky switch. I haven't noticed a 6 second problem last I tried, the other day. Hhmm, now I gotta check if that light had the 220/47K resistors combo, thought it did, not sure. Just checked my notes and I got the latest Narsil V1.2+ in 7 lights. Older versions in dual switch lights: JM07, X6R, and Y3 I believe, maybe 1-2 more.
I finally posted the new release of Narsil, version 1.2. here's the summary of changes:
Vers 1.2 2016-09-04:
- added support for 2.2V, 2.3V and 2.4V reporting (min was 2.5V)
- in ramping, remove the 3X click toggle of the locator LED (4X click for lock-out turns it off anyway)
- bug fix: mode sets 9-12 could not be selected!! Fixed this.
Is your voltage calibration compatible with Bistro by chance? The one I am using for the 22k works but seems to have a bit of variance across the voltage range (aka, reads fine at 4.2 and 3v but reads 3.5v at 3.4v). Figured I would just steal your calibration if possible since it seems to be working good.
I use the same header files bistro uses that TK set up.
I use and checked 3 variations of the tables - one in the file: tk-calibwright.h (22K/4.7K before the diode), and two variations in tk-calibMTN17DDm.h, for use with the MTn17DDm drivers that have the voltage divider resistors after the diode.
Great, the table looks virtually the same as mine, just like I figured a few minor changes in the mid range. Minor in the big picture but it still annoyed me lol.
So the 220k and the 22k both use the same calibration? seems that it would be 10x less for the 220k?
As long as the ratio of R1:R2 is the same, it's all good, and same values will work fine - that's been pretty well proven. I saw mentioned the high resistor values effect the OTC cap, but generally speaking, you want an e-switch light with the lowest parasitic drain, so doesn't make sense to use high resistor values for a clicky light/driver.
Just fyi, I'm working on incorporating DEL's internal reference voltage monitoring and temperature monitoring into NarsilTriple. It's at a point where I need it, at least the internal reference voltage monitoring. For the temp, easy enough to just bring it along.
I got sitting on my bench a full up pill triple mod for a OTR M3, and now getting close to finishing a triple mod for the Manker U11. For both, I really need the internal reference voltage monitoring because both have the indicator LED support nad it need to go on pin #7, which I already have testing and working.
I'm using DEL's code from post #1095 as a guide, but it's a little hairy - not quite sure what I'm doing yet with the port/signal initializations.
Tom, following with interest here. Awesome job. This would be perfect to compensate the loss of pins on a triple channel driver and save components for voltage and temperature measuring.
Could you tell me which components are needed for an indicator LED on pin7.
Is it still a series resistor before the LED and a bleeder resistor to GND? Or does swapping to pin7 change anything? I’d like to implement this into a mod of the BLF SRK v3, but have no experience with indicator LEDs until now. Much obliged.
Oh, that's my plan for your BLF SRK too. I got in 3 HQ BLF SRK v3's (thanx!), and got plans, actually really big plans.
Yes and No: Yes - you still need the resistor before the LED, No - bleeder resistor is only for tailcap LED's which are not intelligently controlled by the MCU, as per PD68's method/design.
I've experimented with lots of LED/resistors. I started at low value of 2K ohms, and now at 6.8K ohms, could go higher or lower, depending on what you want for brightness and amps draw, plus depends on the SMD LED you use - color, voltage draw, etc. I haven't tried PWM's on one yet, but it's certainly possible.
@Tom, thanks for the info on the indicator LED. I’m quite eager to use Narsil and I’m working on a version of the BLF SRK v3 driver that is more tailored to my needs. Now I can wrap it up including the option for an indicator LED.
And knowing a bit of you here and hearing you talk about, quote: really big plans, that sounds exciting.
Just got the first reading in the triple Narsil of battery voltage using the internal 1.1V ref . Temperature isn't working though - doing some trouble-shooting...
I'm at 7304 bytes used, of the 8K - oh boy... But this is with adding a temperature control config setting, and displaying the temperature in C (Centigrade) by blinking it out like we do with voltage.
This is DEL code, so he's Canadian . But also, the MCU is really reporting temp in centigrade units. Centigrade is the same scaling as Kelvin. Also more importantly, C is 2 digits for the ranges we are dealing with, F is 3 digits, so blinking out 2 digits will be quicker for sure.
Update: Ok, got temperature readings now - my fault, simple bug. I'm using DEL's code, which he commented has a low pass filter - seems to do fine adjustments on the temp reading, but figure the frequency of readings are roughly 1/4 second, if I understand it all.
Not sure how to understand the temps though. Been getting 35C initially (95F), and the temp of the MCU feels like room temperature to me. It did go as high as 41C (105F) after running the light on max for a minute or so, using a M2-Z test light with a 22mm TA triple, with the driver hanging out and connected to a battery in a carrier with alligator clips on the wires.
I don't have any support yet for powering down output based on temperature though, so it's still early.
Also for voltage monitoring, a cell at 4.20V reported as 4.1V, while a cell at 3.85V reported as 3.8V. Dunno what's goin on there, though I think it's all configured carefully like DEL's, and he uses an equation with subtracting out 0.2V for the diode, so may be a driver variation - need to do a lot more testing on this, but looks very promising - this will come in real handy...
Did you measure the voltage of the cell while it was in the circuit? Otherwise there could be a slight voltage sag as source for the lower values.
Did you use a driver where R1 is before or behind the diode? If before, no substraction is needed.
But from my experience with the 13A voltage measuring is not that precise anyway and I could live with a variation of 0.05V anytime (or 0.1V in the 4V range).
. Temperature isn't working though 
- doing some trouble-shooting...