Anduril 2 driver questions

Flashlight Modding and DIY Parts
1

Hi all,

I’ll try to be as direct as possible. Anduril 2 seems to run on constant current, then plummets and turns off when the cell is depleted (2.8ish Volts.) So 2 questions:

  1. in this “off” state, is there still parasitic drain due to the eswitch/guts, or is it a firm cutoff with 0 activity?

  2. is there a way to calibrate a voltage based dimming curve that scales to the user defined ceiling and floor modes? I.e., 4.2V to 3.7 = ceiling capable, 3.7V to 3.2V ramps down accordingly with 3.2V being floor, then sub 3.2V to 2.8 would run at a fixed (firmware hard cap, like step 2 or 3) lower current mode until cutoff at 2.8V?

Thanks in advance!

2

No, Anduril is just the user interface. The result can be a constant current or PWM with direct-drive or a combination.

The microcontroller still requires a little bit of power, but it can enter a deeper sleep state and turn off more peripherals.

No, that wouldn’t make much sense. You will experience a similar effect with a simple direct-drive driver. What’s the goal?

3 Thanks
3

A hybrid vehicle has both gas and electric drive sources. I want the option to be able to select between DD emulation and constant current, or some hybrid of the two, and something that won’t just cut straight to off with little to no warning. It’s why older vehicles had the “limp mode” even with certain component failure, it gives you enough to get you somewhere less dangerous.

4

In short, I guess I’ve had both the luxury of an abundance of power sources where “i don’t have to worry about power” AND the experience of “oh shoot, I’ve got 30 seconds to find another power source because my CC light just dropped to life support mode because I forgot to manually turn it down.”

5

true for lights with regulated output such as D3AA (yes Anduril):

zeroair-reviews-emisar-d3aa-black-4500K-107-2048x1538
zeroair-reviews-emisar-d3aa-black-4500K-107-2048x15382048×1538 433 KB

and Skilhunt H150 (No Anduril):

zeroair-reviews-skilhunt-h150-v2-nw-110
zeroair-reviews-skilhunt-h150-v2-nw-1102560×1919 166 KB

otoh lights such as TS10 (yes Anduril):

zeroair_reviews_wurkkos_ts10_red_body_86
zeroair_reviews_wurkkos_ts10_red_body_862560×1919 190 KB

and Wk03 (No Anduril), have unregulated output:

zeroair_reviews_wurkkos_wk03_68-2048x1535
zeroair_reviews_wurkkos_wk03_68-2048x15352048×1535 507 KB

To avoid getting stranded in the dark, i make a point of checking battery Voltage, and replace with a fresh battery when I see anything less than 3.7V

that way I dont leave the house with less than a half full battery. And I keep a spare battery, and/or a spare light handy…

charts from zeroair reviews… I rely on his runtime tests to see the shape of the output curve…

The charts can also show me the Sustainable vs UnSustainable outputs of a given light.

I prioritize using Sustainable outputs and avoid using UnSustainable outputs…

2 Thanks
6

Fully agreed on all points, lol. Either way, for me, because I typically focus my attention on other things, I tend to lose track of what level/how bright I had my lights on for, as I assume many of us do…I’m planning for my lack of planning, I guess.

I typically have 3 lights on me at any given time, a thrower/high lux, a general edc, and a backup edc, and sometimes a second general edc. I rarely ever carry loose cells, just in case I’m caught in the rain, flood, dirt scuffle, situations where I would NOT want to be swapping a battery where the guts are NOT potted, and the cell has no protection circuit.

Basically, I bet on my own absentmindedness, and because that is a constant in my life, I would like something that functions as a hybrid regulated AND dd light. A constant solution to address a constant issue, if you will.

1 Thank
7

Problem is that the voltage of the battery will drop under load. The firmware cannot respond in the way you want.

8

Direct Drive = batt connected directly to led. Good buck drivers have 100% duty cycles so i ques it is same DD with some drop across circuit.

1 Thank
9

Alright, perhaps I was too specific. But you definitely understood what I would like to happen. Can the firmware generally be tuned to what I described, perhaps more fine tuned with the voltage sag in mind?

10

I already have an idea of how to address the voltage sag. Record the active voltage, record the corresponding resting voltage. Plot out the curves to associate the active curve to the resting curve. I’m making an assumption that the cell cutoff of 2.8V in Anduril accounts that if a resting voltage is 2.8v, then the active voltage would be around 2.5V, liion danger zone. Does that sound correct?

***edit because I feel like I have to talk to to you as I would a computer, no offense intended. When Anduril cuts out at 2.8V, is that cell resting voltage, or is that the cell’s last reported active voltage?

11

The driver is only able to measure the input voltage. This includes the voltage drop due to the load. So if the driver sees 2.8V under load, it reduces the output and the voltage might rise to 3.1V again.

The voltage drop problem is more severe with boost drivers, as they draw a higher current when the voltage is low, causing the voltage to drop even more.

Direct-drive drivers use the voltage drop for regulation. They assume that the voltage of the battery (limited by their internal resistance) drops to the forward voltage of the LED while running at an acceptable current. Further brightness regulation is then implemented with PWM (turning the LED quickly on and off).

Combining a regulated driver and simulated direct-drive behavior isn’t easy. First, the driver has to simulate the IR of the battery by tracking its voltage or level of charge. Almost no switching driver can be turned on and off quickly enough for PWM, so the dimming has to be done in the current regulator as well. It might work with a driver that can be switched between constant output current and constant input current.

12

No problem here at all :slight_smile: It does not matter what kind off driver. If MCU will sense low voltage mark it will start to execute LVP code. It will step down level or just shutdown. Depends on code.

2 Thanks
13

I don’t see the Problem either. As soon as the voltage goes below a threshold, lower brightness. Whether the voltage rises again or not doesn’t matter.

That allows for pretty much the behavior OP wants. A couple of my lights throttle when they are close to running out, and then give another 30 or so minutes of low brightness before the actual UVP kicks in and they shut off.

2 Thanks
14

Yes, this! If the Eswitch always needs a current to run, it’ll remain in its low voltage state as long as the circuit is never physically broken. Even if it is, there will be the correlative Active/Resting value table that BECAUSE the Resting Voltage is under “x”, it will only be able to hit an applied max of “Y”, THEN it will measure the active load and adjust accordingly.

This should alleviate the issue of the overzealous user who keeps repeatedly opening and closing the circuit to attempt to reset and trick the firmware reach “Max” or “Turbo” mode.

Hypothetically, it would go something like this:

|♤♡◇♧| Physical circuit closes, immediately cycles multiple instances of cell multimeterdetection including resistance and Resting Voltage (for redundancy and accuracy), quickly followed by a blinky readout for the user (programmable to on or off, and can be skipped by activating the light.) It assigns a max current draw in accordance to a Resting Voltage value table, which the factory tunes all drivers to (FOR EXAMPLE ONLY):
*Y= standard 100% tuning, could be 50% of “Maximum User Turbo For Killer Amperage”, or MUTFKA for short. So if turbo uses 7A, the most Y will use is 3.5A (turbo can be activated for a set reduced timer on any mode above X3, and will have a set timer UP to the specified duration, BUT subject to time reduction according to the Active Voltage tables)

X5 4.0V<4.2V, Y or MUTFKA, user t=30s
X4 3.8V<4.0V, 50%Y<Y, or MUTFKA, t=10s
X3 3.6V<3.8V, 20%Y<50%Y, or MUTFKA, t=5
X2 3.4V<3.6V, 10%Y<20%Y,
X1 2.8V<3.4V, 0.001%Y<10%Y
X0 x<2.8V, 000000

^this will ensure safe ceilings to prevent overdrawing due to excessive sag.

THEN when the light turns on, a corresponding Active Voltage value table (:heart:◇:heart:◇:heart:◇ ADD ACTIVE VOLTAGE TABLE LATER :heart:◇:heart:◇:heart:◇) will translate the output as the voltage sags, example below:

If Resting Voltage is X5 state,
Output Y amps. Cell sags to 3.7V, so Y amps quickly ramps (smooth or stepped) down through X4 state over 3 seconds, with the ability to stop between the levels if the sag peters off due to reduced draw. IF threshold not met, it drops past X4 into X3, so on so forth. HOWEVER, whether Active Voltage sets an instance specific hard cap or will be used as a soft cap relative to Resting Voltage needs to be determined, as well as how many steps there would actually be, as the number of steps would also determine or influence the regulation of the “stepped mode”.

I’ll put this thought on hold for now until I can scratch out a flow chart or something, and can veg out as I game it out… If someone else has any ideas, it would be greatly appreciated.

Again, to reiterate…I am the type of person that makes it why everything has to be defensively programmed or designed, but not because I am a professional, but rather because I am an idiot.

15

I don’t know what kind of bicycle you want to invent , but it is invented already and works properly.

2 Thanks
16

Not Anduril specific but “tapered output” has been argued about since the dawn of LED drivers allowing constant current.

“Most” users want a flat or flatish output for the majority of the life of the cell, then sensible low voltage behaviours (no excessive flashing or sudden unexpected shutdowns etc).

There are niche use cases (I’ve typically seen caving as the example) where users want a gradual decline in output over the life of the cell.

I find the desired combination of a “complicated” UI like Andruil, and “direct drive behaviour” quite curious.

In instances where I’ve needed to rely on lights (underground for 8+ hours), my preferred lights had simple UI with discrete modes which I know roughly how many hours runtime I’d get.

I think I understand your motivations, but with Anduril, you could get a voltage readout, know roughly how much capacity you had remaining, and use suitably low modes to compensate?

1 Thank
17

Can it work underwater? :melting_face:

18

To address the last point only, I always INTEND to proactively interact with my lights, but something else always ends up demanding or occupying my undivided attention…I’m terrible at time management, so I tend to work at my own pace and set my own focus, to the point where I forget to eat until I get the “eat food now you’re starving” shakes. When I zero in on something, like a plumbing issue, taking apart things, etc., I have a very difficult time walking away from it because A) i might not get back to it and B) it needs doing right, and I’m in the zone.

I’ve had fully regulated lights do that annoying"blinkyblinky" thing, or just completely shut off when I’m in the middle of something, it COMPLETELY shifts the focus away from the task at hand. The dimming, on the other hand, gently reminds my brain that “hey, it’s getting around that time, put a pin in it,do your backups and saves, feed me and feed yourself.”

Anduril seems to be capable of this kind of tuning, but it might look more like a fragmented Narsil after I poke around in it…

2 Thanks
19

Aren’t Anduril lights gradually stepping down towards the end of their battery life anyway? Any runtime graph I see (of Anduril lights with proper Bucks/Boosts) runs until a certain point, then does something between 20 and 90 minutes of gradual step down until the actual LVP kicks in and shuts the light off for good.

1 Thank
20

Anduril UI keeps same PVM level until LVP kicks on.And that is how i made in ZigZag UI

	if (voltage < 31 && actual_level > M5) {set_level_s(M5);}
	else if (voltage < 29 && actual_level > M4) {set_level_s(M4);}
	else if (voltage < 28 && actual_level > M3) {set_level_s(M3);}
	else if (voltage < 27 ) {
		if (actual_level > M2) {set_level_s(M2);}
		if (actual_level < M1) {
			ticks_since_adjust++;
			if (ticks_since_adjust > 620) { // 10 seconds
				blip(1);
				ticks_since_adjust = 0;
			}
		}
	}
1 Thank