Attiny25/45/85 FW Development Thread

Fortunately, we probably don’t really need to hardcode the temperature calibration. I think we can let the user do that — run the light on turbo while measuring, save the temp to eeprom every second or so, and then when they turn the light off the step-down point will be set.

I plan on using an internal visually-linear brightness array of 64 or 128 levels, depending on available space. Even if the light only has 4 actual “modes”, it will use the larger set as its internal representation of brightness. When the temperature gets too high, drop the internal level by one. Repeat if it stays too high. If it gets too low, increase the internal level by one (to a maximum of what the current “mode” specifies). This gives it nearly-imperceptible output changes while regulating the temperature, much like what recent Zebralights do.

As a bonus, this table means the user can smoothly ramp output. They might choose only 4 main modes, but they’ll have 64 or 128 total to choose from. And on e-switch lights they can use the full set. And by abstracting the output, it should work on both single-channel and FET+1 drivers (though it will need to be recompiled for each). And if we want lots of mode groups, it’s simple because each mode is only a single number regardless of driver type… with plenty of address space left over to represent blinky modes.

These are some of the ideas I’m hoping to build soon. I’m not sure if it will fit on a tiny25, but I hope so.

The user cal would work - we don't need to know true temperature anyway, so it's simpler, just not sure what value that would have, another words, what are we trying to protect from over-temp, and how does exterior temp effect MCU temp in varying environments of outdoor temps, wind (bike usage for example), rain, etc. I dunno if we have to do this type of testing to prove it out or not - hard to say. Have you thought about these issues? It's been going through my mind a couple of times thinking bout it. The external temp sensor seems to have more value, but hard to say. Could be the external housing temp stays pretty in sync with the MCU's, or close enough at least - I might be over-thinking this.

The higher res of larger internal table sounds great - makes a lot more sense. I never was crazy about having to use the mode table for adjusting for LVP as well. I think there is/was a firmware variation that did stepped droppage of PWM's for LVP, but not table driven. If we do have to do averaging, might have to do ADC's frequently enough to have a good adjustment response time.

I suspect that it might help to stuff thermal transfer cubes into the pill between the MCU and the plate where the MCPCB rests. This should give a better temperature reading, I think.

But it might work well enough without… I mean, the Meteor used the attiny85’s internal sensor and it does okay.

As for ADC readings, I figure it will probably have to keep two backlogs for averaging… read the voltage, add it to the voltage data, take an average, maybe make a decision. Swap the ADC channel. Read the temperature, add it to the temperature data, take an average, maybe make a decision. Swap the ADC channel. Repeat. This would be part of an active main loop somewhere which also handles blinky mode events and e-switch events.

Blinkies will likely disrupt the event timings (especially e-switch) unless it’s all asynchronous… but async is hard to do on such a small processor. Perhaps the WDT can handle that. I’m hoping to get rid of as many interrupt handlers as possible though, to reduce bugs and code size.

I’m not sure if it would be better to use a round-robin array and act on the average at each step, or collect several complete samples before doing each average.

In any case, I think I’ll be able to get hardware soon so I can start on the code. :slight_smile:

If there’s room, I also hope to queue e-switch events in a meaningful form so that complex button events can be mapped to arbitrary actions. No more awkward hard-coding the logic and special cases in an interrupt handler. I started on this once a while back, but quickly ran out of room. Hopefully it’ll go better this time.

Sorry, I’m doing a lot of thinking out loud here.

Cheat codes! :party:

Hi Tom E. Sorry for confuse you that my modified codes are for an external LM45 sensor connecting to PB3. I thought that the thermal couple between the LED and the sensor is very critical in actual application. General speaking, the MCU is remote from the LED so I prefer to employ an external sensor.

Hi ImA4Wheelr. Thanks for your advice. The high fuse should be 0xDF (SPI enabled). My modified codes have not been tested with a driver yet.

Ahh, ok. I'm thinking you'd get more reliable results with an external sensor, so all's good.

T_K - please think out loud Smile. Interesting - didn't know the Meteor was using the 85 and it's internal temp sensor. I didn't get one, and hadn't been keeping up on the threads. It sounds like if it's set up properly, it can be practical. To me, the Meteor is nothing that unusual, except for it's small size. What Richard is doin with a M6 is more interesting to me. Haven't seen/heard much in details, accept it has 4 FET's - wondering if he is stacking them/running in parallel. I didn't realize parallel FET's would be necessary because the better FET's are rated to 50-100 amps.

Great conversation going on in here tonight. TK and Tom E, one seriously talented duo.

Tom E wrote:

. . . I know real estate on the 15 and 17 mm FET+1 drivers is really tight now, so an expanded footprint for a 45 or 85 might be impossible, but for the 25, it's a true drop-in replacement for the S8S1 package, and looks like you can find the 25's at a reasonable price. . . .

Another option is to just bend the legs in on a 8S2 (SU) chip. I find the best approach is to lightly push the legs on the inward arch (towards bottom of each leg) until the leg just touches the silicon chip. Is springs back just a hair and fits the SSU footprint nicely. It's easy and only takes a couple seconds to do. I imagine we will occasionally get a broken leg, but I haven't yet so far. The picture below is a bad angle. I'll try to get a better angle next time.

Here are some better angles. First pic is comparison to an Attiny13a SSU for scale. Attiny45 SU on top. Second is a profile view. The progamming clip fits and holds much better after the pins are bent.

Used your FW for a bit tonight Tom E. Only got to use it while it was connected to the PS because I had some kind of short when I assembled the light. The little I did use it, it was very sweet. The momentary switch was flawless. That strobe is wicked by the way. I couldn't really simulate a clickie switch with my set up, but the little I did, it worked fine. I like the way you have it set up with memory on the clickie switch and all.

I didn't test turbo time out. LVP seemed to be working fine, but I just did a quick check using the PS.

Can't wait to get the short fixed so I can put it through more paces and take the light into the wild.

EDIT: Driver was a HX-1175b1 modded for 9 amps out to an MT-G2 using 4S cells. Alt PWM output was disabled and 2 Modes were added for a total of 7 modes.

Anyone know of a decent small 18650 host with both an e-switch and clicky switch? The Convoy L4 is pretty large…

I’m mostly looking for something to use for testing.

I believe the EE X6R is a bit smaller

It's hard to find - I haven't seen one, else I would have ordered it. Might be available in a better quality, higher price light, dunno. This is the best deal around for the X6R at $22.80: aliexpress.com Eagle-Eye-X6R, little higher at $24 from BG with the discount code: bbbc2c. I think you, or anyone, will love this light modded. It's a real nice quality host - think it was first going for close to $40, but definitely worth $30 easy.

I got several lights with both switch's, but the smallest is the X6R. The UranusFire C810 is actually real nice (but big), the SingFire 327 is also nice (big), then there's the Warsun X60 (and rebrands) and the Y3 of course.

Your other choice would be an e-switch with a real nice tail lockout - they are excellent for the twisty method. I really like the Roche AS31 - little smaller than a L4 but still bezel is C8 size, but smallest C8 size reflector light around, and no tail switch but nice twisty lockout. I've had good luck with many ZY-T11 clones, ~$10, but the tail thread anodizing is not quality, so you don't get a clean, solid OFF on twisting, and I think with use, it will get worse and worse. There's also the lottery effect - some are better than others, even in the same order of qty 2-3.

Small dual-switch? Ultrafire C20 aka Crelant 7G3CS. There is a very positive and helpful review on BLF. I’ve been wanting one for months and I just Tuesday ordered one on AliExpress for $20 flat.

Edit: Review: UltraFire C20 / Crelant 7G3CS clone

Thanks! Both the EE X6R and UF-C20 look like good hosts for this. The X6R has a bonus of built-in indicator lights (though I don’t think there will be any spare pins to drive them), while the C20 is smaller and uses e-switch wires, and specs of its innards are published in JackCY’s review.

Edit: I can’t tell what size the EE X6R driver is; looks like 20mm. I think it might have the switch onboard though, with a custom-fit driver, so it might need a smaller driver piggybacked onto it like how this Convoy L4 mod did it.

If I understand correctly, I think the pins will be…

reset

1

8

VCC

OTC

2

7

Voltage ADC

e-switch

3

6

PWM 1 (FET)

GND

4

5

PWM 2 (7135)

(I think pins 2 and 3 can be swapped, but both will be needed)

So, no room for indicator lights. But plenty of code space for extra modes and options. :slight_smile:

^ If you're talking about Tom E's latest, Pin 2 is momentary switch and Pin 3 is unused. At least that is what I assumed and did. Didn't look at the code. Now I need to check. Checked.

TK I’m hoping you have enough time to do both a ridiculously fetaured DS FW on the bigger MCU’s and a tamer version for the 13a.

I love the UI of STAR DS already, it’s just missing “modern amenities” like dual-pwm support and multiple mode groups

The C20 is a bit of an odd setup with that driver spring design/setup, and the driver is 19 mm in diameter according to Jack's specs. Check out that review carefully. Of course that was all pre-OSHPark drivers Smile. It is nice to have both switch's though in a 18650 tube EDC and with a separate switch mount, not driver mounted. But it's length of 135 mm is a bit big. If a conventional driver mounted spring can be used, and you can get a good ground connection for the driver, it would be nice. For $20 it's a good deal.

But to use this host for testing, it's not ideal - I'd much rather have a retaining ring on the driver and enough space to fit long wires, so I can easily re-flash the driver without soldering. A bigger host would be better I'd think.

Where'd you find this for $20 on AliExpress? Cheapest I found is the Crelant one for $24.

Check out my X6R mod details in post #78 here: https://budgetlightforum.com/t/-/33113. It's a fwd clicky tail switch and is now running my e-switch/NOINIT combo on a 25.

I got it during the 8/25 sale

Hmm… The C20 has a weird nylon retainer / spring setup, while both the X6R and L4 look like they’ll need the driver piggybacked. None seem ideal. But all I really need for development is a simple tube light head and some extruded parts set up for easy access. The host is more for testing real-world use later in the process.

What would be really cool is a Roche F6 with a switch in the tail instead of a glass breaker. Of course, that also would require a special driver due to the way the switch is handled… like, a derivative of Helios’ driver.

pilotdog68, I think the attiny13a might be able to handle a dual-PWM ramping firmware with the ability to use a tail switch for momentary tactical purposes. No mode groups, but you’d have quick access to virtually every possible level. Would this work? (I’ve been meaning to make one of those, but don’t yet have a FET+1 with an e-switch)

Ahh, missed that... Could be the Crelant 2015 version has some internal design changes, maybe. Jack's review was back in 2013. I'm thinking though they only changed the LED to XM-L2.