If you're reading these logs for substantial updates about the project, you can safely skip this one. The parts for the mk2 rev1 board arrived today, but the PCBs won't be here until mid-next-week. I haven't had much motivation to work on software this week, but I've instead been thinking about the hardware and actual construction of the watch

Display

In the past few updates I've been designing around a 2.13" flexible epaper display, in place of the 1.8" memory LCD, and the mk2 board that's arriving next week has connections for that display. However, I've become increasingly disillusioned with the epaper for two reasons. First, the size. The epaper is substantially larger than the memory LCD, but the resolution is much lower. The epaper has an active area of 23.71 x 48.55 mm, with a resolution of 122 x 250 pixels. The memory LCD, by contrast, has an active area of 27.60 x 36.36 mm and 230 x 303 pixels. This means that the epaper results in a chunkier watch with less resolution. The tradeoff is that the epaper provides a nicer contrast and a pleasant matte surface, but after playing with a few 3D-printed prototypes, I just can't get over how chunky the watch feels.

Beyond the size and resolution, though, is the power consumption. As mentioned at the tail of the last update, updating the epaper at a rate of 1 Hz gives, according to the datasheet, an average power draw of about 2.4mA. Even bumping that down to an update every minute gives an average current draw for the display of 300uA. By contrast, the memory LCD promises a typical average power draw of just 20uA at a 1 Hz refresh rate. The stated maximum for 1 Hz, according to the datasheet, is just 80uA, substantially less than the best case for the epaper. (note for anyone checking my math: these figures came from table 6-5 in the datasheet, where they're listed in uW at 5V).

Based on these factors, I think that I'll probably go back to the memory LCD after all. A sleeker watch with something like twice the runtime (depending on how much power the rest of the watch uses, of course) seems like a win-win. I'm sure I'll find a use for the epaper in another project, or in a different variant of this one. Luckily, there's not a ton of change to the schematic; both displays run on an SPI bus.

Microcontroller

The title of this project, at time of writing, is "nrf52 SmartWatch." However, I've recently come back to an alternative microcontroller that I had initially dismissed: the Sparkfun Artemis, based on the AmbiQ Apollo3 Blue. I decided on the nrf52840 at the outset of this project because it seemed well-established with lots of library support, and sufficiently low-power to use in a wat ch. The Artemis, though, seems to be equally well supported and, by some estimates, an order of magnitude more power efficient than the nrf52 line. Consumption numbers for the Apollo3 Blue's BLE radio in actual usage (ie, not running 100% duty cycle RX or TX) are hard to find, but this article provides a tantalizing benchmark in the tens of microamps for a BLE connection (as well as a 1uA estimated sleep current). There are a lot of places where that could go up between that idealized example and my project, most notably that those benchmarks are actually from an Apollo2, but anything on that order of magnitude would be great.

One downside to the Artemis is its lack of built-in USB support. A USB to Serial converter like the ft232 or ch340 mostly solves this problem, though that does preclude the possibility of any non-serial USB support (which I was unlikely to include anyways). There are also the standard hazards that come with a less-common chip, though Sparkfun seems to have done a decent job of mitigating those.

I ordered an Artemis dev board to play with.

Even though a lot of the design might change, I'm still excited to put together the mk2 board when it arrives next week. I'm much more confident in this design than the previous one, and I'm hoping to have something to show by next weekend.