Ha Ha Ha, to funny, I know what your saying, phone tells me stupid things like that and makes me wonder why do I own this thing, my old flip phone worked just fine, until the phone company said I had to buy a new phone since my flip was so old it was the equivalent of the rotary dial phones, I liked them toā¦ ha ha,
I am not sure those phones are that smart but they are capable of scaring me sometimes, like how did this phone know that, and it wants me to turn on photo recognition, ha I donāt think so, making me paranoid nowā¦
Oh no no no, I donāt want anyone change anything because I said something: itās just me thinking loudā¦
M43ās UI1 is also great for this light when it comes to press and hold for momentary turbo (no ramping then). That would work for me as well.
Iām trying not to change much of Hankās design, so I donāt think the click patterns will change. However, it might be feasible to make double-click toggle turbo instead of being a one-way trip.
Additionally, with mode memory you can set the brightness to whatever you want, and then it is a simple one-click on/off at that level.
Mode memory is not saved across battery changes. This means it needs a default value. The default could be moon, 10 lm, level 65 (100% on 7135 chip, 0% on FET), or something else. Iām thinking the 100% 7135 mode might be a good default, since itād be nice to have a shortcut to the highest regulated level with no PWM. I measured it at 133 lm on mine. This level would be accessible at any time by loosening the tailcap, tightening it again, then clicking the button once. However, 10 lm might be nice too.
Sound like a plan?
BTW, the difficult thing about reading battery and temperature values is that ā0ā digits donāt get a blink. So, a temperature of 21 gets āblink blink pause blinkā, while a value of 20 gets only āblink blinkā. I intend to fix this by making zeroes give a very short blink instead of nothing.
That thermal regulation looks really good! Great job TK!
Yes TK the temp reading was impossible for me to figure out even after taking a actual temp reading then attempting to figure blinks to the actual reading.
First mistake I think I made was an attempt to read the blinks from the point of extremely high temps and seemed rather pointless because of how fast this little light really does cool down, it cools very quickly and will give you blinks all over the place, it doesnāt seem to have set temp levels to give an accurate blink reading but seemed to me that would have been thought of but mine at times would either just kept blinking steadily when very hot but when cooled quite a bit there was continuous blinks of sets of four and light was just warm, a cold light is 9 blinks so not sure what that translates to assuming in Celsius, 9 Ā°C or 48.2 Ā°Fā¦ doesnāt seem logical to me. ?
Edit: The Beacon mode is rather low,
I think the beacon light output must be set at 20% of max output and that seems way low to be very effective, it is also very slow and should be more like a flash if thatās possible, present light level is a good default level but it would be nice to have the ability to ramp up the beacons output to max if need be by just holding down the switch while in beacon mode like it is in the M43, Edit: Delete wrong infoā¦
Glad your on the upgrade team TK but also means I will be buying more D4 lights with the improvements or drivers for change outs if available and then Hank will probably have the other D1S light about ready I hopeā¦ Thanks for listening TK
Yes, I love it! (133 lm)
You make the best UI:s :+1:
Itās funny that people want the beacon mode to be brighter. I find it way too bright.
Maybe it can use the memorized ramp level instead. Thatās an easy change.
Anyway, Hank sent sort of a ācare packageā. It consists of a bunch of parts which (mostly) were either prototypes or failed QC, but can be assembled into working lights for testing and development. There are sharp edges and dents and other issues on nearly every piece. These are the kind of parts you wonāt get in production units:
There is one XP-L HI and one XP-G2, unknown tints. Iāll get measurements after theyāre assembled and working:
Of particular interest is that these show how the switch is assembled. It appears to be very compact, just a membrane switch and a rubber boot, with a ring press-fit over the boot to keep pressure on the parts:
Since I know someone will ask, here are the dimensions:
- Boot hole depth: 1.9 mm
- Boot hole diameter: 13.7 mm
- Membrane switch thickness: 1.3 mm
- Membrane switch PCB: 6.0 mm x 6.0 mm
- Switch hole: ~1.0 mm (?) x 6.0 mm x 6.0 mm (plus cutout corners)
ā¦
On a totally different note, I updated my thermal regulation simulator today to try to make it match what I measured on the D4. Itās fairly close, but I think the actual D4 gets less-hot and reaches its stable temperature sooner than the simulation. And for some reason I had to use attn=6 here instead of attn=4, but otherwise the parameters are the same as I used on the actual hardware. Hereās how it looks when simulating the āregulation test 5ā from earlier:
The most interesting parts are a bit easier to see if I give the simulator a smaller ābatteryā:
There is, um, probably a bit too much info packed into each graphā¦ but I think what it shows is pretty close to what I measured on actual hardware. So it seems like a fair model for testing changes without waiting an hour for each test.
My opinion about UI is
From off
Long click min
Click - saved ramped mod
Two Click - max mod
And some idea about ramping. Now there are 150 levels and it is impossible to tell which one is selected now. Idea is to make 2 mode of ramping one with 150lv and another with only 10lv. Mods are easy to distinguish and have nice spacing. The ramping time is the same ,but mods change every 0.25c
This is already implemented in the new D4 code. Additionally, it has:
- Loosen + tighten tailcap, then click: Go to maximum 7135 level (~140 lm with no PWM and no FET).
I implemented those two UIs in 2014 in the āFerrero Rocherā project. Theyāre called Ramping_UI_table.c and Baton.c in the firmware repository. I plan to make updated versions for the D4, but it wonāt be part of the production run. Theyāre example UIs or test cases for a new generic code base.
Jay, the 100%7135 is back! I love the work you do on the D4 Toykeeper! 
Thank you for the switch info didnāt want to pry on the retainer until someone had some info, so thanks TK I can pry away,
Do you think Hank will have any replacement switches and boots, mainly switches, drivers would be great also, thank youā¦
Oh, good news, thanks you. Such UI is much more convenient.
Great info :+1:
So is there any chanc that Hank will sell the D4 with YOUR firmware on intl outdoor ?
The idea as I understand is that what Toykeeper is developing now is to be in the D4ās that Hank is going to sell on intl-outdoor.
The improvements made by TK to the firmware will make the D4 a really good flashlight for sure !
This is why I waited 
Both level65 and 10 lumen are good values for such a small EDC light as default memory values. However, I certainly prefer level65 (133 lm) for two reasons:
1) It is a very symbolic value that portrays the essence of the light and driver; a true flashaholic should/could understand and appreciate the meaning of this output.
2) ramping to a comfortable 600-ish lumen output is much faster from single click level65, than it is from single click 10 lumen output. Edit: percentage wise itās faster.
I vote for 133 lm level65 as default.
Efficiency vs. output curve is nearly flat, then falls of the cliff and is again nearly flat.
350 mA is the cliff top. It should be easily reachable.
But it should be also easy to tell on which side of the cliff the flashlight is at any given mode. Otherwise there will be nasty surprises of battery draining much faster than it should.
Making 350 mA the default level is a great way of making it easily reachable.
However, ramping from low, one can easily pass it without noticing. I donāt like it and I think it should be somehow communicated to the user.