Thank you for the detailed explanation.
With HOLD_TIMEOUT set to 12, I was having an issue where a hold while on would do nothing. I’ve changed the value to 15.
And please make the battery insertion double blink at moonight.
Yeah…it bothers me too. As well as voltage / temperature indication.
Hang on there a minute. On a bright sunny day blinking out temperature or voltage might be rather hard to see if done at moonlight levels. At the risk of adding ANOTHER configuration, it might be nice to be able to select the intensity of these blinks.
With moonlight configured to be really low, maybe, I don’t know. On my D1 / D4 with stock firmware moonlight is easy to see during a day. Actually with D1 it’s well above the threshold of being painful to look at, even during a day.
Though it may not be moonlight. My complaint about the current level is that the amount of light is disturbing.
If I shine it at my hand to avoid disturbing others, the reflection blinds me.
It doesn’t take moonlight to avoid the issue.
The nitecore MH20’s e-switch is blinking the battery voltage when tightening the tailcap, so why not doing the same with the D4’s front emitters and use the 3 clicks for something else ? A shortcut to 7135 100% for example.
Is there a hex file available of Anduril for a TA FET+1+16 (or 8AMCs) driver? I want to order 2 drivers from lexel and would like em to be flashed with anduril, Lexel can flash them for me with any kind of firmware but he needs/wants the hex file as he “can’t calibrate Anduril like he’s used to in Narsil”.
I myself have no clue what a HEX file is used for or if there is any difference between the hex file for a FET+1+8 and a FET+1+16 driver :person_facepalming:
I would like an Andúril.hex for TA L6 driver too.
I got this when trying to build Andúril .hex file
Can someone point me out what is this error means and how to solve it? I would like an Andúril.hex for 2Channel FET+1 driver.
Thanks goshdogit, yes I’ve downloaded all the files there and add to the AS project, I think the error is the fsm-adc.c file or its comments, never have this issue when compiling Narsil.
That looks like a build toolchain issue, like it’s missing the AVR library headers or isn’t configured to find them perhaps.
It’s already massively sped up compared to RampingIOS, and IIRC dimmer too… and only blinks once. It’s basically using the same boot blink I used in Ferrero Rocher, just a quick blip to confirm power is connected… without causing any meaningful delay. But if you’re in a dark place and trying not to be noticed, it’s still a good idea to cover the light before connecting power.
No, I don’t think it’s quite ready for stable release yet. This is all still alpha or beta code. It’s not even merged into trunk yet.
In general, the ramp (including moon level and ramp shape) needs to be calibrated for each combination of driver type and emitter configuration. A FET+7+1 and FET+16+1 have different ramp shapes, a single XP-G2 and a quad XP-L have different ramp shapes, a raptor-claw and failboat 7135 chip have different moon levels, a 1-channel/2-channel/3-channel driver all have different configurations, an old XM-L and new XM-L2 have different moon levels, a 1-cell (or parallel cell) host and 2/3/4-cell serial host have massively different ramp values (and need different methods of measuring voltage), hosts with/without indicator LED need different configs, hosts with/without a tail clicky need different configs, etc. The full set of configurations grows exponentially with each option.
There is the approach of trying to build a .hex file for every possible config, and hosting dozens or hundreds or thousands of them in the repository, but this means an awful lot of completely untested builds and it’s expensive in terms of repository size. It’s mostly just useful as a brute-force way to test builds to make sure each configuration can at least compile. I don’t think I’ll be hosting all those .hex files though.
My preferred solution is to provide sources only, plus a very small number of stable and well-tested .hex files targeted to very specific and popular hardware — like one for the D4, one for the Q8, and one for the FW3A. For hardware produced in smaller quantities, it’s someone else’s job to build and test.
Thanks for explaining.
So if I were to put 4 Nichia 219B LEDs in my Q8, I would have to reconfigure the software on the driver to get a nice ramping?
Yeah, I’m not Mr. Covert, but in a dark house in the middle of the night it would help to have the blip either off or on moonlight. Just one of those functions I don’t require.
dekozn, a 219B quad would probably work with default settings. Those tend to max out at ~2000 to ~2500 lumens, which is reasonably close to the default ramp’s shape.
That is, assuming the driver works the same as the default, which is calibrated for an Emisar D4.
A single 219B likely wouldn’t work well with default settings, since it’ll probably max out at 500-600 lm. The top half of the ramp would go up really slowly. But I wouldn’t recommend a FET for a single 219B anyway; it’s overpowered for the emitter configuration.
anyone tried andruil in a s42s? I’d love to give it a try but changing the driver while keeping the usb-charging seems to be a pain according to lexel…
What are the parameters for “n” values in the config menu?
Are you referring to the Andúril cheat sheet?
’N’ is just a symbol for ’number of times you click the button.’
For example:
- If you’re setting the interval for beacon mode, clicking 8 times will make the beacon blink every 8 seconds.
- If you’re setting the ramp ceiling, clicking 20 times will set the ceiling to 130 (150 - 20).
- If you’re setting the temperature limit, clicking 5 times will set the limit to 35 C (30 + 5).
Does this answer your question?