In mid-April 2026, Nordic Semiconductor released the <a href="https://www.nordicsemi.com/Products/nRF9151/Download?#A9BA541CDE7C49A1A7B28D0099AC3E24" target="_blank">v1.0.0 NTN modem firmware</a> for their latest chipset, the nRF9151. A "1.0" tag is supposed to mean “ready for production”. But is it, really? And at what cost?Let's put the latest NTN developments to the test and find out if the standard is actually ready for production.<h2>Non-Terrestrial Networks Explained</h2>Non-Terrestrial Networks (NTN) are the 3GPP's response to a continuous demand for connecting the largest part of the planet that no cell tower will ever reach. It opens up a long list of use cases: connecting large farmlands, monitoring energy infrastructure, tracking global logistics, overseeing mining equipment, just to name a few. The standard, defined by the 3GPP in <a href="https://www.3gpp.org/specifications-technologies/releases/release-17" target="_blank">Release 17</a> (frozen in June 2022), <a href="https://www.3gpp.org/technologies/ntn-overview" target="_blank">extends existing cellular protocols</a> (LTE-M and NB-IoT) to work over satellites.The promise is that none of this requires significant changes to the IoT devices. The same modem should support both terrestrial and non-terrestrial networks. The same antenna should work, to some extend. And more and more connectivity providers now let you use the same SIM for both kinds of networks.In essence, the satellite acts as a cell tower deployed in space. Once a data packet is picked up, it's forwarded to the provider's mobile core, which routes it to the right endpoint on the application side. To the application layer, an NTN link looks like a regular cellular session, supporting both uplink and downlink traffic, just with higher latency and a tighter link budget.<h2>Requirements</h2>To deploy an NTN solution, four pieces have to line up:<ol><li>A modem that supports 3GPP Release 17. Several vendors have shipped NTN-capable chipsets, including the <a href="https://www.nordicsemi.com/Products/nRF9151/" target="_blank">Nordic nRF9151</a>, <a href="https://www.murata.com/products/connectivitymodule/lpwa/overview/lineup/type-1sc" target="_blank">Murata Type 1SC</a>, <a href="https://www.quectel.com/product/bg95-s5-satellite-communication-module/" target="_blank">Quectel BG95-S5</a>, <a href="https://www.telit.com/devices/me310m1-series/" target="_blank">Telit ME310M1</a>, and <a href="https://www.sierrawireless.com/iot-modules/lpwa-modules/hl7812/" target="_blank">Sierra Wireless HL7812</a>.</li><li>Access to a satellite network. Nordic currently supports <a href="https://www.skylo.tech/" target="_blank">Skylo</a> (Geostationary Earth Orbit, or GEO) and <a href="https://sateliot.space/" target="_blank">Sateliot</a> (Low Earth Orbit, or LEO). You can work directly with these satellite operators, but several connectivity providers have already integrated Skylo’s satellite networks into their platforms, enabling a single SIM and a single platform to cover both ground and space.</li><li>An antenna that handles the link. Any antenna will technically work, but NTN-optimized antennas help the device attach faster and use less energy doing so.</li><li>A UDP server on the receiving side. NTN today is NB-IoT only, which means UDP traffic only. You need an endpoint that can receive it.</li></ol>On paper, tons of businesses should be lining up to implement satellite connectivity into their use cases. But do they?<h2>Putting NTN to the Test</h2>Beyond the press releases, we wanted to see what an honest end-to-end NTN deployment looks like in 2026. So we built one ourselves. Every part is off-the-shelf, and the test can be replicated by anyone willing to do the work.Our setup contains:<ul><li>Nordic Semiconductor's<a href="https://www.nordicsemi.com/Products/nRF9151" target="_blank"> nRF9151 SiP</a> running the latest v1.0.0 NTN modem firmware.</li><li><a href="https://www.actinius.com/" target="_blank">Actinius Icarus</a> (pre-released) development kit built around the nRF9151 with onboard temperature sensor and accelerometer.</li><li><a href="https://www.kyocera-avx.com/" target="_blank">Kyocera AVX</a> NTN antenna, tuned for the satellite’s L-band frequencies</li><li><a href="https://monogoto.io/" target="_blank">Monogoto</a> SIM with native<a href="https://www.skylo.tech/" target="_blank"> Skylo</a> NTN integration</li><li><a href="https://tago.io/" target="_blank">TagoIO</a> IoT platform, with an integrated UDP server to store and process data.</li><li><a href="https://www.qoitech.com/" target="_blank">Qoitech Otii</a> power profiler, measuring the device’s energy consumption during the process of connecting to a satellite, sending and receiving data.</li></ul> <img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1779356878241-IMG_2783.JPG" style="width:100%px" class="fr-fic fr-dib" />The NTN setup with an active GNSS antenna, Actinius Icarus development kit with the nRF9151, and the Kyocera AVX’s L-band antenna.The sanity check is built around three questions:<ol><li>Does it work?</li><li>At what price?</li><li>At what power budget?</li></ol><h3>Does it work?</h3>We started from Nordic's open-source <a href="https://github.com/nrfconnect/Asset-Tracker-Template/tree/ntn_usecase" target="_blank">Asset Tracker Template</a>, which already ships an NTN use-case branch. The only modifications needed were a light adapter to TagoIO's UDP endpoint and a reformat to match their lightweight telemetry format, <a href="https://tago.io/tip" target="_blank">TagoTIP</a>.Connecting to Monogoto required no separate provisioning step apart from enabling the Monogoto overlay at build time. The device booted, registered on Skylo, and started reporting in. From there, the Monogoto hub gave us live feedback on attach status, signal quality, and data flow.Power it up, and data showed up in the TagoIO dashboard. The verdict: yes, NTN works, with off-the-shelf parts and openly accessible firmware. <img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1779356814522-Monogoto+Dashboard.png" style="width:100%px" class="fr-fic fr-dib" />Monogoto hub showing the live NTN connection<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1779356830100-TagoIO-dashboard.png" style="width:100%px" class="fr-fic fr-dib" />you TagoIO dashboard, visualizing the location and temperature data<h3>At what price?</h3>Monogoto's NTN pricing to access Skylo's network is $0.30 per KB, billed in 50-byte increments (<a href="https://monogoto.io/monogoto-ntn-pricing-pay-as-you-go-simplified-pricing/" target="_blank">source</a>).During the test, the following payload was sent, which (including its overhead) contains a total of 152 bytes.<pre>&lt;code&gt;PUSH|&lt;token&gt;|&lt;device_id&gt;|[temp:=14.00#C@=52.089895,4.313049{device=*2519};x:=0.1532#m/s2;y:=0.0383#m/s2;z:=9.4611#m/s2]&lt;/code&gt;</pre>The sensor payload of 152 bytes rounds up to 200 bytes, which works out to roughly 6 cents per message. Send one every fifteen minutes for a month and you're looking at $173 per device. Suddenly the question of what you put in each packet, and how frequently you send the data becomes very relevant.Compared head-to-head with terrestrial cellular, often under $0.01 per MB, NTN looks expensive. But that's the wrong comparison. NTN exists precisely where terrestrial coverage doesn't, so the fair benchmark is traditional satellite connectivity. Against that, Monogoto's NTN pricing is remarkably competitive. The real question isn't whether it's cheap in absolute terms, it's whether you can make the economics of your specific IoT business case work.<h3>At what power budget?</h3>One key question remains, does it work out with the available power budget of battery-driven devices? We challenged Qoitech to conduct an in-depth analysis of an IoT device sending data over satellite networks, and the outcomes are more interesting than expected, and we'll walk through it live. This and more will be shared in the upcoming webinar, happening on June 2!<h2>Join the live demo!</h2>Let's move past another article promising "ubiquitous connectivity" and show how the technology works in reality, giving real data about the pricing and power budget.We’re warmly inviting you to join the <a href="https://app.livestorm.co/iot-stars/the-non-terrestrial-networks-sanity-check?utm_source=iotstars&amp;utm_medium=wevolver" target="_blank" rel="noopener noreferrer">live webinar</a> on June 2, 4pm CEST / 7am PST. We'll send a message from a device to a non-terrestrial network, show the power trace as it happens, and put real numbers next to the cost and energy questions every NTN evaluation eventually runs into.On the agenda:<ul><li>A live, end-to-end NTN demo</li><li>Technical notes from Maor Efrati, CTO at Monogoto</li><li>Power analysis findings from Björn Rosqvist CPO at Qoitech</li><li>NTN antenna insights from Carmen Redondo, Director Global Marketing at Kyocera AVX</li><li>Open Q&amp;A</li></ul>See it for yourself and decide whether NTN has a place in your next IoT deployment.<a href="https://app.livestorm.co/iot-stars/the-non-terrestrial-networks-sanity-check?utm_source=iotstars&amp;utm_medium=wevolver" target="_blank" rel="noopener noreferrer">JOIN WEBINAR</a><hr />by<a href="https://www.linkedin.com/in/laurensslats/" target="_blank"> Laurens Slats</a> <a target="_blank">laurens@iotstars.com</a> Further reading:<ul><li>3GPPs NTN overview <a href="https://www.3gpp.org/technologies/ntn-overview" target="_blank">https://www.3gpp.org/technologies/ntn-overview</a></li><li>Monogoto NTN pricing:  <a href="https://monogoto.io/monogoto-ntn-pricing-pay-as-you-go-simplified-pricing/" target="_blank">https://monogoto.io/monogoto-ntn-pricing-pay-as-you-go-simplified-pricing/</a></li><li>Antenna performance:  <a href="https://www.everythingrf.com/community/from-earth-to-orbit-the-important-role-of-antennas-in-ntn" target="_blank">https://www.everythingrf.com/community/from-earth-to-orbit-the-important-role-of-antennas-in-ntn</a></li><li>Skylo’s coverage map:  <a href="https://www.skylo.tech/resources/geographical-coverage" target="_blank">https://www.skylo.tech/resources/geographical-coverage</a></li><li>Asset Tracker Template for NTN use cases:  <a href="https://github.com/nrfconnect/Asset-Tracker-Template/tree/ntn_usecase" target="_blank">https://github.com/nrfconnect/Asset-Tracker-Template/tree/ntn_usecase</a></li></ul>&lt;footer&gt;&lt;a href="https://iotstars.com/" target="_blank"&gt;&lt;img alt="" src="https://storage.mlcdn.com/account_image/1148207/U4X1BwIYduwGPcZaFJ6WNDC0ebjqq3bxw7wcVExY.png" class="fr-fic fr-dii" /&gt;&lt;/a&gt;&lt;/footer&gt;

NTN modems are "ready for production." But is it, really? And at what cost?

The Satellite IoT Sanity Check

In medical devices, automotive systems, and industrial automation, software is a regulated component of the product itself. That changes what "good enough" means for a build process. A binary you cannot reproduce is a binary you cannot validate, and a build environment you cannot audit is a liability in every certification cycle you run.Despite this, many embedded teams still operate with manual or loosely controlled build processes: toolchains installed directly on developer machines, no enforced versioning, and test and analysis steps that run inconsistently, if at all. The problems this creates are well understood in theory but chronically underestimated in practice. Build reproducibility directly affects validation scope, certification timelines, and release predictability.CI/CD pipelines provide a structured path out of this. Automated builds, integrated analysis, and containerized environments together standardize execution, generate compliance evidence continuously, and reduce the audit burden at release time. Adoption does not require a dedicated DevOps team or a full infrastructure overhaul. Teams can start with automated builds alone and extend the pipeline incrementally from there.<h2>The Real Price of "Good Enough" Build Processes</h2>The most immediate problem with uncontrolled build environments is variability. When each developer maintains their own toolchain configuration, subtle differences accumulate, from compiler versions to library paths, optimization flags, and environment variables. Two developers building the same commit may produce different binaries. In most software contexts, this is inconvenient; in regulated development, it is a compliance failure waiting to materialize.Unqualified or non-certified toolchains compound this. During audits, teams must self-justify tool behavior, documenting that a given compiler version produces correct output under the conditions used. This is significant validation work that certified toolchains eliminate by shifting that burden to a qualified third party.The downstream effects are predictable. When defects are found late, as they inevitably are when analysis and testing run manually or infrequently, debugging requires first reconstructing the environment the defect occurred in. That reconstruction may not be possible if the environment state was never captured. Troubleshooting build and pipeline failures alone can consume up to <a href="https://www.iar.com/blog/enabling-consistent-workflows-with-cloud-enabled-solutions">40% of development time</a>, time that should be going toward innovation, testing, and actual feature work.Audit preparation in these environments is largely manual. Engineers assemble evidence from disparate sources: build logs from one system, test results from another, and analysis outputs from a third. Certification timelines extend unpredictably not because the product is unsafe but because the documentation trail is incomplete or inconsistent. Engineering effort shifts toward rework and environment management rather than toward the product.<h2>Anatomy of an Embedded CI/CD Pipeline</h2>A well-structured embedded CI/CD pipeline follows a 5-stage, fixed sequence: Code → Build → Analyze → Test → DeployCode commit triggers build, which feeds into static analysis, which gates automated testing, which then produces validated artifacts for deployment. Each stage is automated, version-controlled, and produces structured outputs.<a href="https://www.iar.com/embedded-development-tools/embedded-ci-cd?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver" target="_blank" rel="noopener noreferrer"><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1777030324914-image1.png" style="width:100%px" class="fr-fic fr-dib" />A Modern CI/CD Workflow. Credit: IAR</a>The value of this goes beyond speed. The pipeline becomes a system of record. Build logs, analysis reports, and test results are generated automatically on every run, linked to the specific commit that produced them. The path from source code to deployed binary is fully traceable and reproducible. When a regulator asks for evidence that a given artifact was built from a known state and tested against defined criteria, that evidence exists and is organized.Continuous validation through static analysis and runtime checks, integrated directly into the pipeline, shifts defect detection to the earliest possible point. A coding standard violation found at commit time costs minutes to address. The same violation found during integration testing can cost days.<h2>Containerization: The Foundation for Consistency</h2>Reproducibility requires that the build environment itself is controlled and versioned. <a href="https://www.iar.com/blog/a-new-chapter-for-our-docker-support-introducing-the-iar-cloud-ready-containers-repository?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">Containers</a> solve this directly. Packaging the toolchain, compiler flags, analysis tools, and all dependencies into a versioned container image means every pipeline run, whether on a developer's workstation, a cloud runner, or an on-premises CI server, executes in an identical environment.This has a direct compliance benefit. Qualification effort can be focused on the container image rather than each developer's local setup. Once the toolchain configuration inside a container is qualified, that same configuration runs identically everywhere, eliminating the risk that a local toolchain update silently changes the environment under assessment. When <a href="https://www.iar.com/embedded-development-tools/functional-safety?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">TÜV-certified</a> toolchains are packaged inside containers, the certified boundary is clear and fixed. The container image itself becomes auditable: its contents are known, its version is tracked, and its behavior is consistent across infrastructure.Isolated container environments also provide a security boundary. Dependencies cannot drift silently, and there is no ambiguity about which version of a tool was used for a given build.<h2>Performance and Quality Gains You Can Measure</h2>The shift to automated, containerized pipelines produces concrete gains.<a href="https://www.iar.com/embedded-development-tools/embedded-ci-cd?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver"> IAR Build Tools</a> on Ubuntu deliver build times roughly twice as fast as equivalent Windows-based workflows, and <a href="https://www.iar.com/embedded-development-tools/code-quality-and-compliance?utm_source=web&amp;utm_medium=article&amp;utm_campaign=wevolver">C-STAT</a> static analysis runs approximately 3.5 times faster. Across build and debugging effort combined, automated analysis with pre-qualified toolchains reduces total time by 50 to 80 percent.C-STAT enforces MISRA C/C++, CERT C/C++, and CWE coding standards across every pipeline execution. At that speed advantage, comprehensive standards coverage stops being a bottleneck and becomes a continuous, low-friction part of the build process. Quality metrics follow a similar pattern. Continuous enforcement of coding standards on every commit, rather than periodic manual review, produces roughly a <a href="https://www.iar.com/embedded-development-tools/code-quality-and-compliance">41% reduction in defect injection rates</a>. Defects caught earlier in the pipeline require significantly less effort to fix, and downstream testing loads decrease as a result.These are not marginal improvements. For teams operating under release pressure in regulated markets, halving build and debug time while reducing late-cycle defects directly affects both certification timelines and product quality.<h2>Starting Small: Incremental Adoption</h2>CI/CD adoption in embedded development does not require a dedicated DevOps team or a large infrastructure investment. The risk of incremental adoption is low: starting with automated builds does not disrupt existing workflows or trigger re-validation requirements.The practical entry sequence is to automate builds first, capturing the toolchain configuration and making builds reproducible. Then, introduce static analysis as a pipeline gate. Afterwards, you add automated testing. At each step, containerized environments simplify setup and make the expanded pipeline portable. Teams retain ownership of their pipelines throughout. The incremental approach also means compliance evidence accumulates progressively rather than requiring a large documentation effort at the end of a release cycle.<h2>Enabling Embedded CI/CD with IAR </h2>IAR's toolchains are built for automation-first workflows. IAR Build Tools are headless, scriptable, and integrate with standard CI platforms including GitHub Actions, GitLab CI, and Jenkins. Static analysis through C-STAT and runtime verification through C-RUN run inside pipelines without manual intervention. Toolchains pre-certified to IEC 61508 (industrial automation), ISO 26262 (automotive), and IEC 62304 (medical devices) reduce the validation work teams must do themselves during certification.Cloud-based licensing removes the constraint of node-locked licenses tied to specific machines, enabling consistent workflows across local development, cloud runners, and on-premises systems. Support for over 20 processor architectures means teams working across device families can standardize on a single toolchain ecosystem without being forced into architecture-specific tool fragmentation.IAR Embedded Trust extends pipeline automation to firmware security. Automated signing and encryption within the pipeline integrates security requirements from CRA and UN R155/R156 directly into the build process rather than treating them as post-build steps.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1777030409990-image2.png" style="width:100%px" class="fr-fic fr-dib" />Credit: IAR<h2 id="isPasted">Conclusion</h2>Build reproducibility in modern embedded development is the foundation that compliance work depends on. Automated workflows, built on certified toolchains, ensure consistent execution, validation, and traceability from commit to deployed artifact. An environment that cannot consistently reproduce a binary cannot validate, certify, or maintain it.Regulatory expectations around software development processes are continuing to formalize across medical, automotive, and industrial sectors. Teams that establish reproducible pipelines now gain direct control over their development timelines and compliance readiness, rather than discovering gaps under deadline pressure during certification. The cost of manual builds is always higher than it appears, and it compounds with each release cycle.

This article explores how automated CI/CD pipelines replace fragile manual build processes with reproducible, auditable workflows that improve compliance, reduce defects, and accelerate development in regulated embedded systems

embedded development

ORGANIZATIONS. SHAPING THE INDUSTRY.

Latest Posts

The Satellite IoT Sanity Check

The Hidden Cost of Manual Builds: Why Teams in Regulated Sectors Must Embrace CI/CD