The only light I have with Lume1 driver is a T1R from Fireflies… When I last asked, it sounded like Fireflies has some pretty “special case” stuff going on with that light and it’s a project of it’s own.
I’m all good with figuring my way through the flashing process, up to a point with the adapters I have, but I’m like an amoeba next to a lot of the folks around here…
The Lume1 FW3X is not the same Lume1 in T1R.
First difference is amperage, 3A in small Lume1 and 6A in new driver (like in your T1R, is black and is RevC, the old is orange and for now is not supported by @loneoceans)
If you buy T1R recently sure it have the last firmware. Don’t worry, some of us can help you where do you need
Yes, there is X1L in next weeks. It has Lume X1 and is a new version with 6V out. All the last driver probably mount Attiny 1616 so they are easy to upgrade.
Not supported yet, I’m going to try and find some time to work on it this weekend.
Yeah, I kinda suspected the "FW3X"indicated it’s different enough to warrant asking…
No rush - I’ve seen how busy you are around here!
Please know all the work is appreciated. Between your updates and TK’s with all the changes of late I’m almost able to enter my preferred A2 settings from memory.
Oh nice!
I don’t update anything… I mod
The cool people are
@ToyKeeper
@thefreeman
@wolfgirl42
@dmenezes
@SammysHP and others I don’t remember now
No worries, I’ve been seeing the work those folks put in!
Thanks @wolfgirl42 for your efforts in trying to fix the fw3x-lume1 build, but unfortunately it doesn’t appear to be fully fixed yet.
TL;DR: temperature regulation works now, but is too aggressive and reduces output so much that the light stays way below the set temperature limit.
Verbose version:
After flashing this hex file I did the usual procedure of a factory reset, going into advanced UI and enabling turbo in the ramp config.
The FET turbo still only lasts single digit seconds (6 seconds in the first test with my FW3B). For a quick comparison I went back to the old build from loneoceans github (hex file says 2020-12-14, but light blinks the date code 2020-12-04) and got a FET turbo time of 33 seconds with the same light and the same battery (18350 @ 4.1V).
After the few seconds of turbo the light ramps down quickly, so much so that it barley gets warm. The reported temperature after a handful of minutes is below 35°C, I got 33°C with my FW3B and just 29°C with a second light (aluminium FW3A).
As you would expect from a MCU with internal calibration, the lights did report the correct ambient temperature (+/- 1°C compared to other Andúril lights and an IR thermometer), both before any tests and after the test (and of course a rest of at least an hour). To double check I manually set the base/current temperature and set the temperature limit to 45°C, but the result was the same. Even with the temperature limit set to 60°C the FW3A was only marginally warmer after a 5 minute test starting from turbo with a reported temperature of just 32°C.
The FW3X uses an external temperature sensor… which is why its thermal response is weird. The sensor is fine, but it needs special code that I haven’t been able to test or maintain properly.
It seems to work fine with both my lights (FW3A and FW1A Pro, both driver swapped to lume1 by adair21) after I added MIN_THERM_STEPDOWN.
Hmm, interesting. I’ll take another look - on my own lights I tend to set a more aggressive thermal limit than stock, but as far as I can tell, mine at least feel accurate to my hand.
(#include <reminder_to_check_temp_calibration> 
)
You are right, I missed that detail.
Thanks!
That definitely doesn’t even get close to the limit, my guess is THERM_RESPONSE_MAGNITUDE needs to be lowered - the default is 64 but some other lights including thefreeman’s boost drivers have it set to a lower value instead.
It’s such a pain to flash (reversed MO and MI) that I’ll flash and test it later as I’m a bit preoccupied right now, but here’s a build if you want to go ahead: 31.4 KB file on MEGA
Added to cfg.h:
#define USE_CONFIG_COLORS
#define DEFAULT_BLINK_CHANNEL CM_MAIN
#define MIN_THERM_STEPDOWN 65
#define THERM_RESPONSE_MAGNITUDE 16
#define THERM_FASTER_LEVEL 145
Did a quick test and it seems to reduce the brightness a bit slower (but I can’t tell for sure), apart from that it is still the same. Turbo lasted 8 seconds and the reported temperature after a 5 min run was only 32°C.
I didn’t change anything (apart from the usual factory reset, going to advanced UI and enabling turbo).
hmm… I guess I’m interested in TK’s thoughts here - the temperature reading does at least seem to be accurate (if I force the issue by keeping it in turbo, I can get the temp to read 60 on mine), but stepping down is just too aggressive at relatively low (30ish) temps.
Workaround is just to bump up your limit, I guess.
I’m guessing there’s probably something in fsm/adc.c causing it to emit spurious overheat warnings which only affect this particular hardware model. But that’s only a guess. It seems like it’s probably ramping down to the lowest level allowed by thermal regulation, no matter what the temperature is.
Basically, there’s some custom code in there that I probably broke at some point but didn’t notice because it doesn’t affect any lights I actually have.
Yes, it seems that way. I just finished a longer test of 30 min with the temperature limit set to the maximum of 70°C and the light regulated down to a pretty low level (in between the 3rd and 4th step of the stepped ramping). Reported temperature after 30 min was just 31°C.
At the moment I’m desperately trying to adapt the firmware from Fireflies lume1 rev.B (orange one) to the modern version of Anduril 2. I use the following methodology: I got three sets of cfg and hwdef files: original lume1, kr4 from 675 (very similar to lume1), kr4 modern. Then I figure out how everything was renamed and rearranged and make changes accordingly to «new» lume1 files.
I saw my steps as:
But I’m really stuck. So far I have managed to create hwdef.h, hwdef.c, anduril.h, etc files and build hex with which the torch at least turns on and responds to the button and clicks. However, at relatively high levels middle of the ramp and higher I observe strange jumps in the output level, like suddenly LESS - again MORE - again LESS and so on until we reach the ceiling of the ramp with the expected output level. Lower levels are OK. Turbo with FET working as expected.
#define PWM1_LEVELS 1,2,3,3,3,3,3,4,4,4,5,5,6,6,7,7,8,8,9,9,10,10,11,12,13,14,15,16,17,18,20,21,23,24,26,27,29,31,33,35,37,39,41,43,45,48,50,53,56,58,61,64,67,70,74,77,80,84,88,91,95,99,103,108,112,116,121,125,130,135,140,145,150,156,161,167,173,178,184,191,197,203,210,217,223,230,238,245,252,260,268,275,283,292,300,308,317,326,335,344,353,363,372,382,392,402,413,423,434,445,456,467,478,490,502,514,526,538,551,563,576,589,603,616,630,644,658,672,687,702,717,732,747,763,778,794,811,827,844,861,878,895,913,931,949,967,985,1004,1023,0
#define PWM2_LEVELS 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1023
Maybe root of the problem in new logic in set_level_main and gradual_tick_main and «dynamic PWM» itself, but I’m stuck and if somebody willing to point me direction I would really appreciate that
If somebody willing to look at the code it’s here.
If I were in your shoes, I would concentrate in PWM1_LEVELS and PWM2_LEVELS in anduril.h; would try and help further if RL wasn’t so effed-up right now.
This is already on my todo, might try to this evening or tomorrow.