thanks
how about if you wave the light up and down… can you see the dots?
T10T PWM
Gnope. Both ’mini and ’micro, both on level 1, shake up’n’down, nothing, swing beam across the ceiling as fast as possible, still nothing.
Hell, I’d even swear they’re linear, not pwmed.
Addendum, even in my cellphone’s camera (live, not recorded), no pwm-lines.
I think that’s a limitation of the KR4 in particular
[quote=jon_slider]
I would prefer a tailswitch, so SF12 instead of SP10
[quote]
Anduril does not work with a conventional mechanical tail switch. Lights like the FW3A or Noctigon KR4 have an additional electric path designed in to allow a momentary electronic button to be used in the tail.
However, Convoy may soon be introducing a version of their AA/14500 light with a clone of Bistro, wbich is one of the most versatile mechanical switch firmwares available. It is a bit larger of a light than most AA models, though.
That’s actually due to the hardware, not Anduril. On a 1×7135 driver, Anduril’s minimum output should be less than 0.5 lumens, but not all 7135 chips seem to be quite stable at those low currents. My ROT66, for example, has a subtle flicker at the lowest output the driver can supply. It’s slower than PWM, and actually, I’m not very bothered by it.
It definitely would be great, though, to have Anduril in an AA light capable of firefly level outputs.
it seems hard to shoot a video to show how the candle mode in Anduril looks like perfectly. Anyone knows?
digital candle
analog candle
Interested
If possible, it would be great if the driver had the flashing pad things like on the Emisar lights. It’s great to be able to easily keep the firmware up to date.
Agreed - hope the pogo pin flashpad thing is high on the priority list. It really should be/has to be.Therefore the re-programming pin access is important for a couple possible reasons:
- they probably would use a small footprint MCU to save space
- the smaller the light, the more difficult it could be to get access to the top side of the driver
- firmware tends to be evolutionary
- not sure if anyone has done BLF firmware supporting 2 different battery types; NiMh and Li-Ion, so not sure if detection can be implemented. I see on other AA boost designs that LVP is supported only for the 14500, not the lower voltage batts, so could be a technical limitation, maybe?
Most boost chips only operate down to 0.9V (typical) or 0.7V. So LVP is probably only needed for the 14500.
Though it may be safe for the cell, still seems weird not to have any notification because if the boost chip drops out, I would think the light just turns off with no notice.
Intersted. Definitely want a “non-ano” version.
If it has nimh support and not just li-ion, I’m interested.
If I remember right the PAM2803 boost IC that alot of these AA lights use drops out about .7v shuting off the light. It does kind of give a warning at around .7v where the light output is getting really dim before shut off.
I’m kind of wondering if going that low might be a problem for the mcu.
Interested. Would love to see Andruil ui or some kind of ramping os in a blf version of this light. Would be the ultimate carry if it could also work on nimh AA, but I would still buy if only 14500.
Just fyi, Lexel and gchart are actively discussing and working on a design that's Atmel based so we can run Anduril on it.
Awesome!
Thanks for the update Tom E. I presume this will be li-ion only then.
Hum, not knowing anything about electronics, wouldn’t that go “against” the whole concept of this “project”? :zipper_mouth_face: