Golioth Can Now Run Entirely on Qualcomm Modems

Today marks the first implementation of running the entire Golioth firmware stack on a modem processor. This dramatically reduces resource consumption on the external MCU processor, and makes it easier to add Golioth to any hardware or platform.

The Golioth Firmware SDK has worked with modems from a wide variety of vendors for quite some time. This includes supporting offloading portions of the network stack, such as DTLS sockets, to the modem processor, which can improve both security and performance. Shifting the entire SDK to the modem takes this a step further.

Anatomy of a Modem

Engineers regard modems as a networking black box. An external MCU issues AT commands to access hardware-specific functionality. The modem (and really the packaged module that includes the modem) typically consists of one or more CPUs and digital signal processors (DSPs), as well as a variety of peripherals. These processors run vendor-provided code, which is typically distributed as an encrypted binary blob.

Modems are also power hungry, as embedded processors are often more robust than the external MCUs that interface with them. For example, many modems house Arm Cortex-A cores. This stands in contrast to the more constrained Cortex-M cores common to many MCUs. For this reason, optimized applications will turn the modem off or enter it into a low power state for the majority of the time the device is operating.

Running on a Qualcomm Modem

Qualcomm historically provides more information about its modem internals than some other vendors. In 2018, they announced support for the “LTE for IoT SDK”, enabling customer firmware to run on the Cortex-A7 core inside MDM920x modems. From the post:

Now, with the LTE for IoT SDK, you have a hostless option, too: Use the on-board A7 to develop with the advanced features in the Qualcomm API (QAPI) and built-in support for IoT cloud solution providers. You can save yourself the cost of the external MCU, the investment in cloud R&D and the headache of separate roadmaps for modem and processor.

While offloading more network capabilities to the modem processor is compelling in theory, it does not obviate the requirement of an external MCU in many designs. Furthermore, customers are still responsible for implementing connectivity on top of the APIs offered by the SDK. In some cases, this can make the product even more complicated, as custom firmware, likely targeting different platforms (the Cortex-A7 runs ThreadX), must be developed and distributed for both the modem and the external MCU.

Golioth already simplifies embedded device connectivity with table-stakes device management services, alongside robust data streaming capabilities and remote command and control. Moving the Golioth Firmware SDK to the modem processor allows customers to recognize the full benefits of offloading the entire connectivity stack, without having to take on the complexity of developing for separate platforms.

We have developed a port of the Golioth Firmware SDK that integrates with the Qualcomm API (QAPI) support on Cortex-A7 processors in MDM920x modems. This enables dropping a connectivity module, such as the Quectel BG95, onto a board design and getting instant connectivity via the Golioth cloud platform. As shown in the video at the beginning of this post, the Golioth Firmware SDK can run entirely on the BG95, freeing up resources for an external MCU to perform the primary operations of the application, then call high level APIs via the modem interface to communicate to and from the cloud.

Running on Other Modems

Another benefit of running the Golioth Firmware SDK on the modem is the ability to easily move from one modem to another. This reduces the risk of relying on a single part, ensuring that a different modem, even one from a different vendor, can be easily incorporated into future hardware revisions. We have already begun work to support offloading Golioth on non-Qualcomm modems.

However, integrating any modem into a hardware design can be complex. In addition to the engineering expertise required, regulatory, conformance, and carrier approval can be costly and onerous. Module vendors can simplify this process by providing pre-certified parts, but they do not shoulder the responsibility of working with service providers to ensure connectivity for connected devices.

While we believe in allowing Golioth users to have total control over their hardware and the code that runs on it–an ethos that is reflected in our open source SDK–we also are always listening to how we can further streamline the path from prototype to production. Because of this, we have also begun development of our own System on Module (SoM) solution that can be incorporated into customer designs, further reducing the number steps required to build a connected product.

What’s Next?

Interested in offloading Golioth to the modem processor and simplifying your hardware and firmware? We are now engaging with select customers to trial both offloading Golioth to the modem and incorporating a Golioth SoM into a design. Reach out to [email protected] for more information!