The user interface (UI) on the Aukey LT-T6 is not very good. I was not happy with it, so I took it apart. Hey, an eight pin micro! Hey, the PIC matches the footprint!
Software should be pretty simple. Probe some pins, document some signals, replicate the signals, and create a better interface.
Since all the ICs have had their markings removed, I'm not sure what the chips actually are. But, a quick check of the footprint of some 8-pin PICs verifies that I can swap the unknown chip on the PCB out for one that I can program.
I did a parameter search for an 8 pin device with PWM and an EEPROM, since I wanted to use hardware PWM and be able to save settings. Interestingly, the PIC16F18313 was the only candidate.
This PIC has only two PWMs, so I can't use it with all four LED drivers. I'll just power the white LED driver with this hardware PWM, and bit bang the remaining three 2 kHz RGB drivers.
A really nice feature of this modern PIC is the preferal pin select, which allows me to programmatically assign functions to pins. This way, I can assign the hardware PWM output to match the existing footprint. The other pins will just be GPIO, so nothing special needed there.
Carefully remove the four screws in the base under the anti-skid rubbery circle
Now that it's apart, probe around and figure out what the chips do and what signals exist at which pins.
Pin 5 of U2 has a 20 kHz PWM signal on it. As the brightness changes, it cycles through 20, 60, and 100 % duty cycle. When the LED is to be off, the pin is held low.
The white LED driver appears to be a switch-mode constant current design. The details of the design are not important here, since we know how to control it.
Pins 2, 3, and 7 have a 2 kHz PWM signal, with duty cycle correlating to the following:
Pin 2: Blue PWM
Pin 3: Red PWM
Pin 7: Green PWM
It is interesting to see that these LEDs use current limiting resistors, with PWM being used as more of a voltage source here. Again, not going to dig in to it because I know how to control it.
Pin 6 changes when the power LED changes. For my version, I won't be using this. In fact, I may even disable this entirely, since I'm not sure why a lamp needs an LED to indicate that it is on.
Pin 4 is pulled low when the shroud is touched, so is the input from the cap sense interface chip, U5. Again, the implementation doesn't matter, all we care about is the signal.
interestingly, I just stumbled across this project and I own the exact same lamp. I'm looking to replace the IC with an ESP8266 running the awesome WLED software while preserving the touch feature. From your experience, do you think that's feasible? What's the voltage that the IC and the sensor use? Thanks!
I have the same lamp and agree that the interface is terrible. I would like to do something similar, but I'm fairly new to electronics / makering. Would it be possible to do something like this by swapping out the entire PCB with a Raspberry Pi Zero? Presumably you'd need to add a capacitive sensor?
AHHH! That is so cool! Thank you so much for sharing! I bought a few touch sensors but then let in languish. I need to dust it off and give it another go!
I suspect that I'll need to dust off the ol' oscilloscope and/or eyeball those images in detail, because the repo in question is unmaintained. I *was* thinking of using an esp32-h2 for ZigBee, until I saw how unattainable/expensive they were (also, no wifi), but am thinking about the esp32-c3 as a replacement. Since it's plugged in, we're not *terribly* concerned about power consumption.
As much as I hate writing from scratch, I likely *will* because I don't find the terms of gpl3 palatable. MIT/BSD/Apache are all much better suited to me ^_^
Hey Joel,
interestingly, I just stumbled across this project and I own the exact same lamp. I'm looking to replace the IC with an ESP8266 running the awesome WLED software while preserving the touch feature. From your experience, do you think that's feasible? What's the voltage that the IC and the sensor use? Thanks!