Attiny25/45/85 FW Development Thread

You’re right, it doesn’t appear fatal. :zipper_mouth_face:

I finally put one of these drivers into an actual light and did some temperature testing.

At first I nearly destroyed an LED trying to set a heat limit, since apparently the MCPCB was floating instead of having good contact with the pill. Oops. At least the emitter still works, though moon is much lower than it used to be and there are some tint irregularities.

After fixing that, I’m finding that the pill-to-MCU thermal lag makes things difficult. When setting a threshold, the MCU may not be as warm (yet) as it should be. Then when stepping down later, it can sometimes step down much farther than necessary and then take a long time to come back up. And after it comes back up, it may not go as high as it should because the threshold is too low.

… though on a second test (I left it on turbo longer during calibration), it behaves much closer to how it probably should.

It may be because I’ve got it in a big copper pill, and maybe it would work better on a smaller light. But so far, although it works, it doesn’t work as well as I had hoped. And I may need to add a special state transition to bump it back up to the original level instead of short-tap taking it to the next level.

I ditched my experiments with a temperature controlled mode. If the temperature rises above the threshold I just call the same critical routine as critical voltage and put the light in critical mode (either off or very low output depending on setting). The user has to manually switch modes or restart the light to get out of critical mode, which of coarse will only work if the temperature is lower.

I found that the different heat lag characteristics in different lights made it too much of a hassle to make a generic routine for all lights that wasn’t annoying.

After tweaking it until my battery got too low to heat the light up, I think I might have finally eliminated the thermal “bounce” effect (repeatedly over-shooting the target then rebounding).

… maybe.

I’ll find out tomorrow when the cell is recharged.

The thermal controls might actually need to be adjusted according to the physical host the driver is in, to account for varying amounts of thermal lag. It’ll be interesting to move the driver to a smaller host after I’ve got it working right, to see if it still works.

There’s also now an option to turn off thermal regulation. Just tap the button during the first second of its calibration mode, and it’ll calibrate itself to 255 (hot enough to cook pizza, I think).

For those that are interested in using it, could you add a build time option for an external thermistor to ground (as the temp increases voltage would drop on the attiny pin) instead of using the internal sensor? Attaching a thermistor to the pill with thermal compound should provide less heat lag.

Sure, but I don’t have anything like that to test with so I can’t guarantee it’ll work. :slight_smile:

Do you know what changes the code would need? I suspect that the only thing which would need to be changed is the ADC_on_temperature() function in tk-voltage.h, to tell it to use a pin instead of the built-in channel. Or possibly just the definition of TEMP_CHANNEL in tk-attiny.h, where the rest of the driver layout is defined.

(I know, the naming schemes there suck… needs to be renamed better)

Oh, drat. I just realized this needs a slightly deeper change. The built-in sensor rises with temperature, but you say the thermistor value drops with temperature? I bet that could be worked around with a one-line change somewhere… like adding “temp = 255 - temp;” just before the end of get_temperature(). It’d be easier than swapping all the <s and >s, at least.

The thermal lag, etc is not a problem. The things do not heat up fast enough to a level where it causes problems. If you are worried, you can adjust the trip point down a little to compensate for the lag/lack of direct thermal coupling, etc. Besides, a proper thermistor circuit is MUCH more complicated than just hooking the thermistor to ground and relying on the internal pullup (or an external resistor) to drive the thermistor.

Here is my guess. Hoping you could tell me if I’ve missed anything. Well, besides the change needed since the pin voltage would drop with increasing temp. :~

tk-attiny.h:
#define TEMP_CHANNEL PB4

Plus add another digital input disable like on otc pin and voltage pin
#define TEMP_DIDR ADC4D // Digital input disable bit corresponding with PB4

tk-voltage.h ,
#ifdef TEMPERATURE_MON :

You already have this waiting
//DIDR0 |= (1 << TEMP_DIDR);

Yeah… I originally tried to set DIDR, but the compiler didn’t recognize any of the symbols I used so I suspect it might not be relevant for the internal sensor. TBH, I’m not 100% sure I’m doing it right… but it does at least work. :slight_smile:

It should be straightforward for a pin-based sensor, if I look up the symbols it uses for the lone unused pin. It’s probably the same as setting up voltage or OTC, only with a different pin.

Just checked, looks like it is ADC2D for PB4.

#define TEMP_DIDR ADC2D // Digital input disable bit corresponding with PB4

Bistro is fabulous. Using it on a tiny85.

I hope you’re feeling better.

Also, you’re probably the first person to try bistro. Detailed feedback would be helpful. :slight_smile:

It’s not really made for my personal use; I’d hardcode everything if it was for me, and put in a lot more blinkies. Bistro is more about making things configurable enough to cover most people’s preferences without reflashing. The initial setup may be a little obnoxious, but hopefully it only needs to happen once.

BTW, I’m trying to decide how to use the remaining space. One option is extra blinkies, like a stop-motion party strobe or a smooth pulse beacon. Another option is adding a factory reset config option. Another option is possibly a timer to shut off the light after a while (or maybe ramp it down gradually then turn it off). Or maybe other stuff. Thoughts?

Thanks. Still holding on. :ghost:

I would have tried it a few days sooner but I had an odd problem at first. It was freaking out, changing brightness modes randomly, no response to clicks. It was most odd in that reflashing didn’t help and even my v177 bistro.hex (which had been working fine during a brief test the other day) was freaking out the same. Went back to blf-a6 and the driver worked fine.

Haven’t used all the options much yet. The configuration method (blink current option then stutter) does work nice. And I would think click off during stutter will be easier to understand for people. Imo the stutter brightness seemed a bit too low.

Code wise, that you’ve simplified how hidden modes are specified is really great. I could see a lot of people getting a bit stuck there.

I like the idea of a factory reset option.

You could throw in an SOS. I’m sure it’s very rarely needed but some people do like having it available.
Maybe a reserve power option? If left running without interaction it could give a flicker warning when it gets close to ~20% battery left, wait a minute and if it receives no click in acknowledgement from the user it would ramp down slow and turn off. The warning might be useful in some situations like when being used as a tent light or if you’re taking a walk, happily using med-high burning through all your juice too fast to have enough for the walk back.
How about a runtime config option to toggle into a simple mode set / second mode set. Say you want to loan your light to someone. Wife / gf / partner going for a walk, child going camping or treat-or-treating. Toggle over a 2nd mode set (like a simple L-M-H, no memory, no medium press, no hidden modes) in one step. When you get the light back toggle back to all your normal settings in one step again.

ToyKeeper wrote:

It can be hard to follow incremental threads, so here’s a summary of . . .

I agree. Is there anything I can do to help? Perhaps a link in the OP to a post that has a summary of your latest developments? I'll post link to the above post. If you prefer a different post to be your status post (or if you what any other info put in the OP), please let me know. I have renamed the thread.

Hmmm…. I think I like that idea. 8)

If you’re going to do that specifically for “loaning out” the light, maybe the top mode in that set should be somewhere among 60% - 80% of what the light is capable of. Or, better yet, let the top mode be configurable, and the other modes be a fixed spacing based on that top mode now being considered 100%! Could that be done?

Edit: To get out of that special mode set should be something that is not easily discoverable. Any kid “playing” with the light and pushing the button for the fun of it shouldn’t be able to accidentally leave the mode set.

This I like the idea of. One of the things I find happens a lot when I loan lights is they cannot cycle through modes because of the medium.

Yea, with L-M-H, I did mean not 100 since that’s more of a turbo with our fet + 7135 drivers.

The current 15 quick clicks to get into config mode doesn’t feel to easy to stumble into accidentally. Toggle mode set could just be another config option. Maybe the 1st option to make it quicker the switch over to it.

How much extra space did you need to fill? :wink:

An anti-theft feature! |(
Friends, coworkers can’t be trusted? :smiley: The light plays dead when you pop in a fresh battery. Something like 3 mediums clicks then 3 quick clicks unlocks it. Light keeps a general running track of the battery voltage, just enough to know when a battery with significantly more charge has been switched in. Too much to be just from battery self recovery.

Be sure to add a lanyard tag or slip of paper in the battery tube that reads “If found (working or dead) please call 555-LITE-MINE”