Hell yes! And welcome to BLF Caleb.
@ToyKeeper enabled this functionality on the FW3A driver iirc (led as light sensor) but found it was not practical for much of anything.
Must have missed that, and I even have a FW3A haha.
It seems like the main hurdle is finding a light modulation source that has a fast enough data rate to make it a viable option. I could see it being used by the end user if total programming time is 5-10 minutes. Again, it may be that there is no easy and fast way to do this.
I’d also like to explore how well it functions as an ambient light sensor in dark situations. The builtin transimpedance amp comes in handy when measuring uA or nA levels. In theory, you could turn the led off for a few milliseconds, take a reading, then turn back on. If the buck-boost regulator can turn on/off fast enough, measurement events may not be visible.
Definitely interested in hearing more about it. Always could do with more driver designers 
2 Thanks
I can’t help with the original question but I mentioned this a few years ago in a thread as a feature I would love in a future driver - I wonder if it would be easier to create a pcb based wifi antenna (the square-wave looking design) and offer PC-configurable firmware to flash it with? I would love a computer or phone based interface that allows you to tick or un-tick the number of modes, memory on or off, strobe or no strobe, where in the order you wanted the strobe etc and then the program compiles it and then writes it to your driver wirelessly with wi-fi or nfc. Asking way too much? Most likely! But one can dream.
Hell yeah. It’s… 
I’ve noticed lots of emitters stay very dimly lit after turning then off for a surprising amount of time (sometimes a second or two). Do you know if this is due to the driver or the emitter? It may interfere with your non visible light measuring. Other than that the driver sounds very intetesting
1 Thank
I would go for USB Firmware Updates over wireless. flashlight bodies are usually full aluminum, not much signal will get in or out, and antennas for 2.4 GHz are not super small. And unless you use a ESP32-ish chip that hosts a webserver which you connect to and then upload new FW, it also needs special software again (like the Adafruit BLE OTA firmware update thing for their nRF528xx bootloader).
USB updates via ideally uf2 are the most user-friendly choice IMO. No drivers or tools needed on any hardware/OS (android, iOS, macOS, windows, linux) since it uses mass storage protocol. DFU being the second choice, it needs apps and drivers.
2 Thanks
High-end flashlight manufacturer Lux RC did/does similar updates, so it’s possible.
I can’t access their website so can’t see if they still support it. Maybe they went out of business
Thanks for the link! As mentioned there, the data rate is too slow for reflashing the entire firmware practically.
But this optical method seems suitable for inputting custom settings per user.
40 seconds is reasonable and 16 bytes of data could fit a lot of customizations such as default levels, turning on/off simple mode, choosing the active channels for multichannel, turning on/off post-off battery check, etc. And maybe even things that are currently only configurable by changing code such as deactivating the third digit of precision in battery check.
1 Thank
This effect is caused the output filter cap for switching regulators. It holds onto charge after power is turned off, and not intrinsic the the emitter itself. Which is why you typically don’t see this on fet or linear drivers. In any case, the switching regulator I’m going with has an output discharge feature which drains the output cap in a few microseconds.
For flashlights that already have a USB port, I would 100% go with DFU/UF2 programming. It’s so much easier and robust than OTA. My last big project was developing a ESP32 based product with OTA and web interface, and getting the wifi to a stable point was a real pain. There’s just so much unnecessary software overhead and complexity associated with wifi, especially for a flashlight.
1 Thank
Nice project and welcome to BLF.
Yes since it would take a more reasonable amount of time.
I’ve been waiting for a long time for an integrated buck-boost IC with decent power, there was the LT3120 that came out not too long ago but the FETs still had relatively high resistance, the TPS55289x looks much better but it’s quite expensive and relatively large.
I’m curious how you’ll get good resolution to go down to 50uA with the i2c variant, considering the steps are 50mA which is quite coarse. My plan was to use the analog version (552892) with the usual error-amp circuit and 2 sense resistors, either with low side sensing, or by using the output (CDC) of the internal current sense amp which would allow high side sensing, if it’s precise enough but it’s probably not the case.
Oh, I totally lost non-USB lights out of focus for a moment. In fact I wanna make a similar thing, replacement PCB for an older gen Lupine Piko, and I was thinking about going the OTA route there, too.
Absolutely makes sense for that, and I’ll follow your project for inspiration ^^
Been a fan of your drivers for awhile, always interesting to see what ideas the other hardware guys come up with 
In theory, it would be simple to have two high side current sense resistors, and switch one out depending on the current range. But since the TPS55289 only has a current limit resolution of 7 bits, at 50mA full scale the LSB is 390uA, way more than I’d like. Also as I’m sure you know, eliminating oscillations in the feedback loop for a switching regulator gets extremely tricky for high dynamic range situations such as this. Due to the self-imposed constraint of using the MSP430’s builtin opamp, I’m limited to low side current sensing. In order to sense high side, it takes no less than 5 resistors, and I don’t have that much space. Plus you have to worry about offset voltage, resistor matching, etc. So I opted for the following strategy: dual low side FETs, one is a short directly to ground for currents >50mA. When you want less than 50mA, turn off the main FET and use the other for linear current sink.
A concern I have about the linear regulator is that the offset voltage determines the minimum output current achievable that is guaranteed to be > 0. The MSP430’s opamp is specced to +/- 5mV Vos, which is not great. The burden voltage of the low side current sense resistor is ~200mV, so this corresponds to an accuracy of +/- 1.25 mA, which is pretty terrible. The way I get around this is by significantly reducing the open loop gain of the op amp to ~2. This will decrease gain accuracy due to variations in the threshold voltage on the low side fet, but what I get in return is a psuedo-exponential response input response. Meaning, variations in offset voltage and resistor tolerances will have a smaller effect at low currents, and also improves dynamic range practically acheivable.
The blue trace is the simulated PWM DAC input, green trace is LED current. Notice the small curve at the bottom of I(R5). Ignore the P/N of the op amp, I just chose one that seemed close enough to the MSP430 builtin. Depending on how well this works, I may have to switch to an NPN as opposed to a FET. The lower input impedance and tighter Vbe tolerance makes this exponential curve even more gradual. But I’m going to see how the FET works out this time since I can save a little PCB space by going with a dual-fet part.
The phosphor layer of some LEDs will stay glowing for some time just like a glow in the dark toy, even with FET drivers (no output capacitor). Some LEDs glow for longer than others, it will depend on the phosphor composition.
LED at standby, TS10 FET driver, no glow.
LED recently turned off, TS10 FET driver, golden glow.
2 Thanks
Wow that is very noticeable, I didn’t realize it could be that bright. I know most emitters are phosphorescent to a certain extent, but that’s something I didn’t consider very much.
Another thing to consider is the fact that some LEDs ate VERY sensitive to 365nm UV, to the point that the driver of my Q8 Pro turned on, the button backlight was responding to the switch commands, and I could even do a voltage check, and it was reading 2.3V with the battery tube removed, so if you want to use the main emitter as a sensor you could use a 365nm LED as your Tx and you would have a strong signal to work with.
2 Thanks