MDBT42Q Clock & Watch Projects

Posted on
  • 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!


    2 Attachments

    • 8SYkgRf%SoSlIuHOLN73IA_thumb_38f8.jpg
    • UNADJUSTEDNONRAW_thumb_38f0.jpg
  • After making the handheld, I got distracted by discovering DL1414/DL2416 "intelligent" LED displays. These things are cool! Originally made by Litronix, HP and Siemens in the 1970s as 4-character 16-segment alphanumeric displays, their descendants are still being made today, in the same form factor with similar part numbers, as 4 x 5x7 LED matrix displays. What makes them "intelligent" is the fact that you write 7-bit ASCII character codes to them, rather than having to worry about scanning through individual segments and digits.

    My favorite thing about the 2416 display in particular is that it has the same pin row distance, and almost the same # of pins, as the Espruino MDBT42Q breakout - so you can attach the two directly! Okay not quite - I had to bend & re-route the display GND pin around the board with a bodge wire. Though not necessary, I also decided to bend the display's VCC pin to attach to the BAT voltage instead of 3v3, since the higher LiPo voltage gives the display a bit more brightness. All pretty easy, and you end up with a tiny computer + retro display (see photos)!

    I've been testing the displays (1980s? era NOS/reclaimed units from eBay, ~$20) using this simple Arduino library I found on Github:­library - and it was pretty easy to port it to a Javascript module for use with Espruino. I'll clean up the code this week and publish it on my Github with an open license. I also want to write a "scroll" function for longer messages.

    The whole thing comes out so small that I should (theoretically) have no problem fitting it into a case with a couple of buttons (only a few GPIO pins left...) and making a little retro watch out of the thing. I'm still trying to figure out the best battery + power management arrangement, the little Adafruit Micro Lipo charger I'm using, while small, may be too bulky unless I snip off the JST connector. More to come...

    Wishing you all health and safety, and a good project to work on, during these weird times.

    3 Attachments

    • UNADJUSTEDNONRAW_thumb_39b2.jpg
    • 5BNm3yBJQ5+QEvaqviDrng_thumb_39ba.jpg
    • oCdYkymLT4WmeDeYYjxK7A_thumb_39b9.jpg
  • Mon 2020.03.23

    Nicely done write up and a super tidy, clean, compact solution Dan.

    To understand how the following comment relates, one needs perspective of all the large the stuff we had up through the seventies, prior to the Japanese designing it all smaller. Think reel-to-reel recorder before the introduction of the Sony Walkman. (maybe some of you wont even know what that is, should you be born pre Smart Phone era!)

    Reminded me of an extremely funny 1979 movie scene (yes I saw it back then) of the
    Steven Spielberg comedy '1941' staring John Belushi where the submarine is forced to dive, and the Japanese mariner commenting in frustration in the attempt to take his tube radio below deck, as the closing hatch is too small. Hilarious! Eye opening remark epiphany, considering the explosion of miniturization that had just started. Couldn't find a YouTube link, but did find a reference:

    'Also the Japanese sailor trying to fit an enormous radio down the submarine hatch.'
    "We've got to figure out how to make these things smaller!"­ilm/NineteenFortyOne
    halfway down the page

    That last image in post #2 gave me another alternative to the discussion we recently had, powering the Puck:­520/

    Note to @Gordon, envision the future MDBT50Q having an extended scored break-off tab containing the LiPo charger built in, sans un-necessary parts for projects like @dandelany created above.

  • Nice - thanks! You could definitely improve the Sharp Memory LCD library by the look of it - I don't have time to try an actual one here, but changing this in the existing library should work:

      g.flip = function () {
        digitalWrite(cs,1); // CS on
        spi.write([0b00000001,1]); // update, 1st row
        var w = g.getWidth()>>3, h = g.getHeight();
        for (var y=0;y<h;y++)
          spi.write(new Uint8Array(g.buffer,y*w,w),[0,y+2]); // pad and do 2nd row
        digitalWrite(cs,0); // CS off

    Also any calls to spi.send could be spi.write - it doesn't try and read data so it never has to allocate anywhere to put the received data.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

MDBT42Q Clock & Watch Projects

Posted by Avatar for dandelany @dandelany