| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
(old wording was confusing people)
|
| |
|
|
|
|
|
|
| |
(2021-09-10 r619.1.11)
The gradual_target var was getting clobbered and causing thermal regulation to stop
until the next thermal warning event, every time it reached a new ramp step.
So... save/restore it to prevent it from getting clobbered.
|
| | |
|
| |
|
|
|
| |
(use the same value as LVP; easier to configure if it's in only one place)
|
| |
|
|
|
| |
(because it's kind of important to know which MCU each light uses,
and because this will be helpful later when the build system is rewritten)
|
| | |
|
| |\
| |
| |
| |
| |
| | |
(which also changed the way tint ramping is implemented,
to make things generally cleaner and more flexible)
|
| | |
| |
| |
| |
| |
| |
| | |
(apparently Hank liked the D4Sv2-tintramp demo/experiment so much that
he decided to use it in production for the K9.3... so it need its own
builds since it's a pretty different light even if the driver is almost identical)
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
by turning off one more of the recent extra features
(can turn it back on later if the build size goes down)
|
| | | |
|
| | |
| |
| |
| |
| | |
(can't test because I have no hardware, but it at least compiles)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
initial turbo drop,
on 3-channel drivers like FW3A and ROT66
(as shown here: http://toykeeper.net/torches/fw3a/therm-2019-05-22.1.png )
What happened was... the FET would start to drop, but gradual adjustments noticed that
the Nx7135 channel needed to go from 0 to 255, so it would then slowly ramp that up,
and then afterward, the FET drop could finally continue... because the code didn't
jump straight from 0 to 255 like it was supposed to.
Simple, easy fix: Make channel 2 go up immediately just like channel 1 does. This makes
the thermal response several seconds faster than it was before, so it doesn't get as hot,
and is less likely to overshoot and bounce later.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
turbo modes
(it's weird, but Hank wants it)
also reworked gradual tint adjustment a bit, so some complex parts go in set_level() instead
(probably needs more testing)
|
| | |
| |
| |
| |
| |
| | |
(suggested by solrize)
(doesn't seem to reduce size of t85 builds though)
|
| | |
| |
| |
| |
| |
| | |
to make its thermal regulation smoother and generally increase tint ramp resolution in middle modes
(also, tried thermal regulation, and it works)
|
| | | |
|
| | |
| |
| |
| | |
thermal regulation)
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
and (maybe) thermal regulation (untested)
(also broke BLF LT1 in the process; need to fix that now)
Rewrote how tint ramping works, so it provides a virtual "PWM1_LVL" for other code to use,
and it translates that internally into actual hardware controls. This should, in theory,
allow smooth thermal regulation (gradual_tick) to work on tint-ramp lights.
|
| | | |
|
| | |
| |
| |
| |
| | |
(initial rev, will almost certainly need changes later)
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
+ runtime option for smooth ramp speed
+ runtime option for whether hold-from-off should ramp up or stay at the floor
+ runtime option to select turbo style / 2C style in Advanced UI
+ same thing, but for Simple UI
* sped up the auto-reverse timing window; it was too slow
|
| | | |
|
| | |
| |
| |
| | |
because it was too fast
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
also made it possible to block turbo in Advanced UI
(each one has a 2C style:
0 = no turbo, only ceiling
1 = Anduril 1 style, direct to turbo
2 = Anduril 2 style, ceiling unless already there, then turbo
)
|
| | |
| |
| |
| |
| | |
(also, adding this reduced the ROM size somehow)
|
| | |
| |
| |
| |
| |
| | |
(2C while on goes to full-power turbo (A1) or ceiling (A2))
also renamed _OPTION defs to _CONFIG for consistency
|
| | |
| |
| |
| | |
(default) or stay at floor
|
| |/ |
|
| |
|
|
|
| |
(requires the user to set it up, so it won't happen to new users unless they do it on purpose)
|
| | |
|
| |
|
|
|
|
|
| |
special clauses
(also adjusted KR4 jump start levels a bit)
|
| |
|
|
| |
places
|
| |
|
|
|
|
| |
(to make initial response consistent)
(otherwise, it can randomly take up to ~16ms to turn on)
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Added a new #define DEFAULT_AUTOLOCK_TIME to simplify compiling
firmware with the autolock timer enabled by default. If this is not
specified, the autolock timer remains disabled by default.
This removes the need to modify lockout-mode.h directly.
|
| |\ \
| | |
| | |
| | | |
allowing configs to disable the thermal autocalibration feature
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Moved factory reset thermal auto-calibration behind a new default-on
config #define USE_THERM_AUTOCALIBRATE. Commenting this out or the
usual #ifdef/#undef in a cfg-[...].h build file allows for manually
calibrating the temperature offset.
This may be useful for factory-calibrated temperature sensors or for
those who regularly flash custom builds and don't want to recalibrate
each time.
Determining the correct temperature offset for a given flashlight
first requires flashing a build with auto-calibrate disabled, using
that to determine the offset, which can then be baked in to future
firmware builds.
|
| | |
| |
| |
| |
| | |
(also fixed reported values being too low by a factor of channel.pwm_min)
|
| | |
| |
| |
| |
| |
| |
| | |
flickering
(I didn't see any flickering on my lights, but SammysHP reported it was visible)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
and reduced the jump-start-moon power a bit too
(he says both are good now, but I don't have hardware to measure it myself)
The higher floor is because, when the driver is really hot from being on turbo,
going directly to moon causes the LEDs to turn off for a while until the driver cools.
The new floor is the lowest level where post-turbo activation works reliably.
However, it should turn on even at the level 1/150 when it's not hot.
|
| | |
| |
| |
| | |
things are right
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
the defaults work better
(the overrides were mostly needed as a side effect of having 1024 PWM steps instead of 256)
|