Make your favorite watch smart with Ganance

Show Notes

The dynamic duo, Alex & Ian join me from Ganance, where they're bringing fitness metrics to classic watches, combining sensor tech with stylish choices. We dig into the inspiration and ideation process as well as some really technical details with fellow firmware engineer Ian.

Reserve yours at ganance.com

Takeaway these three main bytes:

• Find a partner that can immediately share your vision. It's worth waiting for the right person.
• Data collection and refinement is an ongoing process - so OTA updates are key to continually improve the customer experience.
• Battery life shouldn't be an afterthought! Plan for it from the architecture.

Chapters

00:00 Introduction and Background

01:05 Meeting and Partnership

03:23 Hardware Development and Decision-making

04:35 Iterative Development and Planning

06:16 Target Market and Customer Profile

08:28 Addressing Style and Fashion

10:20 Hardware Components and Communication

12:23 Discussion on Zephyr RTOS

14:22 Tap Detection and Sensor Optimization

16:54 Future Plans and Gen 2 Development

25:09 Architecture and Communication

26:48 Gen 1 and Gen 2 Plans

29:20 Battery Life Optimization

32:12 Business Goals for the New Year

33:30 Partnerships with Watch Brands

34:00 Conclusion and Thank You

Full Transcript

Vigs (00:00) Alright, so I've got Ian and Alex here with me. They're from Ganance. So, thank you guys for joining. To start off, Alex, why don't you tell us a little bit about how you came up with the idea behind it and what it is. Alex Ocampo (00:09) Absolutely. So Ganance is a wearable tech company and we're giving our customers back their personal style and their health data with our slim disc that attaches to the back and underside of your favorite traditional watch. Connects to our mobile app through Bluetooth. And that's how you interact with all the health information you love, steps, active minutes, calories, etc. And the smartwatch functionality like call and text notification, music control, call rejection. Things of that sort to truly make your favorite watch a smartwatch and activity tracker Vigs (00:45) I love that. I was going to put some images up here, but you just, you had the product right there. That was a real smooth demo you did. So cool. How did, how did you and Ian meet, tell me about like, you know, when this all started, how long have you been on this journey? Alex Ocampo (01:00) Yeah, so the product originated was a very personal problem I was looking to solve. I had a watch that my oldest brother gave me for my college graduation. Uh, so very sentimental, very meaningful that, you know, when wearables, Fitbits, Apple watches, et cetera, came out, I stopped wearing my watch because I really do value the data that a lot of these activity trackers provide. And then my oldest brother who gave me that watch, he ended up suffering a health scare that he thankfully survived from. But that event reminded me of this watch and how truly meaningful it was that had been sitting in a box for several years at that point. And that's kind of when I first asked myself the question, like, why can't I have both? Like what do I have to choose between my watch and my data? And, you know, having no background in hardware, I just kind of got after it. Was fortunate enough to find the ML community where, you know, it's the largest hardware innovation space in the country. So any kind of half we work, half manufacturing and prototyping plant where any skillset or machinery that you need to make a prototype is all under one roof. So after getting it, through the early stages of like prototyping and development, I was blessed to find Ian when we needed some firmware, looking for some firmware support and found Ian after interviewing. It must've been at least 15 firmware engineers. I was like, what about one more? Like I had interviewed 15 people like Thursday and Friday. And if I remember correctly, Ian was like, oh, I'm free Tuesday morning. I was like, do I really want to wait two more days? And for the 16th engineer, I'm very happy I waited. I think Ian and I kind of hit it off right away. I think our working styles worked really well. He was the first contractor I've ever. worked with that came in on time and under budget. So that was a positive sign there. So after working in a contract capacity for a few months with Ian, I asked him if he wanted to join me on this journey and get after it together. And thankfully, he said yes. Ian (03:01) Okay. Vigs (03:19) That's so, it's so good to hear that you like did that one extra interview. It's because you just need one, right? It's all about that one. So it doesn't matter how you get it. And it's awesome you guys are able to connect. Ian, from your perspective, when Alex first approached you, you know, what was the current state of the hardware and, you know, going in, did you have an idea of the work that you would be doing? Ian (03:40) Well, I think one of my first steps sitting down with Alex was being like, what are you building? Right? Like it's always asking people. I come from a consulting background and at the time I was kind of looking to leave consulting. I had a lot of kind of big things happen in my life the year before. And so I think the first step was, you know, like figure out what people are building and like, how can I help you build that? How can we build something bigger, better, you know, like more to your style, whatever you're looking for. And I think in the process of learning it, there was a lot of open questions that I like to think that I helped answer. But also in the process of building it, I kind of started to become more and more attached to it as well. So I think that was a good thing, right? Vigs (04:30) Yeah. And how did that journey go? Like as you were building it upfront, did you already know all the features you wanted to support or was it kind of iterated as you went along, you guys with brainstorm ideas and just build it up as it went, how did that go? Ian (04:44) Yeah, I think Alex sort of approached it as a let's build it as we go sort of thing. And I've lived through too many, to put it very politely, train wrecks that have taken that approach, that I'm very much like a let's plan and let's make a list. And I always tell people, you know, make a list of everything you could possibly want, do some like, do some dreaming, right? Do we want to get to the moon? What does this look like? And then bring it back to reality, prioritize it, and then start to draw some lines around, this is what we can realistically do, and this is what that means. And then even further than that, be like, oh, okay, like, let's look at some edge cases and a little bit of, you know, a little bit of the planning and the requirements, and then just like those weird cases, and just give it a little more thought to make sure that what we're building makes sense. Because the worst thing you could do is build a feature, and then it doesn't work for 90% of people because you just didn't think about it. Vigs (05:45) Exactly. Yeah, that's one of the things that I always like stress to my peers. Everyone is like, don't build something that no one wants. Like build whatever that bare minimum is and go find out if people want it before you go and like build the whole thing. Because the last thing you want to do is spend all this time building something. And everyone's like, I don't need this. Like, you're not solving a problem. Um, but that's not you guys. You guys are clearly like found this problem that, um, you know, I want to ask you, Alex, are you. Do you see this as targeting specifically watch into a gift, or do you see this happening at a much larger scale of anyone that owns a nice watch that wants to wear it out and not just wear their fitness watch all the time? Alex Ocampo (06:23) I think the beautiful thing about watches is like how much of a spectrum it is. Like you can have your like hardcore enthusiasts who are super knowledgeable about all the mechanics and the movements that go into it and like that's its own class of like watch lovers but then it's you know someone like myself who you know I don't own expensive watches, I'd like them for the complete kind of an outfit or, you know, they give me the little dose of confidence to put me in the right like mood or mindset because I feel like I'm truly expressing myself, you know, as that's how I want to show up in spaces. So it's everything ranging from your, I think looking at our beta group is an interesting representation where, you know, we have the hundred thousand dollar like. AP perpetual calendar kind of watch. But then we also have, you know, the 20, $30 Casio like watch. So it's, I think we've tapped into this very wide audience of people who just want to, they want to wear the actual device they want to wear, um, with still benefiting from the tech. I think when I was first sort of doing the customer discovery to see if this was, if there was something there. I would ask anyone I saw wearing a wearable two simple questions. And I mean, anyone, whether it was like the barista serving me my coffee or the doctor or nurse kind of giving me my COVID cotton swab. Um, if they're wearing a wearable, I'd ask them, do you like the wearable? And a hundred percent of people said, yes. They're like, Oh, I like seeing my steps. I like the social element. You know, great. Um, my follow-up question was if you could be wearing anything on your wrist, would you be wearing that device? and 100% of people said no. And that to me was like, there's a big gap here. We all like the information that we're getting and the data, but none of us like the vehicle that we're receiving it in. So that to me was like, okay, there's a gap there that we can close. Vigs (08:23) Thank you. Yeah, and I think the thing that I really appreciate about the idea is instead of going for like, say, just like another band or something, you know, maybe without a watch face, you kind of figured out how do we hide this tech underneath something that people are proud to show off. And not just something that like, for example, I have a Fitbit, I barely use it to tell the time, but I really like to track my steps in my sleep. And so that's the primary reason I have it. But I think it looks ugly. And whenever I go out and I'm dressing nice, you know, I don't have expensive watches either, but I've got a brown watch, a black watch, a silver watch and a gold watch. Just to span like the range of outfits, right? None of them are over like 30 to $50. But the point is that I like to express my style through that. And I kind of feel like a dork wearing a Fitbit and a regular watch. I'm like, that's too much. I don't need to be doing that, right? So I think, yeah, you're coming in at a really specific angle. And... I think there's a lot of potential here. I mean, just, I don't know if you have like specific competitors, but just think about the market for Apple Watch bands. Like that's kind of what the market you're in, right? You have people that are trying to express themselves, but for those people, they still have to deal with the Apple Watch itself, like that square kind of brick that doesn't really have a personality. So I think there's a lot of great potential here. So kudos to you for, you know, doing that customer discovery in your day to day life. Alex Ocampo (09:53) Yeah, I think you just explained it great. Your profile is our ideal customer profile. Ian (09:57) Hahaha Vigs (10:01) So Ian, digging more into the hardware side of it, tell me a little bit about what are the different kinds of sensors, what are the microprocessors you guys are using, tell me a little bit about some of those decisions and how you made those decisions. Ian (10:16) Yeah, so we're using a Nordic chip. A lot of things specifically with like processors, it comes down to, well, I inherited some of the hardware to be fair. I wasn't the first on this journey. But a lot of it, when it comes down to processors, I think it comes to developer tools. You know, there's certain ecosystems like ST that they've done with their line. that have extremely friendly developer tools and things that are easy to stand up and a really solid hell, things like that. And I think Nordic is also one. Nordic has really embraced Zephyr. I think Zephyr is, I have a lot of very strong opinions about it, some good, some bad, but I think overall Zephyr is a step forward over what traditional Bluetooth and RTOS development environments is or has been. Yeah, and apart from that, like choosing sensors, things like that, a lot of, a lot of our decision-making process and even going into version two with this, it's a lot of what accuracy of data do we need and do customers need and how do we get that level of accuracy with what we have? Um, I think that sometimes engineers go into things and they want things down to the nanometer precise, um, but. you know, you're the NFL and you're dealing in yards. So I think that a lot of our conversation comes down to that. And then also then further on when you after picking, right, it's also like that cost structure of what can the and that's, you know, where Alex comes in saying this is too expensive, make it cheaper. the cost structure of can we support this, right? Because there's a lot of sensors I would love to put on there, but we cannot sell people hardware for $5,000. That's just not a business. Vigs (12:18) Exactly. It's always about finding that trade off, finding that balance between what are the better known features you want to support for the price that people are willing to pay. So judging by some of the features that you guys mentioned, you guys probably have some sort of an iView, accelerometer, gyroscope. Tell me about some of the other sensors that you guys have kind of decided is worth customers paying for. Ian (12:26) Mm-hmm. Mm-hmm Yeah, so on this version, it's mainly that attempt sensor. And then we kind of get creative. I think one thing, Alex and I had a conversation a while ago. And one thing that was brought up is like, what do we want to be known for? And he was like, what do you want the tech side of this company to be known for? And I said creative engineering. And part of that is like, You know, like we have mindfulness features and in the planning of that is how do we get data out of these mindfulness features that isn't just asking people tons of questions, right? And part of that is just counting how many Bluetooth signals you're around, right? Finding your normal average and are you around 10 times as many as normal? You're probably in a pretty hectic environment, right? Vigs (13:29) Oh Ian (13:30) And things like that. So I think that there's like, there's those sensors, like the IMU, which, which is great and things like that. And then there's other things that we kind of use as well to pool in, to then kind of define our, um, to then be able to define some of these, these metrics or like these goals more of. Vigs (13:49) Yeah, that's, that's a super interesting way to be like a, essentially you're a context of wear wearable, like you're going to be able to know exactly where your user is, are they at home alone with just their AirPods or are they out and about somewhere with a whole bunch of other Bluetooth devices? So that's, that's pretty interesting. Um, I kind of had a similar thought, but with wifi, I know Nordic doesn't have a wifi thing at the moment, but essentially like when you're downtown somewhere, you open up your wifi list. It's just like, is. Ian (14:11) Mm-hmm. Vigs (14:17) overwhelmed with so many different networks, whereas you're at home and there's just like two or three networks, right, depending on where you live. So I think that's a really neat idea to use the existing radio, the Bluetooth radio, and then try to get additional information from that. I think I also saw a demo you guys did where you were able to play and pause music, so doing tap detection using the accelerometer instead of just using it for a step counter. So tell me a little bit about that development. Ian (14:38) Mm-hmm. Vigs (14:46) You know, like, are you guys running some sort of model here? Is it using the accelerometer's built-in functions? Ian (14:52) Yeah, so it's the tap detection is a little bit of a thorn in my side. Alex called it the high five detector. But essentially we use the inbuilt one, but then the other thing we do is, or we're kind of pushing out in our next OTA, is pulling data off the accelerometer and looking for other things. Like is your hand still for... half second leading up to the tap, because one of the big things is people putting on jackets or just day-to-day life. You might flick your wrist, and if you flick your wrist in the right way, that counts as a tap, right? And so because of that, it's sort of like how do we now get rid of all these false positives? And we're sort of on our route there, and it's probably going to be a never-ending journey, but hopefully we can squash the majority of them. So. Vigs (15:35) and. Yeah, I definitely going to be something that it's part of the journey. I don't think it's ever possible to be 100% accurate. But like even to this day, AirPods, right, they have issues all the time where my paws when I'm like, brushing past it, or if I'm putting on a hat. So I think there's, there's a chance of being a very high percent of, you know, regularly, like regular positive confirmations, but you might have a little bit of some false positives here and there. And that's just part of Alex Ocampo (15:52) that. Ian (15:58) No. Vigs (16:21) had a life in development, right? Ian (16:23) Mm-hmm. Yeah, I mean that's true, right? And also, I think with like those false positives, at least if we can get to the point, my goal with most things is get to the point where it's an abnormality, not a commonality. Vigs (16:38) Definitely. Yeah. Okay. Don't think I forgot that you said you had strong opinions about Zephyr. Let's unpack that a little bit. Ian (16:49) Oh, I love to hate Zephyr and this podcast is not nearly long enough for how many rants I've given to my brother about it. But essentially Zephyr is such a good tool because at its core, right, what it's trying to do is it's trying to kind of, it's up kept by the Linux foundation and it's trying to take that same Linux-ian view onto an RTOS, right? Vigs (16:57) Aw man. Ian (17:12) And I think there's such a huge gap for that. Because the traditional RTOS, like free RTOS, like the core free RTOS is only a couple thousand lines of code. But more or less, it's just a very simple scheduler with a couple of linked lists and whatnot added here and there. But Zephyr kind of takes that and goes, OK, well, what if you're using devices? And what if you're using all these other things? And what if you want to configure that? Right? And there's so many good built-in tools with Zephyr. When it comes to just different inbuilt libraries, even around like linked lists and stuff, you could use their inbuilt one or other things like that. But my whole problem with Zephyr is there are so many, there are so many configurations that our configuration file is two, three, 400 lines of configurations. And even now, every once in a while, I'll be doing something. This literally happened a day ago where I was just poking around the code, looking at something and I go, oh, we didn't quite configure this correctly because it has a default configuration. So it just kind of goes under the radar and I go, oh, okay. Well, this needs to be configured. And then from version to version, these configurations just always change and go wild, right? So I think Zephyr is such a great tool for that. Vigs (18:09) Mm-hmm. Ian (18:36) But for me, it almost needs something more like Yocto, where you kind of have more of a set path to configure through or something like that. But then the other thing is debugging it, because then if you have an issue, for example, the device tree, which I think, I don't think I've heard anyone describe the device tree as wonderful, because it gets flat compiled, but they're trying to take that Linuxian dynamic compilation view of it. Um, it just, it doesn't really work. And then they're using Python on top of C. Um, so then some of the error codes you get are just completely wrong in a name. And it takes 15, 20 minutes for you to figure out where exactly this happened from. Um, and so I think that in certain way, like, I think it made things so much nicer and easier, but then just things so much more wildly complex. And in my viewpoint of the device tree, completely uselessly complex to the point that we just avoid the device tree almost entirely and pour our own drivers in. And then we'll just use like the I2C driver that Zephyr provides. And then our driver lives on top of that within our app, right? Because leaving it within their thing. And then the other thing is like, for example, with Nordic, right? If you use MCU boot. Vigs (19:42) Yeah, we started doing that too. Ian (20:04) Right? So traditionally, use the device tree flash layout. Right? But if you use MCU boot, you no longer use that device tree flash layout. You now use a partition manager file. Why? What is the point of redefining it somewhere else? And then being like, and then when people show up, and they're just like, yeah, this isn't working. And they're like, oh, you're setting it in the wrong place. Oh, of course you have two different places to set it. And depending on configurations, one works or one doesn't, you know. Vigs (20:40) Yeah. My, my experience with Zephyr, I think I resonate with a lot of what you're saying. My experience has been like, put in a bunch of effort, get something working. Now something's working and it's very nice. A lot of things are built in, you know, one or two lines to pull in like an entire USB library. And then you run into a bug in the field and you're like, ah, I don't like, it's not in my code. So it's somewhere in Zephyr. And then you like, Ian (20:57) Yeah. Vigs (21:06) our face of description again, where you're figuring out which of those configurations that I miss or like which ones are set to the default that I haven't thought about. Um, and then it's like, it just cycles that way, you know, like overall, I feel like it balances out the like compared to regular developments environment. Um, but I will say, uh, it has helped a lot. So, um, this is kind of specific to product development firms, like, like my company, um, because we work with a lot of different chipsets and so it's helped our reusability. Uh, Ian (21:20) Mm-hmm. Vigs (21:35) Whereas if you're a product code for just one piece of hardware, like how portable do you even need that code to be, you know, like with you, you're like moving those drivers to your application code, which is completely fine. It's a lot easier. I'm sure it solves a lot of headaches. But now it kind of defeats the purpose of Zephyr wine to be all portable, easy to switch between different pieces of hardware. So yeah, make the bag. Ian (21:43) Mm-hmm. Mm-hmm. Well, and the other thing you have to watch with their drivers as well is because their drivers are community contributed. No hate there, love anyone who will contribute to anything community, like keep doing it, I love you to death because you are the heart and soul of why the world works. One guy in Nebraska that spends five hours a week is the reason why the internet exists. But... One of the things is they're written for their own purposes and that's great. Or like, you know, a lot of them just fail without notice or anything like that, where a call just return or something. And then Zephyr takes the stance of, well, these are community contributed. We don't really police them as long as they fit like our code style. We accept the community driver, which, you know, in some ways I think is very noble, but then in other ways I pulled in drivers that. just break all the time and then it's sort of like a huge headache and then I end up down this path of just rewriting them and stuff which is why we've just taken this process of we'll just accept, we'll accept starting fresh, look at their driver and then make our own, you know. Vigs (23:13) Mm-hmm. Yeah. A lot easier to debug something that you read than someone else. Ian (23:18) Yeah. Well, or sometimes it'll pull in a different one. We had an issue where there was like two versions of a driver and it was pulling in the wrong version of it. And, you know, it took us a long time to figure that out. So that was fun. Vigs (23:20) I'm out. Yeah, yeah, it is hard to manage. What is positive though, is a lot of these ship manufacturers, Nordic being the primary one, are pushing adoption for Zephyr. So Nordic retired their like NRF5 SDK, I think earlier in the year, last year. And so as we see more support from these vendors, I'm sure they'll go a long way towards, more funding, more money goes towards that organization. Ian (23:46) Mm-hmm. Mm-hmm. Vigs (24:02) Um, which should hopefully address some of these concerns, but as far as like an initiative goes, I feel like we're headed in the right direction, right? For the longest time, for the longest time I've had all these zips downloaded of like, okay, here's the atmo SDK. Here's a Nordic SDK, here's a SC SDK. And it's like, oh, there's an update. I got to delete this entire zip folder and download the new zip folder. Um, so it is, it's relieving a lot of, um, headaches for a lot of embedded developers. So. Ian (24:09) Oh, 100%. Hahahaha Yeah, well also like tool chain management and just so many other different things as well, pathing, wow, I guess Zephyr doesn't really fix that. We use VS code and VS code just does a wonder for that kind of stuff. Vigs (24:44) Yeah, yeah, it is super nice. Um, taking kind of, uh, a level block diagram level of product, um, tell me about, um, some of the components and how you guys are architecting the, the communication between them. Like accelerometer is that over I2C? Is it over spy? Um, kind of lay out that block diagram for me. Ian (25:04) Yeah, it started, that started over I2C and then kind of moved to Spy as we kind of saw, you know, redesigned into Spy as we saw a need for greater data processing. Because I think initially it was more of we're going to let the IMU do a lot of its own work. Um, and then for cost reasons and for other things, different IMU also now need like, you know, now, now we start moving into the area of like trying to stamp out these, um, these phantom errors, for example, like the taps. So now it's pulling in that, that data off of the IMU, letting it decide its own tap because it's good at that. You're great, you know, and then we'll decide when we accept that tap or not. Right. And things like that. And then also the need for like other submetrics. Um, like one thing that we're kind of looking at doing in, in planning is like a dead reckoning system. Um, so that we can, uh, so that we could take your steps data that's being, uh, that's being calculated on the IMU and then take the dead reckoning system and understand like, you know, where are you taking steps, where are you just holding something in your hand so your arm wasn't swinging, you know, that sort of thing to again, right? Like. make a better product so that when someone looks at their steps and it looks off, that's an oddity, that's not a regularity. Vigs (26:32) Mm-hmm. Yeah, definitely. And you guys have this MVP that's out. Are you guys calling it an MVP, or is it kind of Gen 1? What do you call the current stadium? Ian (26:43) Yeah, I think it would be Gen 1 would be the more accurate state of it. Vigs (26:49) Yeah, so now that you have this Gen 1 out, are you guys kind of brainstorming additional features? Like, is there any user feedback of, this would be nice, that would be nice? Like, kind of, what would your ideal Gen 2 be taking all your learnings from Gen 1 so far? Ian (26:55) Ahem. Um, yeah, I spent a lot of time scrolling through data sheets for MCUs, probably way more than I like to admit. And, um, but, uh, there are so many really cool chips out there. Um, and I found one from Renaissance, um, that I really love, but they only have Zephyr on part of theirs. We have pulled in a lot of Zephyr libraries at this point, so it's going to be hard to like pull apart. Um. And then it's kind of doing that, but then also the reality of the world of doing like cost structures. So like sitting down and being like, okay, what does it cost to get this really cool chip and is the cool point, like, you know, like the trade off with the business side of things as well. Um, so I think Jen, Jen too, um, we're in talks with Nordic about using the NRF 54 chip, so I think that's probably where we're going to end up realistically because. it sort of ticks most of our boxes and all the important ones. And then we'll probably use the same accelerometer, include maybe we're looking at like an ECG because that's relatively inexpensive, but then off put the processing on the chip. Maybe wireless, maybe something else, I don't know. Vigs (28:27) Thank you. Ian (28:29) Say that again Vigs (28:30) Did you say wireless for charging? Ian (28:32) Yeah, because right now we're using a pin-based system. And it's good, it does what it needs to do and it does so reliably, so no hate there. But always looking for the next best thing, and improvement, so. Vigs (28:51) Yeah. Have you guys, um, I don't know if you've talked to your users about this, but are there users that, you know, maybe they're just out and about and they don't want to wear a watch, but they still want to wear the Gannance tracker. Um, is that like a use case for you guys? Cause I would imagine, you know, someone that wants to track their sleep, they're not going to wear their nice watch to bed. Um, but are they going to be owning two separate fitness trackers or, you know, what are your thoughts on that? Ian (29:15) Yeah, we're actually looking at developing a band specifically for sleep tracking and whatnot. Because just like you say, if someone has a nice watch, you got a Rolex or something, do you want to wear that to bed? The answer is probably no. Vigs (29:32) Yeah, that's a good idea having a band. And then again, there's a whole accessory upsell there with different kinds of bands, according to people's styles and a lot of room to grow there. What's your guidance current like battery life and what have you done to optimize it in the firmware? Ian (29:40) Mm-hmm. Yeah. Yeah, a lot of that is just pure architecture designs. The battery life is up to about 40 hours. I always make a joke, it's a popularity contest because we have haptic feedback and that vibrational motor running. Obviously, the more times that alerts the user, the more battery gets burned. So if you get a lot of notifications, your device is gonna die a bit earlier. Um... So that's like, yeah, that's like 40 hours. What was the other part of the question again? Vigs (30:27) What have you done to optimize it in the firmware? Ian (30:29) Oh, yeah, the architecture side of things. So what we do is we run a series of state machines. So we run active objects as state machines. They're really, really good for kind of abstracting away that kind of stuff. And while we don't have robust code tests in place, it's very easy to start introducing that module by module and slowly building that up. Because the way that those that active objects are created and scaffolded within the code, you already sort of have this layer of abstraction, and then you kind of pull together a lot of callbacks and stuff into a file. So because of that and the pointers, it gets a little bit complicated to build, but it's extremely efficient because everything's built on a QBase system. polling, everything's waiting for something to happen. So pure event driven. And then everything's kind of in a known state, right? And like the other thing is introducing some timers to turn off Bluetooth. So if you haven't been connected in a while, we just shut it down and the first second someone picks it up or starts moving it around, right? Turn it right back on, right? And then they'll be able to discover it. They'll be able to connect. They'll do their thing. Maybe they left it at home. Vigs (31:32) Yeah. Nice. Ian (31:57) It doesn't need to run all day while they're at home if it's not connected. Vigs (32:01) Yeah. Exactly. Yeah. So it sounds like a combination of architecture decisions as well as identifying these usage scenarios to be able to save power there. Super cool. What do you guys hope to achieve as a business in this new year? Ian (32:07) Mm-hmm. I think just selling out units, getting the word out there, getting some awareness for the business, things like that. Alex can add to that, I'm sure. Alex Ocampo (32:29) Yeah, we're just adding to that. You know, we're finding our first group of evangelists and we're finding a lot of interest in the watch community, both individuals, but then also watch brands, which is something that has been a pleasant surprise. I think, you know, we initially were thinking, direct to consumer, because watches are very personal, very emotional, some would say irrational, why people spend so much money on watches, but. I think we found resonance with watch brands who were coming in and solving a real problem for them as well. So, I would say just continuing to build out industry connections, industry partnerships, finding that first group of evangelists for the brand. Vigs (33:14) That's definitely a good play to go both to the consumers and to the watchmakers. I saw on your website, you're already working with a Finnish watch company. Is that accurate? Alex Ocampo (33:25) Yeah, so Roje, that's one we've spoken with. I think they really like the idea. This is kind of the general theme of conversations across the industry. Using it as a complementary item or like a bundle or an upsell. Imagine like checking out, when you're checking out at any e-commerce, it's like, did you want to add this to your cart as well? So those kind of like interesting upsells, I think, are interesting opportunities for us. Vigs (33:41) Thanks for watching! And I'm sure they would be open to any sort of custom branding opportunities there too, where you're kind of adding that watch's brand and making it seem like it's coming from that company. Yeah, overall, super, super excited with what you guys are building. I will go sign up for that wait list right after this, because I'm very excited about this technology. Kudos to you guys for what you're building, and thank you so much for coming on and sharing. Alex Ocampo (34:23) Absolutely. Thanks for having us. Ian (34:23) Yeah, thank you for having us.

Since you scrolled this far, maybe you could leave a review?