search

ToyKeeper / anduril

Anduril 2 Flashlight Firmware and FSM UI Toolkit
GNU General Public License v3.0
199 stars 48 forks source link

Added support for loneoceans Lume1 Lume X1 designs and some Anduril updates #37

Open loneoceans opened 7 months ago

loneoceans commented 7 months ago

Added support for the Lume X1 driver design, and added some additional functionality in Anduril2.

Changelist:

Lume-x1-40w and lume1-6af binaries tested working on Lume X1 / Lume1 development platforms. RGB LEDs working on different ports, as well as Beacontower mode. Temperature check (negative sign) tested working by placing driver inside freezer. Added functionality makes use of ifdefs since smaller MCUs like Attiny85 do not have sufficient flash. All 74 hex builds succeeded using make command with no errors.

SammysHP commented 7 months ago

Thanks for your contribution and updating the patches for your great drivers! You might want to check the code for the FW3X-lume1: https://github.com/ToyKeeper/anduril/tree/trunk/hw/lumintop/fw3x-lume1

loneoceans commented 7 months ago

Added support for the Lume1-6AF driver, as well as some bugfixes found for Lume X1 driver and Beacontower mode. TODO: create definition files for relevant flashlights which use the Lume drivers, such as some FireflyLite flashlights, as well as write more detailed documentation for these drivers.

loneoceans commented 6 months ago

Added additional config files for some FireflyLite flashlights (those that use the Lume1 and Lume X1 drivers), as well as took a stab at the E12C (needs testing). For E12C, had some trouble trying to fit firmware into Attiny85 due to flash constraints with 3 PWM tables, and had to undef sunset timer (uses almost 500 bytes) to compile. Updated MODELS and BRANDS list. Todo: add config for older 1634 Lume1 drivers.

loneoceans commented 6 months ago

Added config files for the older Attiny1634 Lume1 drivers.

Light-Veteran commented 5 months ago

Thank you for all your support and for your awesome drivers

SiteRelEnby commented 3 months ago

Tested 6af today, looks good, everything working as it should. Will work on the others as time allows.

Edit: It does seem to be getting hotter than it should. 67 degrees on tempcheck and 60 degrees externally using IR, from a turbo run on stock thermal settings. I'll have a look as well.

SiteRelEnby commented 3 months ago

@loneoceans if you don't mind answering a couple of questions:

Edit: see below, some of these don't matter now.

The problem righ now that when I tested it, it would never step down from turbo, and exceed the temp limit even with TURBO_TEMP_EXTRA considered - if TURBO_TEMP_EXTRA is going to be used then the thermal regulation under that point should probably be made more aggressive.

SiteRelEnby commented 3 months ago

...and I just realised that the fireflies-specific config overrides the default thermal limit to 60, that's why no matter what I changed I couldn't get it under there, heh... IMO that's too high for such a small light, especially with TURBO_TEMP_EXTRA.

Comment added: https://github.com/ToyKeeper/anduril/pull/37/files#r1547006604 - with a value of 50 here, 6af looks good.

SiteRelEnby commented 3 months ago

Going to work on testing X1 next, just need to collect some data with the stock firmware first, should be able to within the next couple of days unless something comes up.

loneoceans commented 3 months ago

Hi @SiteRelEnby, so glad to have you help review the code! I really appreciate it, along with the many other contributions you have made. Thank you.

Answering your questions, for the T1R, as far as I am aware, none the emitters that Jack paired with it should be driven via FET. The hardware actually supports PWM though, so you could set your own reduced-power Turbo mode. But in general I am not quite fan of unregulated FET drive. I believe the T9R had a SBT90 option, which can take the full 100% duty cycle FET. As a side note, I have an updated driver topology being finalized which will mitigate these issues.

For thermal settings, I absolutely agree with you, and my preferred default thermal threshold is 50C; this is why they are set as such in the loneoceans HW definitions. However, I am sure that you are aware of the desire from perhaps a small but vocal group of hobbyists about sustained brightness and turbo modes, which have led to the request from FFL to set the default higher. I tried to push for and succeeded with a default of 50C for the newer Lume X1 boost drivers, but let me try to reach out to Jack again about the defaults.

In addition, the therm_warning thresholds and response magnitudes definitely can use more fine-tuning! I'm not quite sure if I fully understand how these variables are actually handled, or their design intent, so I'd love to get your help on these values.

Thanks again for offering to help out with the X1, if you need any additional hardware or such, please let me know. I did message you on Reddit previously but I'm not sure if you've seen it, but I'll be happy to answer any questions over chat or another more convenient platform if you'd like.

SiteRelEnby commented 3 months ago

@loneoceans I tested a few different builds with different thermal config before I noticed the fireflies hwdef was overriding the thermal limit and they didn't make that much difference when the limit was raised (i.e. having the limit at 60 made way more of a difference than when I was finetuning the thermal regulation even to be significantly more aggressive), although I didn't test as many combinations as I would want to be 100% certain yet, and I'd say that most of them are reasonable for a high efficiency driver,

I'm well aware of people wanting a hotrod, I'm one of the more vocal hotrod lovers after all đŸ˜œ, but the highest ADC temperature I observed was 63 degrees externally via IR, and ADC temp of 68, which is reaching the point of being dangerous to the battery - perhaps not with a Molicel, but it's more than I'd want to push something more marginal.

The issue was that when the light heatsoaked, it took a long time for thermal regulation to drop it about 4-5 levels (if I had to estimate, I didn't think to set mode memory up before trying that run...).

I think that maybe with emitters that use FET it's fine (my E07X gets just as hot but actually drops off much faster in heat generation when it throttles down out of turbo, while the T1R stays heatsoaked just barely under its thermal max for way longer) as with FET there's a bigger drop off in the rate of heating from only a single level of stepdown taking away a good 25-50% of the actual output when only dropping a single level, but with regulated only like the T1R, the main issue I ran into was that it was stepping down slowly enough that at level 145 or so, the buck driver's output was still enough to cause the light to overheat. In addition, I found that even when deliberately heatsoaking the light, I noticed that sometimes the ADC would not quite read high enough to cause even a single stepdown for too long to be subjecting a battery to.

My suggestion would be to either make thermal regulation somewhat more aggressive in general on noFET (145ish is not an appropriate level to step down to after 5+ mins of heat soaking on a light where the power curve by ramp level is largely flat, as opposed to a big kick up at the end with a DD FET), and/or to reduce TURBO_TEMP_EXTRA to 5 on noFET. I can test a few combinations tomorrow and see what works, I have a lumen tube and IR camera to test with, and I'm happy to push output as high as it's safe to do so.

SiteRelEnby commented 3 months ago

For FET, it's probably fine as it is, there's a big output drop in just the one level.

For noFET, with an effective limit of 70 in turbo, it was reaching 63 externally, and was holding that temperature without stepping down at all (i.e. when 2Cing the light, it dropped back to the original level as opposed to going back up to turbo). Presumably as it has not stepped down yet that correlated to 69 internally.

For noFET, sustained upper ramp output is always going to be fairly good, and since there's no real perceptible difference between turbo and 149, I was thinking perhaps a thermal limit of either 50 +10 for turbo or 45+15. That way, the light holds turbo for as long as possible, but just has a larger stepdown to a safe sustainable thermal level - I tested with 50 + 10 and the maximum external temp was 55 - if you think 60 in general is acceptable as a maximum external temp it can reach, would 50+15 or even 55+10 be acceptable? That way it can reach 60, but won't remain at battery-damaging temps internally.

I have no problem with the light being generally set up to run hot, but it can't be to the level that it risks burning someone or causing damage to the battery (60 degrees is only safe for skin contact for 5 seconds - I very lightly burnt my finger trying to get it into tempcheck after one test run) - the higher limits might be absolutely be fine in a larger light but the driver is efficient enough that even with the 22430 tube the T1R gets dangerously hot. It's definitely an excellent driver, the main reason it's a problem is how well it does hold turbo without dropping due to battery voltage sag after all - I'm learning driver development at the moment and I completely get wanting to push the limits, and I will point out that even with thermal regulation turned up a bit it still outperforms a T1R with original firmware ;)

If you have alternative solutions I'd be happy to test them, but in general, I feel like the goal should be to keep the real temperature below 60 as soon as thermal regulation has started, but think that pushing it hast 60 briefly for the sake of the initial turbo is probably less of a problem.

Another suggestion, probably not enough to entirely mitigate the problem on its own but something else to consider if pushing the limits on thermals is to set simple UI's 2C style to anduril 2 combined with a ceiling of 130 or so, so the user needs to ramp all the way up to get 150, while you can leave the full ramp unlocked with instant turbo from anywhere in advanced.

re. Reddit, I've decided to make an effort to check Reddit Chat more often, I've missed various stuff before, it's just not that convenient to check as I use old.reddit.com but I'll put some time into finding a solution. I'm probably done for this evening unless I can't sleep, but I'll look at this more tomorrow.

loneoceans commented 3 months ago

Thanks again SiteRelEnby for helping take a deeper look into this, especially with all the testing with different settings and for your very helpful suggestions!

For the noFET config, the idea was to keep the same ramp table, just without the FET channel. The RAMP_SIZE is redefined as 149, and the ramp tables are as well, removing the last value. In addition, the TURBO_TEMP_EXTRA was only intended to be used for flashlights with FET enabled. It should be #undef-ed in the noFET headers, thus the default temperature handling in fsm/adc.c should take over. It sounds like to me that maybe the flashlight is still getting into the TURBO_TEMP_EXTRA mode (did I use the undef directive incorrectly?) That could explain why it was hitting such high temperatures. Alternatively, redefining TURBO_TEMP_EXTRA as 0 should effectively default to the regular temperature stepdown handling as well.

As for your suggestions, I think it may also make sense to set the default ceilings on the noFET version to be lower than the full 6A which it is currently set to. One thing I had trouble with was configuring the temperature response parameters because the driver is used in a few different flashlights (the original intent was for it to be in the E12R only, but Jack decided to use it many other flashlights with vastly different sizes and thermal capabilities). Another way we could go about doing this is to define THERM_RESPONSE_MAGNITUDE to a larger value such as 64 for the noFET version, which should increase the stepdown aggressiveness. I'm going to try to do some additional testing as well on my side, and once we finalize on a good set of values, let's adjust the defaults.

SiteRelEnby commented 3 months ago

I actually missed that it did get undef'd in noFET (or otherwise I was reading some test-hotpatched code I forgot to revert, I guess). I'll test with some increased thermal regulation, I guess the way it was sitting at at 68-69 specifically made me wonder if the +10 was the cause. In terms of improving sustained performance, reducing the lookahead a bit is probably similar in effect but with less overheating possible.

SiteRelEnby commented 3 months ago

PR submitted: https://github.com/loneoceans/anduril/pull/1

With these changes, PR looks good and ready to merge when that one is.

loneoceans commented 3 months ago

PR submitted: loneoceans#1

With these changes, PR looks good and ready to merge when that one is.

Thanks @SiteRelEnby for the feedback and suggestions. Did more testing since I finally got more flashlights on hand, validated with FLIR thermal camera. Requested FireflyLite to reduce thermal defaults. Found a bug in level indexing. Also adjusted default ceiling for the boost driver to be slightly lower, for better sustained performance and more obvious turbo mode.