Accelerating digital signal processing with Arm SME2 for satellite signal acquisition

Satellite downlinks do not arrive as ready-to-use telemetry. They arrive as noisy in-phase/quadrature (IQ) samples that must first be detected, synchronized in time and frequency, demodulated, framed, decoded, and checked before software can use them.

This project began as a pocket-sized idea: pair a phone-class Arm device with a low-cost software-defined radio and make satellite signal acquisition and link checking practical in the field.

The public GitHub project demonstrates that workflow with deterministic synthetic IQ: front-end normalization; timing and carrier frequency offset (CFO) acquisition; CFO and phase correction; binary phase-shift keying (BPSK) demodulation; secondary frame synchronization; Viterbi decoding; an 8-bit cyclic redundancy check (CRC-8); and trust diagnostics.

The performance-critical workload is IQ-domain acquisition, where the receiver searches a known preamble across many timing offsets and carrier-frequency hypotheses. The public implementation provides a scalar correctness oracle, an optimized Arm NEON baseline. It also includes an Arm Scalable Matrix Extension 2 (SME2) path using ZA-backed four-vector (VGx4) operations. On a vivo X300 powered by a MediaTek Dimensity 9500, SME2 delivered repeatable acquisition latency reductions over NEON across every fixed workload tested, including reducing the medium per-capture workload from about 3.59 ms to 1.58 ms, with a 2.14-2.42x speedup across five runs.

That extra compute headroom can be used to return an acquisition result sooner or to search more timing and frequency hypotheses within the same latency budget.

During commissioning, field tests, and proximity-operations rehearsals, the useful question is not only whether the receiver decoded a frame successfully, but whether it acquired the right signal cleanly enough to trust what follows.

What this receiver workflow gives you

A satcom receiver must find the signal in time and frequency before decoding can begin. The acquisition stage searches timing offsets and carrier-frequency-offset hypotheses, identifies the strongest preamble match, and measures how clearly it wins over competing candidates. That makes a pocket-sized receiver useful as an independent ground-side validation tool during rehearsals, integration and test, commissioning, and field demos. It can help developers separate acquisition and radiofrequency (RF) problems from downstream framing, forward error correction (FEC), or higher-layer software problems before they cause delays.

Why acquisition matters for satellite links

Satellite acquisition is not just a generic digital signal processing (DSP) step. Relative motion between a spacecraft and a ground station shifts the received carrier through Doppler, while oscillator error and prediction uncertainty can widen the frequency region a receiver needs to search. Many satellite contact opportunities are time-bounded, so time spent acquiring the signal is time that cannot yet be used for telemetry, payload data, or testing. A practical receiver therefore must search uncertainty in both timing and frequency before it can demodulate the signal and recover the first usable frame.

The public demo represents that problem as a configurable grid of timing offsets and CFO hypotheses rather than as a specific mission waveform. Lower acquisition latency reduces one component of time-to-first-usable-frame; alternatively, the same compute budget can search a wider uncertainty region. That is useful during satellite commissioning and portable ground-station work, and during ground-side rehearsals for Rendezvous and Proximity Operations (RPO) and In-Space Servicing, Assembly, and Manufacturing (ISAM), where teams need to distinguish an RF or acquisition problem from a decoder or higher-layer software problem. The project remains a developer and test tool rather than an operational flight communications system.

Why build this kind of satcom receiver tool?

• Faster field checks: provide a foundation for acquiring and decoding basic telemetry with minimal setup.
• Better logistics: keep the processing core suitable for a phone-class Arm device and a low-cost USB SDR rather than a laptop-heavy bench.
• Earlier fault detection: identify acquisition, frequency-offset, framing, or integrity problems before they delay testing.
• Clearer developer workflow: show the detected timing/CFO estimate, decoding result, and trust diagnostics in one reproducible pipeline.

I wanted the field workflow to answer two questions quickly: did we acquire the right signal, and should we trust what the decoder sees next?

Architecting a pocket satcom lab with SME2

To make the architecture clear, Figure 1 shows the developer workflow. SME2 accelerates the IQ-domain acquisition stage, while demodulation, decoding, integrity checks, and trust diagnostics remain downstream.

Figure 1. Pocket satcom workflow. SME2 accelerates IQ-domain timing/CFO acquisition, creating headroom for lower acquisition latency or a wider timing/CFO search.

Prototype and public development stack

• Arm64/SME2-capable compute target for the mobile use case
• Low-cost USB software-defined radio for the intended field front-end
• Native C++17 acquisition, replay, decoding, and trust components
• Host-side replay tools, correctness tests, benchmarks, and validation scripts
• An arm64 Android Native Development Kit (NDK) command-line benchmark path for future physical-device testing

Pipeline stages

• IQ input: deterministic synthetic complex-IQ fixtures in the public reproducibility package
• Front-end processing: DC removal and RMS normalization
• Acquisition: matched-filter correlation across timing offsets and CFO hypotheses
• Alignment and demodulation: CFO/phase correction followed by BPSK soft decisions
• Verification: secondary frame synchronization, scalar Viterbi decoding, and CRC-8
• Trust diagnostics: acquisition evidence, soft-decision quality, synchronization evidence, clipping, and CRC state

The public release deliberately uses deterministic synthetic fixtures rather than a mission-derived waveform. Each fixture records known timing and CFO only for validation; that ground truth is never used to select the acquisition result. Healthy, impaired, ambiguous, CRC-failed, and no-signal cases make the complete pipeline reproducible without implying compatibility with a specific satellite air interface.

In the public implementation, SME2 accelerates IQ-domain acquisition. The receiver evaluates a bank of complex matched-filter correlations over timing offsets and CFO hypotheses. The optimized NEON baseline uses 128-bit NEON vectors to process timing candidates in tiles, while the SME2 kernel uses streaming mode, ZA vector groups, and VGx4 fused multiply-add/subtract (FMLA/FMLS) operations to accumulate multiple timing hypotheses in parallel.

The result is a Pocket Satcom Acquisition and Trust Lab that combines Arm SME2 acceleration for signal acquisition with downstream decoding, integrity checks, and inspectable trust diagnostics.

Developer requirements

The goal was to serve three kinds of users:

• Satellite and ground engineers who want to verify link health in the field during rehearsals and demonstrations.
• Autonomy and RPO/ISAM researchers who need quick checks that their communication assumptions still hold when conditions change.
• Developers who want a concrete, reproducible example of SME2 in a non-vision workload with safety relevance.

From a technical perspective, the requirements were:

• Provide a reproducible end-to-end replay from complex IQ to decoded payload, CRC result, and trust diagnostics.
• Compare scalar, NEON, and SME2 implementations of the same acquisition search.
• Validate every accelerated result against an independent scalar oracle before accepting performance measurements.
• Exercise healthy, impaired, ambiguous, CRC-failed, and no-signal inputs with deterministic fixtures.
• Keep architecture-specific compilation isolated and make the emitted NEON and SME2 instructions auditable.
• Provide an Android NDK command-line benchmark path for testing on SME2-capable phones.

Arm technology at the core

The project targets phone-class Arm devices. The public repository includes an Arm64 Android Native Development Kit (NDK) command-line benchmark path with runtime SME2 feature detection, alongside host-side replay and benchmark tools for development and validation.

The acquisition correlation bank is the performance-critical kernel. The reference, NEON, and SME2 implementations are built separately and checked for equivalent acquisition results. Object-code inspection confirms that the SME2 kernel uses streaming mode and operations on the ZA register.

The native core also runs as a host-side replay and benchmark tool. This keeps correctness testing, offline analysis, and architecture comparisons independent of the future mobile interface or live-RF input path.

Signal chain from IQ input to trust diagnostics

Figure 2 shows the acquisition-first signal chain and the stages that contribute to the trust diagnostics.

Figure 2. Acquisition-first replay pipeline. Trust diagnostics combine acquisition evidence with demodulation quality, secondary frame synchronization, and CRC state.

1. IQ input and front-end processing
   The public workflow loads deterministic float32 complex-IQ fixtures. The front end removes DC offset and normalizes RMS amplitude before acquisition.
2. IQ-domain acquisition
   A known complex preamble is correlated across a configurable grid of timing offsets and CFO hypotheses. The highest score selects timing and CFO, while the runner-up provides an explicit ambiguity signal. This correlation bank is the primary SME2 acceleration workload.
3. Alignment and demodulation
   The selected CFO and phase estimate are used to align the received samples before BPSK demodulation produces soft decisions.
4. Secondary synchronization, FEC, and integrity
   A later frame-sync check confirms the aligned bit stream. The supported replay then uses scalar Viterbi decoding for the convolutionally coded frame followed by CRC-8 validation.
5. Trust diagnostics
   Acquisition evidence, soft-decision quality, secondary synchronization, clipping, and CRC state are combined into an inspectable diagnostic score and status band.

Trust monitors and rejection

The public project deliberately uses simple, inspectable diagnostics rather than a learned confidence model. The trust layer combines the normalized acquisition peak, best-to-second-best peak separation, residual acquisition uncertainty, bounded soft-decision strength, secondary frame-sync evidence, demodulation clipping, and CRC state.

The resulting score and status bands are deterministic engineering heuristics, not calibrated probabilities or operational assurance levels. The checked fixtures exercise five distinct outcomes: healthy inputs produce high-confidence results; impaired and ambiguous inputs reduce confidence while still decoding; CRC-failed inputs are low-confidence; and no-signal inputs are rejected during acquisition before demodulation is attempted.

This makes the trust behavior easy to inspect and reproduce alongside the acquisition and decoding pipeline.

Synthetic replay and data provenance

All IQ captures distributed with the public project are deterministic synthetic fixtures generated by repository scripts. They are not mission-derived recordings and are not intended to reproduce a deployed satellite air interface. Generator seeds, metadata, and content hashes are tracked so the fixtures can be regenerated and verified in CI.

This keeps the correctness and benchmark workflows reproducible and avoids licensing concerns. A supported live-RF receiver and mission-specific waveform profiles remain outside the current public scope.

Performance gains with SME2

The public release includes a reproducible SME2 performance result for IQ-domain acquisition. The audited benchmark uses four fixed direct-correlation workloads and compares an independent scalar reference, a strengthened Arm NEON implementation, and the SME2 ZA/VGx4 implementation. Every accelerated result must first match the scalar acquisition result within defined numerical tolerances.

Apple M5 Pro

Five independent clean-tree benchmark processes were run on an Apple M5 Pro using Apple Clang 21.0.0. For the per-capture measurement, which reuses the acquisition plan while processing a new IQ capture, the table reports the median of the five process-level medians:

Workload	NEON	SME2	SME2 speedup over NEON (five-run range)
Small	0.0365 ms	0.0201 ms	1.77-1.90x
Medium	0.4997 ms	0.2274 ms	2.17-2.20x
Large	7.084 ms	3.045 ms	2.28-2.33x
Very large	41.320 ms	17.916 ms	2.27-2.38x

vivo X300 with MediaTek Dimensity 9500

The same benchmark protocol was also run at Arm on a vivo X300 powered by a MediaTek Dimensity 9500, with execution pinned to a single C1-Premium core:

Workload	NEON	SME2	SME2 speedup over NEON
Small	0.261 ms	0.134 ms	1.92-2.10x
Medium	3.591 ms	1.580 ms	2.14-2.42x
Large	53.028 ms	25.350 ms	2.08-2.70x
Very large	308.522 ms	150.391 ms	2.00-2.10x

The mobile measurements used the same benchmark settings as the M5 Pro measurements: two warm-ups, 15 samples, a 50 ms minimum per sample, and the default seed. Execution was pinned to a single C1-Premium core; the reported CPU frequency was 1.2 GHz at the start and end of each run and was not sampled continuously during execution.

In the fixed benchmark, the medium workload evaluates a 128-sample complex preamble across 4,096 timing hypotheses and nine CFO hypotheses, for 36,864 candidate correlations per capture. On the M5 Pro used in testing, this search takes about 0.50 ms with NEON and 0.23 ms with SME2. On the vivo X300, the same workload takes about 3.59 ms with NEON and 1.58 ms with SME2.

The mobile results make the practical impact clearer. On the vivo X300, SME2 approximately halves acquisition latency across the tested workloads. For the large workload, latency falls from about 53 ms to 25 ms, while the very-large workload falls from about 309 ms to 150 ms. For a field receiver, that headroom can be used either to return an acquisition result sooner or to search a broader timing and frequency uncertainty region within the same response-time budget.

These measurements cover fixed synthetic acquisition workloads on an Apple M5 Pro and a vivo X300. They demonstrate similar SME2 gains on both platforms, but they are not a general cross-device performance claim or a measurement of complete end-to-end satellite decoding. The large and very-large cases are stress sweeps; for substantially wider searches, FFT/filter-bank or hierarchical approaches may be algorithmically preferable.

Developer experience integrating SME2

From a developer's point of view, integrating and evaluating SME2 required careful refactoring but no specialized techniques.

The main steps were:

• Start with an independent scalar acquisition oracle so optimized paths have a trustworthy correctness target.
• Build and strengthen a NEON baseline before judging whether SME2 adds value.
• Structure the timing/CFO search so multiple acquisition hypotheses can be evaluated efficiently in parallel.
• Isolate the SME2 kernel in its own compilation path and use streaming mode, ZA, and VGx4 operations explicitly.
• Keep streaming-mode entry and exit around a meaningful batch of acquisition work rather than microscopic inner operations.
• Remove unnecessary input packing for consecutive timing grids so SME2 can read interleaved IQ directly.
• Gate every benchmark on correctness, inspect emitted assembly, and repeat measurements across independent processes.

The main lesson for developers was that SME2 should not be added to every vectorizable loop. The earlier Viterbi experiment was too small to justify its setup cost. Acquisition works better because it exposes a larger bank of independent correlations that can make effective use of SME2's wider scalable vector and ZA machinery. Choosing the right workload was as important as writing the intrinsics.

What this enables for field and mission developers

The Pocket Satcom Acquisition and Trust Lab is not a flight communications system. It is a ground-side developer and test tool for satellite commissioning, integration, rehearsals, and portable field checks.

That scope still maps to real space workflows. Acquisition evidence can help a team distinguish a timing or frequency-search problem from downstream demodulation, FEC, or application software before escalating the issue. The same pattern is useful in ground-side RPO and ISAM rehearsals, where communication problems can otherwise be difficult to separate from autonomy or mission-software behavior. For developers building a similar system, the main practical takeaways are:

• Make acquisition and basic communication checks portable enough for field and integration work.
• Use the same latency budget either for a faster acquisition result or a wider timing/CFO search.
• Treat ambiguity, CRC failure, and no-signal rejection as explicit outcomes rather than hiding them behind a single decoded payload.
• Use Arm SME2 for classical signal-processing workloads, not only ML kernels.
• Keep the portable host replay and future mobile implementation tied to the same native acquisition logic.

The measured headroom illustrates the field-use trade-off. In a future phone-plus-SDR receiver, it could support a faster acquisition response or a broader timing/CFO search without increasing the user's wait time. During a satellite pass or commissioning session, either option is useful: acquire sooner when the signal is where expected, or search a wider uncertainty region when Doppler, oscillator offset, or field conditions make the signal harder to find.

If a small developer tool can verify a satcom link and indicate when confidence should be reduced, it becomes a more useful companion for field testing and satellite commissioning.

Data sources and licensing

To keep the project easy to reproduce and safe to share:

• All checked-in IQ captures are deterministic synthetic fixtures.
• Fixture seeds, metadata, and hashes are recorded and verified.
• No proprietary or mission-derived RF recordings are distributed.
• The public project does not claim compatibility with a specific operational satellite waveform.
• Live RF reception can be added as a future input path without changing the acquisition benchmark's reproducibility contract.

Where this goes next

The next steps are:

• Add a supported live-SDR input path and extend acquisition toward fractional timing/CFO refinement and tracking.
• Extend the modem stack to additional modulation and coding schemes used by small-satellite links.
• Measure power, energy, and thermal behavior before making mobile-efficiency claims.
• Expand and calibrate the trust diagnostics using broader hardware and RF impairment datasets.

The public GitHub repository at https://github.com/sylvesterkaczmarek/satcom-fec-trust-lab provides the reproducible companion for this article: deterministic IQ fixtures, the acquisition-first replay pipeline, scalar, NEON, and SME2 acquisition implementations, correctness tests, validated IQ and metadata inputs, benchmark-report integrity checks, benchmark evidence, trust diagnostics, and an Android NDK command-line benchmark path. The repository includes the Android benchmark path, while the vivo X300 measurements reported in this article were collected by Arm. Live RF reception and mission-specific waveform support remain outside the supported public scope.

About the author

Professor Sylvester Kaczmarek is an Arm Ambassador and CEO of OrbiSky, working on trustworthy AI and autonomous space systems, with a focus on secure, low-power onboard intelligence for satellites and cislunar robotics. He builds developer-ready tools that turn cutting-edge research into flight-credible capabilities for real missions and industry teams.