TA I'll add your modegroup updates to the modegroups-TA-tripple.h in HD, being pretty sure you won't mind. By the way, this actually produces the traditional OTC version of the firmware too. I was running it on my light for a couple of weeks. Worked fine, that's now the driver on the test bench, since the OTSM is in the light. Although to test thermal stuff I had to break open the light. I couldn't test with a heat gun with that darn OTC, broke the click timings so nothing worked right.
Oh and of course in the HD version, you can also add more groups. The size is actually still shrinking, about another 50 bytes now (some oscillation, shrink, bug fix...).
Done, it will be in the next HD release. I added the party mode back in. I can't remember if I added that the first time or you had it in then. I think I uncommented it just because it fits now. The one thing I'm starting to realize though is the calibrations are still one central configuration, they aren't split out into the different build configs. This might be wrong. We might want default starting calibrations on different builds targetted at different hardware buildups, not sure. I could add a #ifndef to the calibrations and then they can just be overridden in the main configs if/when needed, probably a good idea. Like biscotti is aimed at a particular driver, so maybe the biscotti HD calibration should be setup for whatever resistors Convoy S2's use. Could be nice to take advantage of the Makefile to be able build some different calibrations by default though in some cases.
On the other hand, if you install WINavr, I have one-click compile bat file on windows, so the user can just change the calibration and re-compile.
TA, question, why do you turn the 7135s on in turbo-1 ramp level, but off in turbo (last number in ramps is 0)? I think they're not really doing much in either case, but to insure mode smoothness, it seems better just to leave them on?
Oh, wait, I see, this was a curiosity in the previous version, but now you've backed turbo off to mode 19 anyway? So it's still odd but irrelevant now right?
How can that make any sense? Not that everything in these electronics makes sense, but... hunh? The 7135's are increasing the fet's resistance? Are they sagging the gate voltage that badly? They do draw a bit of gate current, but we've got some good FET's. Was this tested on one of the modern fet choices? Hmm.. well I've got a light meter here in this phone I suppose.
I dunno - if it wasn't TK, it was one of the first attempts at supporting a FET+1 driver. So from the start, I believed them and went along. I never bothered testing it myself. It kind of made sense to me - the FET is the most efficient part, so taking amps away from it and adding constraints to those amps doesn't sound better to me. There's probably more heat from the 7135's than from the FET, and any heat is a loss.
Electricity doesn't work that way. Sure 7135s have more heat because they're resistive, they're meant to limit current. But they will be pegged wide open because they won't be able to draw as much current as they want with the current flowing more easily through the much less resistive fet. That means their resistance will be pegged at their minimum value. Now that's whatever it is, but let's say pretty high relative to the fet. The fets resistance is whatever it is. Ok, but adding high resistances in parallel to low ones, doesn't ever reduce current. It can only increase it. I'd be more much more suspicious of pulling down the gate voltage. Maybe when the 7135s are pegged they start to draw a high gate current.
As far as heat, they make heat the same way fets do: I^2R. It doesn't matter where the R is, the total heat is I^2R and just like with only fets, less R is better. More parallel things can only decrease R.
There's also the heat factor relating to 7135's, so I'm not sure if that's an effect or not here. It's been mentioned and results seen even by O-L. After his own experiences with high 7135 count mods, he was putting 7135's on separate boards instead of stacking, and adding extra copper metal to grnd by the 7135's in order to heat sink the 7135's. He saw measured improvements.
Dunno, it may only be in extreme cases, like stacking for example. Interesting also that ThorFire on the Q8 added extra 7135 pads for ground, and added solder blobs to them - only reason I can see is for heat sinking.
Yeah the 814 is nice as well, although once the 1617 comes out not sure why you would stick with the 814 from scanning the feature list. The 1617 seems to be the latest version MCU, so figures it would be the best? Since the cost is the same or less it seems like we might as well start with the best and work from there. The extra 8kb will prove very useful I think. I already have ideas floating around that could push even that to the limits.
Also, I noticed that the counter is listed as 16-bit. Does that mean we could get more then the normal 255 steps worth of resolution out of the PWM output? That would be very helpful.
I was curious, is it possible to input a voltage / signal on 1 pin of the MCU and send it back out another pin with PWM? Just an idea I am spit balling, not worth talking about at this point, just curious if it is possible.
This is your answer flint. I tested this myself multiple times and found it to be the same results. Less output with them all on vs just the FET.
I am pretty sure that what is going on is we are reaching the limits of what the current the MCU can put out. Driving a bank of 7135’s + the FET causes a voltage drop on the pin going to the FET and thus in turn increases resistance slightly. This outweighs any advantage the 7135’s may have.
It is pretty easy to figure out why I leave the 7135’s on for everything else, it improves efficiency and reduces the PWM signal.
I would think the higher res counter means more res for PWM's - can't say I've done stuff like that in these MCU's, but have on other processors/hardware.
For the 2 channel Narsil w/thermal stepdown, just this morn I'm sitting at 7594 bytes used, 92.7% full, so yes - could use 16K for sure.
Wow, that would be some super fine adjustments, Talk about the ability to get some low moon modes!
If anyone knows the answer to this it was an open question to anyone, I have a few cases I can think of that this might be useful:
I was curious, is it possible to input a voltage / signal on 1 pin of the MCU and send it back out another pin with PWM? Just an idea I am spit balling, not worth talking about at this point, just curious if it is possible.
Yeah, I think you're right ace, about reaching the gate drive limit. Those 7135's are actually kind of bad that way. A gate shouldn't really sink current, but those do. A quality FET low voltage FET should help there though.
I'm not sure higher bitdepth=higher resolution PWM. It could mean that, but only if you also have a faster clock or slow down the PWM. PWM resolution is clock-limited at the moment anyway. In fast mode there's room to increase the resolution by two, but not more without slowing down below 15khz. We prefer phase mode anyway for moon.
Ok, so it's got a 20Mhz internal oscillator, up from our 8Mhz, so you'll probably end up with twice better resolution and PWM changing from 15khz to 20khz. If you're happy to drop to 10khz you can get 4x better resolution.
I was doing some reading and noticed that at least the newer MCU’s offer a gain feature for the voltage of up to 20x. I am not sure if this is available on the tiny25 but if so that should take care of the low voltage readings on the screen flashing.
If not the new 1617 and 841 offer it for sure to allow much larger differences in the voltage readings.
Those powersaving modes do look pretty great. It looks like they can hit 4uA even even with a cpu clock running (at low speed). OTSM would become continuously tunable, although I suspect I can up the resolution on the present version to 1/8s given the present performance, and I might. I have short press set on 0.5s, min, but that's a little slow. 0.25 might be too fast? I haven't tried. 0.375 might be just right. In worst case it is actually possible to make the first few wakes short and then extend them, so high resolution for short click and then save more power waiting for long click. The wait time is already variable in the eswitch version of things, so it's not even much new code to write.
OK, here’s a request for you all. Can somebody make a multi-channel ~11mm driver compatible with all the new/current software toys and using the smallest/latest/best hardware components? It can be two-sided, with an exposed ground ring on the ‘top’ side and at least a 5mm spring pad on the ‘bottom’ side. I want to use it in a clicky light. I would mock it up myself, but I’ve gotten woefully behind on driver designs. Development is moving on several tracks at once, and changes/upgrades are being made faster than I can keep up with them or hope to understand them.
If nobody wants to do it, could someone at least point me to a schematic for the latest/best driver layout (that I could make into a ~11mm board in Eagle)? I don’t need to understand it to be able to make it. I just need to know what to connect where.
I would love to see lower MCU power usage during moon modes as well. Right now most moon modes use between 5-6ma of current. Of that only about 1ma is being used by the LED. If we could put the MCU in some kind of semi-sleep mode during moon mode operation that would drastically reduce power usage.
With the current MCU’s being used, I don’t think this is possible. The 15mm version I made was basically as small as you can go with the current parts list simply due to how big the MCU is.
With the new 3x3mm 1617 that would change, then an 11mm version should be well within reason if you use 0402 resistors. Might even get away with 0603. You might even fit a single 7135 on the top side.
Although this would have to wait until we have working firmware / hardware layout for said MCU. Till then you could use the DFV tiny13 I suppose but you would not be any better then existing 10mm drivers.
Well, as far as UI and mode groups, it doesn’t take much to make me happy. There’s one specific way that I like for my lights to work. Even the ATtiny13 can handle that. But, I want multi-channel mostly for the efficiency, since it’s a small light, with a tiny battery. I also want the latest firmware toys, like OTSM. I know you guys were talking about the new Atmel chips. I figured nobody has a complete working hardware/firmware system for those yet, but I thought it won’t be long. MikeC is already working with the 841 chip, which is smaller and more capable.
There’s also been the addition of some components and removal of others, making the drivers more stable and efficient. A lot of this stuff has been done months ago, but I’ve never caught on, so it’s still a mystery to me. I made my scratch-built contest light with a driver that I designed to be three-channel. But it was based on the old FET +1 layout, so very simple. Will the current versions of Bistro and/or Narsil still work with a simple legacy board layout, like my scratch-built contest driver? Or do the newest firmware revisions require the newer parts lists and board layouts? Of course, I know they require ATtiny25 rather than ATtiny13, but what else?