← Back to blog

Designing a Cellular Smartwatch to Replace My Phone

Last year, I got rid of my phone and switched to using a smart watch (Apple Watch) full time. This was a personal lifestyle decision that improved my life in a lot of ways. I ran into a lot of problems with this switch though. No smart watches are built to be a phone replacement. Even the cellular ones are still built to be phone extensions. Most of them can't be setup without a phone, and they generally lack the primary productive functionality that you need out of a phone.

I need to make calls, send texts, navigate, play podcasts/audiobooks, and most importantly, interact with my own custom cloud AI tools, so that I could add whatever functionality I wanted. This includes calendar, email, reminders, quick research, notes, shopping lists, etc. This all needed to be done through voice or text, managing cloud infrastructure with the watch acting as a thin client. My Apple Watch could do some of this, but not well.

After switching to the smartwatch-only lifestyle, I first built an Apple Watch app that connected to an AI API that I built to get as much of this functionality out of the Apple Watch as possible. Getting a custom complication built and installed is more work than it's worth, and it's not possible to trigger my own custom commands with wrist raising or a single button press. Phone calls rarely worked, perhaps because of antenna issues. The list can go on.

Since then, I have accepted the ideal experience is not going to happen through the Apple eco-system or through any major brand trying to sell phones first. So, I designed a new watch purpose-built from the ground up for this new use case.

The Core Architecture

The fundamental design decision is that the watch is a radio with a screen, not a computer on your wrist.

Most smartwatches pack a mobile application processor into a tiny enclosure and then struggle with battery life, thermals, and cost. Each new device that comes out tries to run better, faster, more feature-full apps on the device. We went the opposite direction. We asked why the app needs to run on-device in the first place. Our watch runs a low-power wearable processor, not a mobile SoC. It handles radio management, sensor polling, audio I/O, and drives the display. With few exceptions, that's pretty much it. Everything computationally expensive, from speech recognition, natural language understanding, AI reasoning, navigation routing, all happens on servers.

This buys us three things:

  • Functionality. We are able to deploy AI workflows on remote GPUs in ways that would not be possible on a tiny device. It doesn't matter how much more advanced small chips get, big chips will always be able to do more. So offloading processes to a server will have superior functionality, as long as the device maintains connectivity. I could discuss this for hours, and I will probably tackle these points in more detail in a future blog post.
  • Battery life. By offloading compute, we can optimize the device to run for days (in some cases weeks) on a 500 mAh cell. The cellular modem is power hungry, but it only has to be fully active during data transfer, and for users with WiFi connectivity, the device is extremely efficient.
  • Cost. IoT chips are cheaper than mobile application processors. This flows directly into a lower retail price. Also, the watch becomes obsolete much more slowly. We don't need the fastest new processor on our watch every two years. We can have one watch and just update the backend with the functionality that we want. This is fundamentally different than the smartphone economics of needing to drop another $400-1000 every 2-3 years.

The tradeoff is obvious. You need signal. No connectivity means no AI assistant, no navigation, no streaming audio. For our use case this is acceptable. I'm not hiking in the backcountry without cell service expecting to dictate emails. This is a real constraint, but I also spend most of my time in areas with cell service. Cell service is continuing to expand covered areas, and most of the functionality on a smartphone needs service anyways.

Choosing a Cellular Modem

Our data requirements are modest. Voice calls use AMR-WB at 23.85 kbps. Streaming audio is typically 64–128 kbps. AI interactions are small HTTP payloads. We don't need anything close to the bandwidth of a smartphone. Well under 0.5 Mbps covers everything.

Cat-1-bis would have been the natural choice. It's designed for exactly this kind of low-bandwidth IoT use case, it's power-efficient, and it only needs a single antenna. But VoLTE certification with a major US carrier was a hard requirement for a phone replacement. We considered VoIP, but this introduces other obstacles. VoIP numbers are often flagged by services that gate SMS 2FA, which essentially breaks our phone-replacement use case. At the moment, the Cat-1-bis modules with VoLTE certification and broad US band support don't exist. I expect this will change as this category of device becomes more common.

So we went with a Cat-1 modem. It's VoLTE certified on AT&T, T-Mobile, and Verizon. It supports Band 71 (T-Mobile's 600 MHz band, critical for rural coverage) and Band 14 (FirstNet). The idle power is good at 11 µA in power-save mode.

The catch with a Cat-1 is that it needs two LTE antennas instead of one. In a device this small, that's a significant constraint.

The Antenna Problem

This was the hardest part of the project.

We have four antennas in a case that's ~40×53mm. There are two LTE (main and diversity), one GNSS, and one WiFi/Bluetooth. Each antenna needs adequate ground plane, isolation from the others, and enough clearance from conductive components to maintain its radiation pattern.

We're using custom flex PCB antennas positioned around the perimeter of the case. It took a lot of iterations, but we eventually got reasonable performance across all the bands we care about.

Realistically, it's not going to match smartphone-level cellular reception. It can't. A smartphone has 100+ mm of antenna length to work with. We have a fraction of that. The physics of a short antenna in a small, tightly packed enclosure impose hard limits, especially for lower frequencies. I think we did an excellent job at optimizing within those limits, and the diversity antenna helps with signal quality in marginal conditions. I'm confident this device will have the best cell reception of any device its size in the market. Many of the physical design decisions had to be built around RF optimizations.

For GPS, we're using a dual-band module with an external wideband LNA. We accepted the higher power cost here because GPS accuracy is important to us, especially in cities.

Casing Material

Many smart watches use aluminum or titanium. We ran some simulations with antenna windows, ceramic backs, and other options to make a metal case work, but instead we went with PC-GF30 (glass-filled polycarbonate). It has good structural rigidity, reasonable thermal properties, and it's essentially transparent to RF. It also enables IP68 waterproofing with a simpler sealing design. The tradeoff is that it doesn't have the heft or premium feel of steel. We think that's the right call for a device where connectivity is the entire value proposition.

Display

For the display, we wanted always-on capability, maximum power efficiency, and outdoor readability. We are not streaming video or rendering complex animations, so high resolution and fast refresh rates don't matter.

We're using a reflective LCD, commonly referred to as Memory-in-Pixel (MIP) with a front light and capacitive touch.

A quick aside on terminology, because this confused me for a while and I think it confuses a lot of people. Watches that market their displays as "transflective" are usually not truly transflective. The term is a portmanteau of "transmissive" (light passes through the display from behind) and "reflective" (ambient light bounces off the display back to the viewer). A true transflective display would do both. It would have a backlight for dark conditions and reflect ambient light in bright conditions, through the same optical path.

What most modern low-power watch displays actually do is use a purely reflective panel with a front light mounted above it. In bright conditions, the front light is off and ambient light does all the work. In dark conditions, the front light turns on and illuminates the reflective surface from the front. It's a simpler and more power-efficient approach than true transflective, and it's what we're using. The display draws almost nothing when the front light is off, which is most of the time if you spend any amount of your day outdoors or in well-lit rooms.

The Chipset Decision

This is an unusual choice for a smartwatch. Apple, Google, and Samsung use mobile application processors designed to run Android or WearOS, render complex UIs, and handle on-device ML inference. They're also more power-hungry and expensive.

We don't need to run Android or do any compute intensive operations on the watch itself. Our firmware manages radios, reads sensors, captures and plays audio, and drives a low-resolution display. We chose a chip purpose-built for low-power embedded work, not one that's been shrunk down from a phone. It handles everything our firmware asks of it while sipping power.

Power Budget

Some highlights from our power budget:

  • Cellular modem (idle): 11 µA in PSM deep sleep. When you're not actively on a call or transferring data, the modem essentially disappears from the power budget.
  • Display: Near-zero draw with front light off. The MIP technology holds its image without refresh.
  • GPS (tracking): ~18 mA continuous (module + LNA). For casual navigation, we duty-cycle the receiver via software standby, bringing the average down to 3-6 mA depending on the fix cadence.
  • MCU: Idles in the low µA range and only spins up cores as needed.

The big power consumer is active cellular use. The modem can pull around 270–450 mA during a voice call depending on signal conditions. This is why the "radio with a screen" architecture matters. We minimize the time spent transmitting by keeping payloads small and letting the modem sleep aggressively between interactions.

Our target is 3+ days of moderate use. This includes some short calls, messaging, a couple of navigation sessions, AI interactions throughout the day, and some audio streaming. With light use, we're looking at nearly two weeks on a single charge. Voice calls are the heaviest power draw. At this point, the watch can only handle a 60-90 minute phone call over LTE without a charge depending on signal strength. It's not going to be an ideal device for someone that needs to have a lot of long phone calls.

What's Next

We're in the pre-production phase now. We are validating the hardware design, testing antenna performance across real-world conditions, and building out the cloud AI backend. The firmware runs on real hardware. The AI assistant can process voice commands and return responses through the cloud pipeline.

There's a lot of work left. Manufacturing at scale introduces a whole new set of challenges. Carrier certification is its own adventure. And the AI interaction workflow needs to be refined. Voice-first interfaces have a high bar for responsiveness and accuracy before they feel natural.

But the core thesis holds up. If you design a watch from the ground up to be a standalone cellular device with cloud-native intelligence, you get a genuinely useful product that lets you leave your phone behind. Not a lesser version of a phone strapped to your wrist, but a purpose-built tool for people who've decided they want less screen in their life without giving up the connectivity that actually matters.

I'm happy to answer questions about any aspect of the design, hardware, firmware, RF, the cloud architecture, or the experience of actually living without a phone.