Added link at top of OP to the above Post Mike C. If you prefer a different Post to be your status (kind of an “OP”) post in this thread. Please let me know.
If anyone else is publishing Attiny 25/45/85 code, please let me know what Post to link to in the OP.
I don't get any measurable difference with the zener or without. Your zener is obviously leaking a ton more than mine. Why is the Q8 driver drain so much higher than the L5 driver?
Fluke still has burden voltage. That's universal between all multimeters.
Ok - just finished up on some zener lessons from a pro (EE @work). The voltage rating on the zener is very important. A 4.7V zener will leak a lot more than a a 5.5V zener, for example -- this is one variable. The further away the zener rating is from the voltage/power source, the better (less leakage). Probably a 5.5V or 5.7V rated zener would be the best to use (still under the 6.0V rating of the MCU), and would reduce the leakage by a whole lot (it's not linear).
Also, though I made it clear, maybe not, the Q8 driver had brown-out detection enabled while the L5 driver did not - it should leak more, just seems a lot more exagerated, like the zener/brown-out detection combo gets a lot higher. Actually look'n at the #,s brown-out detection mutiplied the drain by about 2.5 times - bout the same ratio without the zener.
The one on the MTN-17DDm is usually a 4.9v or 5.1v, but there is still some variance between different 4.9v and 5.1v zener diodes depending on the manufacturer and model.
I built up the MTN-17DDm boards with my own parts, but believe the zeners I used so far are from you -- think you were kind enough to threw in a bunch in one of my orders though. Have you tried these drivers without a zener with a 25? Wondering if it's critical - I could test them out, but lack a scope to look at signals.
I consider it critical, yes; I wouldn't put it on there if it wasn't doing anything. You probably have the 4.3v zeners then since that is what I had at the time. Not really a worry though.
BTW has anyone looked at the Atmel MCU prices lately? The price just almost doubled on most of them!!! 
Yikes! No - that could be a problem... The 85's are within like 1 cent between Mouser and DigiKey, thru all volumes, at least on one part#. Weird - almost like they are controlling the pricing. Qty 100 @$2.15.
Checked my supplier. Prices are currently about 70% of what I paid last time, lower than I’ve ever paid before. Better order me some before they go up again.
That’s fine. Thanks.
Couldn't get brown-out disable working on the "85" (not 85V) MCU I have. Found a macro in sleep.h that does it all in inline ASM, sleep_bod_disable(), and tried that - still not working. I think I'm doing it correctly and within the 3-4 cycles required, but the mA drain is still the higher # of brown-out. Here's my last try:
sleep_enable();
sleep_bod_disable();
sleep_cpu();
sleep_disable();
They also say the 85 revision must be "C" or higher for this to work, and I see a "B" and "e" letter, but of course no clue what the format of the labeling is - ATMEL gives us no clue I could find.
Tom, I imagine that if you bought your 85s in any recent time it would be the newer revision, right? There are date codes stamped on all of the MCUs. I guess that if they came from an "unauthorized" source then who knows what you've really got.
No, no, the ones I'm using pretty sure are all from you recently - think'n you got yours from Mouser? True - doesn't make sense, but clearly there's a "B" letter present, but also an "e3" or "e4". The V's aren't much different though - also have a cap B and lower case e. Someone mentioned might only be supported in the V version, but I haven't found anything to confirm that. One post I found in a AVR forum (http://www.avrfreaks.net/forum/attiny85-software-bod-disable) said he was told (or posted) by an Atmel rep that where the e3 is represents the 85 revision, so, think'n we are good there. Still, the rest of the description does not match what is in this post -- the date code is not in the same format, so lots of doubt/guessing/etc. Please note in the last paragraph on the forum link the difference he measures is 20.4 uA, which very closely matches what I measure, 37 uA vs. 16 uA (21 uA difference).
At this point, I can reflow another driver with a V version, and try it just for the heck of it. After that I'm gonna punt on this, unless there's a chance getting through to Atmel tech support. Still at 0.037 mA, it's pretty low (0.016 mA with BOD disabled). With BOD disabled using our standard resistors, it's like 0.160 mA anyway, so the 10X factor of the voltage divider resistor change with BOD enabled is still much better.
Just found a bug in the latest Narsil version, fairly minor. It relates to the toggling of direction that's in ramping now -- if you triple-click to battery check, exit, then from OFF start ramping up, then stop - then ramp again quickly, you should reverse direction of ramping (lower), instead it continues in the same direction (brighter). It should be an easy fix - will get to it later today.
So, on the agenda for the next release:
Might be 1 or 2 more things...
I don’t know about anyone else, but it often takes me a lot of experimenting to get unfamiliar hardware features to work by reading the manual and trying to implement what it describes. It’s often pretty opaque and I end up not getting things to work until I find an actual example somewhere else. Maybe it’s the same with turning off BOD.
Yea, that happens sometimes to me as well, just all examples found were failures 
. Makes you wonder... I got a ton of hdwe I/F experience, but still these MCU's are a bit different than what I worked with in the past. The way the datasheet is worded around this feature, is very suspicious sounding, like they are not sure what hardware it will work on. Still, it does point to rev C or higher, and just wish I could get 100% confidence mine were C or above.
Indeed, some of the other el. components/ construction mats too: Its due to those huge floods and are going on again in China….maybe a factory or something else was flooded again
Cant imagine what would happen with those( actualy any) prices if something major hit China
Sorry didn't quote the whole thing, but I fixed it! 
A double-click no longer effects the last saved level. Only true ramping does, and where you start out moon level from OFF. By eliminating a double-click to be a "remembered" level, it fixes a couple things, not only what you mentioned here, but also allows to use to keep their programmed saved level in tact thru a double-click, as requested by a "goshdogit" in the BLF Q8 thread.
I also fixed the bug I mentioned above in post #952, about the toggling of direction in ramping. Sometimes it really, really helps taking a fresh look at a problem first thing in the morn 
.
Ah yes! I used to experience this all the time. It’s like our brains subconsciously continue to problem solve while asleep. Doesn’t happen any more though :person_facepalming:
Yes, it seems to go away as you age. Might have to do with having many more reponsibilities. I miss it too.
Just posted a new update for Narsil - now using a rev #. List of changes:
Vers 1.12 2016-07-16:
- in ramping, add 4X click to do a lock-out
- add attempt to disable brown-out detection when going in to power saving (not working on my Attiny85's)
- bug fix: sometimes, ramping up from OFF, then release, then ramp again quick - it ramps up but should
ramp down -- fixed this
- don't let a dbl-click to MAX effect the saved output level (ramping to a level is the last save level)
- added a new mode set in slot #8 for 10-25-50 levels (no max), original #11 is dropped
- bug fix: flaky, bad problems could have happened for the mode sets #8 to #12 -- fixed this
The 85Fuses.bat file has been updated for BOD enabling - adds a little more to parasitic drain, but still is only 0.038 mA (38 uA) - 3 years to drain 1 Ah.
Manual update to come soon - I hope... Minor changes though, to reflect changes listed above.
Boy, I'm 58, but more a morning person anyways.