Has your opinion on C2 changed or is it still worth the board space if R5 is in place?
There really should be a C directly across pins 4 and 8. But we have been getting away with much, much worse before. I would not bother on the 17 mm boards. Stuff like the ADC will see more noise, but I am pretty confident the driver will be stable with R5 in place. On the larger boards by all means put C2.
I have some 0603 ferrite beads on the way. The idea is to try these in the R5 position. Low DC impedance, but 100s of ohms in the MHz range. This should lower the current pulses going through R5-C1 during PWM. C1 can then be relocated to the C2 position, without stressing D1. I still prefer C1 ahead of D1 though, for the sake of more accurate voltage monitoring - no D1 drop to account for (R1/R2 should always tie to C1).
I have a rev01 of one these running and it looks good enough:
No C2, or R4 (or OTC!). Rev02 increases the vias size and shifts the 7135 to get more clearance for the programming clip. Rev02 is untested and may get further revised once I try 0603 parts on rev01 (currently using all 0805).
EDIT: OSHPark link updated to revision 02 - Small change to facilitate stacking a C2 on/beside C1/D1.
Ohhhh - DEL, I like that board! Pin #2 and #3 pads and a big spring pad - nice!! K, so no C2, no R4 -- cool! Are the MCU pins 13A size? Gotta get some 0603 parts though, for sure.
Hi Tom, yes that is an SS package size. So unfortunately 85s will still need some pin-bending to fit.
I also have 20 mm and 22 mm versions. These have all the components and full size MCU pads. But I need to rework them a little first with what I saw on the 17 mm version.
Edit: The board is intended for 0603 parts, but 0805s will fit as well.
Be sure to post if you come up with a better component layout/list. I might be making some changes to the TA drivers anyways if we are able to eliminate R1/R2 and I could update the other changes at the same time.
So far the 17mm boards with C2 in place seem to be working very well. Although if space is an issue for some reason I suppose you could just not install C2, so not sure I would remove it even on the 17mm. The only thing I would really gain is a slightly larger pass through and a tiny bit more space in the center of the board to spread things.
I think I figured out internal Vcc measurement (so we can remove R1/R2).
Its all in 17.13.1 (page 134) of the datasheet.
The only required ADC-configuration change is to set the ADMUX register to use Vcc as reference voltage. (Note this configuration will give a 10-bit result, to be read from the ADC register.):
ADMUX = b00001100;
If we want to read internal temperature, ADMUX need to be set back to read ADC4 with Vbg as reference:
ADMUX = b10001111;
…and we then alternate between the two configurations with a small time delay after each change. Possibly we also need to read the ADC twice each time, to get more accurate results.
To figure out the ADC result for Vcc:
adc_result = ADC; //16-bit integer
where adc_result = (Vbg / Vcc) * 1024;
= Vbg / (Vbat - D1) * 1024;
where Vbg = 1.1 V
and D1 = drop over Schottky = ~0.25 V
So adc_result = 1.1 * 1024 / (Vbat - 0.25)
The typical lookup table we use will look like this for Vbat:
4.2 V = 285
4.1 V = 293
.
.
.
2.5 V = 501
Note lower Vbat gives higher results (Vbg becomes larger as a percentage of Vcc). This would also be an opportunity to finally upgrade to 10-bit ADC operation.
DEL, has anybody told you lately that we really appreciate you here? Thanks for working on this stuff for us. 
With all these driver improvements going on, as well as Tom E and ToyKeeper kicking out newer and better firmware so often, it’s a good time to be a BLFer!
DEL - does this match what Halo... posted in post #731: https://budgetlightforum.com/t/-/34900/731 ?
DEL - is very much appreciated!! 
Very exciting. Once we get this into common firmwares I can drop two 0805 components off my boards (so it will be much easier to fit on the little ones, like the glorious X2R) and we get an extra pin available, so triple channel + indicator LED for NARSIL, or maybe some dual-eswitch lights if the host fits, or who knows what else
Just a reminder: internal Vcc measurement doesn’t work with zenermods.
Ouch! Didn't realize that, makes sense, and am sure was mentioned, and forgotten by me 
. Can we assume same for LDO, because it's doing the same thing, regulating the voltage coming in to the MCU?
Could we take a voltage reading on the same pin but compare it to the internal reference? Or is it still limited to ~6v max no matter the input pin?
That is what we are doing currently. But once you exceed 1.1 V the reading is saturated. Therefore R1/R2.
There are other options: a 2.56 V reference, external reference, or Vcc as reference. None useful to us unfortunately.
Very much the same thing.
long readVcc() {
ADMUX = _BV(MUX3) | _BV(MUX2); // Set reference to Vcc and measurement to internal 1.1V bandgap
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuring
uint8_t low = ADCL; // must read ADCL first, it then locks ADCH
uint8_t high = ADCH; // unlocks both
long result = (high<8) | low;
//Note: might need to discard first result
result = 1125300L / result; // Calculate Vcc in millivolts; 1125300 = 1.1*1023*1000
}
‘ADMUX = _BV (MUX3) | _BV (MUX2);’ is equivalent to ‘ADMUX = 0b00001100;’.
Then there is a delay for Vref to settle. I would do this differently to not hold the program.
‘low = ….’ together with ‘high =…’. and ‘result = …’ can be simplified to simply ‘result = ADC;’.
Halo is calculating the voltage in mV, which is also a valid approach - removes the need for a lookup table.
The D1 drop has to be added to this calculation to get the cell voltage. EDIT: and it should be 1024 in the formula, not 1023.
And yes, unfortunately not useful for zener or LDO fed MCUs.
Not lately :D, but it is people like Tom and TK that do all the heavy lifting!
Yes, it’s worth saying again, Tom and TK are very much appreciated as well!
Indeed, if not for all the hard work and time of these people flashlights would still have 5 modes with blinky being a non-option. lol
Yeah, but don’t talk too bad about blinkies… TK loves them!
Thanx!
TK likes her biking blinkies - does a lot of night time biking, I'm assuming.
Proof of concept, if anyone wants to try it:
tiny25/45/85 Vcc and temperature reading
As configured the firmware is for a FET+1 driver.
No memory, starts up in medium mode, one click to low, another to moon.
Next mode after that is cell voltage flash-out.
And after that is the MCU temperature flash-out.
Then a bunch of blinkies to be ignored.
There is a pseudo ‘double-click’ from off to get to DD mode.
The new ADC stuff is mainly inside the ADC interrupt routine spanning lines 159-183.
Mind the fuses, as programmed it is meant for a 1 MHz clock:
* Fuses:
* Low: 0x62 (8 MHz clock, 8* divider, 14 CK + 64 ms startup)
* High: 0xdf (no BOD, SPI enabled)
* Ext: 0xff (self prog disabled)
avrdude -c usbasp -p t25 -u -B 10 -Uflash:w:???.hex -Ulfuse:w:0x62:m -Uhfuse:w:0xdf:m -Uefuse:w:0xff:m