This is the first update in quite a while! First, the timeline. I wore the watch daily from the time of my last update until roughly the end of the summer. Then, I accidentally hit my wrist against something and popped the acrylic screen protector free. When I took the watch fully apart to re-seat everything and glue the acrylic piece back in, I discovered that the PCB was significantly rusted and decided to take the opportunity to redesign the case. Then real life got hellishly busy and I did nothing until roughly mid-December. I started wearing the watch daily again some time in January, and haven't had any problems since. Some observations:

Enclosure

The biggest problem with the previous iteration was waterproofing. Since then, I redesigned the enclosure to use an annular snap-fit design instead of cantilevered tabs (check here for a better description than I could write). This means that it's a much tighter fit (it took some pressing in the vice to get everything properly snapped closed), but I've had no trouble with water getting into the watch since I made the change. I also floated a prototype case in a bowl of water overnight (with the snap joint below the waterline) and no water got in, so I'm reasonably confident that it's good enough for daily wear. The other possible point for water to get in is the button bar, so I increased the flange on the flexible TPU part and haven't had a problem.

Battery

There's still a problem that I haven't worked out with the MAX17262 fuel gauge that causes it to always report 35% battery or less, but empirical results don't lie: I'm getting 2.5-3 weeks of use on a single charge, which includes ample flashlight use. I'm pretty pleased with this; I sleep with the watch on, so I can't charge it overnight, but plugging it in for an hour every few weeks is a completely acceptable interruption to my daily routine as far as I'm concerned. I may even be able to extend the life further if I do some aggressive optimization, but I'm not certain it's worth the effort at this point.

Software

I still haven't made a lot of headway as far as the mobile app. Mostly I just haven't had the motivation; I don't actually need any smart watch features. I would like to be able to set the time automatically via my phone to account for RTC drift, but being a few seconds off every now and then is only slightly maddening.

Schematic

Now that I don't think the hardware is going to change much anymore, it seems like I don't have any more excuses to avoid cleaning up the schematic and posting it. I'll try to get that done in the next week or so. The software is also a mess, but I'll try to get that posted as well in case anyone is interested.

If you have questions, leave them in the comments and I'll do my best to answer them!

I've been working on the watch a fair amount, but I realized I've been bad about project logs. So here's a sort of omnibus update:

Highlights

• I've been wearing the watch daily for the last two weeks. Aside from plugging it into the computer to program and debug it, I haven't charged it. The battery reports 58% / 3.9V, and appears to be losing somewhere around 4% per day. Bluetooth is currently not active, so the power draw is primarily from the MCU waking up to redraw the screen once / second, plus the quiescent current of the components and occasional use of the backlight and flashlight.

Mechanical

• The biggest mechanical issue I've had is best evidenced in a picture: 

That's me, having just washed my hands. The cloudiness you see is not, unfortunately, a trick of the light, but a bit of water that got in (presumably through the flashlight hole) and stuck between the acrylic protector and the screen. Luckily this didn't damage anything, and eventually it cleared up on its own.  It did, however, demonstrate the need for something a little more robust than a hole with an LED poking out.

Adding a small protrusion for the light turned out not to impact the aesthetics nearly as much as I'd expected. I cut a small circle of clear acrylic and sealed it into the hole with a healthy drip of superglue, and I haven't had water issues on that side since. I do occasionally get a bit of water seeping in around the white button bar on the other side of the watch if I'm not careful, so the next revision of the case will likely include a better buffer there (or perhaps just make the TPU fit more snugly to keep water out). I don't need the watch to be fully submersible or waterproof, but it needs to be able to stand up to handwashing without damage.

Thermal

• This definitely could have gone in a different section, but I didn't want to pass up the opportunity to have a "thermal" update.  In a previous revision, running the flashlight LED for more than 15 seconds or so melted the solder joint on its current-limiting resistor. I'm not sure what I did differently this time (maybe there was a short in that revision?), but I can run the flashlight for a minute or more without any noticeable thermal effects. It's still plenty bright, and extremely useful to have on hand (pun intended).

Electrical

• No changes to the electronics in a while, except for moving everything over to a new PCB (same revision) when I finally tracked down an issue to a trace that I'd inadvertently cut at some point.
• As I've started implementing a real UI (see below), I've noticed that I need debouncing caps on the buttons. The bounce I'm seeing isn't awful, so this is a "when I do the next rev" change rather than a "why I do the next rev" change.
• The vibration motor isn't working in the version of the watch I'm wearing. It's worked in previous iterations, so I think there must be a short. I'm away from my bench this week, but I'll investigate more at some point.

Bootloader

• I hadn't updated the bootloader in a long while, but I noticed in the latest release of the Adafruit nRF52 bootloader, they fixed a bug that reportedly caused firmware updates to fail sometimes. That's a behavior I've seen a fair amount, but not at all since I updated :)
• I'm considering abandoning my custom fork of the Adafruit bootloader (no code changes other than a custom board definition) and instead using the stock version with some compiler directives to change the USB name and ID. More on that if I do it, but it's low priority since USB ID is really just a vanity thing.

Firmware

• I've started developing a UI framework for the watch. The core concept is the idea of a "view". From the code comment:

  /*
   * Views are the primary UI structure. A view is a bit like an "app" on a
   * smartphone. The active view's draw() method is called (by the system
   * controller object) when the screen updates, and when user events happen (like
   * button presses), the active view handles them.
   *
   * Inactive views still get their update method called, but they are not drawn.
   *
   * Views can create child views, then add them with sys->switchToNewView()
   * The system is responsible for `delete`ing views when they exit.
   */

(I will note I haven't actually done anything with the `update()` but yet, and may remove it. We'll see.)

A good example of a View is WatchFace, which is the "home" view (it, unsurprisingly, shows the time and date). Near the bottom of that file is a hacked-together main menu view, which is created and drawn when one of the buttons is pressed from the watch face. Menu is its own view type, and I'm making heavy use of C++ lambdas to populate it. I'm sure I won't regret this at all, and it won't come back to bite me. Various menus will probably eventually be encapsulated in their own source files (and thus maybe use statically-defined functions rather than lambdas), but this is fine for now.

I'm pretty happy with the concept of views and the "View Stack" (exactly what it sounds like), which should give me enough of a framework to be useful without constraining what I can do when I start getting BLE notifications.

• To make views work, I've basically implemented my own event handling and dispatch system. It seems to work fine, except that button press events (which are currently the only kind) are handled within ISRs. This so far hasn't been a problem, but it does somewhat limit what I can do on a button press. I will probably eventually move to deferred interrupt handling, but not until I have to.
• I've started working on BLE, using an nrf52840 dev board and my android phone rather than flash unknown code onto my wrist. It's going well, but nothing worth putting on the watch yet. I'm learning more than I ever wanted to know about BLE and HID, though. Specifically, it seems as though android forces a relatively quick connection interval when your peripheral device uses an HID profile. I'd hoped to use HID Consumer Keys for play/pause and similar, but since a small connection interval means more wakeups and more transmit power, I think I'll likely abandon HID and do play/pause using a companion app. I would still like to have the ability to turn on HID, to use the watch as a "clicker" to advance slides, so I'll need to investigate that more.
• I'm very curious to see what BLE does to my battery life. Roughly 4% of the 500mAh battery used per day translates to an average current draw of ( (0.04*0.5) / 24) = 833uA which is.... fine? This is a very coarse estimate and I'll do more power profiling once I have a featureset worth optimizing, but I am hoping to get the draw down to at most half that.... and I still have to add in BLE rx/tx. I'm also curious how much is the flashlight/backlight; if my math is right, running the flashlight draws about 1.25A, and even 30 seconds of that per day would account for half of my estimated draw. We'll see, I suppose.

I'll try to post more frequent updates as time and life allow. Thanks for all the comments and suggestions; keep them coming!

As usual, pictures first:

The project is slowly moving again! The reason for the long time between updates is primarily that rev. 5 didn't work, I got discouraged, and I stopped working on it for a while. Pictured, jammed into the case, is rev. 6, which has a few improvements:

1. An IPX8 splashproof USB port. This took some fidgeting to get the fit right, but now the USB port is (theoretically) resistant to splashes coming in to the USB port. This lets me leave the watch on while I wash my hands without worrying. The bottom of the case is still snap-fit PLA without an O-ring, so the whole thing is almost certainly not actually waterproof.
2. The flashlight system has been massively simplified. The MOSFET is now on the main board, with just two holes to solder wires in. Only the LED and its resistor are on the daughterboard, which is mounted in the side of the case, and they're connected using some thin wires that I pulled out from a deconstructed ethernet cable.
3. I've (at least temporarily) given up on buttons on the hand side of the watch. In addition to overcomplicating the internal wiring, they also just don't look good.

The flashlight feature is stupidly bright. At full brightness, it's significantly brighter than my cell phone's "flashlight" feature. After using it to navigate around my dark bedroom at night, I may have to dial it back just so I don't blind myself. It also draws somewhere around an amp, which is not a great thing to do with a 500mAh battery (a 2C draw). It also gets extremely hot; I'm hesitant to leave it on for more than 30 seconds at a time for fear of melting the solder joint. This explains why the breakout boards available for the XM-L2 are chunks of aluminum bigger than my watch itself... the next revision will probably use an aluminum daughterboard PCB that can act as a heatsink, and the final form for the watch might involve a machined aluminum case rather than the 3D printed version.

The flashlight mounting also needs some work. The XM-L2 lens isn't, as I initially thought, hard plastic. It's soft, and I managed to mar it with the tip of my tweezers when I was trying to mount it. It still works, but it doesn't look great.

The remaining question is battery life. I haven't done any profiling on a rev. 6 board yet (it's a pain to take in and out of the case, so I plan to assemble a second one for testing at some point). My empirical testing has so far indicated that battery life is pretty decent; I've been wearing it nonstop since Thursday evening (when these pictures were taken) without charging it. It's now Saturday afternoon, and the MAX17262 reports 94% remaining (which I don't especially trust), and a battery voltage of 4.0V (which I do), down from 4.2V at full charge.

Now that the watch basically works mechanically, it's time to turn to software. The next few updates, whenever they are, will likely be focused on the watch UI and/or the mobile app rather than the hardware. If I get a good power profiling setup, I may focus on some power optimization too.

After wearing the watch for about a week, I plugged it in to upload some new firmware and immediately started having issues with the built-in USB connection on the chip. My suspicion is that the ESD fairy struck again, this time damaging the MCU rather than a power system.  Rev. 5 (and rev. 5.1, which is identical except for adding pads for a current shunt resistor so I can more accurately measure power consumption) includes ESD protection in the form of a TVS diode, so I think I'll take a break for a week or so until the new boards and parts come in rather than continue to destroy components every few days.

The good news: in wearing the watch for a week, I've found that it draws about 8% of the battery per day. This is an extremely rough estimate, but (assuming I can trust the readings from the MAX17252, which I'm not sure of) is a promising sign: that points to an average ~200 uA consumption, pre-battery-optimization but also pre-BLE-enable. I did manage to get ahold of an oscilloscope, so when rev. 5 comes in I'll be able to get much more accurate consumption numbers.

Small update tonight: I just finished routing the rev. 5 PCB for the watch, which has a few small but notable improvements:

• A TVS diode array protecting the USB power and data lines. After a pile of clean laundry killed a voltage regulator last night, I had the realization that most, if not all, of my inexplicable power system failures could be explained by ESD events. Hopefully, rev. 5 won't have that problem.
• Instead of hard-wiring the enable pin on the 5V boost converter that drives the display, it's not controlled by the MCU. I also added a schottkey diode pair that drives the display with the higher of VIN (the battery) and +5V (the regulator). Experimentation shows that the display will function fine until the mid-3-volts range, and the 5V boost converter draws 90uA quiescent while enabled. As long as the battery has a voltage that the display is happy with, I can now shut off the boost converter and save those 90uA. This does mean, somewhat amusingly, that I'll actually have to increase the power draw (by turning on the boost converter) when the battery gets low.
• In rev. 4, I had broken out through-hole connectors for VUSB, D+, D-, and GND, in the hopes of later adding some sort of dock. Those holes got in the way, so in rev. 5 I overlaid the USB connector with an FFC connector that could be soldered instead. When I do get around to building a dock, I should be able to remove the USB connector and use an FFC connector to connect to the docking hardware instead. In the meantime, the USB port remains fully functional.
• I replaced the board-to-board AXT[5,6]10124 connector pair (intended for a flexible circuit board holding the flashlight and wrist-side buttons) with a 6-position FFC connector.  Rather than having to wait 3+ weeks to iterate on flexible PCBs for the wrist-side daughterboard, I decided to instead use a short FFC cable to connect to a low-profile rigid circuit board on the wrist side. This may end up adding a fraction of a millimeter to the wrist side of the watch, but the ease of assembly and iteration should more than make up for it. I also found some interesting low-power capacitive sensing options for the wrist-side that I might try. Rather than GPIOs, I broke out the I2C bus and a single GPIO for interrupts. This should give me more options to experiment if my initial ideas don't pan out. (I did consider that I can use two GPIOs as a second I2C bus, but I thought that enabling a second I2C peripheral might draw more power than I need. There are low-power I2C GPIO expanders if I need them).
• I removed the reset button and replaced it with a jumper. I didn't even bother soldering the reset button on the rev.4 board, so I figured I could reclaim the board space and short the jumper with a wire in the rare case that I need to do a hardware reset -- most of the time I use software resets, and my firmware enables the watchdog timer to reset itself after a few minutes in case it gets hard stuck.

I also did a tiny bit of software work to move towards having a real interface. This involved shuffling around a bunch of source files to make PlatformIO's build system happy, but otherwise there's not much to report.

The next few updates will probably be software, since I'll probably get daughterboard and dock prototype board finished tomorrow and sent out for fab over the weekend, then I'll have to wait a week or two before I can start assembling and testing.

Pictures first:

A bunch of good progress. In no particular order:

• I assembled the rev 4 PCB assembled with no apparently showstoppers. I have a few cosmetic / mechanical issues to fix in rev 5, but nothing that prevents me from wearing the watch. I did have a bit of a hard time soldering it, but I blame that on either my solder paste or flux expiring, or on some weird interaction with the black soldermask.
• I modified the memory LCD driver to use hardware SPI instead of bitbanging. In my admittedly unscientific tests, this drops the time for a full screen redraw from ~170ms to ~39ms, approximately a 4x speedup. Most of the CPU awake time is currently spent redrawing the screen, so switching to hardware SPI (which uses DMA) means that the CPU can sleep for this whole process. I don't have a great way of measuring current consumption at the moment (I don't have a scope), so I don't know exactly how much of a power savings this is. I was able to find a Nordic forum post suggesting that the DMA peripheral draws up to 1.5mA when active, but even if that's true, a (1.5mA * 40ms) process that happens once per second is equivalent to a 60uA constant current draw. That's acceptable in my book, if not completely ideal.
•  I was successfully able to interface with the BMA400 accelerometer, which I chose in part for its ability to raise interrupts on single and double taps (while running at ~15uA). I can now double-tap the watch to enable the screen light, which is extremely handy.
• I got the vibration motor working. It's exactly the same circuit as the backlight (with one resistor value changed), so I'm not sure why it didn't work before. I don't currently have a use for it, but it's cool that it works.
• Electrically, the flashlight daughterboard finally works. However, when I mounted it in a prototype case, it made the watch hard to assemble and ruined the aesthetic. It may be back to the drawing board for the flashlight and two buttons mounted to that board. I've found some interesting options to replace the buttons on that side, like a wheel or multiposition switch. Or maybe I'll just forgo buttons entirely on the hand side -- the three buttons under the white TPU bar (on the wrist side) work fine, and I can design an interface that only uses 3 buttons + tap if I need to. I would like to have a fourth mechanical button, though. I need to keep thinking about that.

The little bit of bad news: something weird is going on with the power system. I had two MCP73831's (the battery charger IC) go up in proverbial smoke within an hour of each other a few days ago, on two different revisions of the board. The only things in common were the battery, which may (?) have had a loose lead, and the USB cable. Hopefully it was the battery, and now that I've replaced the lead it'll all be fine. Hopefully.

The work continues! I'm approaching the point where the fact that I have no idea how to write an android app is going to bite me, so good tutorials and examples (especially ones that do BLE things in the background) would be highly appreciated in the comments :)

Good news! I've mostly assembled the rev. 4 board, and it seems to work. The biggest change is a boost regulator that drives the LCD at 5V, instead of the previous VIN (which could be as low as the 3V cutoff voltage of the battery). This means that the screen will continue to work even when the battery voltage starts to sag. It comes at a cost -- the TPS60151 is rated at 90uA quiescent current -- but on the whole I think this makes the usable life on a single charge substantially longer (since the whole voltage curve of the battery is usable now). One future optimization might be to use VIN until it sags too low, then enable the boost regulator, but that gain probably isn't worth the complexity.

I say "mostly assembled" because, somehow, I've misplaced my nrf52840 modules. The power systems seem to work, but without disassembling my rev3 prototype (which I've been wearing for the past few days), I don't have brains to test the I2C devices. Hopefully those will be delivered this weekend, and I'll be able to have a working rev. 4 watch next week.

In mechanical news: in the months since my last serious work on this project, I bought some differently-sized nozzles for my 3D printer. This means that I can print the case with an 0.2mm nozzle rather than the 0.4mm stock nozzle and get some much finer details. This lets me cut a little bit of thickness out of the watch! The prototype I'm wearing is 13.00mm thick, and I may be able to cut most of another millimeter off if I figure out a safe way to press the LCD directly against the protective acrylic. 13mm definitely doesn't feel too big, though.

More updates soon. I'm glad to be back at work on the watch!

Good news! Two apparently-intact displays arrived from Digikey today! I'll need a few days to get the rest of the project out of storage and load the project state back into my head, but at long last the project can continue!

Interestingly, these new displays don't have the "NO OPTICAL BONDING" sticker on them. I wonder if this means that I can press them right up against the acrylic... I'll have to find out.

I guess I'll see y'all next year!