Look for EV_click1_hold in off_state, and remove the part about “if (arg >= HOLD_TIMEOUT)”. This should make ramping start about 24 frames sooner. However, it will also eliminate the ability to long-press from off to go to moon.
I’ll try this. Thanks!
I use low modes frequently, but I might be willing to lose a shortcut to moon to get a slightly shorter delay in ramping up from off.
You could also just give it a smaller value, like 6 to allow a 6-frame window to stop at moon before ramping.
And to make the timing easier, you could make it not turn the light on until that window starts. Slower feedback from off, but it gives a timing hint for the shortcut. Tradeoffs…
It runs at 62 frames per second, or 0.016 ms per frame. So a value of 12 is just barely under 1/5th of a second.
People have had difficulty with a window of 18 frames on the Q8, and I’ve found that 31 frames feels too long, so I used a default of 24.
Zebralights, IIRC, use a window of 0.5s or 31 frames:
Frames 1-31: Light is at low, release to go to high.
Frames 32-62: Light is at low, release to stay at low.
Frames 63-93: Light is at med, release to stay at med.
Anyway, I just wrapped the definitions of HOLD_TIMEOUT and RELEASE_TIMEOUT to make them definable from the UI code instead of having to dive into headers. So, after this update is pushed, just stick an extra line in the main UI file and it’ll override the toolkit’s defaults.
The HOLD one is how many frames it takes to go from a “press” to a “hold”, or how long a single click can be. The RELEASE one is how many frames it waits after a click to see if another click will happen. To cause a full click event to be sent to the UI code, what happens is…
User presses button. “EV_click1_press” event gets sent to the UI code.
Anywhere from 1 to HOLD_TIMEOUT frames happens. Let’s say 12 frames.
User releases button. “EV_click1_release” event gets sent to the UI code.
Light waits RELEASE_TIMEOUT frames, and nothing happens. Now we’re at frame 36.
“EV_1click” event gets sent to the UI code, indicating that it was only a single click and it’s too late for a double click to happen.
The events aren’t quite immediate though… they go into a queue and get sent/processed later when the MCU is in an idle loop. In normal circumstances, this only delays things by a few microseconds… enough for the current interrupt (WDT, PCINT, ADC) to finish. I’ve generally been very careful to avoid anything time-consuming during interrupts, because those need to be serviced quickly and then go back to the regular code flow as soon as possible. The queue offloads the time-consuming parts to a safer part of the code.
I’m kind of just rambling now though, twiddling my thumbs while waiting for DHL to show up with new lights.
I just wrapped the definitions of HOLD_TIMEOUT and RELEASE_TIMEOUT to make them definable from the UI code instead of having to dive into headers. So, after this update is pushed, just stick an extra line in the main UI file and it’ll override the toolkit’s defaults.
ToyKeeper wrote:
The HOLD one is how many frames it takes to go from a “press” to a “hold”, or how long a single click can be. The RELEASE one is how many frames it waits after a click to see if another click will happen. To cause a full click event to be sent to the UI code, what happens is…
User presses button. “EV_click1_press” event gets sent to the UI code.
Anywhere from 1 to HOLD_TIMEOUT frames happens. Let’s say 12 frames.
User releases button. “EV_click1_release” event gets sent to the UI code.
Light waits RELEASE_TIMEOUT frames, and nothing happens. Now we’re at frame 36.
“EV_1click” event gets sent to the UI code, indicating that it was only a single click and it’s too late for a double click to happen.
Thank you for the detailed explanation.
goshdogit wrote:
12 it is!
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
—
Idiot proofing something only creates improved idiots.
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.
And please make the battery insertion double blink at moonight.
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.
dekozn wrote:
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
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.
And please make the battery insertion double blink at moonight.
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.
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…
I got a Q8 in the mail today… and Anduril now has indicator LED support. It’ll probably change a bit in the near future, because I did kind of a quick hack, but it is at least working.
It also adds two more config settings — indicator state for regular operation, and indicator state for lockout mode. Each one can be “high”, “low”, or “off”. At some point I’ll probably also add a fourth state for “blinking”.
To configure these, go into lockout mode. Then click 3 times to step through lockout indicator modes (one step per triple-click), or do “click, click, hold” to select a main indicator mode (release when it’s at the desired level).
By default, it uses high for regular operation and low for lockout. But this could also be low/high, off/off, high/high, or whatever.
The indicator LED does not blink during use, like during battcheck, but it would probably be relatively easy to add if that’s desired.
This is great news btw! Sorry, haven't been following the progress but it sounds all good. Are you using PWM's to control the brightness? If so, is it the same typical rate, ~15K?
Have you considered or looked at external temp sensor support? Are you having the same issue of I/O pin shortages or have you looked at I/O pin sharing as Mike C has done? I really think for us to take the next step, we need to look at the 16 KB Atmel with greater I/O pin counts - this would solve a bunch of road blocks I'm having. We just need to team up with a board designer and come up with an easy way to dnld the firmware to one of these MCU's. Couple options there - not difficult to do, takes some extra real estate, but we also save real estate because of the smaller foot print of these MCU's, if we go with the square 5x5x5x5 configuration.
I have used DS18B20 temperature sensors with Arduino projects in the past and had great luck with them. They use the Dallas OneWire protocol to communicate and as such, only require a single I/O pin for the comms bus. Each sensor has a unique serial number so it is possible to control multiple OneWire devices via the same pin. This also means that the code in a production environment needs to be autonomous in discovering and identifying all the devices on the bus. I am not smart enough to know how heavy the library is on memory so I don’t know if it would even be possible in the smaller processors. I have been looking around at various other OneWire devices in an attempt to justify using this method but so far have not found anything terribly promising. The most interesting so far has been the DS2762 Lithiuum battery monitor. It is pretty big real estate wise and the spec sheet appears to show that the current monitor max is 2.5 Amps, but there may be a way around that. It also includes temperature monitoring so would be one device for both temp and battery.
Quote:
The DS2762 high-precision Li+ battery monitor is a
data-acquisition, information-storage, and safety protection
device tailored for cost-sensitive battery
pack applications. This low-power device integrates
precise temperature, voltage, and current
measurement, nonvolatile (NV) data storage, and Li+
protection into the small footprint of either a TSSOP
package or flip-chip package. The DS2762 is a key
component in applications including remaining
capacity estimation, safety monitoring, and battery specific
data storage.
There are also OneWire Real Time Clock chips that would allow much more precise Alarm clock modes.
This is great news btw! Sorry, haven’t been following the progress but it sounds all good. Are you using PWM’s to control the brightness? If so, is it the same typical rate, ~15K?
If I recall correctly, the way Narsil does it is somewhat different:
At least, if I’m reading the code correctly.
In Anduril the sequence is:
Eliminating the pause at step 2 is easy. Eliminating or reducing the pause at step 1 is not so easy.
I use low modes frequently, but I might be willing to lose a shortcut to moon to get a slightly shorter delay in ramping up from off.
You could also just give it a smaller value, like 6 to allow a 6-frame window to stop at moon before ramping.
And to make the timing easier, you could make it not turn the light on until that window starts. Slower feedback from off, but it gives a timing hint for the shortcut. Tradeoffs…
12 it is! Ramping feels much snappier from off.
Thanks again for the help, TK!
It runs at 62 frames per second, or 0.016 ms per frame. So a value of 12 is just barely under 1/5th of a second.
People have had difficulty with a window of 18 frames on the Q8, and I’ve found that 31 frames feels too long, so I used a default of 24.
Zebralights, IIRC, use a window of 0.5s or 31 frames:
Anyway, I just wrapped the definitions of HOLD_TIMEOUT and RELEASE_TIMEOUT to make them definable from the UI code instead of having to dive into headers. So, after this update is pushed, just stick an extra line in the main UI file and it’ll override the toolkit’s defaults.
The HOLD one is how many frames it takes to go from a “press” to a “hold”, or how long a single click can be. The RELEASE one is how many frames it waits after a click to see if another click will happen. To cause a full click event to be sent to the UI code, what happens is…
The events aren’t quite immediate though… they go into a queue and get sent/processed later when the MCU is in an idle loop. In normal circumstances, this only delays things by a few microseconds… enough for the current interrupt (WDT, PCINT, ADC) to finish. I’ve generally been very careful to avoid anything time-consuming during interrupts, because those need to be serviced quickly and then go back to the regular code flow as soon as possible. The queue offloads the time-consuming parts to a safer part of the code.
I’m kind of just rambling now though, twiddling my thumbs while waiting for DHL to show up with new lights.
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.
Lazy-R-us
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
Idiot proofing something only creates improved idiots.
I would like an Andúril.hex for TA L6 driver too.
Reviews: Olight Seeker2 pro, Lumintop GlowI, Sofirn SP36, Convoy 4X18A, Convoy M21C, Brinyte SR8 Rescue Angel, Astrolux MF01 mini, Astrolux FT03S, YLP Sherp S15, Sofirn SP40, YLP Panda 3R and Unicorn, Armytek Prime C1 Pro, Acebeam M50, Imalent MS18, Convoy M3, Nitecore TIP2, Imalent RT70, Wuben T70, Sofirn SP32A, Thorfire VG15S, Thorfire VG10S, Thorfire TG06S
Mods: Imalent MS18 dedoming, Astrolux MF01-20K, Small sun T08 MT-G2, Eagle eye X6 triple XPL, Ultrafire F13 MT-G2, Convoy C8 XHP70, Solarstorm T3 triple XP-L HI
Big flashlight measurement and beamshot collection
3D printing stuff for flashlights
My flashlight related Instagram
My Flashlight related Youtube channel called Zozzlights
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.
____________________________________________________________________________________
Sorry for my poor English
See my post here.
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.
____________________________________________________________________________________
Sorry for my poor English
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?
Idiot proofing something only creates improved idiots.
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?
‘N’ is just a symbol for ‘number of times you click the button.’
For example:
Does this answer your question?
I got a Q8 in the mail today… and Anduril now has indicator LED support. It’ll probably change a bit in the near future, because I did kind of a quick hack, but it is at least working.
It also adds two more config settings — indicator state for regular operation, and indicator state for lockout mode. Each one can be “high”, “low”, or “off”. At some point I’ll probably also add a fourth state for “blinking”.
To configure these, go into lockout mode. Then click 3 times to step through lockout indicator modes (one step per triple-click), or do “click, click, hold” to select a main indicator mode (release when it’s at the desired level).
By default, it uses high for regular operation and low for lockout. But this could also be low/high, off/off, high/high, or whatever.
The indicator LED does not blink during use, like during battcheck, but it would probably be relatively easy to add if that’s desired.
This is great news btw! Sorry, haven't been following the progress but it sounds all good. Are you using PWM's to control the brightness? If so, is it the same typical rate, ~15K?
Have you considered or looked at external temp sensor support? Are you having the same issue of I/O pin shortages or have you looked at I/O pin sharing as Mike C has done? I really think for us to take the next step, we need to look at the 16 KB Atmel with greater I/O pin counts - this would solve a bunch of road blocks I'm having. We just need to team up with a board designer and come up with an easy way to dnld the firmware to one of these MCU's. Couple options there - not difficult to do, takes some extra real estate, but we also save real estate because of the smaller foot print of these MCU's, if we go with the square 5x5x5x5 configuration.
From this chart: https://en.wikipedia.org/wiki/Atmel_AVR_ATtiny_comparison_chart
best option seems to be the 1634, pricing/package options here: https://www.arrow.com/en/products/search?q=attiny1634
I have used DS18B20 temperature sensors with Arduino projects in the past and had great luck with them. They use the Dallas OneWire protocol to communicate and as such, only require a single I/O pin for the comms bus. Each sensor has a unique serial number so it is possible to control multiple OneWire devices via the same pin. This also means that the code in a production environment needs to be autonomous in discovering and identifying all the devices on the bus. I am not smart enough to know how heavy the library is on memory so I don’t know if it would even be possible in the smaller processors. I have been looking around at various other OneWire devices in an attempt to justify using this method but so far have not found anything terribly promising. The most interesting so far has been the DS2762 Lithiuum battery monitor. It is pretty big real estate wise and the spec sheet appears to show that the current monitor max is 2.5 Amps, but there may be a way around that. It also includes temperature monitoring so would be one device for both temp and battery.
There are also OneWire Real Time Clock chips that would allow much more precise Alarm clock modes.
Lazy-R-us
goshdogit, yes that answers my question:)
TK, that is awesome!
BLF Q8 Janus --- Emisar D4 RGBW --- Green Lantern and HAL 9000
6th Annual Light Contest Entry --- 7th Annual Light Contest Entry
Pages