 Hi, welcome to my project I've been working on for almost a year now. It's an open source smartwatch where the application is built. So what this talk is about is what you see here. It's a little bit about what Zedas watch is. Some background about the project, why I built it. And then we will go into more details about the hardware, the hardware selection, software applications for the watch. First a little bit about me. I'm an embedded developer. I've been at Ublocks for about six years now. Working lately with Zephyr slash NRF Connect on Nordic MCUs. Privately, I tend to do a lot of hobby projects. I always have some projects running on the side. Often including mechanical design and 3D printing, and of course programming. It's fun when things move, right? Often I've been using the ESP32, but not for this project. So what is Zedas watch? It's called Zedas watch because it's a lack of imagination from my side. All smartwatch names I could think of was already taken. What inspired the name was the ZMK project, the Zephyr mechanical keyboard. So I kind of copied the naming scheme from that one. And the hardware. So the project contains all the Kaiket files for the PCB, the casing, the mechanical case, the files for that. I've made a dock, and of course the full bomb. On the software side, there is the Zephyr-based application. And the applications that run on the watch also as part of this application. So here on the right you can see the different parts. The PCB, the casing, the display, the vibration motor and so on. So first some background. So why build a smartwatch? And this is why. And it's a long story, or actually it's quite short. And everyone keeps telling you that this is the end of all your free time. You will not have any time to work on any hobby projects anymore. And what happens next is you have a small panic attack because what to do now. So you have to come up with a master plan, how to solve this. And somewhere in the back of my head, I thought that maybe there is like one hour or two every now and then, which I could use to work on some project. And eventually this is why I ended up building the smartwatch. Because it's a good foundation and you can have a lot of features. I didn't want to have to think about what to implement. Let's say you have one or two hours. I don't want to sit down for one hour and think of what feature I want to implement. If you do a smartwatch, you just look at what does our smartwatches do. And I will just copy the same features. So let's save some time. And if I don't want to do that, then I can sit down and maybe come up with something new. I don't know. Endless of possibilities. And lots of late nights later, actually nine months later. Vers a baby and an open source smartwatch. And that's the story behind it. Okay, so let's move on and get into more details about the zipper part of the smartwatch. So I had some requirements. Then being BLE, of course, because you want to have a continuous connection with your phone. And it has to be low power because smartwatch, you don't want to have to recharge it every day. You want it to run for at least a week and maybe even more. And I needed like an MCU and the ecosystem that would help me to not having to reinvent the wheel. I had this limited time, like nine months, so I didn't have time to write everything. And something with a big ecosystem. And that's where Nordic MCUs for their low power. And that I've had experience working with them before in work. I didn't want to add another thing that I was not familiar with for this project. Noripa Zephyr. Obvious, all my requirements are met. And some extra nice features, I think, from using Zephyr, which is, from what I know, is quite unique for this ecosystem. I can say that everything is completely open source. So everything from the highest level application in my software, like a flashlight application, down to the lowest level radio code. Thanks to the open source Bluetooth controller, that's part of Zephyr. I think this is quite cool. So now some things about the hardware. And Zephyr played a big part in selecting the hardware for my project. Mostly because of the small or short time frame, where I really wanted to have most of the foundation done by the nine months. Hence I really had to optimize the selection of the components. So I didn't have time to write too many drivers. I needed drivers that were already implemented and known to work. I also didn't have time to sit down and debug I2C buses for errors and so on. Because you know the hours they just fly by when you dig down into that. And actually how I selected most of the components on my watch, was by browsing the driver's directory in Zephyr. And this is quite nice because it's huge, as you know. And you're browsing around, finding what features the sensors had implemented in Zephyr and what they could do when I came down to the ones I have right now. And also my PCB design knowledge was not too big. This is actually the first one I've done. So I tried to stay with ICs that were easy to use and didn't require a lot of external components. So I tried ICs that did everything internally. And also because of the limited PCB size, this was kind of a trade-off between the size of the ICs I would use and the solderability, because I would be hand-soldering everything. So all of this was kind of a trade-off also. So what did I end up with? So I eventually did two versions of my smartwatch, where the first version did work really good, actually. Just some small patches. This was the foundation for most of the software development I've done for the smartwatch. It features the NRF 52833, which I eventually grew out of because both RAM and the flash was completely filled at the end. As soon as you do like UIs and things like this, it will just eat up flash and also there's not a lot of RAM on it. Which then I ended up with the version 2 where I upgraded pretty much everything. So it features the NRF 5340 with much more RAM and flash. And I kind of reworked a lot of parts to make it easier to build up and solder. Or the software features, hardware features for my version 2, which is also the latest version I have. As I said, the NRF 5340, SVMCU, BMI 688, and RAM mental sensor, which can do air quality measurements and you can even deploy some AI models or something on it to kind of smell. Nothing I've tried out, but it's there. And you can do whatever you want with it. I've added a magnetometer. I don't know why actually because does anyone use the compass app on your watches? But I had some extra space so I threw it in because why not? And also this pressure sensor which I think is quite nice. It can detect like 20 centimeters or something changing air pressure. So it could be used for some cool software features. An IMU for extra meter and gyro for gesture detection and things like this. Also nice with this IMU is that it has some gesture detection built in which saves me some time so I don't have to implement that also. And a capacitive touch screen, circular, 240 x 240 pixels. And lastly a haptics vibration driver for the vibration motor to get some nice haptic feedback on the watch. And also versus Pulse Oximeter and Heart Rate Sensor which is there, it works. You can redraw data from it but I have no algorithm for it because it turns out it's quite complicated to get all of that working and combine, you need to combine it with Vaxelometer movings and all of that so I just haven't focused on that. And also it made the mechanical casing design a bit harder because it sits on the bottom side. So for now I haven't mounted it on the watches I've built as of now. Okay, some conclusions from selecting driver sensors from Sefer driver's directory and I think it would be good if more vendors kind of provided more official driver support of Sefer because it's growing fast and with Nordic they're quite huge also so I think it's a good selling point for some vendors to provide more official drivers because right now there's a lot of drivers community maintain but they, at least the ones I have been working with kind of lacks more of advanced features from the sensors. So in the end actually I ended up porting for a box sensors their box libraries to Sefer instead. Ideal of a good best way would have been to update the drivers in Sefer but I just didn't have time for that. And also I learned the ship shortage was a pain so I feel the pain from the hardware engineers at my work and I had to do free redesigns because of, yeah, you know, components just you can't buy them anymore. Okay, so onto the software. So now it's time to bring the hardware to life with Sefer. So first thing, you will meet this, this, the device tree. And what you will do for the hardware bring up will create the board, the ZS watch board based on the NRF340DK you'll add like one sensor at a time so the hardware specifics for the ZS watch and you get this a lot of times at least if you're me but eventually you fix this small typo and you iterate until you have all the sensors and all of your components brought up. Yeah, eventually it's all working and your hardware is fine and this is actually true story. I think kind of worked on the first try which is nice for me. Yep, like I said, jokes aside. It was quite smooth and if you've been working with the device tree since before it's quite nice. It's a steep learning curve I would say but this is passed in the past now so it was smooth for this project. Okay, moving on to the actual software. So my idea for the architecture was to kind of keep everything as clean as possible so I wanted to separate files as much as possible so that like a module based software is not anything new but it's something I wanted. So it took heavy use of the SysInit macros from Zephyr and tried to separate all like have no dependencies between all of my C files. I'm using the Z-Bus, the Sephyr messaging bus for all the communications within the application and for propagating data. And as much, I tried to separate the code as much as possible so anything that could be made as a kind of standalone application for the watch I tried to separate that from everything else. It's like settings and all of that. It's just, it's a separate chunk of C files. We've not too much dependencies to the rest of the system. Okay, so a little bit about how I've designed the smartwatch architecture. So the base of all of it is the Z-Bus which propagates the data between all of the different modules in the watch. So for example you have the charging manager. All it does is to look for when the charger is plugged in. When that happens versus an event published on the bus and whoever listens on it can act on it. And like the battery manager will sample the battery periodically and publish these samples or slash measurements to the Z-Bus. And the communication from the phone. This is for example a notification from the phone and this is sent to the watch. The communication manager will publish this to the bus and subscribers can, or listeners actually can act on it. Then you have power manager which handles kind of to keep the power consumption down when the watch is in idle and then you have apps and things like this that also listen on the bus to act on things like gestures and extra meter movement and things like this. So moving on to low power. For me low power was very important for my watch. So I tried to get everything from the hardware at first to be capable of being really low power, but you also need to take many considerations for software to keep power consumption down. And for the watch, the main kind of contributor to high power consumption is the display. It consumes a lot of power so it's 60 milliamps at full brightness. So it's important to keep the display off as much as possible. So this is just a simple example how like the wake up works and that is you have the power manager which will look for idle time out. So for example after 40 seconds I have right now the watch will go into an idle state and turn off the display and there will be an event sent on the Z-bus that we are now entering low power mode and everyone that can act on this in the system. And then you have the IMU so when you do the wrist wake up gesture versus an event sent and the system can wake up. And with Safari this is super easy to do with power management APIs. So I have two options. Either I can cut power to the display in the touch ship and then they will consume literally zero microamps because I have a separate 3.3 volts regulator powering these parts of the watch or I can put them into sleep mode and this is a trade off between power consumption when the watch is idle and the wake up time from like the sleep mode to active mode. There is like almost one second of lag when you boot the display for example from the power off. And you have the Siffer regulator APIs which makes all of this quite simple to use. Ja, and there was also another thing that I had that I had to take into consideration when you have many standalone things in the system and that is let's assume you have ten different modules that needs to do something periodically like once per second and all of them will kind of use delayed work to do this independently when you end up with ten wake ups per second which could be eliminated to just one in actually so this is something I've implemented to kind of save additional power. Ja, so my solution is kind of to split it into different you have like slow events, medium events and fast events and the modules can subscribe, listen on these events on the bus. Ja, so this is the power consumption measure right now you get around maybe eight days with the display in the more power consuming mode where it just goes down to sleep mode and if you disable regulator the PCB and the hardware can go into a quite nice low power mode and it's also super easy to break the power consumption when you do some coding and then you make a small change and then everything consumes a lot of power so this is something I need to add like some kind of way of automatically measuring the power consumption so I don't break it all the time. Ok, so moving on to the user interface user interface is quite important for at least for non-technical people because when they have a smartwatch all they care about is what they see on their wrist and the smartwatch is what they see that's the UI so for UI I'm using LVGL which is a super great UI library for embedded devices it supports everything I could imagine it has like features that I didn't think you could do on embedded features that I expected only to have on desktop UI frameworks and it also takes care of button navigation and through the LVGL case scan port it also takes care of the touch input on the display so here on the right you can see kind of at least what the watch face looked like a few weeks ago and all of this was quite simple to build with LVGL because it has like widgets for these round things that you can just tell it to what percentage should be filled and all of that Ok, so moving on to applications or apps within the watch what you see here is what I call the application picker so it's just a long list of all applications currently on the watch and this is where you launch apps from here's just some examples of what some apps I have right now so you can control music on your phone for example and you can watch the battery status I made it kind of a settings system that can automatically fill in the UI depending on a list of settings and settings types of course you can have notifications on your pop up notifications you can see in the middle one not looking too fantastic but it's all work in progress just a small demo of the responsiveness of the touch so you can see it's not perfect but it's pretty good there's more work to be done to further optimize the LVGL port of LVGL port and other things and you can also do swipes and gestures on the watch face to quickly enter a specific app and so on which is quite handy to not have to go through the application picker ok, so some basic about applications in the watch so I tried to keep it super simple so an application is just this struct you have a start function, stop function you have a name and an icon the name and icon is what you see the application picker upright so this is what will be populated here and each application have to call the application manager at application through the sysinnet macro so each application kind of adds themselves to the system so I thought it would be a fun idea to let's create an app here to see how it's done so let's save our requirements and show the suffer logo and when the screen is touched or a button is pressed we will rotate it and the first thing we need to do to do that is we need to find an icon for the application manager in this size we need to find the suffer project logo which we will be rotating and we just use the online tool from LVGL to convert these images to C files and then we put it in the images folder ok, so what we need first we create a folder for the new application we will be creating the ZDS, so suffer developer summit app we need a CMake file, just compile everything here the actual application that you can see here is populating the struct with the app name and icons and the start and stop functions and you can see this is initializing or adding this application to the picker then we have the UI, we need a header file for that so my idea was to separate the logic from the UI so this makes it easier to keep it separated and it also allows to run the UI easier on a desktop simulator for LVGL and in the UI we will create the icons or the images that we will be rotating we will add a button and add listeners to those to handle the rotation so in the button pressed we just rotate the image a bit and this is what we get so you can see the ZDS entry in the application picker with the suffer kite icon and if you press on the screen you will see the logo is rotated and we can also extend the application for example if we are interested in events from the IMU for example if the users wiggle their wrist we can listen on that event and when that happens we can reset the rotation back to original on the suffer project logo so this is kind of how you would do that and our application can also listen on power events so when we are going into inactive and active state in case the application is doing something that keeps the watch awake then we can the application or whoever wants to listen to those events can handle that accordingly and all of this is done you use the ZBUS listener macros to add callbacks for these events and also thanks to suffer and all of the magic behind the scenes you can run it on linux you throw the native POSIX port using STL for the display window and actually you can also have the Bluetooth up and running using the HCI USB sample on any development kit or development board that's supported and all of this just works out of the box in linux you just plug in the USB sample and it's detected automatically and this was super nice I postponed this for a while because I thought it would be a lot of work but in then it was just one night and everything just worked just some small changes I had to do in the application and some things to get ability working and a small change in the display STL because if you have a high resolution screen you get the 240 by 240 window which is super small but there are some handy functions in STL to just upscale the window so it saves a lot of time not having to reflash all the time and it allows anyone to kind of play around with the ZS Watch software on their own desktop computer this is just a small demo of it up and running you can see through the STL port you can get user input you can navigate around the system and all of that works and here we have the app we just created and we can click on the screen and it will rotate the logo and we can also see that since I have Bluetooth up and working in a second you can send receive notifications from your phone here and they will pop up on the screen ok part of this project is also that I've made a dock so you can easily program the watch easily charge it through USB cable so the dock exposes the GPIs you need power and programming pins and one additional GPI that could be used for anything you'd like right now I'm also working on a different kind of dock version without a debugger because that requires a license and yet you can only get from me and so on so there will be another release of the dock soon which without the debugger capabilities and some small fixes so the idea is you just put the watch on top of it and it just works for the casing it's a 3D printed case it's not 100% yet but it works pretty good but you can always improve and actually one of the biggest hurdles in this project was this connector to the dock so I've been thinking for months trying to find somewhere I wanted some magnetic pogo pin connector but it was really hard to find something that was also very low profile because I didn't want to make the watch too thick just because of it I picked a super simple solution and found a low profile pin header which is like 2 mm high for the communication with the phone I'm using also an open source application the gadget bridge app which is an application for people that don't want to use like Samsung apps or Google apps or Huawei apps for wearable devices and this one supports a lot of smartwatches from other smartwatches and what I do here is to just fake being another supporter smartwatch in the gadget bridge app and it will automatically just send me everything I need and it just works out of the box and it also has a lot of features that I have not yet utilized on my watch ok, so how much will it set you back somewhere around 120 dollars is the full bum for the hardware which I think is quite affordable from what you get and the dock is super cheap just a two layer PCB with a few components and what's next for the project I'm not sure I will see but some ideas I have at least right now is to improve the LVGL port and suffer because it's not handling double buffering display rendering correctly so even if you use turn on double buffering it's actually not utilizing it so there's no performance gain from turning it on so I think this will help a lot with to get even more responsiveness in the UI I want also to improve the native post export because it was at one evening hack and so there's some more cleanup to do to get all the edge cases to work and also I found this new sensing subsystem I think for suffer I think this would be a good fit where you have many modules that wants to read from the same sensor and I think this is all handled as part of this new subsystem and then some more rework and more improvements for the power consumption to get even more battery life out of it and lastly some hardware changes that would be nice to use the PMIC that way I can eliminate a few components on the PCB and I think it will make room for an external flash chip also and in the future it would be nice to even crank more power and use the new NR54 H20 chip maybe it seems quite nice and powerful and I'll also even more use cases for the watch so conclusions this wouldn't be possible without the big ecosystem as suffer with a lot of good documentation lot of samples and a lot of code already in place so I could really focus on my application and not all of the layers below it and I also learned that I should have done the post-export a long time ago probably saved me a lot of time but you learn and also some additional bonus because of the hardware have quite a few sensors so if you just don't mount the display and the vibration motor you have quite nice powerful low power board for sensors that could be used for anything yeah and that's it and you can find all of it on this github page and all the documentation and so on feel free to contact me if you have any questions and we can also do first questions in here we can take them now yes always I'm the main tester of it yep sorry okay, so what happens if my app crashes yeah, right now so if it crashes I'm keeping the clock in RAM retention so if it crashes it's still there so that's how I keep the time right now and when the watch wakes up the phone application will automatically connect to the watch and also send the latest time information so the clock is kind of almost always correctly there's no clock in the watch so it's just using the internal clocks on the Nordic chip MCU so it will drift for me you always have your phone on you and if you send an updated time like every now and then you will not drift away too much yes so the question about if I would consider using a GPS within the watch and I thought about this and because I've designed this for me and what I wanted and I didn't want a GPS because I always have a phone on me so I didn't see the need of a GPS with just more complexity and more code and more things that consume power yep, so about the power consumption was asked and if my measurements were real life measurements or calculated and the answer is that they are measurements based on my usage for a day and I could see that I had the screen on for about 3% of the day so it's kind of calculated but depending on the bugs in my code the power consumption will move up and down during my development because I keep breaking it it's super easy yes mostly software about the time spent on the project most of the time I spent on software development there were some startup time that took to learn the PCB design but I would say maybe one month with PCB design and then like ten months of software so in the back if there's a guide how to build it yes partly but also partly not so if there's interest I will spend more time on it but as my time is limited I'm just doing what I feel is most fun at that moment but if there's interest then that's fun and then I will do that you can get in touch but all of the files is there and I'm thinking of maybe ordering some prototype assembled boards because it's not fun to hand solder and it takes hours and small yes I need to recompile the project for each application yes I think there's always a way for most things it's about time and effort I think you can dynamically link in apps maybe I haven't looked into it but maybe if someone is good in those parts of software then let me know yes yeah that's something I my plan if I have more kids I'm not thinking about that right now so I'm living happily as is okay I think the time is up so if you have any questions we can do it afterwards yeah we can take a moment and thank you for the presentation thank you