| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces "USE_CONFIGURABLE_RGB_VOLTAGE_LEVELS"
with "USE_AUX_THRESHOLD_CONFIG", which controls the brightness of
button LEDs while the main LEDs are on,
and during post-off voltage display.
Same basic concept, but works on single-color LEDs too,
and lets the user finally configure POVD thresholds.
The code for this is a bit messy, but the aux LED code as a whole
is pretty messy since it wasn't designed for the things it does now.
The entire thing needs a refactor or rewrite someday. But not today.
For now, this is just enough to make the pull request
cover more use cases before merging into trunk.
I've tested it on a variety of lights, but am not yet entirely
comfortable with it. However, it worked on at least these:
- 1-color button LED, no RGB
- front RGB, 1-color button LED
- front RGB, hardwired also to RGB button
- RGB button, no other aux
These may need extra changes,
and may have extra config options which do nothing...
- front RGB, no button LED
- 1-color front aux, no button LED
- no aux at all
- attiny85 lights (some could theoretically support the new options,
but none even try)
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
into pr10-SiteRelEnby-rgb-voltage-configurable
pulling pr10 branch into a feature branch based on a newer trunk
* 'rgb-voltage-configurable' of github.com:SiteRelEnby/anduril:
Add a feature to make RGB voltage configurable
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adds two entries to the battery voltage settings menu, the first
isathreshold for switching aux to high, and the second sets a minimum
level for it to be displayed, also effectively allowing the feature to
be entirely disabled if not wanted.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
After testing on every device I can, and getting several users to also
test this, it appears to reduce and sometimes completely eliminate
preflash on most devices... and the cases where it wasn't reported to
help, at least it didn't make things worse. Some units apparently just
can't get the flash eliminated completely, despite trying lots of things.
Instead of turning the chips on and then waiting 4ms, it now turns the
preflash absorber on, waits ~0.6ms, sets misc params, then turns the
boost chip on, then waits ~0.6ms, then turns the preflash absorber off.
This seems to work best on li-ion power, where on my devices it completely
eliminates any preflash. There is still a very mild flash on AA though,
which I wasn't able to get rid of. But it's like... 0.003 lm for just
a few milliseconds, really not bad. Even in the worst case reported by
a user, based on the video they took, it looks like just 0.01 lm for
a few milliseconds.
|
| | | |
| | |
| | |
| | |
| | | |
for some reason, and didn't commit... saving now to change branches,
but should delete this commit if it turns out there was no reason for it
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- calibrated party strobe
- removed duplicate or commented-out code
- added a basic readme
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- changed model number from 0281 to 0171
- cleaned up blink_negative and AUXLED_RGB_DIFFERENT_PORTS a little
(but the latter needs a complete refactor, as soon as the
hardware abstraction code can handle aux LEDs better)
- cleaned up USE_LONG_BLINK_FOR_NEGATIVE_SIGN a little
- removed USE_OTG_IN_MOMENTARY since it's not actually used
- moved hw/loneoceans/lume-x1-avr32dd20/* files into hw/hank/lume-x1/
- superficial cleanup on hank/lume-x1/hwdef.*
- removed some of the extra stuff from hank/lume-x1/anduril.h
- adjusted calibration (especially ramp table) on hank-lume-x1
(ramp shape is pretty close to a D4K-boost now, but with more firefly modes)
(calibration is based on a sample size of 1, further testing needed)
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
https://github.com/loneoceans/anduril/commit/d83ebb75dab8c462b7efa841bccc00a136ff15a2
The [PR](https://github.com/ToyKeeper/anduril/pull/37) has a lot of other
stuff in it, so I'm just picking out the parts needed for this particular
light, and leaving the rest for later.
Will need further edits before merging into trunk.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
(also, fixed bug where a totally empty li-ion didn't get limited)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
and not letting the magic smoke out of updi adapters any more (probably)
The alkaline detection might be a little too lenient though; it
could potentially fail to activate limits when the cell is completely
full or stronger than an average alkaline. One of my test cells
measured at 72 / 75, so if it was just a little stronger it'd pass...
but most alkalines I tried were in the 40 to 60 range and failed easily.
OTOH, if I make it easier to fail, it's likely to trip on normal li-ion
cells, and I don't want that.
So as a future enhancement idea, maybe it should have a smaller sag
threshold for AA and a larger threshold for li-ion. That would reduce
false negatives for AA, while still preventing false positives for li-ion.
|
| | |
| |
| |
| | |
(saving progress here so I can work on a different branch)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
- new ramp
- production style config defaults (simple mode, Hank config)
- candle tuning
- fixed way-too-fast thermal regulation
(might still be a bit fast, but it's a lot better)
|
| | | |
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* trunk:
enabled eeprom read/write stabilization by default on recent MCUs, to prevent corrupt data
thefreeman-avr32dd20-devkit: enable boost bypass at boot, so AA/NiMH can boot
avr32dd20-devkit: use unimplemented "CH" pin as a boost bypass control
added "emisar-2ch-fet-joined" build, for D4S w/ lighted switch
documented FW3X swapped pins better
documented Wurkkos TS25/TS11/FC13 distinctions
build.sh: don't require DFPs, newer avr-libc doesn't need them
use BLIP_LEVEL instead of 0 for "blip"s
clarified which-hex-file.md a bit; make sure the model number matches
fw3x: reduced pulsing on low modes
|
| | |
| |
| |
| | |
(it's an odd case with a 2 channel driver which only uses 1 set of LEDs)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The 0144 model number is reserved for the successor to the Meteor M44.
This is Hank's first AA light, so it's assigned as 0161:
- 01: Emisar
- 6: product line 6
- 1: model 1
|
| |/ |
|
| | |
|
| |
|
|
| |
Phew, that's a lot of changes! And there's still a lot more to do...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
by raising MCU clock speed to half at levels 2+
instead of the previous value of 1/4th speed
I tried full speed too, which makes ripple much smaller and faster...
but it also causes a big jump in brightness between levels 1 and 2.
My lux meter shows ~350 at 1/150 or ~500 at 2/150,
but at half speed it's ~650 at 2/150,
and at full speed it's ~1100 at 2/150.
So I went for a happy medium to balance ripple, brightness, and runtime.
|
| |
|
|
|
| |
@hank-noctigon-kr4-boost, @hank-noctigon-k1-boost, @hank-noctigon-dm11-boost
(0216, 0253, 0273)
|
| |
|
|
| |
and updated other scripts and files accordingly
|
| | |
|
| | |
|
| |
|
|
|
| |
(still need to update file contents afterward,
but doing it in a separate commit so git can detect renames easier)
|
| |
|
|
| |
(also modified the build scripts to work with the new file structure)
|
|
|
(just moved files, didn't change the contents yet,
and nothing will work without updating #includes and build scripts and stuff)
|
