Ok, another thermal runtime test. The previous one had the temp limit set to 60°C, resulting in a body temp of 45°C. I’m guessing this is due to the poor thermal path from the driver to the body. I had calibrated the MCU’s thermal equation using room temp (21°C) and my oven at 85°C. I ran another test with the temp limit set to 70°C, which resulted in a stabilized body temp of 53°C - definitely hot, but not scalding. Here’s what the resulting graph looks like. BTW, it takes the about 12 minutes for the body temp to reach it’s max and stabilize.
I’m curious about turning off thermal management to simulate the stock driver and take temperature readings since I didn’t do that initially.
Yup. But the D10 has a “standard” 20mm MCPCB, IIRC, making LED swaps easier. And they can accept optics with a little bit of effort. But yeah, the same electrically speaking.
Well, with the dual I got, I swapped the LED's to T6 4C's that I had laying around, and I wired in a ATTiny85 to the stock driver, using NarsilM in 1 channel output mode. It worked pretty well. On a 35E cell, got 3.26A and about 970-930 lumens, not much drop in 30 secs, got barely warm, maybe, so handled the heat pretty well. All worked great til it stopped working...
Seems like after it heated up, something shorted out. If I loosen up the driver, it goes back to working, but as soon as I tighten it up, it shorts out again (i.e. light comes on max).
So my theory was correct about it being a simple FET channel, and wiring up the 85 with grnd, Vcc, switch and FET is all that was needed. Also I replaced the D1 diode with a 4.7 ohm resistor, and that worked well. Got frustrated with it for now - will trouble shoot it later. Need to de-solder the LED wires which are kind of a pain to thread thru the tube to the MCPCB. The wiring and positioing the 85 are all tight, so something there probably is making contact where it shouldn't.
Wondering whether it would be possible to make a PCB for conversion from ATtiny to PIC, particularly since it would only require three (or four) traces?
Do-able but no room for it in this light. It would be better to design a driver that's a dead-on fit to the stock one, but even then, parts placement is critical because you have to have clearance for the plastic piece - there's just no wiggle room. Not many options with this light. The plastic piece is the important thing here. Probably a way to trim it to accommodate a stock size OSHPark driver, but didn't look at that.
So far what I've seen with this NarsilM on a wired in chip can work well with this light - it doesn't get a lo-lo, ramping at the low end is a little flickering - expected from low output levels to a FET though - seem the same thing with our normal FET's. I'd probably have to lower the PWM rate for these low levels - we've (maybe just TK) have done this before.
You are really limited in full modding this thing - the LED wires go thru tiny channels inside the battery tube so you can't go to heavier gauge, for the dual, not so easy to replace the MCPCB. Maybe using 2 small ones, but has to be thin as well. I want to keep the amps low, better efficiency then on just a single FET channel. I might actually remove a current limiting resistor or 2.
I haven’t noticed any flickering at the low end on mine, and I have the PWM compare at the low end set all the way down to 1. It’s running with clock at 3.33MHz, no divider on the timer, 8-bit mode (period=255), and using Phase Correct. So… I think PWM freq should be around 6.5kHz.
I had considered that as well. With as cheaply made as this thing seems, I don’t really feel motivated to create a driver for it from scratch. If I open it up again, I’ll probably just remove a current limiting resistor and call it a day.
You know, I've been re-reading your post #2 describing what you did -- this is dang impressive!
Yes, your PWM's and clock are way lower, so that could be the difference. I forget, but mine are probably 15-18kHz.
Your solution is wayyy better than mine for sure. Like your porting of the RampingIOS, and got it in 4 KB. Don't recall how big it was for our use, but thought it was over 4 KB.
Thanks, Tom! Having the same pin mapping as the original MCU made things easier (physically). And I think it was close to 4KB when I compiled it for the 85, I didn’t really do much trimming. Next step is to try and get NarsilM and Anduril ported. But I’m sure I’ll need to switch to the x16 chips since those are available in 8KB and 16KB versions. It certainly won’t be for this headlamp though - the x16 chips are QFN.
I thought TK was working on the port to a 16 KB part, not sure if it was this same family -- think there are 2 16 KB tiny's? Not sure if she is aware of what you did here, though I'm not keeping up on all the threads.
For this 412 part, it sure is huge to have the same pin config as a PIC - all these Chinese flashlights seem to use a PIC. Sounds like you know a lot more than I about these micros - I really haven't done any more than these flashlights with the classic 13A/25/45/85 family. Most of my micro experience was wayyy back, and when I have more recently worked on them, the groundwork was setup for me regarding the dev tools, programming, etc.
I would think your port changes could apply easily to NarsilM, maybe easily to Anduril as well. I sure would be interested to get them ported to a 16 KB part, and have an easy dnld setup.
I think the effort was being done on the 1634, it’s also a 16KB chip, but uses the same architecture as the 85. MikeC has been using the 1634. And I think TK is aware of my efforts. I PM’ed her about my on-going documentary here.
Hmm, so it looks like they replaced the no-name chip with a PIC (as well as some other mods). Outside of tterev3 here, I don’t remember seeing much adoption for PIC on BLF. I’ve never actually looked at any code for them.
Easiest way to mod this driver is to remove 1 resistor, proper way is to build new driver from scratch ;))
Wondering what we get if we replace those little fets to a 7135 and short resistors on output? ;))
