I'm glad to see you are considering the TURBO 19 as an official variant. It means I don't have to carry it :). Of course I appreciate the point for low Vf LED's lacking any more dynamic solution at the moment, but I want level 20. Of course I have a fancy build script that builds many varieties of things, but it's actually not that flexible. It varies certain particular configurations according to the file name listed as a the build target, not any configuration. Anyway, there ways to do it, but I have several TA modegroup based builds now, although only 3 I wouldn't call very experimental.
Yeah, I have found that setting the pwm to 200 is the best soultion at the moment to low Vf LED’s and/or hosts that just don’t need all the extra heat of full turbo.
Although I find the simpler way to set it up is to simply change the last FET channel pwm from 255 down to 200 instead of changing the turbo to mode 19. I find it simpler, just change that one number and recompile and it is done.
The best thing with existing hardware would be a voltage compensation arrangement that increased the PWM as voltage dropped. It would also mean you would not need to use thin, long wires and could run normal 20-22awg wires.
Yeah, when I really need use of high modes, I tend prefer reverse mode order. But to just get the brightest, from off I just I double-click, hesitate, click. The hesitate is because of the 0.5s medium click default on HD at the moment, something I may look into adjusting. Until other folks try it a bit and weigh in, it's not bothering me enough to change it yet though.
One of the dual switch configs I thought would be neat, already started to write it, is if the power switch works in reverse, as in completely in revers, so long press and hidden modes all have the reverse sense. It's actually not so simple to do though as things on these limited byte scales go.
Could consider some kind of idication/user-feedback on entering turbo (or maybe just last mode?) Like a quick single blink.
So looking through it a little, I'd say what's missing is maybe a 4, ONE, 10, ALL
I don't care much about things above ALL except when biking and I access TURBO through reverse usually. It solves the "am I there yet" problem. Oops, back in moon.. no problem. I may add it in. The only real downside is if it gets up to 50 modes it could get pretty hard to keep track of blink count in the menu, lol.
I updated bistro HD to v1.3 (skipped 1.2). It now includes TAv1.3 modegroups plus one removed group, one hybrid of my own, and the commented out "party" group.
It also includes, by default in the TA-modegroup builds, the new thermal stepdown code replacing the bistro thermal feedback code.
And it includes a couple of different (untested) dual-switch modes, where the power switch comes on either in last mode or in first hidden mode, especially for Lexel, although I like the first hidden mode option (if I had a dual switch light).
Build size for TA OTSM is about 1812 including stepdown and the new modes, still slightly smaller the previous one.
Details are here:
awesome
One question, where do i connect the e-swtich wires to this driver? 
Edit:
Okay, i figured it out, the tread from the Q8 helped me.
I’ve got most of the basic functionality I had on the 84A up and running on the 841 and thought someone might be interested in a few things. Maybe there should be a new development thread for the newer MCUs but I’ll start here as most of the interest for new MCUs appears to be here.
There are a few more BOD fuses to play with. There are dedicated fuse bits for BOD in active mode, and BOD in sleep mode. This means the BOD can be enabled in normal operation and disabled in sleep mode, all controlled by fuse bits. No more mucking about with software BOD disable.
Another interesting fuse bit is that BOD can be set in “sample” mode instead of constant on. This is what the datasheet has to say about sample mode:
Compared to the mode where BOD is constantly enabled this mode of operation reduces power consumption but fails to detect drops in VCC between two positive edges of the 1kHz clock. When a brown-out is detected in this mode, the BOD circuit is set to enabled mode to ensure that the device is kept in reset until VCC has risen above VBOT . The BOD will return to sampled mode after reset has been released and the fuses have been read in.
There is also a Power Reduction Register where one can turn off a bunch of modules. I turn off everything except timer/counter0 and the ADC.
I did some OTSM testing, but as OTSM methods vary I should first state my setup.
My power off routine is initiated when the normal voltage monitoring routine reads 2.2V or lower. On power off I enable the watchdog to wake up the MCU at 0.125 second intervals to read voltage on normal voltage monitoring pin. I don’t do pin checks as these MCUs don’t like high voltages on any pin and I want my drivers to be compatible with 2S and 4S voltages. I use a division factor of 8 for “power off” ADC readings.
Testing with the above method and a single 0805 cap rated at 100uF gives me consistently just over 7 seconds of measurable off time when active BOD is constantly enabled. If I switch active BOD to sample mode I consistently get just over 13 seconds (sleep BOD disabled in both cases). This is good news for me because I can now settle for a single 0805 cap. I was unable to get more than 2 seconds with a 100uF on my 84A drivers.
Another thing worthy of mention is that the PWM timer/counters are not on dedicated pins. You set up a timer as you want, and then attach a pin to that timer. As far as I can tell there are 8 PWM capable pins but only 6 can be PWM:ed at the same time (I think). I only use PWM on a single dedicated 7135 in my lights so I haven’t dug into those details. I just set up an 8 bit timer/counter and attached a pin to it. I have not yet tested with a 16 bit timer/counter.
Looks good, Mike! Wow! Up to 6 PWM channels? And assignable to pins/timers? I hope this 841 chip gets to be mainstream in our driver designs soon!
From what I saw, you don't even need bod on some of the new chips mentioned, can't remember if it was that one, but graphs for idle sleep, that run with the cpu clock, show less than 4uA of current draw. Yeah, you can get down to 1uA with deeper sleep, but that probably won't be needed. Having the full time clock of idle would be great. So I'm not sure there's any need to disable BOD anyway. Anyway, disabling BOD in software was never a problem at all though, not for chips that were able to do it. It was just one command, no mess, and it never caused any trouble. The powersaving options of these new chips should be useful one way or another though and might make OTSM work with even smaller caps, (could save a 1$ :) ).
With the 841 or 1617 (I really have my hopes pinned on the1617 being the next go to MCU) having so many more pins to play with, we now have the ability to easily use a separate pin for the otsm and use it as a trigger instead of a voltage sense.
Didn’t this net much better sleep times in prior testing as it didn’t have to wait for the ADC cycle? This is something that could be explored again. We can also have a dedicated pin for the e-switch and even dual e-switches.
I just posted over in the XHP50.2 thread also, but thought I’d bring this idea here since I see a lot of good development happening.
Could we use the input voltage monitored through the ADC to limit the PWM duty cycle when the cell voltages are high? This way we can direct drive the newer LEDs without drawing crazy current levels.
My thought is that by using the LED I-V curve we could potentially get rough current regulation based solely on the cell voltages and PWM duty cycle using direct drive. This also lets us take advantage of the higher efficiency of the new LEDs.
Yes, we absolutely could and it's been discussed a bunch. It was I believe the first thing I posted here back around September before I knew better. The answer then was it's hard. That answer hasn't changed, but chips have gotten bigger, and even on the attiny25 space has been saved. Getting anything like a "curve" level of precision is not easy with these chips, that aren't very capable of math. Some kind of rough correction that at least goes in the right direction is more doable. This is confounded by the fact that measuring voltage at the Vcc input is already a 1/x curve, where measuring it at the divider isn't and both methods are used now, but the I vs Vf curves aren't linear anyway, never-mind light output, heat etc. I actually took a bunch of djozz's data and re-ploted in a number of ways useful for this but lost the file :(. Maybe I'll do it again. I might at least still have the data I extracted from his plots. We discussed a few specific software plans in the attiny25 thread. Gchart had a simple but real code demonstration. I had a more general, but pseudo-code plan outlined. It hasn't gone any farther yet. It's on my possible todo list for bistro HD, but I'm taking it a little slow on bistro-HD right now.
Oh, yeah, this all gets complicated by how the three channels add if you want to do it for more than just one turbo mode and want the mode order correct on any build with any number 7135s, but that's solvable too I think.
My next task in HD refining/checking the click timing, which might actually even be wrong at the moment by 1 wake or 1/4 second, which could explain why 0.5s seems a bit too slow. for higher timing resolution, but this is relatively easy.
With BOD enabled in active and sleep mode my times are much shorter (around 3 seconds), but of coarse I am aware that the method that I am using is very inefficient.
Well, the mucking about I was referring to was the mucking about that I went through. I mucked about plenty trying it on the 85, and mucked about even more on the 84A because with it I could check that BOD off command was accepted, but I saw no difference in off times. I mucked about with extended sleep periods without waking up the MCU just to test BOD disabled in sleep, and although the bit check said it was, there was no difference what so ever in measurable off times. There is plenty of mucking about potential left for anyone who wants it, but for me it has ended with the 841.
For sure using the ADC like I described is inefficient, I just posted these results as a comparison and first test. Because of them I can move forward because I know now no matter what I want to do I can get by with a single 0805 cap. As I get 13 seconds from a 100uF cap I’m thinking I can go as low as 22uF with my current method to give me over 2 seconds.
You did post somewhere back in the 25/45/85 thread about a different method for checking off time. I don’t quite remember what it was, it had to do with changing cycling though sleep times or something. I remember giving it a go on the 84A but as BOD disable wasn’t really working I did not get any differences (I found sleep times actually a little worse on the 84A compared to the 85V). I don’t remember the details but I’d like to give it a go on the 841. Do you have that link or can find your post about it again? I tried a quick search but couldn’t find it, and I remember it took a while to locate when I wanted to test it on the 84A. Also, what method are you using in Bistro HD?
The 1617 is not easily available to me, and the pin outs are different so it would require re-designing my drivers. Also, it took a long time until there was an AVRDude conf file that supported the 841. If it takes as long with the 1617 I’d have change my development environment for the 1617 because I don’t want to wait. From what I can see the only real advantage over the 841 is the additional 8K. As I currently don’t need it it’s not worth the hassle of switching so I’ll sit back on this one for now. DEL was looking at it, has he made any progress?
If you are only going to be doing single cell voltage drivers, then that’s fine. If you are going to to multiple cell voltages then you are going to have to deal with lowering the voltage as the max rated voltage input on any pin is 6.5V. This applies to both the 841 and 1617.
It did on my 85V tests, but not on the 84A. I’ll look into it on the 841 just to see the difference. If I really like it I guess for single cell drivers I could populate the first voltage divider resistor with a very low valued one, leave the second out, use the voltage monitoring pin for off time trigger, and read voltage for monitoring through VCC. This would at least allow me to use the same boards as for multi cell drivers. I’d just have to have separate firmware routines for off time and voltage monitoring.
It would be really nice to be able to go as low as 10uF for both single and multi cell drivers, so I’m definitely looking into increasing off time efficiency. Preferably without board design changes though.
So from the sounds of it, it is possible, but getting it to work consistently between builds would prove challenging depending on LED selection, number of cells, additional 7135s etc.
Looks like I may need to invest in the tools required to program my own, as it seems like it could be done without too much hassle on a light by light basis by just calibrating the correction factors. Especially since if I am programming my own, I only need the modes specific for a single light to be on the chip, which could save space.
I might sift through some data and do a bit of math to see if I can at least get some sort of rough correction figured out, though I would guess there will be a fairly big difference between the 3V and 6V LEDs.
Are we using a fixed internal ADC reference or does it vary as input voltage changes?
I mispoke, didn't mean to say you don't need BOD I meant to say you don't even need deep sleep. But that's the 1617, I don't know much about the 841.
I don't know any truly different way to do sleep timing on the old chips (new ones, yes). Yes, you can change up the sleep length. I'm looking at doing that now maybe, not hard, first few sleeps in 0.125 seconds, then lengthen to 0.25s. I think I'm going to end up liking 0.375s as a short press threshold, so that would be good for that. The only other thing I do is combine pin wakes so that even at slow sleep cycles I still get instant wakes. You can only measure time by counting the wakes still, so still limited to that cycle for resolution, but you get instant response. That's what HD does, and it works. But it's still just watchdog for timing.
The ADC way isn't so inefficient. I implemented it in a test version of HD that I never released and using the ADC during wakes didn't hurt performance one bit. The numbers of why are detailed in the manual. If it's hurting it for you then you're using the ADC differently than me or have some pin states different. However, going to a more efficient chip, who knows. That's different, but it also matters less.
Anyway, yeah 13s for 100uF is great. I'm not surprised the newer chip can do that after what I've seen with the 1617 specs. It can probably do better than than without even shutting off the cpu clock, likely with ms timing resolution even, not that we need it. Oh, but at those tiny currents, choosing the diode and LDO well will definitely matter, especially when things are hot. I think that LDO TA found should be fine though, but it might be an issue if getting too ambitious, like hoping for 10uF, which on paper is I think possible with the 1617, but difficult in reality maybe, and I'd rather get the idle sleep mode than squeeze $0.20 cents more off the capacitor.
But, all that is great, but OTSM works fine with TA's drivers right here too. About the only difference a user will notice with the 1617 is that they can spend about $1 less on a capacitor. Otherwise, both will work fine.
LED selection definitely. Number of cells, well, it may impact the voltage read method being used, so yes true. Number of 7135s I think can be dealt with. I wrote an outline for it somewhere in last several pages of the attiny25 development thread. I'd review that post myself before I tried to program it.
There are two ADC reference methods widely used, one is referencing the ADC input voltage to the internal 1.1V reference. For that you need a voltage divider that brings the battery voltage to the ADC input pin below 1.1V.
The other method is to actually "measure" the internal 1.1V reference, using the Vcc input as the ADC refernece voltage. The result the ADC gives is 1.1V/Vcc so that's the 1/x I mentioned. Both Narsil and Bistro HD are using this method for 1S. You may think, fine but we already converted that to blink-out voltage right? Not really. In Bitro-HD at least I have a table in 0.1V precision. Worse yet it's not a table of voltages, it's a table that stores two numbers, 3 and 6 for 3.6 and is used to generate 3 blinks followed by 6 blinks, so it's not even single int. This is basically TK's originally way, difference is now there is actually math in the code to generate that table, but that math is done at compile time. It's static. So this is all basically starting over creating some formulaic "curve", and a different curve for the two different voltage read-out methods.
Aha, alrighty. Thanks.
I did find that link I asked about but I don’t think I’ll bother. I have a few other things to try in order to extend the time a little, but no big deal if they don’t work. It’s mostly out of curiosity, I can settle for 22uF caps.
RE, using pin trigger instead of ADC.
True it would still need the voltage divider, would the trigger still work with the voltage divider in place? You could always tie the voltage divider to 2 pins and use them separately.
Or can you trigger the pin with a ground signal? You could set it up to trigger if the ground is broken, this should eliminate any issues with higher voltage. As a bonus it would not have to wait for C1 to discharge before triggering, it should be instant, thus saving time during shut down as well.