How to Architect a Connected Device: From Antenna to Cloud

It’s hard to find a consumer or enterprise application that hasn’t been ported to the cloud or originated there. Cellular is increasingly becoming the preferred option for getting data in and out of data centers, whether they’re hyperscale or edge computing. In fact, cellular itself has become yet another data center workload, with Comcast, Dish Wireless, and O2 Telefónica among the operators choosing cloud-native core networks for 5G.

To ensure performance, reliability, scalability, and security, device OEMs, systems integrators, and their customers must take a holistic view of the full connectivity stack: antenna, module, network, cloud, and data flow. Each of these components plays a key role individually, but they’re most effective when the design recognizes their relationships with one another.

Don’t Be Penny Wise and Pound Foolish

Many IoT applications are highly cost sensitive. That means their sensors, controllers, asset trackers, and other nodes must be as inexpensive as possible — especially in large-scale implementations such as tens or hundreds of thousands of devices around a smart city or utility territory.

One way to achieve that is by leveraging the cloud so the devices don’t need prohibitively expensive amounts of memory and processing power. The catch is that uploading all that data and then downloading the action to be taken requires power, and many of these devices run on batteries.

A design that saves $2 on the BOM but adds 50 mAh/day of radio activity doesn’t save money. It just moves the cost from procurement to truck rolls for battery replacement. It also undermines new battery-maximizing technologies such as 5G RedCap’s discontinuous reception (DRX), where the device puts itself to sleep to save power. That’s ideal for IoT devices that need to remain in service for several years. (For more information, see “With 5G RedCap, Less is More for IoT.”)

The design goal shouldn’t be to “minimize device compute” or “minimize radio traffic” in isolation. Instead, the design should focus on minimizing the product of the two, which usually means being methodical about what gets sent rather than just how much.

Another example is GNSS, which many IoT applications use for positioning, navigation, timing, (PNT) or all three. The easy way to save memory/MCU cost for positioning applications is to “let the cloud do the fix,” but that comes at a price because downloading a few kB of A-GNSS assistance data before every fix trades MCU cost for downlink power. That’s problematic because on LPWAN links such as LoRaWAN and NB-IoT, the downlink is often the most expensive and least reliable part of the budget.

A savvier design approach has the GNSS receiver capture and upload a brief raw signal snapshot (tens of bytes, not a computed fix). The cloud server uses that snapshot to resolve the position, with no need for assistance data from the device. Eliminating both the on-device fix computation and the downlink achieves up to ~90% lower power and acquisition time versus a standalone GNSS fix.

Some best practices that apply to both cellular and GNSS data:

• Compute in the cloud, but push only the raw/compressed input, not a request for cloud-computed output that requires a downlink round-trip. One-way (device → cloud) is almost always cheaper than a request/response pattern.
• Question whether the device really needs a “result.” Many utility and smart city use cases (consumption logging, environmental monitoring, leak/tamper detection) don’t need the device to act on cloud-computed output in real time. Instead, batch the decision-making and push a downlink command only on the rare occasion that an action is genuinely needed, such as a firmware update or threshold change.
• This approach works well on narrowband/LPWAN links only when uplink snapshot payloads stay tiny, such as 12-50 bytes. That’s why raw-snapshot/edge-summarization approaches matter more than the cloud’s computer power.

How to Choose the Right Antenna

Cloud-offloaded positioning still needs the module to acquire enough satellite signals to build a useful snapshot. But time to first fix (TTFF) is one of the most power-hungry processes for a GNSS-enabled device because the receiver’s RF front end and correlators are drawing peak current the entire time it’s searching.

This challenge highlights the importance of not only choosing the right GNSS antenna, but also making that choice early in the design process rather than weeks or months later. The antenna is relatively inexpensive compared to the module, but it’s disproportionately responsible for how long the expensive part of the receiver is drawing power. That’s one major reason why the antenna deserves the same design attention as the RF matching network rather than being an afterthought sourced on price alone. (For a deeper dive, see “Antenna Selection: Six Ways to Avoid Tripping on the Most Overlooked Step in Device Design” and “Why Antenna Decisions Make or Break Your Entire System — and Your Bottom Line.”)

So what exactly makes an antenna “right”? Here are a few key considerations:

• Passive vs. active: Active antennas use an integrated LNA to improve sensitivity and thus shorten TTFF, especially when signals are weak or the system has high cable loss. The downside is that the LNA draws power. So if the device uses a battery and does infrequent fixes, a well-matched passive patch or chip antenna close to the receiver often wins on total energy, even if raw sensitivity is lower.
• Axial ratio/polarization: GNSS signals are right hand circularly polarized (RHCP). If the device’s antenna isn’t RHCP — a problem known as mismatch — at least half of the signal (~3 dB) can be lost before the receiver even starts correlating. That means longer integration times and more power to reach the same C/N0.
• Group delay variation across the band: Cheap antennas can introduce phase distortion that hurts code/carrier tracking, thus delaying TTFF under marginal conditions. This is particularly problematic for devices in locations that attenuate GNSS signals, such as a utility meter in a basement or a tracker under vehicle glass.
• Placement and ground-plane dependency: Many low-cost GNSS antennas are rely on a ground plane to work effectively. Put them on an undersized or crowded PCB ground, and the realized gain (and TTFF) can degrade badly versus datasheet numbers measured on a reference board.
• A warm/hot start strategy: An antenna good enough to hold a marginal ephemeris/almanac lock between duty cycles enables the receiver to skip cold starts almost entirely. This is where antenna quality and the firmware duty-cycling strategy complement each other.

Get in touch for orders or any queries: sales@rfdesign.co.za / +27 21 555 8400

Courtesy of Taoglas