Hi! I've been keeping myself busy playing with the MDBT42Q breakout - in particular, working on a few ideas for watches, clocks and other "ambient" data displays. The low power + flexible voltage regulator on the MDBT42Q breakout make it ideal for things like this. And being able to program it wirelessly is awesome!
I already posted this first project in the "what you're working on" thread, but figured I'd start a new thread where I can keep my notes/questions/related projects together.
My first iteration is this little handheld device using an MDBT42Q + a Sharp Memory LCD + a LiPo/charger and a few buttons. These Memory LCDs are great - super low power, but much faster refresh rates than e-ink are possible. I'd like to eventually make a DIY minimal smartwatch using one of these displays, but figured this was a good way to get started and learn how to use them. More info + build log on this Hackaday page.
I really like having physical buttons on my watches instead of a touchscreen - though these metal tactile buttons from Adafruit are a little big to be side-mounted (and too clicky to be practical on a watch!) I'm ordering a few different types from Digikey to try for the next version.
I'd also like to experiment to find the lowest-power way to keep the LCD running - it needs a pulse on one of its pins every ~1-10 seconds to keep a voltage bias from building up and causing burn-in. Currently this is done with a
setInterval in the Espruino
MemoryLCD library, but it may use less power to tick it using hardware, with a TPL5111 or similar low-power timer, rather than waking up the SoC.
For the most part, things have been working seamlessly and it was a lot of fun to build. The main problem I've run into - though I haven't yet tried hard to solve - is the fact that it takes ~400ms to update my 144x168 memory LCD (LS013B7DH05). I have gotten at least 10-15 FPS with one of these using a Feather board + Arduino library, so I know they're capable of it. I'm guessing this comes from the fact that the
MemoryLCD module calls
spi.send once for every byte of the framebuffer, causing a lot of function-call overhead for each frame. I'll experiment with calling
spi.send with an array containing the whole buffer, or maybe the whole row at least? Any reason why this won't work? Thanks!