I tried two — XM-L2 with S2+ reflector, and XP-L HI in a BLF X5. Similar results. I measured one using my expensive fluke, the other with an attiny25 and a bit of math. Similar results. I think it just needs to be able to work with relatively small voltage changes… and, fortunately, it does.
Plus, the auto-calibration lets it accept a wide range of input sources. Just try not to change the brightness too much during data transfer, since it works on a midpoint threshold instead of edge detection.
Given enough ROM space, that should be possible. I’m still targeting tiny25 though, to make it work on existing drivers (after an “optic nerve” mod). However, the approach I’m using should make it relatively easy to add other stuff.
That might be worth the extra space it’d require. Instead of streaming all of eeprom, it could send a couple header bytes — start point and length — then stream the data. It wouldn’t cost much ROM, and would dramatically speed up small changes. I personally don’t want to wait for like 2 minutes every time I tell it to change one setting.
This would also make it a bit easier to detect when there was a transfer error. If the flashlight doesn’t blink out a confirmation after the app stops, the user can see that it didn’t work.
Most cheap lights from MegaMart already do what most people want. We’re a long way into that “20% of the gain takes 80% of the time” part of this field, only it’s more like 2% and 98%. And no solution is ever truly universal.
But it’ll be nice for people who really enjoy detailed customization, and probably also nice for people who make or sell flashlights. Could allow per-sale customization without hardware changes.
Anyway, I’m in it for the fun, mostly. I might do what I usually do — implement the fun part, the prototype, then leave the detail work to people who are more interested in that sort of thing. I’m a lot better at starting things than I am at finishing things.