Amazon Sidewalk in the field: lessons learned

How do you connect a small, battery-powered tracker that moves around and can't count on Wi-Fi? Cellular works, but it adds a SIM card, a monthly fee and a bigger power budget. Amazon Sidewalk offers another path: a shared network built from Echo and Ring devices already in people's homes.

At Focus, we brought Amazon Sidewalk to two existing tracker products. Each one used a different chip vendor and operating system. This article covers what Sidewalk is, how it compares to LoRaWAN, and what we learned along the way.

‍

What is Amazon Sidewalk?

‍

Amazon Sidewalk gives low-power devices long-range connectivity without anyone building a dedicated network.

It works as a shared neighborhood network. Compatible Echo and Ring devices act as Sidewalk Bridges. Each one shares a small, capped slice of its owner's internet connection: at most 80 kbps. Your device never needs its own gateway, SIM card or Wi-Fi password.

Devices talk to the nearest bridge over one of three radio links, which Amazon calls PHYs (physical layers):

• BLE (Bluetooth Low Energy, 2.4 GHz): the fastest at 1 Mbps, but it only reaches tens of meters.
• FSK (frequency-shift keying, 900 MHz): 50 kbps, reaching tens to low hundreds of meters.
• CSS (chirp spread spectrum, the modulation behind LoRa, 900 MHz): about 2 kbps, with the longest range at hundreds of meters.

Messages land in AWS IoT Core for Amazon Sidewalk. Coverage already reaches more than 90% of the US population.

‍

‍

Amazon Sidewalk vs. LoRaWAN

‍

Where Sidewalk wins: infrastructure and cost. With LoRaWAN, you either install and maintain your own gateways or pay a network operator. With Sidewalk, the gateways already sit in millions of homes, with no operator fee. For a device that moves around a neighborhood, a dense network you didn't build is hard to beat.

Where LoRaWAN wins: control and reach. Sidewalk coverage follows wherever Echo and Ring owners live and opt in. Rural routes and remote sites can go dark, and you can't add a gateway where you need one. Sidewalk also has hard limits:

• It's only available in the US, Canada and Mexico.
• On CSS, a moving device can send one uplink (device-to-cloud message) every six minutes in normal mode.
• CSS payloads are capped at 19 bytes.

If you need guaranteed coverage at a fixed site, or deployments outside North America, LoRaWAN is still the better tool.

‍

Our projects: two trackers, two platforms

‍

Both projects added Sidewalk to existing trackers. The goal was the same: extend what each device could already do onto the Sidewalk network. Beyond that, almost everything was different.

• Project 1: Nordic's nRF Connect SDK on Zephyr, with a Semtech LR1110 radio. It used all three PHYs: BLE, FSK and CSS.
• Project 2: a Silicon Labs KG100S module running FreeRTOS, with a Semtech SX1262 radio. It used only the 900 MHz links, FSK and CSS.

Product requirements drove that split, but it has a side effect. CSS can't be used to register a device on the network. So a design without BLE depends on FSK for onboarding.

‍

‍

What we ran into, and how we handled it

‍

Running a custom BLE mode. The Nordic tracker also needed its own custom BLE mode, separate from Sidewalk. These were our first Sidewalk products, so we chose the simplest approach we could validate: a mode switch.

The cloud sends a downlink (cloud-to-device message) that stops the Sidewalk stack. The device then starts advertising in our custom BLE mode. It returns to Sidewalk when the app requests it, or after a reboot. Today, we'd also evaluate running both side by side, which some Sidewalk SDKs support.

Building on a beta. Location on the Nordic tracker used the v1.1.0 location add-on, which was still in beta. Two issues came up:

• The firmware image outgrew internal flash, so we had to use an external flash partition. That made OTA (over-the-air) updates slower than expected.
• We hit stability bugs and fixed them ourselves. Both fixes were merged into Nordic's Sidewalk SDK. One was a hardcoded LR1110 chip-select that broke custom boards. The other was a crash during Wi-Fi location scans.

‍

By the numbers: range, payload and power

‍

We can't share field data from these projects, so these are the published figures we designed against. Current draw comes from Silicon Labs' reference measurements.

• BLE: tens of meters, payloads up to 255 bytes. About 156 µA average while connected, and 65 µA in slow advertising.
• FSK: tens to low hundreds of meters, payloads up to 250 bytes. About 23 µA average on a KG100S, and 40 µA with an LR1110.
• CSS: hundreds of meters, payloads of just 19 bytes. About 47 µA average on a KG100S, and 70 µA with an LR1110.

The real trade-off is that the payload size, uplink and data rate are set by the network. Message formats, location update rates and OTA strategy all have to fit inside those constraints.

‍

‍

Lessons learned

‍

If you're building a battery-powered, mobile Amazon Sidewalk device, here's what we'd tell you:

• Abstract the OS first. Write your own OS and hardware abstraction layer (HAL), then build the Sidewalk stack on top. We ran Zephyr on one project and FreeRTOS on the other. A thin HAL makes switching RTOS (real-time operating system) fast and easy.
• Design for debug access. Make the enclosure easy to open, with J-Link or USB within reach. Amazon's qualification process relies on a command shell to send commands and read logs.
• Protect the keys during OTA. Never let an update overwrite the internal NVS (non-volatile storage). Sidewalk keys are flashed to one section, then moved to an encrypted region once the device reads them. If that region gets overwritten, the only fix is reflashing the keys.
• Budget time for qualification. It takes a few weeks, with some back-and-forth to guide the testers. Plan your release date around it.

‍

Closing thoughts

‍

Amazon Sidewalk is a strong option for mobile, low-power devices in North America. There are no gateways to deploy and no operator fees. The network is already built.

It's also a young ecosystem. Expect to spend part of your time on the SDK itself, not just on your product. Go in with a clean abstraction layer, a plan for your keys and a realistic qualification timeline.

At Focus, we've now brought Sidewalk to several clients. If you're evaluating Amazon Sidewalk for your next product, get in touch.

‍