LP, he’s saying the base setting should be 25C…I think. I found the M43 UI too confusing so I pulled it, stripped the driver, and piggybacked in an FET driver. I have Anduril in my M43 now too. And a Master/ 3 Slave configuration if I remember right. It gets really really REALLY hot in Turbo, way fast! 12 Samsung emitters will do that in this small of a light.
Thanks Matt, it was one of those wild hair moments. 
(unfulfilled due to the lack of the extension tubes Sofirn quit on)
Anduril works fine in Ham’r because the drivers are separated from the heat source by a significant amount of aluminum. By filling the head of the light with the base of the finned addition there is a LOT of mass underneath the emitters. My M43 has the drivers virtually up against the bottom of a comparatively thin emitter shelf, as such it floods heat into the Master driver in a very quick manner and Anduril isn’t set up for this… too much too fast by a wide margin so the thermal issues arise in the driver. Again though, in the even more powerful Ham’r it’s simply not a problem.
lol… I found some behind the scenes footage from Dales HAM’R build!
Maybe this is a similar issue to what TA is experiencing trying to get Anduril to function on the MF01S?
You’re an active member on BLF…
You’re well informed and have some pretty in depth knowledge from what I can see…
Yet you’re able to resist buying every amazing new flashlight that comes around!?
Here’s a link exploring some commercial buck and boost drivers, tests and modifications:
I send you link to extended manual.
It means that temperature of flashlight body should be 25C. After 14 times and hold light blink twice and button blink green - calibration is done.
if light blink once and button blink red than calibration failled due to large(>16C) difference between temperature of light and estimated temperature by m43.
The consequence of this procedure that you can adjast “50C” stepdown in some range .e.g. if you calibrate M43 at 20C stepdown would be at 45C
I will also ask for a link to the extended M43 instruction
i am interested in this manual as well. Thank you for the link. Could someone who knows how please enlighten those who do not, on how to get this translated into English?
thank you!
The village people are breaking out their pitchforks (they already have the torches out)
•
•
•
THANK YOU AEDe!
Whoa! Thanks a bunch!
Thanks Tom Tom,
I started with Jason suggestion on that guys youtube videos which are helpful in a practical diagnostic sense. I then took your advice and checked out some online free ee lectures where I stumbled across an old school one from a MIT EE engineering prof. lol WAY over my head but I like it. lol makes me wish I did go the scientific route in school instead of business. Nevertheless I might just learn about what you guys are talking about one day after all!
Thanks for the additional link. The EE course is vast compared to the more specific information I’m trying to grasp right now like the flashlight components
That’s a great idea, actually. Complex, I’m sure. But I like it haha
I’ll be bummed if there are no pogo pins, it seems like they are not that hard to add, and they add a whole lot of functionality.
Or even if you could just tip out the driver like on the Q8 to flash the chip…super easy!
FWIW, the variability of the ATtiny 85 (and 25), internal temperatures could be calibrated out quite simply, by selecting a calibration mode, turning off, soaking the torch at a specified temperature (ice bath 0 C, 20C household ambient, 70 C in fan oven, even boiling water 100C). Turn on again, sensor value measured, offset calculated, stored. Before anything has warmed up, confusing things.
Preferably done in manufacturing, before customer gets them and has to mess about with it themselves.
Sounds similar to M43 description.
SOP in automotive stuff, where we used sensors using base-spreading resistance, such as the KTY13 series from Siemens. Now Infineon. One of these on the MCPCB could transform things. Maybe not even needing another MCU pin, muxed in with something else.
Cheap as chips, very precise and stable with a 3-point calibration and curve-fit. Single point cal. good enough here.
Narsil lets you blink out the raw MCU sensor value and apply the offset yourself when setting up your personal preference for thermal control. Good feature. Helped me set up my Q8 with some scientific method, instead of just suck-it-and see.
Precise thermal control is essential to manage these thermally limited torches to their best, I’m not sure we are any where near there yet with the current approaches.
Re: firmware version. No we don’t need obscure build version stuff. Something like 4 digits, w x y and z.
W = base version. Starting at 0 for pre-production/prototype code.
X = revision level, 0 for prototypes, start at 1 for production releases.
Y = hardware build standard applicable. Same idea.
Z = detailed hardware standard applicable, such as tuning for different LED choices.
When signalling 0, make it ten blinks, so it’s clear that you have got pre-release code.
Put a QR code in the paperwork or engraved somewhere on the torch, linking to a model-specific site with the details:
Source code. With clear commenting.
Hex files, with checksums.
Change lists. Bugs fixed, known bugs not fixed, new bugs found. Features added, features removed, UI changes.
Much as PC manufacturers do when releasing their BIOS updates. User can decide whether to apply them or not.
Alpha code releases for the bold, explaining what things are being tried out. Stability warning. Also coded 0.
Feedback method to report issues.
May not suit “fast and light” coders for whom this is tedious. Or are “output only”.
Personally I would like to see torches only released at a solid stable tested 1.1.1.1 with no compelling reason to consider updating.
Then there is the question of regression testing, and how thoroughly it is done …
Manufacturers might not like this, e.g. customers receive V 1.1, but learn 1.2 is current and fixed some important things, so want it instead. Distributors with lots of 1.1 stock to sell, wanting to send it back to be brought up to date.
Meanwhile manufacturers have moved on to the next thing, and aren’t interested in updating old products that still work well enough. Leave that to the enthusiasts to figure out themselves.
Not to mention useful in manufacture, to allow last minute firmware installation.
If really not there, as in some previous ones, I can only speculate that the driver on this one no longer shows the hand of e.g. Lexel or Texas_Avenger consultation.
Perhaps a decision to copy the proven base design and have it done elsewhere. Now that he has learned enough to have a go.
Today the hardware, maybe tomorrow the firmware ?
ISTM that Hank likes to plough his own furrow, and do things his own way.
His business is making unique torches, to sell to consumers as-is. Take it or leave it.
Our educated input perhaps listened to, and desire for mod-ability, add lustre, but are not necessarily a primary consideration, possibly a distraction.
Web searches when researching mostly lead here, and are generally very favourable, that’s surely worth cultivating.
Nevertheless we also contribute to his sales and his bottom-line, perhaps in a small way, as well as free beta-testing. A fine line to walk.