most LEDs change tint with current. Below a certain current the tint might deviate heavily from what is expected for that LED at nominal drive currents.
Using PWM mitigates that effect as the drive current is always the same. The brightness is controlled by the length of time the LED is switched on. The downside is lower efficiency, as an emitter pulsed at a high current but low duty cycle is less efficient than an emitter driven at the same effective current but with 100% duty cycle (= constant current).
This is a reason why i.e. computer screens always have pwm controlled brightness, as you do want the same colors for different screen brightness levels.
So whats best? It depends efficiency, tint, cost & complexity of the driver, range of available levels… there is much to take into consideration.
ok shame ali shipping options are so lame, over 40days last time i order there and lion cells probably can get rejected in customs… weird so hard to find that brand closer to me…
Mine took 16 days to the UK, so about normal for AE/BG purchases.
EDIT: I was tempted to buy the Liitokala but wasn’t willing to take the risk of getting fakes. I think the Shockli’s are the best all-round 26650 out right now (even though they’re likely a re-wrap) and am pretty sure the store and cells are genuine so was happy to wait.
To my knowledge Swedish customs do not have restrictions on li-ion cells. They haven’t stopped any of mine coming in anyway.
When I wanted the Shockli cells I sucked it up and ordered from Mountain Electronics together with a bunch of other stuff. Yes , shipping and import taxes costed a bit but I was willing to pay for speed and reliability so MTN was the best choice at the time.
In my tests of 10 top cells (size notwithstanding) the Golisi 26650 came in third, bested only by the Samsung 25S and Samsung 30T. Even the well known LiitoKala Black fell 8 Amp’s behind the Golisi. This was on my 17 emitter Ham’r, the Golisi showed 27A delivery from a single cell. The 25S did 28A and the 30T did 30.3A. So there’s just not much out there that can best the Golisi 26650 4300mAh Gold cell.
I ordered a D4S on Jan 12, and it shipped Jan 17. Still have not received it yet. The tracking number Hank provided shows no update since January 17th.
I had ordered from Intl-outdoor before and the tracking was always accurate and updated regularly. This time however, 17track is not showing any updates. Should I be worried?
When you take a cell out to charge it and then put it back in the light, the light first comes on at 100% of the 7135 chip. This is where the “blip” is when ramping, it’s an indicator that you are leaving the regulated section and entering the FET section. It can mean a lot if you are below this blip or above it, as even the slightest bit above it enters the PWM’ed FET section that shares the 7135 chip at 100% with the PWM’ed FET. Once over the blip line the emitter is getting full current, just pulsed to control output, so there is a difference in how the emitter perceives the power it is getting. (warmer, more efficient, at 350mA as compared to pulsed at 5-6A)
I can’t readily discern a tint difference between the upper end of the 7135 and the lower end of the FET, but the human visual system takes context into account in ways that sensors don’t.
I thought I enabled the mid-ramp blink on the D4S… at least, mine does that, using the default build of Anduril-D4S.
Not really… it’s complicated. Here’s how the UIs are related. This is an approximate timeline tree showing relationships between different firmwares…
First, the Narsil side of things. It’s a long chain so I’ve flattened out the first two derivatives to reduce the tree depth for easier reading:
STAR_momentary v1.6 (JonnyC, 2014)
forked as eswitch-13 UI (Tom E, 2014, based on STAR_momentary)
forked as eSwitchBrownOut UI (Tom E, 2015, copy of eswitch-13 with changes plus TK’s library headers)
… continued development, renamed to eswBrOutCfg (Tom E, 2015)
… renamed to Narsil (Tom E, 2016)
… continued development, Narsil 1.10, 1.11, 1.12, 1.1, 1.2, 1.3 (in that order) (Tom E, 2016, 2017)
forked as RampingIOS (V1) (Tom E, 2017)
… continued development, RampingIOS V2 (TK, 2017)
used on Emisar D4, D1, D1S
(branch is dead now)
… renamed to NarsilM (Tom E, 2017)
… continued development, NarsilM 1.0, 1.1, 1.2 (Tom E, 2017)
used on BLF Q8, BLF GT, Fireflies ROT66, and a few other lights (?)
… continued development, NarsilM 1.3 (Tom E, Texas_Ace, Lexel, 2018) (note: there are several TA/Lexel forks called “NarsilM 1.3” and they have not been merged together yet)
used on Lumintop GT-Mini, Lumintop GT70, Astrolux S43, and a few other lights (?)
Shortly after the Emisar D4 came out, I started on some completely new code to run on it. This was briefly called “round table”, but soon came to be known as “FSM” or “spaghetti monster”. It’s what I used as the base for Anduril, a.k.a. the blade Narsil reforged. The name was chosen with Tom E’s approval, to indicate it is a symbolic successor. Anyway, its history is a bit shorter:
FSM (TK, 2017, 2018, 2019)
Momentary, Baton, DarkHorse, Ramping-UI (TK, 2017, FSM example UIs)
Basically, the first few Emisar products used RampingIOS V2, which was based on the old Narsil before it had a “M” at the end. The D4S uses RampingIOS V3, which was based on Anduril. Despite appearing to be just a version bump, the two actually share no code and have no common ancestor.
As far as code ancestry trees go, this is pretty simple. At one point, a lab I worked at had the UNIX family tree printed out on paper, and the chart was about 10 meters wide… and it didn’t even include the Android or Kindle branches, since it was printed when Android was just starting out. If I recall correctly, it also had only a very simplified version of the Linux distro tree, because that by itself is a huge chart. Here’s a greatly simplified version of the Linux distro tree, in case anyone wants to see what one small portion of the larger UNIX tree looks like. Or a somewhat more detailed version…