I've configured TA FET+N+1 drivers to be FET+1's before, just didn't populate the bank. On over powered lights, the bank is a problem. The FET's we use run as cool as a cucumber, but can't say the same for the Chinese knockoff's - TA did some testing on those, not sure how they do thermally, but he thought they performed acceptably, just not as good, but could be hit & miss.
There are 2 different factors here.
1. The 7135 chips are directly overlapping the MCU causing it to heat up prematurely.
2. The MCU software seeing the rapid heat increase and predicting it needs to lower the power.
Regardless of any software changes, the issue of the MCU thinking the flashlight is getting hot (when itās not) is still going to cause the early stepdown. The only fix I see that makes sense is to physically reduce the premature heating of the MCU (deactivating the 2nd channel, physically removing the chips overlapping the MCU or adding the heat spreader).
I believe the software changes TK made are more focused on eliminating the pogo or oscillation effect of the brightness level, aka not reduce brightness too much then have brightness ramp back up. I think her new code has it drop a more reasonable amount and then be much more level.
As far as setting the 2nd channel to max out at 50% of its ability in order to reduce heat output, I dont know. If it makes the 7135 chips heat up half as much then maybe it would help. You could probably test it by setting the top of ramp to a lower level. Stock is 31 clicks, so maybe set it with around 50 clicks? This might require measuring the amp draw, unless TK or Tom knows what step would halve the output of channels 1+2. Once itās set, you just test it out and see if you get a premature stepdown. If it works, you would need to change the Anduril code to limit output on channel 1+2 and bring in the FET sooner to compensate. I canāt modify Anduril code and Iām not sure the average person can either so Iām not sure how feasible this solution would be (assuming the tests results were good).
Hi,
Iāll have this flashlight soon and wonder if You can advice me 2 things:
- I want to use it with batteries Liitokala 50a ( 26650 and 20A discharge - gives 5500 lm from tests ) or Samsung 40T ( 21700 and 30A discharge - gives 7470 lm ) which will be better for this flashlight? Itās much easier/cheaper/faster for me to buy one of this instead of Shockli if someone ask.
Test link: ASTROLUX MF01 MINI - This Flashlight has it all!!!!! - YouTube where I found that lm values
If we assume that flashlight has heat problems should I go for this 40T or it makes no sense and lumens will drop so quickly that itās bad idea ( with / without copper/paste mod )?
- What kind of material are that āstickersā on heat sink made of? This is made for thermal or electric conduction ( maybe both ). What should be max temperature that this stickers/glue could stand? Maybe You can share me a link for that type of stickers?
Greetings and thanks for answer 
At max/turbo, all our firmware sets the FET to 100% and both 7135 channels are turned off. We found this to be the best max output, rather than turning all 3 channels on. So considering this problem of the MCU seeing a high temp even at max/turbo, I'm not sure what's going on. It's hard to imagine the 7135's are getting hot when they are not even turned on ?? I've been thinking the simple replacement of the plastic retainer with a copper one increases the heat path to the driver significantly, and that's why it does so better when at max/turbo. The 7135's will get turned on when the temp regulation starts turning down the output, so at that stage, the heatsink's connection to the 7135's should be helping. From past proven tests, done by Ol Lumens for example, we do know heat of the 7135's is a big problem and heatsinking them makes a big dfiference. So I think this heatsink helps in both these ways, though not sure if copper would do significantly better than aluminum. But again, sometimes the cost of copper over aluminum isn't a big factor after the shipping costs, manu costs, labor to install being the same,etc. Even a slight advantage of copper may be worth minor extra cost.
As we discussed, the mini doesn't handle heat so well, so maybe the 50a battery will be a better choice. All depends on your usage and how you want to use the light: 10 seconds of outstanding brilliance (40T) of a wow factor, or having a somewhat longer duration of decent output (50a).
The stickers are for electrical insulation, not conduction. There to keep things from grounding out that you don't want to ground out, such as protecting the caps, and protecting the batt+ end from touching ground.
Thanks Tom, so far I was thinking similar way that maybe itās better to have this longer working instead of short bright flash and then even worse stepdown. Some people on Youtube write that this 40T will be better but maybe they didnāt test that in this exact flashlight model.
In the long run of any Anduril lights I would progress on MCUs to 1634 and 1-series and put a dedicated NTC on the MCPCB
Itās again the egg and chicken problem, if the firmware does not support new MCU and thermistor no drivers are made
Well, the 1634 is not a problem - already there, but not sure if she has support for an external thermistor. The 1-series is too new. She said the tool chain isn't quite there yet - I haven't checked into that myself, but ultimately that's where we ought to be heading to.
I wish I could get 1634 17mm and 20 mm drivers. Of course I'd prefer buying the boards from OSHPark and buying the parts and reflowing myself. I'm still ordering 17mm and 20 mm drivers from OSHPark for the Attiny85 - no choice at this point.
Here's a look at 1634 support in Anduril:
/* Emisar D4Sv2 driver layout (attiny1634)
* (same layout as D4v2, except it's a FET+3+1 instead of FET+1)
*
* Pin / Name / Function
* 1 PA6 FET PWM (PWM1B)
* 2 PA5 red aux LED (PWM0B)
* 3 PA4 green aux LED
* 4 PA3 blue aux LED
* 5 PA2 e-switch
* 6 PA1 (none)
* 7 PA0 (none)
* 8 GND GND
* 9 VCC VCC
* 10 PC5 (none)
* 11 PC4 (none)
* 12 PC3 RESET
* 13 PC2 (none)
* 14 PC1 SCK
* 15 PC0 3x7135 PWM (PWM0A)
* 16 PB3 1x7135 PWM (PWM1A)
* 17 PB2 MISO
* 18 PB1 MOSI
* 19 PB0 (none)
* 20 PA7 (none)
* ADC12 thermal sensor
*/
There's no more chicken and egg thing. The firmware supports it, just a lack of 1634 drivers.
Ok, I'm egging you on, Lexel... 
lume1 has external temp sensor, so there must be some supportā¦possibly not yet public.
Can't recall details or where, but I know there's been some testing. I thought most of these sensors are wayy better than the internal ones - don't need calibration. With all those spare pins, shouldn't be difficult to add support.
I thought about a quite simple solution like simple SOT323 2,8V LDO 220kOhm high resistor and 47k NTC with a calibration table like for 2S voltage readings
Ohh, didn't realize so may parts were needed. I know I've seen temp sensors, say for an Arduino or Raspberry Pi like this: https://www.amazon.com/SunFounder-DS18B20-Temperature-Arduino-Raspberry/dp/B013GB27HS?ref_=fsclp_pl_dp_7. Maybe little simpler - dunno, maybe more smarts built in.
There have been always single data line temp sensors like this, but they are usually big and need you communicate with them, a NTC can be very simply implemented
You can eliminate the LDO with firmware battery level compensation
But then you would lose many of the benefits of an external sensorā¦ like increased accuracy and no need for calibration. It would be a noisy signal again, because at least one of the factors in the equation would be a noisy signal.
Regulated drivers generally already need a LDO to keep the MCU at a stable voltage, so it might not require extra parts. Basically, if any part of the driver relies on analog control voltage, itās going to need hardware to make the voltage stable. It doesnāt make much sense to design the hardware so it needs workarounds in softwareā¦ that would likely just ensure the output graphs are bumpy and veer gradually off course as the battery drains.
Iāll take 2
Another simple solution to not to use NTC and relative to that lookup table or polynomal computing of temeprature is to use just diode as thermal sensor or dedicated analog thermal sensor like this https://www.mouser.bg/datasheet/2/268/20001942G-1820450.pdf
In this analog sensors they just use diode as sensor which give about 2mV/Ā°C and amplify output voltage to about 10mV/Ā°C. Using sensors like this need very simple calculation of temperature and we need only one additional ADC channel for this and also they are cheap.
so worst case is +/-2Ā°C with those, they seem to need 3.3V Vdd
a quality NTC is very precise and can be easily used in the firmware by a simple analog voltage input
Is there still chance for one copper heatsink?
Is there still chance for one copper heatsink?
Iām interested in one. Pm sent