Attiny25/45/85 FW Development Thread

At easyb I might not fully understand your question about Fet+1. But one thing BHD attempts to do is bring the tripple, quadruple, double(or single) channel bistro versions back together with preprocessor configs that work again. You can select any combination of PWM channels you want in the fr-tk-attiny.h. Select the corresponding layout in bistro.c Define the corresponding "ramps" any way you wish in modegroups.h. For moon modes you're best to stick to PWM and PWM2 channels, because they run on timer0. It seems to be just very difficult to get good control at low levels on timer1, although I did get a pretty good moon out of channel 4 by setting it to 0 PWM (not zero mode, mode zero shuts off PWM4 entirely, the only way I found to get full off, so just would want 0 in the ramp table for PWM4) . PWM3 works differently than 4, and is maybe ok too.

So I made little excel calculation for off-time, including power consumed while waiting to detect the pin fall, just using RC and threshold voltage etc. Everything matches up reasonably well with what I saw. It looks like tweaking a few things should get it well up over 3s with only a 3.0V battery, including going from 30uF to 47, but also getting the better diode, going to a V-chip, and lowering the pin voltage by 25%. It should work like this with a bit higher resistor values too, so that's good (I'm going to try 500 R1, 1500 R2 and no bleeder). I have the v-chip but I'd forgotten to get the diode and resistors, so still waiting to put it together. The Ta cap shouldn't be very temperature sensitive and neither should the reverse leakage on this new diode, so I'm hoping the numbers stick when hot. I think this will likely work well.

Oh and of the chips I've seen,

25's were revision G (good)

25V: revision F (still good),

45V: revision G (good),

85: revision B (bad/no bods).

So the situation with attiny85 seems bad for BODS.

Hmm... so good and bad. At 3.0V input, the new setup (v chip, Ta cap, low leakage diode, tuned voltage divider) is able to measure off-clicks over 3s in length, (I'm pretty I measured it closer to 4 once, but haven't tried to reproduce that) using only 47uF of capacitance, and does it even with high overall bleed resistance (4.3kOhm). At that voltage and bleed value, that's as good as I would have dared hoped for.

The bad, for some reason it can only do that on low modes. I've done a ton of measurements. Off-time power consumption has nothing to do with what mode it was in before it turns off, because I always shut down PWM before sleeping. mcu power consumption while it detects shutdown does impact it though. LED consumption does not, because it's isolated by the diode from the MCU off-time cap, C2. If anything high LED current should drain C1 faster and result in quicker off-time detection before the mcu eats up its reserves.

Ok, so I measured mcu current draw in all modes (again). It doesn't vary much. With my powersaving trick enabled it's about 2.1mA for 1 7135 or the fet. It's closer to to 3mA for all 7135s (the difference actually being in-line with the spec sheet drive current for the 7135s, although it's interesting that these are technically still on when the FET is running, and yet the drain goes back down to 2.1 when the FET is on). As it turns out, I can get about 1.5 seconds of off time on the FET on full power if I add back a 500ohm bleeder, but I can barely get any off-time at all from the all 7135 channel. For the single 7135, again on low, it gets very long times. On full throttle at 3.0V it can squeeze out over 0.75 s, getting close to 2s by 3.5V, all with the bleeder, so bit worse than the FET. This seems to indicate it's not about total LED current. But I'm at a bit of a loss what it is about.

It's very possible that I just missed this in the first build. I was mostly testing on low or turbo, and didn't even have the backside 7135s installed on that build.

The extra 0.8 or so mA of the all 7135s does not seem to add up to anywhere near enough too explain this, from the math or experience (I did some work to get it down from 4mA in the first place, and yes it helped, but no where near this drastic). The math from all the measurements actually adds up pretty well in line with the 3s+ I'm getting on the low mode.

hmm...

Oh this is probably not a heat thing. It's still on the bench and separated from the LED. Of course the whole point of this particular diode and the Ta cap are that both should be pretty immune to heat, but that's not proven yet.

very strange that the channel effects the total time.

Reminds me, I need to put together a final release for the Texas Commander driver. It works fine, just sadly limited to either low currents in regulated mode or to last gen LED’s with higher Vf or it will overheat.

Works great with last gen LED’s though and if you stuffed the driver with thermal cubes it should help it as well.

I see, it seems we're both a bit stuck. Yes, I was not expecting this bug. I don't think this is a fundamental problem with the methods, and maybe I'll figure it out eventually, but it's a puzzle. I'm starting to wonder if the PWM is interferring with pin change detection and I'm half tempted to desolder the 7135s to see if it still happens if they're not hooked up. My first guess was higher mcu drain due to drive current, but I couldn't make the math work out this bad without pretty crazy numbers, and then measurements show no crazy values. About the only other thing electronically is somehow increasing the effective C1, but at 1uF that seems pretty far fetched too. I guess the diode could be leaking, but why then? It's strange, and strange is the realm of the mcu so I'm started to suspect something going on with the off detection.

I'm a bit surprised about your driver too. We dump these levels of heat in 7135s all the time right? I guess they're pretty spread out though.

The driver still gets pretty warm with the 7135’s, the key difference is that the 7135’s have a thermal regulation circuit built in that turns down the power if they get too hot automatically. This happens a lot but no one notices due to the fact the human eye doesn’t notice the rather small changes in output.

The other big factor is that the 7135 heat sinks directly to the ground ring and thus it able to dump the power into the host.

Lastly the 7135’s are indeed more spread out which helps as well.

From our testing we came to basically the same conclusions as the LD-3. It can dissipate around 1.5-2W of heat max if connected to the host well. You might be able to push that a bit higher if you fill the cavity with thermal cubes.

This is fine for the last gen emitters with high Vf as they max out around ~1.5-2W of heat. The latest 219C 90 CRI on the other hand could need as much as 3W+ for a single LED. Same for the L2 and other new LED’s.

The option to fix this would be to make a custom mcpcb that puts the FET directly on the mcpcb do it can easily dissipate the heat. Then it would in theroy be able to handle basically LED setup. This would need a custom mcpcb though which would be costly.

This is the only option I see going forward with regulated compact drivers, although it would be hard to fit the FET onto a 16mm star.

That is unless we can figure out a compact buck driver.

Luckily the Texas commander has a direct drive turbo mode that uses the normal PWM and can handle tons of power but the regulated modes are still limited.

differences in attiny hex

So I now have a Makefile automating builds of several configurations in combination with several chips (with for example: -DCONFIG_FILE="bistro-custom.h" -DATTINY=25) . For what it's worth, my code built for the attiny45 and attin85 differs by about three bytes in the instruction payload of the hex files. I haven't bothered to figure out what those bytes are, but obviously there can be some memory address differences at least, but I just don't know. The attiny25 file is different, and for that I knew at least one reason, the attiny25 uses an 8 bit stack pointer and the 45 and 85 use 16. I access the stack pointer so in this case there's even different source code. Will and attiny45 hex work on an attiny85 without problems? I don't know, but at this point I wouldn't try it unless I had to.

No luck on this 7135 thing yet. I hoped it was a software issue, but it doesn't seem to be. I went back to the old test rig with no back-side 7135's using latest firmware, and also tried an older version firmware with the new driver. The test board works fine, with the all7135s channel on, with no actual 7135s on it. Just to see, instead of shutting down all channels right before sleeping I turned on turbo instead. It really shouldn't matter, and it didn't.

About the best idea I have is get the driver to self trigger a shutdown. by sending input power through a second channel FET. Then it's possible to time the shutdown detection. Mostly that would just prove what already seems true though, but still wouldn't explain it. This is really puzzling.

a crud.. never mind. I thought I had progress on this 7135 thing, but I think I fooled myself. Anyway, I'll keep playing with it.

Anyway, I found diagnostic tool. I can sneak in a Vcc ADC read in the interrupt right between detecting the shutdown and powering off. It's working, although no time to interpret it now. It should give insight into how much time and charge is lost before the shutdown. I could make use a couple actually, like one after the first wake, and get a read on how much drain is happening during sleep that way too.

So some interesting results. Unless I'm getting completely fooled, like the interrupt is firing at all the wrong times (TURBO works so it can't be all broken) I think I'm measuring the voltage on C2 immdiately after the pin fall is detected.

I first had to calibrate my Vcc read real well (which uncovered a slight bug in the calibration function, but almost irrelevant really). Anyway

In turbo I'm getting:

Input Voltage Vcc Catch voltage

4.0 3.06

3.06 2.71

On All7135s I'm getting almost the same

Input Voltage Vcc Catch voltage

4.0 3.00

3.06 2.60

I find it interesting that the 4.0V reading does relatively badly compared to the 3 V readings in both cases. But what's more interesting is that there doesn't seem to be any serious problem here with the 7135s, and yet there is. This helps though, because if this holds up it at least points to what's not the problem, power down detection time, unless that 0.1V is really a big deal, I wouldn't think so.

This seems to be a good tool. I'll continue, trying to measure voltage at the first power-on and see what that looks like.

(just updated numbers to uncorrect for the diode, so these are real voltages on the Vcc pin now.)

SOLVED!!!

Yes. I got it. Just had to find the right pin state to get the driver pins into after shutdown detection. Apparently output low doesn't work (or output PWM 0, should be the same thing). I have no idea why not. Input high is documented as a good option because it's high impedance and avoids supposedly problematic middle voltages (input low actually means input floating). And yet, the solutions was input low. It maybe helped that I shutdown the 7135's first pulling them down with a quick output low first, I don't know.

Anyway, it not only works, it works great. You can whistle a couple of line of Dixie before you turn you light back on. I've got the code in a bit of a mess at the moment from all kinds of testing, so I'll probably start over from the last release and add things and test, might take a couple of days, might not, but I think we'll have OTSM working great in bistro here shortly.

I keep recompiling and reflashing this same ROM and keeping checking that it's really in ALL7135s because I keep thinking I must be confused, but it's working.

Updated: It actually works over 4s at 3.0V without a bleeder (~4K of divider resistance) and 160C heat gun pointed at it!

:D

I have no idea what you are talking about Flintrock but your writing tells me you are excited and that can only mean one thing. Your onto a winner. well done. :+1:

Thanks MRsDNF.

OTSM. (I think TA named it that). I think it means off-time sleep mode or something like that. It's the replacement for OTC in bistro HD. It means that the length of a medium click is as steady as the watchdog timer, which as far as I can tell is about 10% even when hot, which is much better than many caps. It's also not sensitive to all the resistor tuning that the OTC is, so should eliminate those headaches.

I've got the first low-capacitance bistro Texas Avenger OTSM light ever right here in my hand, working just fine. I thought the issues were worked out several weeks ago, but it hit a snag when applied to a real light. The snag is now defeated.

These fixes will of course get posted up to the bistro-HD thread shortly.

Thanks for the explanation. Now to remember it. :+1:

12v jobbers isn't a term I can google to fix my bricked chip /board (I tried to do a flash and I think I bricked my chip) What do I need to fix my driver board? It's a 17DD MTN Fet + 7135.

I built a high voltage serial programmer to deal with that stuff: High Voltage programming/Unbricking for Attiny – Arduino, ESP8266, ESP32 & Raspberry Pi stuff

However, if it’s one driver you’re talking about it’s cheaper and less frustrating to just get a new one. I used the reset pin quite a lot on the ATtiny85 so I needed this in order to be able to flash after activating reset pin as IO.

Edit: false alarm, read here .

Have to reanimate this thread, I guess.
Did anybody take the dependency between voltage and temperature readings on Attiny25/85 into account?

For my 2018 BLF Contest light I developed bluetooth remote control with telemetry. Voltage and temperature readings are sent to the app once per second. I noticed a significant dependency between voltage and temperature. Here a couple of readings for roughly the same temperature:

at 4.6 V temperature reading is 13 °C
at 3.6 V temperature reading is 27 °C
at 2.7 V temperature reading is 33 °C

As you can see the dependency is not linear. When I find some time I’ll do more research.
For now I’d say this dependency might interfere with temperature regulation.

I didn’t care much about it. On the other hand I don’t recall getting such wild variations, but since I haven’t touched the 85 in ages my brain has purged most of that stuff. I’m sitting with my ATtiny1634 drivers right now so I just tested: 20°C at 2.6V and 22°C at 4.4V, nothing for me to worry about.