Brilliant!
Is the optic nerve programming similar to what oveready and torchlab uses?
ToyKeeper, did you read my question? it’s about the D4v2 firmware issue, not airport novels.
I would like to know how you test your firmware before releasing them (your standard procedures)
Do you test them, at least?
Yep, bansuri nailed it
It’s impossible to test everything, there can be thousand situations to test…(knowing this as a Key user/software tester at work)
Buggfree software doesn’t excist!
My question is purely technical and related to the original post.
Thanks.
In some ways, yes. The way I first heard about the Lux-RC drivers (which Oveready uses) was because I was telling someone about the proof-of-concept I made and they asked if it was like the Lux-RC feature. So I looked it up, and, sure enough, it was basically the same idea. Except Lux-RC uses an additional sensor, while the optic nerve method does more or less the same thing using just the main LEDs. The emitters can double as sensors, with no need for a special MCPCB or extra wires.
But the D4v2 does not have an optic nerve. That’s more of a FW3A thing. Also, I haven’t added support for it in FSM yet, because my initial tests suggested that it might not be as useful as I initially hoped.
Proprietary Information…
For curiosity sake, do you have more than one account on this site… Could be PI !
That MCPCB indeed looks thick.
Has anyone measured how thick exactly it is?
No, at least as of nowadays Lux-RC uses LED as well.
Just the aux LED and not the main ones.
Does anyone know if higher regulated output was considered (or requested by users?) during design of D4v2 ?
Varbos, at cost perhaps of a higher low it would be easy to increase the regulation level by stacking a 7135 chip. The programming may not utilize it in levels by default but you would still have a doubled level of regulation. (More with yet another chip, if there’s overhead clearance for it.)
So, you didn’t test the D4v2 firmware before releasing it…
You should ask for advise on BLF. There are some adult experts around here, who would be glad to help you improving your “overall methodology” (or absence of)
ToyKeeper (or Lips), for curiosity sake:
-do you know what maximum temperature will a 18650 unprotected high drain battery withstand before its unsafe?
Jeff, you seem eager to assume too much. Toykeeper writes code for far more than simple flashlights… her testing and development is complex and much too complicated to simplify for a post here, which is what she tried to tell you. And there ARE some of the top engineering minds in the world assisting, please accept that we know what we are doing here.
The level of driver seen in this light simply wouldn’t exist if not for the extensive development here on BLF. This D4V2 brings some new aspects into play that have not been done before, finding a glitch that is layers deep is not exactly a new thing in the industry. AND, you also have to remember that the Mfr and it’s extended contractors also have parts to play…. at any rate much of what goes on behind the scenes should stay there, behind the scenes.
We are enthusiasts, this is a hobby mostly delved into at personal expenditure of time and finances. You are welcome to design and develop your own and freely give it to the forum, we always welcome new ideas if you have any. 
Jeff, you should probably be asking these questions to Hank. It’s his product and he needs to have the holistic view of the hardware and software working together. I doubt he will feel obliged.
Modern Li-ion cells, protected or not, have a protection membrane that will cut off the cell to prevent catastrophe, whether they will or won’t is another question. Discharging at levels that heat a cell to 150 degrees C or more typically renders the cell inoperable and this usually cannot be reset. It is normal for lead wires to become unsoldered well before this happens, killing the light. Or springs overheat and collapse, also effectively killing the light. Traces on PCB’s have been known to evaporate, also rendering the light useless. As usual, simple questions have complex answers that can lead to days or even weeks of research.
I have personally built flashlights with current draws in excess of 90A. I have seen individual cells deliver 28-33A without issue. The possibility of a direct short overheating a cell to catastrophic failure is always something to consider, hence muggle modes on a hot rod flashlight are really quite ridiculous, any kid or flashlight noob can inadvertently switch the muggle mode off and enter full power modes, I’ve seen it too many times. Risk of fire from the heat output by multiple emitters will always remain very real, any light of this magnitude should therefore always be treated as the potentially dangerous tool it is… these ARE NOT toys!
No one said it was not tested, of course it has been tested. People here are simply refusing to feed the troll.
Yes, ToyKeeper has explained in previous posts here that the firmware was extensively tested. For example:
When looking at USBASP boards, what are we looking for in the specs? Will this one on Amazon work? I could wait two weeks for the one ToyKeeper recommended here, but I can have the Amazon one tomorrow. The programming key-pcb from OSH PARK is out of delivery today, would like to get started on this.
I think the cheapest “prime” equivalent I could find is this one:
https://www.amazon.com/dp/B00AX4WQ00/
It appears to be the standard old school one we have been using for a while now, but no promises. At least if it doesn’t work you can return it
Can you link me to that please?