I wouldn’t say no to a S2+ sized, tail switch, single “throwy emitter”, 5A max with no FET light for light painting.
That really needs to go.
My favorite Muggle-ish reference in Anduril was the MISCHIEF_MANAGED return code in the FSM source files.
I don’t think I can deal with remembering 6 clicks this, 10 clicks that. I have the whacky idea of implementing a text based interface for FSM, yes text based. To go into flashing mode you’d use the button to key “FL” (…. .…) in Morse code, and so on. They made me learn Morse code to get my ham license back in the day, so I might as well put it to some use.
To enter advanced mode, of course, you’d have to key in “ISSIAUTNG” (I solemnly swear I am up to no good). 
Well yes, all of that is true, and from a technical point of view you probably have done most of what you could to make Anduril 2 mass market compatible. But if we’re talking market adoption then I’m not convinced that’s enough. At the end of the day the Anduril developers (you?) find yourself in a B2B2C situation, where you’re trying to get manufacturers to use your software for consumer products. Anduril 1 has a reputation for being for nerds only, and for being used primarily on cheap hot rods. You can’t shake that off easily by changing some technical stuff (the UI) that you still have no hope of describing without a complex diagram.
If you were to just get rid of the advanced mode altogether, rebrand the result as Anduril Redux, make sure it’s not named together with “Budget”LF ever, drop the current license, and have a high quality (for the mass market!) reference light - then this might go somewhere. As I see it right now, Anduril “2” indicates that someone has doubled down on the feature set, while maintaining the core of Anduril 1. And I think that’s even true to a large extent.
Again – this is not a bad thing at all, and while I’m on a modified Anduril 1 with my lights I appreciate what Anduril 2 is and does. I’m playing devil’s advocate here. But at the end of the day you haven’t really countered my knife analogy. Anduril 2 still can do all of the things that are irrelevant to, and get in the way of, the mass market. Why would I buy something that can be whatever I want it to be if I need stuff on which professionals have already done all the thinking for me, and have come up with a narrow set of settings and features that are useful out of the box?
It’s a novelty. I was drawn in by the FW3A. The wonder of that wall of light. But then… it can’t last. Too much heat. But now, these newer emitters such as CULPM1.TG… are making stellar throw with longer runtime, capable of being housed in such small form factors. Really, at this point it’s easy to carry 2 flashlights—one dedicated for ample mid-range spill, and another for long range throw. Governed by Anduril 2.x and GOLDEN!
“Mass market” is subjective. Who is buying flashlights costing over $50, purchased from various China based retail websites? Average guy buys whatever he finds on the aisles of Home Depot, Lowes, Target, and Walmart. I don’t ever see Anduril for the mass market. From what I’ve observed, most people expect on/off, MAYBE a couple of brightness settings. That’s it. Oh, and multiple AA batteries, not lithium. Outside that, is the flashlight enthusiast or “more advanced” consumer who understands/appreciates more capable flashlights but after getting one doesn’t dwell on forums looking to optimize their next flashlight purchase. Would they buy a light with Anduril? Perhaps, if it’s marketed right. And then the flashaholic? Very likely.
^ What xevious said. Except for fire and police departments, military contracts, the market is the box store buyers. We are the connoisseurs of flashlights. I really appreciate what TK has developed. I don’t want every light I own to have Anduril but it is very nice. Subtract all the boutique stuff and it is a very intuitive UI and that is basically what A2 is in simple mode. Click and hold from off is great for applying the right amount of light to the job at hand. To me that makes it a great pocket light. Being in a hot rod is just just the icing on the cake. Light up the back 40 for a few seconds is a useful option when you need it.
It wasn’t like that originally. The auto-reverse feature was added because people requested it. I put it behind a compile-time option so it could be turned off, but years went by and nobody used the option. Nobody asked for it to be turned off. So eventually the non-reversing code got removed entirely, and as far as I can tell, nobody even noticed.
This is the first time I’ve heard anyone ask for it to go back.
Perhaps the auto-reverse timing window is a bit too long? It could be shortened. That’ll make it harder for some people to use though, so I don’t want to make it too short.
In older versions of FSM, it had the ability to handle Morse code sequences. Button events were represented as a list of actions, and event handlers received a reference to that list so they could interpret it however they wanted. However, this was removed and simplified because it was cumbersome and bug-prone, the extra capabilities were never used, and removing it freed up quite a bit of space.
I have no plans to drop the license. It might still be possible at this point, because there are few enough contributors that we could probably all talk and come to an agreement… but the biggest change I’d consider, probably, is switching FSM from GPL to LGPL. And that change wouldn’t even mean much since everything on these tiny MCUs is static-linked.
Anyway, remove all the fancy stuff, and it’s not Anduril any more. It’d be … er, … Muggleril? I’m bad at names.
Instead, I’m hoping there will be other interfaces available, and people can choose whatever UI they want when they buy a light, or flash their favorite UI afterward. Like, at time of purchase, the customer could select the host color, LED type, whether to include a battery, and which UI they want.
You’re probably right. There’s very little chance of getting open-source lights into the aisles of Home Depot or Walmart. Mass-market free software has happened with other types of devices, like phones… but lights aren’t complex enough to need a full-featured operating system.
It’s not that Anduril isn’t used in high-end lights… it’s that Anduril is only used in high-end lights. We may think a Sofirn SP10S is pretty cheap and mundane at just $16, but it’s a premium item compared to what most of the population gets from places like hardware stores, petrol stations, and grocery stores.
At the other end of the spectrum, BLF has open-source firmware on lights like the GT94, which costs $600.
But even with only enthusiasts involved, there is still a wide range of different ideas about what’s good. Some people want something simpler, some want more complexity. Anduril tries to span a large part of that spectrum, but it can’t cover the whole thing.
I can get to Turbo in Advanced with a double clic
IF I first ramp to top of ceiling (not if I double clic to top of ceiling)
this is inconsistent…
it would be better if 2C 2C gave Turbo in advanced
I use a user configured startup level of 15 lumens (force start in HDS speak). That is similar to my Lumintop Tool AAA.
I also use a 5 minute, last mode memory in my FWAA. I can revert to default by removing and replaicing the head, which resets the memory to my default.
I agree, I like knowing how many lumens my light is set to. I use a light meter to give me an idea. So when I want to set a 400 lumen ceiling… for my SST-20 4000k, that would be 90/150
I would like ramping to behave in a consistent manner
right now, after ramping up, another press (within a very short time) ramps down… but if I wait too long, then the next press ramps up
this is inconsistent
I personally would prefer that each time I ramp UP, the next press ramps down, consistently, regardless how much time passes… That is how the ramping on my NItecore D10 works, and I like it…
I dont use Anduril ramping because, it is too fast, and I have to fiddle with the button too much to go up and down or up and up and then down, or even in some cases the light thinks I double clicked, when all I wanted was to ramp down
….
also, I HATE the double blink mid ramp, it makes me try to ramp up and down as close as possible to it, but I can never land on the same spot… and I most certainly cannot go directly to the top of 7135…
so…. I use stepped mode (because it has no double blink mid ramp)… not ramping, because I find ramping with double blink so frustrating.
Like the Convoy 4X18A / 3X21A !!! :sunglasses:
This topic has been pretty divisive, so I’m planning to add a runtime config option for it.
Some people want the ability to set a meaningful ceiling level which isn’t easily bypassed. Others want the ability to go directly to full power no matter what the ceiling level is set to (though, in that case, I wonder why even bother having a ceiling at all). And it’s a pain to recompile and flash to change it. So it’s already set up as the first slot in the global config menu… I just have to finish adding it.
This is a good example of how different people think in different ways.
I specifically made sure it would not work like the D10, because the D10 method is inconsistent and I don’t like it. I had to devote part of my brain to remembering which way the light would ramp next time I pressed the button, and half the time it would end up being the wrong direction with no way to consistently start in the intended direction. It felt like I was flipping a coin each time I tried to ramp.
So I gave it completely separate button actions for ramp-up and ramp-down.
Early feedback indicated that people had difficulty figuring out how to ramp down, so I added auto-reversing.
Putting a timer on it is a compromise between D10-style always-reverse and Unheard-style never-reverse. It gives direct access to both up and down, eliminates the need to remember the last direction, and reduced the amount of support requests I get to almost zero.
I find that most lights are waaaay too slow, so I tuned it for the speed I like. Rather, Tom tuned it and I liked what he did, so I reused it. However, the existence of so many slow lights probably means that some people like it slower… and I shouldn’t ignore that.
The ramping speed isn’t easy to adjust, because the “frame rate” is hardwired into the attiny chip. So it could run twice as slow or three times as slow, but there’s no easy way to change it by a non-integer amount like 1.37X slower. Would it be sufficient to have a half-speed option? Then instead of 2.4 seconds from end to end, it would be 4.8s.
About the mid-ramp blink, it happens in both smooth and stepped ramps, and it only blinks once at each reference point. The reference points are different for each type of hardware, typically indicating when the power circuit has gone from “first gear” to “second gear”. Some lights don’t have a blink at all, and I’ve been kind of pushing for new lights to omit the blinks. Especially if there is a button LED, the button can indicate which “gear” the light is in without a need to blink the main LEDs.
That was one of the first things I had changed:
It adds a short delay at the transition from one channel to another so that you have a chance to stay at max regulated.
Done. Can be enabled in the global config menu like the 2C turbo behavior:
Already done.
It was good/necessary in Narsil where there was no other way to ramp down, but your Andúril has CC&H. It is more consistent to remove auto reverse. In addition, I wonder if reversing the direction is really more often used than keeping the direction. I really don’t like it and often found myself waiting for the timeout.
BTW, Crecendo, you will know this, also doesn’t reverse the direction. Using it is more straight forward for me.
Please make a poll. Maybe it’s only me, but maybe more people are bothered by this inconsistent action.
Edit: BTW, ramping is too fast for me, too. But I’m 53yo ;-).
Maybe 3-4 preset mode, like slow - medium - fast - mega faster
I learned a lot reading this thread but I’d like to learn more. Is there a place with more documentation about Anduril (1 & 2) for someone interested in creating their own branch?
Maybe some tips and tricks to avoid bricking lights?
Thanks!
^
this
2.4, 4.8, 7.2, 9.6 seconds? Who would use something even slower than 4.8 s?
> [Unheard] BTW, ramping is too fast for me, too. But I’m 53yo ;-).
Recent version of the software changed this, I think, so you might try reflashing.
> [Toykeeper] License…
Please keep it GPL3, that is what attracted me to it in the first place, preserving the end user’s ability to get the code and reprogram the light. Every damn poser Ferengi whines about GPL code because they want a handout for proprietary products, but then they use Linux and GCC anyway so it’s fine. If they want people to write proprietary code for them, they can bloody well pay the developers for that.
> [Mass market]
In mass market electronics the AVR is actually a fairly expensive part, and a mass market light is more likely to use something like a Padauk processor that has a few dozen bytes of ram and costs a couple of cents instead of close to $1. So Anduril doesn’t compete there on hardware cost grounds. That is fine, most people don’t want to hack their lights anyway.
It would be great if the strobe could use the last ramped/stepped brightness level (mode memory). I don’t ask for much!
TK
good exposition
could you possibly rank the factors in order ?
- would be the main reason why anduril isn;t everywhere
- the next most important
so on
but i get it
i was guessing cost was the main thing
one thing i get from the whole thread is, there are many ways it could cost more, besides just needing ATTiny
including hardware redesigh, safety issues
and a bunch of other stuff
what i REALLY want is anduril to run somehow on alkaline/nimh voltages, 1.35
which i think the ATTiny cannot do.
That is not really a limitation. The upcoming Sofirn SP10 Pro will have Anduril and works with NiMH down to 1 V (and less).