[♛ FreemeGB] Fireflies PL47 Gen II 4*XP-L/ Nichia/ SST20 Hi CRI 21700 Right Angle Flashlight - ENDED

Just wondering, around how much current to push the 219B to give a purplish bluish tint?

How about a full-charged 40T? Will it also give the PL47 219B purplish bluish tint?

Same here last night with my Samsung INR21700-50E fully charged, be careful with nichia 219b turbo mode.

Narsil, actually NarsilM for "Multi" channel output support was further developed/released for the BLF Q8.

Narsil - dates back to 2015/02, vers 1.1 released in 2016/07

NarsilM - v1.0 released in 2017/05, v1.1: 2017/08, v1.3 is the active version

Narsil is the culmination of many inputs from the BLF community with UI contributions from BLF/Q8 members, and software components from ToyKeeper, JohnnyC, Werner and others. I put it all together and added some unique twists of my own. Because of it's rich history and support for many UI options, it's gotten a bit complicated.

Anduril is considered the next generation of Narsil(M). If you are familiar with the Lord of the Rings, Anduril was the sword forged from the fragments of Narsil, so the firmware is very much along the same lines. TK wrote Anduril from the ground up so it's a cleaner re-birth, but with same/similar features. She has taken it further in some areas, like brightness controls over the AUX LED's, campfire/candle mode, etc.

NarsilM has a bit more traction out there right now, more hours of use, maybe a bit more proven, specially for it's uses in the Q8, GT, and associated lights.

I can't make a true comparative list since I'm just not that familiar with the details of Anduril. You would probably find better and more info in the firmware threads. Sorry, I just haven't had the time to keep up with things as I should have.

awesome! Thanks a 1000000

jack replied my email within 7 hours… he asked for the video… I summit already.

I post the video here too. Post # 1672

I dunno - weird, but was the light warm/hot to begin with? Not sure if Anduril has full thermal regulation and not just thermal limiting. It almost looks like it's turning up power after recovering from thermal dropping output. If the firmware doesn't do that, then something weird goin on with the switch I'd suspect .

Here: https://budgetlightforum.com/t/-/32545/1899

Looks like thermal regulation is having issues, though not sure this is enabled in Anduril in the PL47??

That definitely looks like a hardware problem, like it thinks the switch is being pressed when it’s not.

It’d be worth cleaning the contacts and trying to remove any potential dirt or debris from inside the light. I’ve had what looks like little hair-like bits of aluminum floating around in some lights, causing problems. But if that doesn’t help, it’ll probably need a replacement.

There is no such test mode. It looks like it’s in stepped ramp mode and it’s getting phantom button presses.

Speaking of doing one’s homework, I’d appreciate it if you followed your own advice instead of spreading FUD. I’ve confirmed repeatedly in public that I made the code for this light and sent it to Fireflies. The code is published, the compiled binaries are published, and the details are available for anyone who wants them. Speculating about it isn’t merely unnecessary; it has a negative effect by spreading fear, uncertainty, and doubt about things which are not uncertain or doubtful.

The PL47 uses thermal regulation, but the behavior in the video is something else entirely. The thermal regulation system doesn’t go that low, and when it makes adjustments it’s smooth instead of going in steps.

There is only one known bug in the thermal code, and the PL47 uses a workaround for it. Sometimes on lights which heat up incredibly fast, the normal regulation algorithm doesn’t ramp down fast enough. So the PL47 errs on the side of caution by using a hardcoded fast step-down (er, ramp-down) on turbo before switching to the normal regulation.

About the link above… TA has been having thermal issues on a light he built, and is trying to get the code to work, and it’s doing really bizarre things… but as far as I can tell, the problems appear to be caused by his own tinkering. I’ve tried to point him in the right direction, but I think he needs me to actually fix it for him, not just give tips and ideas. And I’ve been too busy to do that for free. In any case, it’s completely unrelated to the PL47.

As far as I can tell, Newlumen’s light has a hardware problem, like burrs inside the light shorting the switch… or something like that.

Ok - good to know bout the thermal reg. I've seen 1 or 2 other reports on PL47's that sounded like switch problems, just that rising output looked strange. I got a PL47 on the way for a long time now - China shipping seems completely shutdown for 2-3 weeks now, least for me for several orders.

Where can I find the PL47 binaries? Is the link from the PL47 page (http://www.ff-light.com/index.php?route=product/product&path=59&product_id=54) to Anduril the current actual code they are using? That link they use simply points to the trunk, so wouldn't that always be updated? I would think there would be a snapshot taken of the exact version and full set of files Fireflies is using?

Sorry, I'm still confused with bazaar.

Ohh, I helped TA out previously, yeah he gets into some strange issues.

That is actually a pretty good answer. They’re similar in concept, similar in terms of broad strokes, but the details differ in many many ways.

It would be difficult to list all the differences. I can go over some of the main ones though…

  • NarsilM has two completely independent interfaces available — one for ramping, and one for mode sets. Anduril uses one ramping-style interface for both, and makes them easy to switch between.
  • NarsilM provides about a dozen mode sets to choose from, configured by the firmware author. Anduril’s stepped ramp uses only a single mode group, but it’s defined entirely by the user so it can be anything.
  • NarsilM keeps the config settings in a master config menu with many options. Anduril uses a few smaller config menus instead, attached to the modes they configure.
  • NarsilM uses a thermal step-down or a turbo timer to manage heat. Anduril uses PID thermal regulation.
  • NarsilM is older and more widely used. Anduril is newer and just starting to find its way onto production lights.
  • Anduril adds a variety of extra features, like: adjustable strobes, candle mode, lightning mode, sunset, and a muggle mode. Also, more aux LED / button LED modes, but those mostly don’t work on Fireflies lights so it’s not very relevant here.

The main thing people tend to notice right away is that NarsilM uses delayed on and immediate off, while Anduril uses immediate on and delayed off. In other words…

  • Delayed on: NarsilM waits until a “click” is either released or held before turning the main LEDs on.
  • Immediate on: Anduril turns the main LEDs on at the ramp floor level as soon as the button is pressed, then either goes up to the memorized level when the button is released, or gives a brief “blip” as a timing hint when it has been held long enough to stay at the floor level.
  • Immediate off: NarsilM turns off the main LEDs as soon as the button is released. If there are any clicks afterward, it turns the LEDs back on again. So, doing a shortcut to turbo means turning the light off for a moment along the way.
  • Delayed off: Anduril waits until it’s sure the user is done pressing the button before turning off or taking other actions. This means double-click to turbo doesn’t cause the LEDs to turn off first, and a click-release-hold to ramp down doesn’t cause a blink either. It also allows other actions without interruptions. However, it means there’s a small delay after click before the light turns off.

The biggest difference is something people generally don’t notice though. The source code for the two projects is completely different. It’s a bit like if someone sent a vague story idea to both J.R.R. Tolkien and J.K. Rowling, and they both wrote books about the same idea… the two books would be very different. But that’s all under the hood where users don’t see it.

I’ve been publishing builds here:

http://toykeeper.net/torches/fsm/?C=M;O=D

I think FF used the 2018-10-27 version for the PL47. If anyone reflashes it though, I’d suggest using a newer version. It should work fine, but there are a steady stream of little improvements over time.


It could potentially be the 2018-11-19 version, but I don’t think so. To determine which one it is, put the light in lockout mode (4 clicks) and then quickly press the button a bunch of times. If it stops lighting up after 3 clicks, that’s the 10-27 version. If it keeps lighting up no matter how many times it’s pressed, that’s the 11-11 version or later. My E07 shipped with the 10-27 version though, and they use the same firmware, so I think the PL47 does too.

Only 1 clarification there: NarsilM has 2 config menus. An Advanced Configuration is for indicator LED options.

I would disagree with calling what NarsilM does as a "delayed on". It's as quick as you click - no delay. Depends somewhat on the mechanics of the switch, and the user, but the firmware doesn't add any delay time.

With my memory I find it impossible for me to use Narsil. I just can’t keep how it works in my head somehow.
On the other hand, I absolutely love Anduril and flash every e-switch light I get with it. I find it much more intuitive… this is for me and my use so someone else may see it entirely different of course.

While we are on subject of instant and delayed on, I wonder why when you double click from off Anduril powered light it blinks before it goes to ramp top?
Narsil is way smoother here and that’s the only thing that bugs me about Anduril. Otherwise I love it and I want Anduril based flashlight in every form factor way down to 14500 and 16340.

Because in Anduril there is no delay from off, the light comes on immediately with the first click and shifts to the top of the ramp with the second. The blink you are seeing is the immediate response turning it onto the last used level. I just tested that in my little Thorfire TK05 and this is what it did. Click it on, then double click to go to Turbo. The double click from off takes it to the top of the ramp. I like to keep the ramp ceiling quite a bit below Turbo for cell conservation. :wink:

Yes, it’s definitely not slow. NarsilM turns on as soon as the button is released, or as soon as it has been held long enough that it counts as a “hold” instead of a click. If you have a better idea what to call it, it might make the concept easier to convey. Easier than writing out something like this, I hope:

When turning on with a single click…

  1. Button is pressed. Anduril turns on at floor level, NarsilM stays off.
  2. Button is released. NarsilM and Anduril both go immediately to the memorized level.
  3. Timing window expires. Both UIs stop looking for more clicks.

When turning on with a hold…

  1. Button is pressed. Anduril turns on at floor level, NarsilM stays off.
  2. Timing window expires. NarsilM turns on at moon level, Anduril makes a subtle “blip” to provide a timing hint.
  3. Second timing window expires. Both UIs start ramping up.
  4. Eventually, the button is released. Both UIs stop ramping and stay at the current level.

When turning off with a single click…

  1. Button is pressed. Nothing happens.
  2. Button is released. NarsilM turns off, Anduril waits for more input.
  3. Timing window expires. Anduril turns off and goes to sleep. Both UIs stop looking for more clicks.
  4. 5 seconds later: NarsilM goes to sleep.

The difference is a small one, turning on at button press instead of button release, but it’s something people seem to really notice. Same with the delayed vs immediate off. The response to it has been unexpectedly large.

I’ve been meaning to change that, and I keep forgetting.

The original idea there was, if there’s more than one click, it should turn off and wait until the user is done pressing the button before it responds. But to make the mem-to-ceiling change smoother, maybe it should instead use the policy of turning off at the beginning of the 3rd click instead of the beginning of the 2nd click.

Edit: Okay, the code change was trivial, but I still need to do some testing to make sure it didn’t break anything.

Edit 2: Seems fine; I pushed the changes up to the repository in the fsm branch. It should land in trunk within a few weeks; I do most of the FSM-related development (including Anduril) in the fsm branch and merge it into trunk every month or so.

Thanx TK! Just dnld'ed latest Anduril source and built it on Win10 Atmel Studio 7.0 for the first time, so I'll be checking it out.

In NarsilM, the dbl click from off first displays the last used level, then goes to max. I always considered that a natural progression.

Most of the ramping UI operation came direct from BLF users, so not sure where it's non-intuitive - would love to know more on that. Maybe the config settings is where the difficulty is? I find I got to look up stuff in the manual myself because I use it so infrequently.

Just tested it on Narsil and it looks like it turn off around 3rd click, can’t tell if it’s before or after. So this should do the trick.

That was fast :slight_smile: I’m Android developer and still that impressed me. I guess that’s the beauty of open source, just a simple message in the forum, can lead to a change in product you love.
Is there a changelog for the builds you make? I want to be able to see when this made it to the builds, so I can update mine Q8.