VesperCSI: A High-Performance and Extensible CSI Acquisition Framework for Edge Wi-Fi Sensing

arXiv:2610.22581v1 [cs.NI] 15 Oct 2026

VesperCSI: A High-Performance and Extensible CSI Acquisition Framework for Edge Wi-Fi Sensing Kaan Baydemir

Sajjad Baghaee

Ilkay Ulusoy

REAL LAB EE Department, METU Ankara, Turkey kaan.baydemir@metu.edu.tr

REAL LAB EE Department, METU Ankara, Turkey sajjad@baghaee.com

REAL LAB EE Department, METU Ankara, Turkey ilkay@metu.edu.tr

Abstract—Channel State Information (CSI) captures fine-grained changes in Wi-Fi channel propagation and provides a foundation for device-free sensing applications such as activity recognition, localization, and occupancy detection. The development of such applications depends on an acquisition system that can handle high-rate CSI streams while remaining extensible to the requirements of individual experiments. VesperCSI is an open-source, GPL3.0-licensed redesign of FeitCSI for CSI acquisition with Intel AX200 and AX210 Wi-Fi interfaces. It targets high-rate acquisition on amd64 and aarch64 Linux hosts using fixed-capacity preallocated object pools and separate capture and consumer threads. A loadable plugin interface supports experimentspecific monitoring, storage, and processing. We evaluate VesperCSI and FeitCSI on Raspberry Pi CM4 receivers in a burst-traffic software crossover. At a 600-MHz all-core frequency ceiling and a target rate of 2500 frames/s, VesperCSI achieves mean sequence retention of 99.017–99.087% in 10,000-frame bursts, compared with 43.972–46.553% for FeitCSI. This ordering persists after exchanging the userspace programs between two receivers while retaining their respective drivers. The comparison therefore characterizes the tested software-and-driver packages rather than isolating userspace effects. These results support VesperCSI as a reusable acquisition component for edge-hosted Wi-Fi sensing under the evaluated workload and platform conditions. Index Terms—Channel State Information, Wi-Fi sensing, data acquisition, edge systems, Intel AX210.

I. I NTRODUCTION Wi-Fi Channel State Information characterizes the complex response of individual OFDM subcarriers and antenna paths. Its sensitivity to propagation changes has enabled device-free activity recognition, gesture sensing, localization, and occupancy estimation. The Linux 802.11n CSI Tool established practical CSI access on

commodity Intel hardware [1]. Subsequent platforms extended extraction to Atheros NICs [2], Broadcom devices [3], commercial 802.11ax hardware [4], and Intel AX200/AX210 interfaces [5], [6]. Although these developments have expanded CSI accessibility, acquisition on a compact host remains a systems problem. Bursty netlink input must be processed without per-record allocation, malformed or irrelevant records must be rejected before storage, and output or analysis work must not unnecessarily obstruct ingestion. VesperCSI addresses this gap through a highperformance, extensible acquisition program implemented in C. It supports amd64 and aarch64 Linux hosts, including Raspberry Pi-class systems equipped with a compatible PCIe Intel AX200 or AX210 interface. CSI access is provided through a CSI-enabled driver build based on Intel’s maintained backport-iwlwifi tree rather than through the driver distributed with the Linux kernel tree. VesperCSI supplies the userspace acquisition engine, configuration lifecycle, storage path, and experiment-control workflow above this driver boundary. In two preceding REAL Lab studies, we used FeitCSI to acquire CSI for an evaluation of preprocessing methods and for a dataset used to benchmark deep-learning architectures for Wi-Fi human activity recognition [7], [8]. Experience gained while conducting these studies, together with the requirement to move future experiments onto aarch64 edge hosts equipped with commodity Intel AX200/AX210 interfaces, motivated the development of a reusable acquisition tool tailored to this deployment setting. These requirements led to VesperCSI, which was developed as a hard fork of FeitCSI, an Intel AX200/AX210 CSI acquisition platform [5]. FeitCSI provides the project’s software foundation, while VesperCSI substantially redesigns the userspace internals around preallocated object pools, consumer-driven pool exchange, explicit overflow policies, and a loadable plugin interface intended for experiment-specific workflows. The contributions presented here concern these architectural changes and workflow extensions above the

TABLE I C OMPARISON OF REUSABLE CSI ACQUISITION PLATFORMS FROM PUBLIC DOCUMENTATION AND REPOSITORIES . BW DENOTES THE MAXIMUM DOCUMENTED CSI CHANNEL BANDWIDTH . ND DENOTES “ NOT DOCUMENTED ,” AND N/A DENOTES A NON - COMPARABLE EXECUTION MODEL . Tool

Source and license

BW

Acquisition hardware

Scripts and modifiable Serial reference source; no documented logger runtime plugin API

40 MHz

Intel 5300

ND

ND

Source and userspace Serial reference utilities; no documented logger runtime plugin API

40 MHz

Supported Atheros 802.11n devices using the modified ath9k path Selected Broadcom/Cypress Wi-Fi chips

ND

ND

Build

Yes

Broadcom BCM43684 802.11ax access point Intel AX200/AX210

N/A

ND

160 MHz Intel AX and COTS; 320 other NICs plus MHz SDR SDRs

Yes

160 MHz

Intel AX200/210/211 and Intel 5300; AX201 provisional

ND

40 MHz ESP32-family (chipmicrocontrollers dependent)

N/A

160 MHz

ZTE E2631 / SR6110 access points

ND

openwifi CSI Open source; [23], [24] AGPL-3.0 with GPL/BSD/ISC components

20 MHz

Xilinx Zynq/ZynqMP SDR/FPGA boards

N/A

VesperCSI [25]

160 MHz

Intel AX200/AX210

Yes

Linux Open source with 802.11n CSI mixed terms: MIT Tool [1], [9] userspace, GPLv2 kernel modifications, and separate Intel firmware terms Atheros CSI GPLv2 kernel; public Tool [2], [10] CSI logger source, license ND

Plugins or custom workflows

Concurrency

Nexmon CSI Public source; custom Firmware-patch ND [3], [11], [12] citation and framework, extraction military-use configuration, and restrictions; GPL-3.0 standard packet-capture base framework tools; no documented host plugin API AX-CSI [4], Research source Driver/firmware research ND [13] archive available on release; no documented request; license not plugin API stated FeitCSI [5] Open source; GPL-3.0 CLI, GUI, and Yes; receive modifiable source; no worker and documented plugin API synchronized plot queue

PicoScenes [6], [14], [15], [16]

Licensed core; open PDK components under GPL-3.0

IAX [18], [19]

MIT project code; GPLv2 driver and separate firmware terms

ESP-CSI [20] Open source; Apache-2.0

ZTECSITool Public source; no [21], [22] repository license identified

Yes; Multiple concurrently active runtime plugins, multithreaded user commands, APIs, SDR reception/decoding and measurement programs Operating modes, Serial C++ scripts, and TCP listener streaming support custom pipelines; no documented runtime plugin API ESP-IDF components RTOS task and examples can be model composed at build time; no documented host runtime plugin loader Python GUI and Yes; host command protocol are listener/display modifiable; no threads; no documented plugin API capture queue

Complete HDL, driver, FPGA and software stack extraction; supports source-level userspace polling customization; no documented runtime plugin API Open source; GPL-3.0 Runtime plugin interface Yes; separate with one active plugin capture and per process; bundled consumer threads monitoring and experiment-control workflows

80 MHz

160 MHz

160 MHz

amd64 aarch64 Deployment notes

Yes

Legacy Ubuntu/Linux environment and modified driver/firmware; MATLAB-oriented analysis Ubuntu PCs and OpenWrt-class routers; additional embedded architectures are hardware-specific Firmware-level extraction on Android devices, routers, and Raspberry Pi 3B+/4B/5

Modified firmware/driver on Asus RT-AX86U; reports sent to a host over UDP Yes (this Linux extraction and work) injection for 802.11a/g/n/ac/ax; project documentation claims amd64 and ARM availability No Broad experimental scope; installation requirements specify amd64 and explicitly exclude aarch64 [17] ND Ubuntu 20.04/22.04 with Linux 5.15.x; AX201 firmware absent and untested in the repository N/A

Native Xtensa or RISC-V embedded deployment; host computers are used only for control and analysis ND CSI-enabled AP firmware; a separate Python host configures reporting and receives UDP reports Yes Custom FPGA image (Zyn- and Linux driver; qMP) prioritizes PHY programmability over commodity-NIC portability Yes Linux with a supported PCIe NIC and CSI-enabled backport-iwlwifi; tested on Linux 6.8 and 6.12, including Debian 13, and on Raspberry Pi CM4 platforms

Intel CSI extraction path, with explicit acknowledgment of their FeitCSI origin. VesperCSI is distributed under GPL-3.0 [25]. The target deployment combines an aarch64 edge host, an Intel AX200/AX210 receiver, and a Linux 6.x kernel. Within this scope, this paper makes three contributions: (1) a redesigned, bounded-buffer acquisition pipeline that achieves higher sequence retention than the tested FeitCSI package under the evaluated burst-traffic conditions; (2) a versioned plugin interface, demonstrated through an experiment-specific activitylabeling workflow, that supports extensible monitoring, storage, and processing; and (3) corrections to implementation bugs inherited from FeitCSI. The retention comparison is package-level evidence and does not isolate the userspace changes from the respective drivers. The target platform also motivates the selection of a directly comparable acquisition baseline in Section VI. The remainder of the paper is organized as follows. Section II surveys existing CSI acquisition platforms and compares their capabilities and deployment requirements. Section III describes the AX200/AX210 firmware and CSI-enabled driver requirements for the target hardware. Section IV details VesperCSI’s capture architecture, bounded-buffer pipeline, record validation, and acquisition lifecycle. Section V presents the versioned plugin interface and demonstrates it with an infraredcontrolled activity-labeling workflow. Section VI positions VesperCSI for ARM edge acquisition and motivates the choice of comparison baseline. Section VII describes the experimental setup and evaluates burst retention, FeitCSI memory growth, and sustained VesperCSI acquisition. Section VIII discusses the study’s limitations and directions for future work. Section IX summarizes the system, principal findings, and scope of the evidence. II. CSI T OOL L ANDSCAPE CSI software spans acquisition, file parsing, signal processing, and sensing applications. This section focuses on reusable acquisition platforms: systems that obtain CSI from a NIC, access point, embedded radio, or SDR and make the measurements available to a host application. Parsers such as CSIKit and csiread remain useful downstream tools, but are excluded from the table because they do not configure a radio or acquire CSI directly [26], [27]. Table I presents a feature and deployment comparison of these acquisition platforms, rather than a head-tohead performance ranking. It focuses on source and license availability, extension mechanisms, acquisition concurrency, documented channel bandwidth, supported hardware and host architectures, and practical deployment constraints. The entries are based on project papers, documentation, and public repositories reviewed on

October 8, 2026. “Open source” is used only when the relevant implementation is distributed under an identifiable open-source license; a public repository without a license is reported as public source. “ND” means that the capability was not documented or could not be established from the reviewed materials, not that a private or experimental implementation does not exist. Architecture entries refer to the acquisition deployment rather than merely to a machine that can compile utilities or analyze resulting files; “Build” denotes build-host support only. Concurrency entries describe the referenced acquisition program or extraction path, not every component of the platform. Likewise, the absence of a documented plugin API does not rule out source-level extensions. A. Source Availability and Extensibility The reviewed projects expose several different forms of openness. FeitCSI, ESP-CSI, and openwifi publish source under GPL-3.0, Apache-2.0, and AGPL-3.0, respectively, with separate terms for bundled dependencies [5], [20], [23]. IAX’s MIT project license coexists with GPLv2 driver code and separate firmware terms. The Atheros kernel is GPLv2, but a license for its separate CSI logger was not identified [2], [10], [19]. The Linux 802.11n CSI Tool likewise has separate userspace, kernel, and Intel firmware terms [9]. Nexmon CSI contains custom file-level terms requiring citation and restricting military-related use, alongside the GPL-3.0 Nexmon framework [12]. PicoScenes retains a licensed core and publishes a GPL-3.0 plugin development kit; ZTECSITool’s repository has no identified license [15], [22]. AX-CSI’s research archive is request-based with unstated reuse terms [13]. VesperCSI provides its source under GPL-3.0 [25]. Extensibility must likewise be separated into runtime composition and source modification. PicoScenes has the most general documented runtime composition model: it discovers multiple plugins and can deliver measurements to multiple active plugin instances [14]. VesperCSI also exposes a runtime plugin boundary, but currently loads exactly one shared object per process. The selected plugin is initialized at startup and runs in the consumer path for each accepted record. The interface is intended to support experiment-specific monitoring, data handling, and control workflows. Only one plugin can currently be active within a process. Other tools permit useful custom workflows without an equivalent loader. FeitCSI and IAX expose commandline modes and modifiable source; Nexmon CSI uses a firmware-patching and packet-capture workflow; ZTECSITool provides a separate Python host GUI that configures AP-side CSI extraction and receives UDP reports [22]; ESP-CSI composes ESP-IDF components at build time; and openwifi exposes the HDL, driver, and

software stack. FeitCSI additionally provides a UDPsocket mode for interaction with external tools such as MATLAB [5]. This enables out-of-process processing, but CSI delivered to an external consumer must traverse the socket interface. In contrast, VesperCSI plugin callbacks operate directly on consumer-local records within the acquisition process, avoiding a mandatory socket hop for extensions that can run in process. This distinction may reduce data movement and protocolprocessing overhead, but its performance impact was not measured in this work.

The 160-MHz platforms are not interchangeable. AXCSI and ZTECSITool instrument specific access-point hardware; PicoScenes spans multiple commercial NICs and SDRs; and FeitCSI, IAX, and VesperCSI use Intel AX-series client interfaces. Within the latter group, AX200 covers 2.4/5-GHz operation and AX210 adds 6-GHz Wi-Fi 6E capability. Actual 6-GHz use also depends on the driver, firmware, access point, and regulatory configuration.

B. Concurrency and High-Rate Acquisition Concurrency is inconsistently documented across CSI projects, so the table does not infer multithreading from implementation language or advertised data rate. The Intel 5300 and Atheros reference loggers and IAX’s C++ listener receive and write records in serial loops. FeitCSI uses worker threads and a synchronized plotting queue, while file output runs in the receive callback [5], [9], [10], [19]. PicoScenes explicitly documents multithreaded SDR reception and decoding [16]. ZTECSITool has host listener/display threads, with CSV writing in the receive thread and plotting of the latest sample [22]. ESP-CSI uses ESP-IDF tasks; openwifi combines FPGA extraction with userspace polling [20], [24]. VesperCSI makes the concurrency boundary explicit. A capture thread removes CSI messages from the kernel-facing receive path and transfers accepted records through preallocated pools. A consumer thread then performs storage and plugin execution. This separation prevents ordinary file or plugin work from executing in the reception thread, while the fixed pool capacities make buffering and overflow behavior bounded. The architecture is therefore described as multithreaded for acquisition, not merely because auxiliary interface threads exist.

Architecture portability depends on both userspace code and the radio-facing driver or firmware. Older Intel and Atheros platforms document conventional PC or router environments but do not establish current aarch64 support. Nexmon CSI and ESP-CSI run close to their target Broadcom and ESP32 radios, while openwifi documents 64-bit acquisition on ZynqMP boards [24]. PicoScenes requires amd64 and explicitly excludes ARM [17]. IAX documents Ubuntu 20.04/22.04 and a Linux 5.15.x baseline, but its repository does not claim an aarch64 deployment [19]. FeitCSI advertises amd64 and aarch64 availability [5]; its aarch64 execution is demonstrated by the CM4 evaluation in this work. Generic PC or ARM support alone does not establish a particular 64-bit architecture. VesperCSI supports both amd64 and aarch64 Linux hosts, provided that the system can attach a compatible PCIe Intel AX200/AX210 interface and build the required CSI-enabled backport-iwlwifi driver. It has been verified with Linux 6.8 and 6.12, including Debian 13 deployments, and on Raspberry Pi Compute Module 4 platforms. These kernel versions are tested configurations rather than compatibility bounds. Operation on an older or newer kernel depends on whether the required backport-iwlwifi source can be compiled and loaded for that target kernel. This combination of two host architectures, 160-MHz Intel AX acquisition, an explicit two-thread data path, and a loadable workflow boundary distinguishes VesperCSI from source-modifiable loggers that provide no runtime extension interface. The driver and firmware requirements underlying this portability are discussed in the following section.

C. Bandwidth and Radio Generation The Linux 802.11n and Atheros tools are limited to 20/40-MHz 802.11n-era measurements, while Nexmon CSI documents extraction up to 80 MHz on supported Broadcom devices [2], [9], [11]. AX-CSI, FeitCSI, IAX, ZTECSITool, PicoScenes on supported commodity NICs, and VesperCSI reach 160 MHz, which is the maximum channel width of the Intel AX210 generation and a useful boundary for contemporary commodity 802.11ax CSI acquisition [4], [5], [6], [18], [21], [28], [29]. PicoScenes also documents 320-MHz SDR-based CSI measurement on suitable hardware [16], but that capability should not be interpreted as 320-MHz support by the Intel AX NICs. ESP-CSI remains an embedded, low-cost alternative at up to 40 MHz, whereas openwifi emphasizes an open and programmable PHY rather than wide commodity channels.

D. Host Architecture and Software Baseline

III. I NTEL AX200/AX210 F IRMWARE AND D RIVER R EQUIREMENTS The firmware and host driver have distinct roles in Intel AX-series operation. The AX200 and AX210 execute Intel microcode that is loaded by the Linux driver during device initialization. VesperCSI does not require custom replacement firmware: the compatible Intel firmware already supplied by the target distribution may be retained. If the required files are absent, they

can be obtained through the official linux-firmware distribution and placed in the distribution’s firmware directory, commonly /lib/firmware [30]. The standard distribution-provided iwlwifi driver, however, does not provide the CSI delivery interface required by VesperCSI. CSI acquisition therefore requires the target system’s wireless driver stack to be replaced with a CSI-enabled build based on Intel’s maintained iwlwifi/backport-iwlwifi.git repository. This backport tree contains the relevant iwlwifi, mac80211, and cfg80211 components and is retrieved from the Intel Linux Wireless repository hosted on git.kernel.org [31]. The resulting modules must be built for and installed on the target kernel, then loaded in place of the distribution’s original wireless modules before VesperCSI is started. Driver installation is consequently a required systempreparation step, while firmware replacement is not. The selected backport branch or commit must also be compatible with the target kernel; the Linux Wireless documentation notes that older backport revisions may not build or operate against newer kernels [30]. For reproducibility, a VesperCSI deployment should record the kernel version, firmware revision, and exact backport-iwlwifi commit used for acquisition. IV. V ESPER CSI I MPLEMENTATION A. System Architecture and Bounded Capture Pipeline VesperCSI incorporates radio configuration and process lifecycle management into the acquisition path. At startup, it identifies the selected wireless PHY, records and removes the existing interface, creates a monitor interface, applies the requested channel configuration, and enables CSI through the installed CSI-enabled backport-iwlwifi driver. It starts the consumer worker before the capture worker. A shared shutdown flag and a pollable pipe coordinate termination with the main thread and the kernel-facing receive loop. The pool, synchronization, and shutdown mechanisms described below separate reception from consumer work without implying lossless capture [25]. Fig. 1 presents the complete CSI dataflow. The Intel AX210 shown in the figure represents the supported AX-series source; the same software path is used with an AX200. CSI measurements produced by the NIC and its standard Intel firmware enter the CSI-enabled backport-iwlwifi driver, which delivers the frames to a kernel netlink queue. The VesperCSI producer receives frames from this queue, validates their structure, applies the configured filters, and pushes accepted records into the producer-owned pool. 1) Pool Layout and Memory Estimate: The acquisition state contains two identically sized, statically reserved pools. A rough estimate of their memory footprint

follows from the number of record slots and the size of the CSI objects stored in them. Memory sizes below are expressed in bytes and pool capacity as a number of records. The capacity of each pool is determined by two compile-time parameters. The nominal record rate used for sizing is denoted by Rmax and expressed in records/s. The corresponding nominal buffering window is denoted by Tmax and expressed in seconds. Their product defines N , the number of nodes and maximum queued-record count in one pool: N = Rmax × Tmax .

(1)

The two pools therefore contain 2 × N nodes in total. These parameters size the arrays; they do not enforce a runtime rate limit or trigger a timed handoff. Rmax is not a measured sustainable rate, and Tmax is not a guaranteed loss-free buffering duration. Each reserved node stores a CSI object containing a header and fixed-capacity data storage. Let Smax denote the maximum supported number of subcarriers. Let Atx and Arx denote the maximum numbers of supported transmit and receive antenna paths, respectively. The data array therefore reserves space for Smax × Atx × Arx subcarrier–path combinations. Each complex CSI coefficient is represented by a signed 16-bit in-phase (I) value and a signed 16-bit quadrature (Q) value, for a total of 4 bytes per combination. The maximum data-array size in bytes, denoted by D, is therefore D = 4 × Smax × Atx × Arx .

(2)

With H denoting the header length in bytes, the estimated storage per CSI record, C, is C = H + D = H + (4 × Smax × Atx × Arx ).

(3)

This sizing model excludes pointers, other bookkeeping fields, and alignment padding; C is therefore not an exact structure-size calculation. It describes the reserved header and data storage, rather than the variable serialized length of a particular measurement. A shorter payload does not shrink a reserved node. Since each pool reserves N record slots, its estimated CSI storage footprint P follows by multiplying the perrecord estimate by the pool capacity: P = N × C = Rmax × Tmax × C.

(4)

The total estimated CSI storage across both pools, Ptotal , is consequently Ptotal = 2P = 2Rmax Tmax C
= 2Rmax Tmax H + 4Smax Atx Arx .

(5)

Both P and Ptotal are expressed in bytes. The actual pool allocation additionally includes the omitted record

Hardware Source

VesperCSI User-Space Pipeline

Linux Kernel Datapath (Netlink)

Double Ring Buffer Buffer A

Intel AX210

Firmware

CSI source

Intel microcode

CSI Driver

Netlink Queue

Producer

modified iwlwifi

CSI frames

validate + filter push frames

Buffer B

producerowned

consumerowned

atomic ownership swap (no copy)

Physical

Kernel space

file Consumer

drain batches dispatch output

plugin (.so)

User space

CSI Data Flow Direction

Buffer Swap Operation

Fig. 1. End-to-end VesperCSI dataflow from the AX-series hardware and CSI-enabled driver to the userspace producer, double-buffer ownership exchange, consumer, and plugin and/or file output. The ownership swap transfers pool roles without copying queued records between pools; enqueue and dequeue operations still copy individual CSI objects. and queue-management overhead, including linked-list pointers, pool metadata, and padding. Initialization links unused nodes into a free list, and enqueue and dequeue reuse the reserved storage without per-record heap allocation by the pool. 2) Consumer-Driven Ownership Exchange: The producer inserts accepted records at the front of its pool; the consumer removes records from the back of its own pool, giving FIFO service within each batch. Insertion copies the CSI object into a free node. Removal copies it into a consumer-local object and returns the node to that pool’s free list before invoking output processing. Thus, the handoff avoids copying an entire batch between pools, but the record path is not zero-copy. A spinlock implemented using C11 atomics protects producer insertion and exchange of the two pool pointers. After a successful insertion, the producer sets an atomic data-available flag with release ordering, then releases the lock. The consumer drains its assigned pool without acquiring this lock. Only when dequeue reports that this pool is empty does it inspect the flag. If data are pending, the consumer acquires the shared lock, resets the flag, exchanges the pool pointers, and releases the lock. The formerly empty consumer pool becomes the new producer pool. No timer, minimum batch size, or full-pool threshold triggers an exchange: it occurs when the consumer is ready and producer data are available. When both pools contain no pending work, the consumer remains in a polling loop that checks whether producer data have become available. There is no conditionvariable or semaphore wake-up for this path. In contrast, the capture loop blocks in poll on the netlink socket and shutdown pipe. The polling design avoids a blocking wake-up in the consumer path, but does not establish negligible idle CPU usage. 3) Consumer Delay and Overflow: While the consumer processes a batch, the producer continues filling

its current pool; it does not force an early swap or wait for the batch to finish. It can nevertheless spin while the consumer holds the handoff lock. If no free node remains in the producer pool, the default policy removes that pool’s oldest queued record and reuses the released node for the new record. Free nodes in the consumer-owned pool are not borrowed before the next ownership exchange. Consequently, the producer’s immediate buffering headroom is limited by its own N node pool, not by the combined free space of both pools. A slow callback or output operation can therefore cause discards despite the separation of the two workers. 4) Shutdown and Pending Records: On receipt of an interrupt signal, the signal handler sets the shutdown flag and writes to the pipe, waking the main thread and the netlink polling loop. The main thread requests CSI disablement, joins the capture and consumer workers, unloads the plugin, removes the monitor interface, and attempts to restore the original station interface before closing the capture file and releasing resources. The consumer tests the shutdown flag at its outer loop boundary; it may finish a record already being processed, but does not explicitly drain either pool before exiting. Queued records can therefore remain unwritten at shutdown. Thread joining ensures worker termination, not queue drainage, and closing the file does not process those remaining records. Shutdown should accordingly be distinguished from a drain-and-flush operation. B. Record Validation and Filtering Each record is validated before admission to an object pool. The capture path verifies the netlink header, declared payload length, and maximum supported payload size. Optional filters constrain the transmitter MAC address, channel width, PHY format, and receive and transmit stream counts. An unrestricted mode disables all the filters. After copying a structurally valid payload, the

capture handler assigns a microsecond-resolution timestamp from the system’s real-time (wall-clock) clock, before the remaining checks and pool insertion. This is a userspace capture timestamp, not the time at which the consumer writes the record. The consumer invokes the active plugin callback synchronously on its local CSI object and then, if basefile output was requested, emits the header and payload using writev. Plugin processing and base-file output can therefore coexist; selecting a plugin does not itself disable the base file. The scatter/gather write avoids constructing another contiguous serialization buffer. The implementation checks the returned byte count and logs a warning at the configured verbosity on a short or failed write, but does not retry the unwritten remainder. Bounded queue storage therefore does not imply guaranteed record delivery to the output file. C. Plugin-Based Research Workflows The plugin interface lets experiments extend acquisition without modifying the capture core. Plugins can inspect accepted CSI records, monitor conditions, generate custom outputs, or coordinate external controls. Loaded at startup through the versioned SDK, they support experiment-specific workflows. Section V describes this interface and demonstrates it with infrared-controlled activity labeling. D. Inherited Issues and Implementation Corrections Review of the inherited FeitCSI acquisition path identified four avoidable sources of per-record memory and I/O overhead [5]. First, FeitCSI dynamically allocated individual CSI objects without releasing them after use, allowing memory consumption to grow. VesperCSI instead uses preallocated, fixed-capacity pool slots and reuses them, avoiding per-record heap allocation and bounding capturebuffer memory. Second, the inherited processing path converted every raw CSI payload into separate complex-value, magnitude, and phase arrays, although these arrays served only the plotting path. The coefficient-by-coefficient transformations were performed even when plotting was not needed. VesperCSI keeps these plotting-specific calculations out of its acquisition core; a plugin or downstream workflow can add them when needed. Third, FeitCSI opened and closed the output file for every record and wrote the header and payload separately. VesperCSI keeps the output file open during a capture session and emits the header and payload together from their existing buffers in a single vectored write. This reduces repeated file-opening and write-call overhead without requiring an extra serialized copy. Finally, FeitCSI printed a message for every arriving record and provided no way to silence this per-record

output. The resulting console I/O added work to the capture path. VesperCSI provides a command-line quiet option to suppress routine per-record messages. V. P LUGIN S YSTEM AND I NFRARED -C ONTROLLED ACTIVITY L ABELING VesperCSI plugins are Linux shared-object libraries that extend the acquisition program through a small, versioned interface. A plugin is compiled separately against the VesperCSI plugin SDK and loaded by the program’s dynamic loader at startup, before acquisition begins. This is runtime loading rather than compile-time inclusion: a compatible plugin can be built or replaced without rebuilding or relinking the acquisition executable. The loader checks for the required initialization, per-record callback, and destruction entry points. Initialization provides the plugin with its SDK version, logging facilities, and optional configuration path; destruction allows it to stop its workers and release resources when acquisition ends. The per-record callback is invoked synchronously by the consumer for each CSI record admitted to the consumer path. It receives the current CSI object and may inspect it, attach experiment metadata in pluginmanaged output, or perform other experiment-specific processing. Because the callback runs on the consumer thread, it is part of the record-processing path rather than an independent background task. If callback work takes longer than records arrive, the capture producer continues filling its own preallocated pool while the consumer is delayed. When that pool is exhausted, the default overflow policy discards its oldest queued record to admit a new one. Thus, a slow plugin can increase loss. The most feature-rich plugin developed for VesperCSI to date is its infrared-controlled activity-labeling plugin. The infrared-controlled labeling plugin demonstrates how this interface can combine CSI acquisition with a practical human-activity collection workflow. As shown in Fig. 2, a custom module attached to the Raspberry Pi CM4 provides an infrared receiver and GPIO-controlled indicators. An operator uses a handheld remote to control capture and select activity labels without interacting with the receiver through a separate computer interface. Commands can start, stop, or discard a capture, and change the current activity. The module’s LED and buzzer provide visual and audible feedback for capture and labeling state. The plugin tracks the capture state, the activity being performed, and the repetition number. While CSI is being recorded, it labels each measurement with the current activity and repetition, then stores that information alongside the CSI data in the same output stream. Users can configure activity durations, pauses, and the

- Infrared Receiver - Buzzer - Red LED

86 mm

153 mm

Intel AX210 Wi-Fi Card

Control Signal

10

2m

m

17

m

0m

Raspberry Pi CM4 with Remote Control Module

40 mm

Infrared Remote Controller

Fig. 2. Infrared-controlled activity-labeling setup. The Raspberry Pi CM4 case measures 153 mm in height (excluding the top module and antennas), 170 mm in width, and 102 mm in depth. The handheld remote controller measures 86 mm in height, 40 mm in width, 7 mm in depth; its depth extends perpendicular to the image plane and is not visible in the two-dimensional figure. The remote sends commands to an infrared receiver in a custom module attached to the CM4 through GPIO. The module provides visual and audible feedback during data collection. number of repetitions, supporting both operator-led and scheduled collection. Keeping these labels and collection boundaries with the recorded data reduces the need to reconstruct them from separate notes later. The plugin interface is not limited to activity labeling. Any extension that conforms to the SDK lifecycle and callback contract can add experiment-specific monitoring, storage, or control behavior. It therefore allows VesperCSI to support new research workflows without requiring changes to its core capture path, within the execution and buffering limits of the plugin model. VI. P OSITIONING FOR ARM E DGE ACQUISITION VesperCSI targets the intersection of Intel AX200/AX210 CSI acquisition, aarch64 edge deployment, and Linux 6.x compatibility. Its reported Linux 6.8 and 6.12 deployments demonstrate this combination, subject to a compatible CSI-enabled backport-iwlwifi build. These tested versions do not imply support for every Linux 6.x or subsequent kernel. Within the reviewed landscape, the relevant AX200/AX210 host-acquisition platforms are PicoScenes, IAX, FeitCSI, and VesperCSI; matching the radio alone does not establish that all four can serve as baselines on the same ARM testbed. The deployment requirements narrow this set. PicoScenes’ installation manual requires amd64 and explicitly states that ARM processors are unsupported [17]. Its exclusion from an ARM benchmark is therefore

a host-architecture constraint, not a lack of modernkernel support or Intel AX capability. IAX specifies a Linux 5.15.x API baseline for Intel AX extraction and explicitly identifies Ubuntu’s Linux 6.8 configuration as incompatible with that baseline [19]. Using IAX would consequently require a different kernel or additional porting, rather than a direct substitution within the Linux 6.x testbed considered here. Other acquisition platforms remain relevant to the broader sensing landscape but address different hardware configurations. ESP-CSI targets ESP32-family radios, Nexmon CSI targets Broadcom/Cypress devices, and AX-CSI and ZTECSITool target access-point hardware [11], [13], [20], [22]. The Linux 802.11n and Atheros tools use earlier-generation radios, while openwifi uses an FPGA/SDR platform [2], [9], [23]. Benchmarking these systems would change the radio or execution model as well as the acquisition software. Such comparisons can inform platform selection, but cannot isolate userspace acquisition behavior on an Intel AX-based ARM host. FeitCSI is therefore the closest directly applicable baseline among the reviewed tools: it supports Intel AX200/AX210 acquisition and advertises aarch64 availability [5], and both programs were evaluated on CM4 hosts running Linux 6.12, with the device-specific driver stacks described in Section VII. VesperCSI emphasizes bounded preallocated buffering, separation of reception from consumer work, and a loadable interface for research workflows; FeitCSI offers CLI/GUI operation and source-level customization without a documented equivalent plugin API [5]. These design differences motivate comparison under constrained CPU resources, but do not alone establish a performance advantage. Section VII evaluates that question within the shared testbed rather than asserting a general ranking across CSI platforms. VII. B ENCHMARKING B URST-T RAFFIC AND L ONG -D URATION CSI ACQUISITION The evaluation consists of three experiments. The first compares the burst-traffic acquisition performance of VesperCSI and FeitCSI. The second examines FeitCSI memory growth and swapping at 600 MHz and records a higher-ceiling acquisition-process crash under the same extended workload. The third evaluates VesperCSI over repeated hour-scale sessions to characterize sustained sequence retention and resource use. A. Receiver Platforms The evaluation compared VesperCSI and FeitCSI on two identical Raspberry Pi Compute Module 4 hosts. Each contained a Broadcom BCM2711 quad-core Cortex-A72 (ARMv8, 64-bit) SoC rated at 1.5 GHz, 2 GB LPDDR4-3200 SDRAM, and 8 GB eMMC storage.

Both receivers used Intel AX210 Wi-Fi cards for CSI acquisition and Debian 13 (trixie). The receivers operated simultaneously at equal distances from the transmitter. Device A used Intel’s public iwlwifi stack, whereas device B used the driver distributed with FeitCSI. Table II records the exact driver, kernel, compiler, and userspace versions used in the evaluation. Both receivers therefore used the same Linux major and minor kernel version, 6.12, while retaining the different patch and Raspberry Pi build revisions shown in Table II. Experiments 1 and 2 wrote their capture files to the receivers’ onboard eMMC storage. During Experiment 2, the configured swap area was RAMbacked rather than mapped to the eMMC or another secondary-storage device. Consequently, SwapPSS in that experiment describes logical process pages placed in the RAM-backed swap mechanism and does not represent secondary-storage traffic. All VesperCSI evaluation runs used the default worker-scheduling and overflow behavior. CPU affinity, and real-time scheduling were not enabled. If the producer-owned pool became full, the default policy discarded its oldest queued record and reused that node for the incoming record. Table III records the compile-time pool-sizing parameters used for the VesperCSI benchmark build. The derived quantities follow the storage model in Subsection IV-A1. They describe the reserved CSI header and payload capacity rather than measured resident PSS and exclude node metadata, pointers, alignment padding, and other process allocations. The resulting estimate is 41,760,000 B (39.83 MiB) per pool and 83,520,000 B (79.65 MiB) across both pools. B. Traffic Generation & Radio Characteristics Traffic was generated from an amd64 PC running Debian 13 using a dual-antenna USB Wi-Fi adapter based on the MediaTek MT7612U chipset. The adapter was configured in monitor mode, and a custom C program injected IEEE 802.11 probe-response management frames in VHT format. The injector requested an 80-MHz bandwidth, MCS 0, two spatial streams, a long guard interval, and no link-layer acknowledgment through its 22-byte radiotap header. MCS 0 was used as a robust modulation and coding configuration to reduce PHY decoding or frame-check-sequence failures that could otherwise appear as acquisition losses. With the benchmark SSID CSI-VHT, each constructed probe response comprised a 131-byte IEEE 802.11 frame before any hardware-added FCS, or 153 bytes in the local injection buffer including the radiotap header. The program controlled inter-frame timing according to a user-specified target traffic rate, providing fine-grained and repeatable scheduling. The

primary channel was channel 36 at 5180 MHz in the 5-GHz band. Probe responses were selected because preliminary tests showed that not all injected frames, such as clear-to-send (CTS), produce CSI reports at the receivers, whereas probe responses did. The receiver/destination address was the dummy address 03:00:00:00:00:01, which was not assigned to either receiver. The two least-significant bits of its first octet identify it as a locally administered multicast address. A probe response does not solicit a client response, and the multicast destination and explicit no-acknowledgment request prevented acknowledgmentbased retransmissions and did not intentionally elicit traffic from surrounding devices. This also preserved the uniqueness required by the benchmark. The source MAC address strategy is described in the following subsection. A iw dev command snapshot for the MT7612U transmitter reported a transmit-power setting of 18.00 dBm. The benchmark software did not explicitly set transmit power, so this was the value reported for the adapter under its driver and regulatory configuration. It is a configured, driver-reported setting, not an independent measurement of radiated power. Both Raspberry Pi receivers were positioned approximately 2 m from the transmitter and placed immediately side by side, with no intentional gap between the receiver units. C. Sequence Numbers Inside MAC Addresses CSI data delivered to the userspace acquisition program do not contain an injector-controlled field, other than a MAC address, that can be used for sequence tracking. We therefore divide the injected source MAC address into a fixed magic prefix and a configurable sequence-number suffix. The magic bytes distinguish the benchmark traffic from unrelated traffic in the surrounding environment, while the suffix is varied for each injected frame. The boilerplate source address is AA:BB:CC:DD:EE:FF, and the number of loworder bytes reserved for sequence numbering can be selected according to the experiment. For example, with a two-byte sequence field, the address takes the form AA:BB:CC:DD:XX:XX, where XX:XX represents an unsigned 16-bit sequence number. Comparing the received sequence identifiers with the expected injected sequence provides deterministic identification of numbered packets that were dropped before being retained by the acquisition program. D. CPU Constraints Before each experimental condition, both Raspberry Pi receivers were configured with the required CPUfrequency ceiling through the Linux sysfs interface

TABLE II R ECEIVER SOFTWARE CONFIGURATIONS USED IN THE EVALUATION . Component

Device A

Device B

Driver

Intel iwlwifi-stack-public: master:14952:c9d28532 6.12.47+rpt+rpi-v8 Debian 13 14.2.0 2.0.0 1.0.0-alpha.83

FeitCSI iwlwifi 2.0.0

Linux kernel Distribution GCC FeitCSI userspace VesperCSI userspace

6.12.75+rpt+rpi-v8 Debian 13 14.2.0 2.0.0 1.0.0-alpha.83

TABLE III V ESPER CSI POOL CONFIGURATION USED IN THE EVALUATION . Quantity Definition Rmax Tmax Atx Arx Smax H N D C P Ptotal

Raspberry Pi Device A

Value

Nominal sizing rate 1000 records/s Nominal buffering window 10 s Maximum transmit paths 2 Maximum receive paths 2 Maximum subcarriers 244 Header storage 272 B Rmax Tmax 10,000 4Smax Atx Arx 3,904 B H +D 4,176 B NC 39.83 MiB 2P 79.65 MiB

/sys/devices/system/cpu/cpu*/cpufreq/ scaling_max_freq, where the wildcard selects cores 0–3. The ceilings used throughout the experiments were 600, 800, 1000, 1200, and 1500 MHz. The same ceiling was applied to all four cores simultaneously, imposing a system-wide frequency constraint rather than limiting individual cores independently. E. General Benchmark Methodology The two Raspberry Pi receivers are connected through an Ethernet switch to the main computer, and each receiver has a fixed IP address. The USB Wi-Fi adapter used for frame injection is connected directly to the main computer. Figure 3 shows this arrangement, which separates the wired control network from the wireless benchmark traffic. A Bash control script running on the main computer serves as the benchmark controller. It issues commands to the receivers over SSH and coordinates acquisition, resource monitoring, sequence verification, and collection of results. Before each campaign, the controller records the selected configuration and checks remote access, required utilities, CPU-frequency controls, and resource-sampling interfaces. It executes the configured CPU-ceiling and traffic-rate combinations sequentially, repeating each

USB Wi-Fi Adapter

Desktop Computer

Layer 2 Switch

Raspberry Pi Device B

Fig. 3. Benchmark testbed topology. Two Raspberry Pi CM4 receivers connect over Ethernet through a Layer 2 switch to the desktop computer, which controls the trials. The USB Wi-Fi adapter attached to the desktop injects the wireless benchmark traffic. condition as specified. Either one or both receivers can be enabled, supporting single-tool experiments and paired acquisition within the same workflow. When both receivers are active, they observe the same injected traffic. Frame counts, software assignments, repetition counts, and timing parameters are specified separately for each experiment. Each trial begins with system CPU and temperature sampling to establish a pre-acquisition baseline. The controller launches a new acquisition process on each enabled receiver and initiates process CPU and memory sampling. Acquisition processes are launched sequentially over SSH; injection begins after a startup interval and a process-liveness check. CSI records are written locally on the receivers. During acquisition, background samplers record process CPU use, resident and swapped process memory, per-core system CPU activity, and SoC temperature. Elapsed times are measured relative to each receiver’s trial baseline. Following completion of frame injection, the controller waits for the configured post-injection interval, intended to give any frames queued in the transmitter’s kernel transmit path time to drain. This fixed delay does not verify receiver-side delivery or confirm that CSI records have reached the capture files. The controller then checks acquisition-process liveness and invokes a

sequence-verification program on the capture file of each receiver whose acquisition process remains active. The program compares the sequence identifiers encoded in source MAC addresses with the expected sequence and reports unique receptions, missing identifiers, duplicates, and out-of-range identifiers. Following verification, acquisition processes are stopped, with stronger termination signals used when necessary. System CPU and temperature sampling extends briefly beyond process termination to provide post-acquisition context. Configuration snapshots, injection and acquisition logs, verification output, and resource traces are collected on the main computer and organized by condition and repetition. A configurable cooldown interval can be applied between trials. Acquisition-process failures are recorded separately from packet loss. A receiver whose acquisition process fails is excluded from subsequent trials, while acquisition on any remaining active receiver continues. F. Experiment 1: Burst-Traffic Comparison Experiment 1 compares the retention of numbered CSI records and the associated host-resource demands under short, finite traffic workloads. Two campaigns exchange the acquisition programs between the receivers: assignment I places VesperCSI on device A and FeitCSI on device B, whereas assignment II places FeitCSI on device A and VesperCSI on device B. Within each campaign, both receivers observe the same injected burst. Each of the five all-core CPU ceilings, 600, 800, 1000, 1200, and 1500 MHz, is combined with seven target rates, 100, 200, 500, 1000, 1500, 2000, and 2500 frames/s. Ten consecutive repetitions of each condition inject 10,000 frames, with four source-MAC bytes reserved for sequence numbering. The resulting dataset contains 350 paired trials per assignment, or 700 injected bursts and 1400 receiver observations in total. All injector logs report 10,000 successful sendto calls to the transmitter interface. This software-side count does not verify over-the-air transmission or reception; receiver captures are assessed separately by sequence verification. Both campaigns contain complete verification results without recorded collector crashes. The configured startup and post-injection drain intervals are 5 and 10 s, respectively. The nominal injection duration consequently varies from approximately 100 s at 100 frames/s to 4 s at 2500 frames/s. The configured inter-frame intervals are 10,000, 5000, 2000, 1000, 667, 500, and 400 µs, respectively; rounding to integer microseconds gives 1499.25 frames/s for the nominal 1500frames/s condition. The crossover retains the hardware and driver associated with each device; it exchanges the userspace tools rather than independently varying the drivers. Agreement between assignments therefore supports the robustness

of the observed ordering on these two device/driver combinations, but does not isolate the contribution of each acquisition component. The campaigns are sequential, and the repeated conditions are not randomized. Results below are descriptive summaries of the retained trials, without an assumption that consecutive repetitions provide independent realizations of the wireless environment. 1) Sequence Retention Across CPU and Traffic Conditions: For trial j, the verifier counts the distinct expected sequence identifiers from 0 through 9,999 found in each receiver’s capture file; denote this count by Uj . The missing-record count is Dj = 10,000 − Uj , and the corresponding loss percentage is 100Dj /10,000. Thus, retention measures which expected identifiers appear in the saved capture, not where an absent frame was lost. No duplicate or out-of-range identifiers are reported in either campaign. Table IV gives the mean missingrecord count and its sample standard deviation across ten repetitions for every CPU/rate combination. The standard deviations describe variation between trials. Sequence accounting does not establish whether a missing identifier was lost over the radio link, in firmware, in the driver, or in userspace. Figure 4 shows that VesperCSI has a lower mean missing-record percentage in all 35 configurations under each assignment. Its condition means range from 0.077 to 1.166% in assignment I and from 0.046 to 0.999% in assignment II. FeitCSI’s corresponding ranges are 0.313– 53.447% and 0.231–56.028%. At the most constrained high-rate condition, 600 MHz and 2500 frames/s, VesperCSI loses a mean of 98.3 records (0.983%) on device A and 91.3 records (0.913%) on device B. FeitCSI loses 5344.7 records (53.447%) on device B and 5602.8 records (56.028%) on device A. Thus, the large separation at this condition persists after exchanging the programs between devices. Increasing the CPU ceiling reduces FeitCSI’s mean loss at the highest traffic rate: at 1500 MHz and 2500 frames/s, the percentages fall to 17.113% and 16.199% in assignments I and II, respectively. The same conditions yield 1.080% and 0.984% for VesperCSI. VesperCSI also exhibits higher losses at the upper traffic rates than at several lower-rate conditions, and its response to CPU frequency is not uniformly monotonic. The results therefore demonstrate improved retention within the tested configuration rather than lossless capture or a universal performance bound. At 100 frames/s, the absolute separation is much smaller, with both tools losing less than 0.8% on average in every condition. 2) Process CPU Occupation and Memory Footprint: Resource traces are summarized using each receiver’s local elapsed time and the controller’s recorded active phase. This phase extends from collector startup to

TABLE IV E XPERIMENT 1: MISSING EXPECTED SEQUENCE IDENTIFIERS PER 10,000- FRAME TRIAL . E NTRIES GIVE MEAN ± SAMPLE STANDARD DEVIATION OVER TEN REPETITIONS . A SSIGNMENTS ARE REPORTED SEPARATELY. CPU VALUES ARE ALL - CORE FREQUENCY CEILINGS . Assignment I

Assignment II

CPU (MHz) Target (Hz) VesperCSI on A FeitCSI on B VesperCSI on B FeitCSI on A 600 600 600 600 600 600 600

100 200 500 1000 1500 2000 2500

18.8 ± 7.1 13.4 ± 5.5 7.7 ± 4.0 9.2 ± 4.2 28.5 ± 3.8 57.0 ± 12.3 98.3 ± 13.2

47.8 ± 13.6 258.7 ± 9.8 837.7 ± 99.4 1328.1 ± 87.1 2399.6 ± 183.9 4118.4 ± 112.2 5344.7 ± 180.8

23.5 ± 9.8 10.7 ± 3.6 6.1 ± 2.1 7.7 ± 3.5 18.7 ± 4.9 46.7 ± 7.8 91.3 ± 11.7

75.0 ± 17.7 376.2 ± 23.1 837.3 ± 38.3 1529.0 ± 23.5 2647.2 ± 104.1 4483.6 ± 120.5 5602.8 ± 66.4

800 800 800 800 800 800 800

100 21.5 ± 11.5 37.2 ± 18.6 200 12.5 ± 5.6 185.8 ± 33.7 500 9.2 ± 7.3 636.0 ± 49.3 1000 8.8 ± 3.1 940.3 ± 88.2 1500 25.7 ± 7.5 1616.9 ± 118.7 2000 57.1 ± 9.5 2603.1 ± 338.4 2500 114.8 ± 21.8 3786.1 ± 160.3

12.6 ± 3.7 8.8 ± 4.7 4.7 ± 2.6 6.8 ± 1.0 23.6 ± 8.7 49.7 ± 8.4 98.2 ± 11.4

43.4 ± 34.2 250.5 ± 30.3 655.5 ± 55.2 923.3 ± 65.9 1538.0 ± 74.2 2634.8 ± 210.2 3984.6 ± 121.3

1000 1000 1000 1000 1000 1000 1000

100 200 500 1000 1500 2000 2500

34.8 ± 11.3 161.7 ± 30.9 566.6 ± 43.8 827.2 ± 60.6 1258.0 ± 166.9 1845.8 ± 280.4 2533.1 ± 438.3

14.3 ± 4.0 7.7 ± 3.2 6.2 ± 4.6 7.2 ± 3.4 22.3 ± 3.9 50.8 ± 8.8 99.9 ± 10.0

39.9 ± 45.8 195.9 ± 58.1 539.7 ± 41.8 862.8 ± 319.7 1245.3 ± 91.7 1800.8 ± 215.9 2617.2 ± 197.9

1200 1200 1200 1200 1200 1200 1200

100 17.8 ± 3.7 36.4 ± 22.8 200 12.4 ± 4.9 129.2 ± 24.0 500 8.7 ± 7.9 482.6 ± 40.6 1000 8.2 ± 2.0 748.9 ± 37.9 1500 24.5 ± 5.6 1001.9 ± 47.7 2000 52.8 ± 9.6 1414.9 ± 191.8 2500 116.6 ± 36.9 1984.3 ± 281.7

13.8 ± 3.3 7.9 ± 4.6 5.0 ± 2.4 5.8 ± 3.6 22.0 ± 4.2 49.5 ± 7.0 96.3 ± 12.2

23.1 ± 7.7 148.9 ± 47.3 447.9 ± 20.1 690.9 ± 123.0 984.4 ± 45.3 1334.8 ± 134.3 2081.2 ± 611.3

1500 1500 1500 1500 1500 1500 1500

100 19.1 ± 8.2 31.3 ± 25.9 200 11.7 ± 3.2 116.5 ± 28.9 500 8.0 ± 5.0 395.6 ± 34.4 1000 8.0 ± 3.0 613.4 ± 42.9 1500 23.9 ± 10.5 834.3 ± 35.6 2000 61.4 ± 16.5 1146.4 ± 83.1 2500 108.0 ± 26.8 1711.3 ± 217.6

13.6 ± 3.7 7.0 ± 2.4 6.9 ± 2.6 4.6 ± 2.0 19.0 ± 2.4 52.3 ± 6.7 98.4 ± 19.4

44.1 ± 48.5 89.0 ± 11.2 393.3 ± 48.7 579.7 ± 38.8 778.2 ± 69.7 1326.8 ± 706.6 1619.9 ± 262.7

18.9 ± 5.8 11.7 ± 3.6 11.4 ± 6.4 8.2 ± 2.9 22.3 ± 6.0 48.4 ± 6.3 86.0 ± 11.6

the post phase after collector termination and includes startup, injection, drain, verification, and termination overhead. The traces do not provide separate injection boundaries, so these summaries are not restricted to the interval during which frames are transmitted. CPU and memory sampling are configured at 10 Hz, although sampler execution and scheduling add overhead to the nominal sampling interval. For each trial, mean process

CPU occupation is computed from the change in process CPU ticks divided by the elapsed span between its first and last active process samples. Values are normalized so that 100% denotes one fully occupied logical core. All four cores remain available with the same frequency ceiling; the recorded launch commands impose no single-core affinity. CPU normalization therefore does not imply that the process is pinned to one core.

Assignment I: FeitCSI on B

0.19

0.13

0.08

0.09

0.29

0.57

0.98

800

0.21

0.12

0.09

0.09

0.26

0.57

1.15

1000

0.19

0.12

0.11

0.08

0.22

0.48

0.86

1200

0.18

0.12

0.09

0.08

0.24

0.53

1.17

1500

0.19

0.12

0.08

0.08

0.24

0.61

1.08

100

200

500

1000

1500

2000

2500

600

0.48

2.59

8.38

13.28

24.00

41.18

53.45

800

0.37

1.86

6.36

9.40

16.17

26.03

37.86

1000

0.35

1.62

5.67

8.27

12.58

18.46

25.33

1200

0.36

1.29

4.83

7.49

10.02

14.15

19.84

1500

0.31

1.17

3.96

6.13

8.34

11.46

17.11

100

200

500

1000

1500

2000

2500

60.0

40.0

20.0

Target traffic rate (frames/s)

Target traffic rate (frames/s)

Assignment II: VesperCSI on B

Assignment II: FeitCSI on A

0.23

0.11

0.06

0.08

0.19

0.47

0.91

800

0.13

0.09

0.05

0.07

0.24

0.50

0.98

1000

0.14

0.08

0.06

0.07

0.22

0.51

1.00

1200

0.14

0.08

0.05

0.06

0.22

0.49

0.96

1500

0.14

0.07

0.07

0.05

0.19

0.52

0.98

100

200

500

1000

1500

2000

2500

CPU ceiling (MHz)

CPU ceiling (MHz)

5.0 600

600

0.75

3.76

8.37

15.29

26.47

44.84

56.03

800

0.43

2.50

6.55

9.23

15.38

26.35

39.85

1000

0.40

1.96

5.40

8.63

12.45

18.01

26.17

1200

0.23

1.49

4.48

6.91

9.84

13.35

20.81

1500

0.44

0.89

3.93

5.80

7.78

13.27

16.20

100

200

500

1000

1500

2000

2500

1.0

Target traffic rate (frames/s)

0.1

Mean missing sequences (%) — common power scale

600

CPU ceiling (MHz)

CPU ceiling (MHz)

Assignment I: VesperCSI on A

0.0

Target traffic rate (frames/s)

Fig. 4. Mean missing-sequence percentage over ten repetitions for every Experiment 1 condition. Rows distinguish the two software assignments and columns distinguish the tools. Cell annotations provide the percentages; all panels share the same nonlinear color scale to retain visibility of sub-percent losses. Labels A and B denote Device A and Device B, respectively; the two Raspberry Pi CM4 receivers are shown in Fig. 3. Memory measurements are proportional set size (PSS) and proportional swapped memory (SwapPSS) from /proc/PID/smaps_rollup. For each trial, the memory figure and the M columns of Tables V and VI use the sample mean of PSS + SwapPSS, with both values summed at each sampling instant and converted from KiB to MiB. This combined metric accounts for process-attributed resident and swapped pages, including proportional shares of shared pages; it does not measure simultaneously occupied physical RAM. Tables V and VI report assignments I and II separately, with one row for each of the 35 CPU-ceiling and target-rate combinations. Each entry gives mean ± sample standard deviation of ten trial summaries for CPU occupation, mean combined memory, or baselinereferenced temperature rise. The SD uses denominator 10 − 1 and describes repetition variability within that configuration; trials from different traffic rates are not pooled. The resource figures show the same condition means and between-trial sample SDs. These SDs are not standard errors, confidence intervals, or variation among samples within a trace. Figure 5 shows that VesperCSI occupies approxi-

mately one logical core throughout the sweep: its condition means span 98.86–100.99% across the two assignments. FeitCSI’s condition means span 4.51–19.53%. At 600 MHz and 2500 frames/s, Tables V and VI give VesperCSI CPU occupation of 99.52 ± 0.21% in assignment I and 98.86 ± 0.29% in assignment II, compared with 12.39 ± 0.38% and 11.51 ± 0.26% for FeitCSI, respectively. The higher CPU occupation of VesperCSI accompanies its improved retention but also represents a resource cost that remains visible at the lower traffic rates. Conversely, the lower active-phase occupation of FeitCSI does not imply a more efficient acquisition path: the tools retain different numbers of records, and the measurement includes periods without injected traffic. These averages cannot establish the CPU service time per retained record or explain FeitCSI’s losses. Small deviations around 100% can reflect multithreaded execution and the finite resolution of CPU-tick and elapsedtime measurements. Figure 6 shows a substantially smaller and less condition-dependent combined process-memory footprint for VesperCSI. Its condition means of trial-mean PSS + SwapPSS range from 78.63 to 80.38 MiB,

TABLE V E XPERIMENT 1 RESOURCE SUMMARIES , ASSIGNMENT I. E ACH CPU/ TARGET- RATE / TOOL ENTRY GIVES MEAN ± SAMPLE STANDARD DEVIATION ACROSS TEN REPETITIONS OF THAT CONFIGURATION . C: TRIAL MEAN PROCESS CPU PERCENTAGE NORMALIZED TO ONE LOGICAL CORE ; M : TRIAL SAMPLE MEAN OF PSS + S WAP PSS IN M I B, SUMMED AT EACH SAMPLING INSTANT; ∆T : TRIAL MEAN ACTIVE S O C TEMPERATURE MINUS ITS MEAN BASELINE IN ◦ C. A LL MEASURES SPAN THE CONTROLLER ’ S ACTIVE PHASE , INCLUDING STARTUP, INJECTION , DRAIN , VERIFICATION , AND TERMINATION . SD S DESCRIBE BETWEEN - TRIAL VARIATION WITHIN EACH CONFIGURATION , NOT STANDARD ERRORS OR CONFIDENCE INTERVALS . VesperCSI on A CPU (MHz) Target (Hz)

C (%)

M (MiB)

FeitCSI on B ◦

∆T ( C)

C (%)

M (MiB)

∆T (◦ C)

600 600 600 600 600 600 600

100 100.04 ± 0.20 78.70 ± 0.13 2.03 ± 0.13 8.06 ± 0.08 200 100.59 ± 0.10 78.68 ± 0.05 1.84 ± 0.09 12.26 ± 0.04 500 100.54 ± 0.31 78.76 ± 0.30 1.73 ± 0.06 17.33 ± 0.31 1000 100.42 ± 0.18 78.73 ± 0.03 1.64 ± 0.04 19.53 ± 0.27 1500 99.56 ± 0.64 79.35 ± 1.20 1.63 ± 0.07 18.10 ± 0.39 2000 99.30 ± 1.16 80.38 ± 4.88 1.64 ± 0.06 14.84 ± 0.26 2500 99.52 ± 0.21 78.90 ± 0.04 1.61 ± 0.06 12.39 ± 0.38

216.92 ± 0.48 1.08 ± 0.26 220.10 ± 0.53 0.91 ± 0.06 221.81 ± 1.88 0.95 ± 0.06 220.58 ± 2.43 0.97 ± 0.08 200.20 ± 4.50 0.99 ± 0.06 161.02 ± 3.15 0.93 ± 0.07 131.80 ± 4.29 0.99 ± 0.06

800 800 800 800 800 800 800

100 100.27 ± 0.10 78.65 ± 0.04 2.54 ± 0.51 6.39 ± 0.05 200 100.44 ± 0.22 78.70 ± 0.19 2.13 ± 0.05 9.80 ± 0.06 500 100.74 ± 0.21 78.68 ± 0.05 2.07 ± 0.08 14.34 ± 0.22 1000 100.42 ± 0.33 78.80 ± 0.31 2.07 ± 0.11 16.43 ± 0.24 1500 99.94 ± 0.22 79.08 ± 0.80 2.05 ± 0.08 16.24 ± 0.34 2000 99.97 ± 0.29 78.82 ± 0.12 2.05 ± 0.08 14.59 ± 0.49 2500 99.56 ± 0.47 78.81 ± 0.06 2.09 ± 0.07 12.73 ± 0.35

214.86 ± 0.57 1.20 ± 0.28 218.94 ± 1.10 1.01 ± 0.06 223.50 ± 1.41 1.07 ± 0.05 226.74 ± 2.64 1.09 ± 0.06 217.07 ± 2.25 1.10 ± 0.07 196.09 ± 8.53 1.07 ± 0.06 168.73 ± 4.00 1.09 ± 0.08

1000 1000 1000 1000 1000 1000 1000

100 100.50 ± 0.15 78.65 ± 0.03 2.93 ± 0.34 5.56 ± 0.04 213.77 ± 0.80 1.11 ± 0.18 200 100.76 ± 0.04 78.64 ± 0.01 2.60 ± 0.08 8.49 ± 0.10 218.29 ± 0.69 1.03 ± 0.06 500 100.91 ± 0.17 78.68 ± 0.10 2.38 ± 0.07 12.55 ± 0.17 223.40 ± 1.57 1.12 ± 0.06 1000 100.70 ± 0.19 78.71 ± 0.07 2.31 ± 0.09 14.63 ± 0.13 227.98 ± 1.80 1.11 ± 0.07 1500 100.38 ± 0.17 78.72 ± 0.04 2.31 ± 0.08 14.70 ± 0.31 223.57 ± 3.77 1.15 ± 0.06 2000 100.00 ± 0.25 78.75 ± 0.05 2.36 ± 0.06 14.13 ± 0.31 212.52 ± 7.02 1.16 ± 0.07 2500 99.85 ± 0.19 78.79 ± 0.03 2.32 ± 0.07 13.08 ± 0.66 198.04 ± 10.40 1.10 ± 0.10

1200 1200 1200 1200 1200 1200 1200

100 100.42 ± 0.09 78.67 ± 0.05 3.38 ± 0.35 5.14 ± 0.05 200 100.67 ± 0.21 78.72 ± 0.12 2.97 ± 0.07 7.76 ± 0.08 500 100.99 ± 0.10 78.65 ± 0.00 2.75 ± 0.08 11.44 ± 0.13 1000 100.40 ± 1.26 78.67 ± 0.01 2.64 ± 0.10 13.42 ± 0.17 1500 100.22 ± 0.62 79.30 ± 1.93 2.60 ± 0.10 13.81 ± 0.13 2000 100.09 ± 0.22 78.72 ± 0.02 2.60 ± 0.11 13.67 ± 0.13 2500 99.77 ± 0.93 80.07 ± 4.17 2.69 ± 0.10 12.96 ± 0.30

213.31 ± 0.74 1.11 ± 0.13 217.27 ± 0.65 1.06 ± 0.09 223.31 ± 0.84 1.13 ± 0.08 227.98 ± 1.71 1.19 ± 0.08 226.87 ± 1.53 1.23 ± 0.06 220.78 ± 4.40 1.23 ± 0.10 208.47 ± 6.68 1.24 ± 0.07

1500 1500 1500 1500 1500 1500 1500

100 100.26 ± 0.29 78.72 ± 0.11 4.13 ± 0.35 4.68 ± 0.13 200 100.43 ± 0.27 78.82 ± 0.31 3.71 ± 0.13 6.96 ± 0.10 500 100.44 ± 0.85 78.65 ± 0.02 3.34 ± 0.13 10.08 ± 0.18 1000 99.79 ± 0.95 78.67 ± 0.02 3.19 ± 0.13 11.89 ± 0.09 1500 99.49 ± 0.57 78.68 ± 0.02 3.13 ± 0.10 12.27 ± 0.10 2000 99.51 ± 0.47 78.71 ± 0.02 3.14 ± 0.11 12.09 ± 0.18 2500 99.22 ± 0.57 79.32 ± 1.48 3.15 ± 0.09 11.63 ± 0.23

213.28 ± 0.80 1.18 ± 0.11 217.28 ± 0.74 1.24 ± 0.05 225.19 ± 1.06 1.28 ± 0.07 230.98 ± 1.33 1.31 ± 0.11 230.97 ± 1.24 1.33 ± 0.06 226.30 ± 2.33 1.30 ± 0.08 215.55 ± 4.93 1.32 ± 0.09

compared with 110.22–230.98 MiB for FeitCSI. No nonzero SwapPSS samples occur in either tool’s activephase traces in Experiment 1, so the combined values equal the resident PSS values numerically, although the

figure and tables include both components. These ranges summarize ten-trial condition means rather than bounds on individual trials. The burst results are consistent with a more stable combined process-memory footprint

TABLE VI E XPERIMENT 1 RESOURCE SUMMARIES , ASSIGNMENT II. E ACH CPU/ TARGET- RATE / TOOL ENTRY GIVES MEAN ± SAMPLE STANDARD DEVIATION ACROSS TEN REPETITIONS OF THAT CONFIGURATION . C: TRIAL MEAN PROCESS CPU PERCENTAGE NORMALIZED TO ONE LOGICAL CORE ; M : TRIAL SAMPLE MEAN OF PSS + S WAP PSS IN M I B, SUMMED AT EACH SAMPLING INSTANT; ∆T : TRIAL MEAN ACTIVE S O C TEMPERATURE MINUS ITS MEAN BASELINE IN ◦ C. A LL MEASURES SPAN THE CONTROLLER ’ S ACTIVE PHASE , INCLUDING STARTUP, INJECTION , DRAIN , VERIFICATION , AND TERMINATION . SD S DESCRIBE BETWEEN - TRIAL VARIATION WITHIN EACH CONFIGURATION , NOT STANDARD ERRORS OR CONFIDENCE INTERVALS . VesperCSI on B CPU (MHz) Target (Hz)

C (%)

M (MiB)

FeitCSI on A ◦

∆T ( C)

C (%)

M (MiB)

∆T (◦ C)

600 600 600 600 600 600 600

100 200 500 1000 1500 2000 2500

99.53 ± 0.10 78.65 ± 0.04 2.04 ± 0.41 8.57 ± 0.05 99.75 ± 0.24 78.78 ± 0.21 1.68 ± 0.06 12.68 ± 0.10 99.79 ± 0.18 78.70 ± 0.07 1.68 ± 0.11 17.56 ± 0.27 99.55 ± 0.42 79.24 ± 1.10 1.67 ± 0.06 18.93 ± 0.32 99.41 ± 0.29 78.83 ± 0.16 1.64 ± 0.08 17.14 ± 0.25 99.18 ± 0.41 78.82 ± 0.05 1.65 ± 0.07 13.81 ± 0.25 98.86 ± 0.29 78.93 ± 0.08 1.72 ± 0.04 11.51 ± 0.26

208.78 ± 0.43 1.10 ± 0.25 204.92 ± 1.26 0.98 ± 0.09 199.20 ± 1.67 1.03 ± 0.05 190.93 ± 0.48 1.01 ± 0.08 170.21 ± 2.29 1.07 ± 0.08 132.91 ± 3.38 1.09 ± 0.08 110.22 ± 2.20 1.04 ± 0.05

800 800 800 800 800 800 800

100 99.78 ± 0.10 78.64 ± 0.03 2.51 ± 0.47 6.67 ± 0.07 200 100.02 ± 0.15 78.69 ± 0.05 2.19 ± 0.13 10.03 ± 0.06 500 100.01 ± 0.39 78.67 ± 0.01 1.97 ± 0.05 14.32 ± 0.27 1000 99.62 ± 0.51 79.20 ± 1.46 1.93 ± 0.04 16.10 ± 0.30 1500 99.50 ± 0.33 78.80 ± 0.22 1.87 ± 0.05 15.82 ± 0.19 2000 99.54 ± 0.27 78.77 ± 0.04 1.90 ± 0.10 14.04 ± 0.39 2500 99.24 ± 0.53 79.44 ± 1.98 1.95 ± 0.05 11.95 ± 0.30

209.68 ± 0.97 1.26 ± 0.44 206.78 ± 1.08 1.11 ± 0.08 202.60 ± 1.66 1.15 ± 0.06 201.66 ± 1.97 1.16 ± 0.08 191.78 ± 1.58 1.15 ± 0.08 170.35 ± 4.45 1.13 ± 0.06 142.54 ± 2.04 1.18 ± 0.07

1000 1000 1000 1000 1000 1000 1000

100 99.96 ± 0.19 78.68 ± 0.07 2.83 ± 0.34 5.67 ± 0.07 200 100.17 ± 0.19 78.70 ± 0.10 2.47 ± 0.10 8.57 ± 0.08 500 100.29 ± 0.27 78.65 ± 0.01 2.31 ± 0.06 12.48 ± 0.27 1000 100.00 ± 0.40 78.68 ± 0.01 2.23 ± 0.10 14.08 ± 0.50 1500 99.87 ± 0.25 78.94 ± 0.69 2.20 ± 0.08 14.20 ± 0.18 2000 99.61 ± 0.22 78.75 ± 0.03 2.19 ± 0.09 13.62 ± 0.26 2500 99.42 ± 0.24 78.99 ± 0.63 2.17 ± 0.06 12.31 ± 0.33

209.22 ± 0.62 1.24 ± 0.23 207.54 ± 0.94 1.14 ± 0.10 206.03 ± 1.48 1.16 ± 0.11 203.07 ± 6.34 1.21 ± 0.07 197.11 ± 2.41 1.22 ± 0.08 187.11 ± 4.77 1.20 ± 0.08 171.29 ± 4.32 1.26 ± 0.07

1200 1200 1200 1200 1200 1200 1200

100 100.05 ± 0.23 78.68 ± 0.11 3.17 ± 0.33 5.15 ± 0.07 210.86 ± 0.63 1.31 ± 0.17 200 100.31 ± 0.14 78.65 ± 0.03 2.84 ± 0.06 7.74 ± 0.08 209.21 ± 1.12 1.30 ± 0.08 500 100.36 ± 0.30 78.65 ± 0.01 2.63 ± 0.09 11.24 ± 0.07 209.14 ± 1.01 1.30 ± 0.08 1000 99.85 ± 0.68 79.45 ± 1.36 2.51 ± 0.11 13.19 ± 0.23 210.07 ± 2.92 1.27 ± 0.08 1500 99.98 ± 0.31 78.70 ± 0.03 2.52 ± 0.11 13.35 ± 0.19 205.07 ± 2.08 1.31 ± 0.12 2000 99.42 ± 0.50 80.13 ± 2.25 2.52 ± 0.07 13.22 ± 0.12 199.15 ± 2.98 1.34 ± 0.10 2500 99.73 ± 0.30 78.78 ± 0.04 2.56 ± 0.10 12.18 ± 0.75 184.60 ± 12.51 1.36 ± 0.08

1500 1500 1500 1500 1500 1500 1500

100 99.86 ± 0.54 78.63 ± 0.02 3.84 ± 0.42 4.51 ± 0.12 210.70 ± 1.02 1.44 ± 0.21 200 100.36 ± 0.47 78.72 ± 0.11 3.38 ± 0.15 6.71 ± 0.08 210.66 ± 0.58 1.37 ± 0.07 500 99.80 ± 1.29 78.64 ± 0.01 3.14 ± 0.16 9.79 ± 0.23 211.11 ± 2.46 1.51 ± 0.08 1000 98.99 ± 0.97 78.67 ± 0.02 2.99 ± 0.09 11.43 ± 0.14 213.09 ± 1.33 1.45 ± 0.08 1500 99.14 ± 0.65 78.73 ± 0.05 2.99 ± 0.14 11.80 ± 0.12 212.00 ± 1.57 1.48 ± 0.08 2000 99.58 ± 0.72 79.28 ± 1.74 3.02 ± 0.08 11.35 ± 0.87 201.13 ± 14.37 1.45 ± 0.07 2500 99.40 ± 0.27 78.74 ± 0.05 3.05 ± 0.08 11.19 ± 0.26 196.22 ± 4.90 1.47 ± 0.13

for VesperCSI, but do not independently identify an allocation defect in FeitCSI or establish long-duration memory behavior. Tables V and VI quantify the memory separa-

tion within each configuration. At 600 MHz and 2500 frames/s, mean combined memory is 78.90 ± 0.04 MiB for VesperCSI and 131.80 ± 4.29 MiB for FeitCSI in assignment I. After exchanging the tools in

FeitCSI

600 MHz

800 MHz

1000 MHz

1200 MHz

1500 MHz

600 MHz

800 MHz

1000 MHz

1200 MHz

1500 MHz

Assignment I

100 80 60 40 20 0

Assignment II

Process CPU (% of one logical core)

VesperCSI

100 80 60 40 20 0 0

1

2.5

0

1

2.5

0

1

2.5

0

1

2.5

0

1

2.5

Target traffic rate (10³ frames/s)

Fig. 5. Mean process CPU occupation during the observed active process samples, normalized to one logical core. Columns identify the all-core CPU ceilings and rows identify assignments I and II. Points show means across ten trials; error bars show their sample standard deviations. The dotted reference denotes one fully occupied logical core. VesperCSI

FeitCSI

600 MHz

800 MHz

1000 MHz

1200 MHz

1500 MHz

600 MHz

800 MHz

1000 MHz

1200 MHz

1500 MHz

Assignment I

200 150 100 50 0

250

Assignment II

Mean PSS + SwapPSS (MiB)

250

200 150 100 50 0 0

1

2.5

0

1

2.5

0

1

2.5

0

1

2.5

0

1

2.5

Target traffic rate (10³ frames/s)

Fig. 6. Sampled mean combined process memory (PSS + SwapPSS) during each receiver’s active phase, in MiB, for every CPU ceiling and traffic rate. Points and error bars denote the mean and sample standard deviation of ten trial means, calculated by summing resident and swapped memory at each sampling instant. The metric excludes other host memory and does not represent physical RAM occupancy. assignment II, the corresponding values are 78.93 ± 0.08 and 110.22 ± 2.20 MiB. At 1500 MHz and the same traffic rate, FeitCSI’s values rise to 215.55 ± 4.93 MiB and 196.22 ± 4.90 MiB, whereas VesperCSI remains at 79.32 ± 1.48 MiB and 78.74 ± 0.05 MiB. The SDs

describe the spread of the ten trial means at each fixed CPU ceiling and traffic rate. Thus, the smaller overall variation in VesperCSI’s condition means does not imply an identical footprint in every repetition.

3) Baseline-Referenced Temperature Rise: Each retained temperature trace reports the cpu-thermal SoC sensor, rather than separate sensors for the four cores. For trial j, the reported rise is ∆Tj = T j,active − T j,baseline , using the sample mean in each recorded phase. Baseline subtraction reduces sensitivity to the initial temperature, while retaining the effects of trial duration, cooling, background system activity, and thermal history. Figure 7 shows a higher baseline-referenced temperature rise for VesperCSI than for FeitCSI in every condition mean. Across both assignments, the rises span 1.61– 4.13 ◦ C for VesperCSI and 0.91–1.51 ◦ C for FeitCSI. Tables V and VI give the ten-trial mean and SD for each configuration. At 2500 frames/s, increasing the CPU ceiling from 600 to 1500 MHz raises VesperCSI’s mean temperature rise from 1.61 ± 0.06 to 3.15 ± 0.09 ◦ C in assignment I and from 1.72 ± 0.04 to 3.05 ± 0.08 ◦ C in assignment II. FeitCSI’s corresponding values increase from 0.99 ± 0.06 to 1.32 ± 0.09 ◦ C and from 1.04 ± 0.05 to 1.47 ± 0.13 ◦ C. This thermal separation accompanies the difference in CPU occupation, but does not constitute a direct measurement of electrical power or energy efficiency. In particular, lower-rate trials transmit the same 10,000 frames over a longer interval, and the active phase includes control and drain time. Temperature differences across traffic rates should therefore not be interpreted as steady-state thermal responses to traffic intensity alone. G. Experiment 2: FeitCSI Memory Growth at 600 MHz Experiment 2 examines whether the resident-memory behavior observed in short bursts remains suitable when the acquisition workload is extended. This analysis focuses on FeitCSI on device B with a 600-MHz frequency ceiling applied to all four CPU cores. Ten consecutive trials each inject 100,000 numbered frames at a target rate of 1000 frames/s, corresponding to a nominal 100s injection interval. The startup and post-injection drain intervals remain 5 and 10 s. A fresh acquisition process is launched for each trial; the reported growth therefore occurs within individual sessions rather than accumulating across successive processes. All ten injector logs report 100,000 successful sendto calls, and all ten 600-MHz trials reach receiver-side sequence verification without a recorded collector failure. Table VII gives the missing-record mean and sample standard deviation across the ten completed 600-MHz, 1000-frames/s trials. FeitCSI misses 45483.6 ± 458.0 of the 100,000 expected identifiers per trial, equivalent to 45.484 ± 0.458% loss. These SDs describe variation between trials, not uncertainty in the mean or the location of losses within the acquisition path. Despite retaining only approximately 54.5% of the expected identifiers on average, FeitCSI’s com-

TABLE VII E XPERIMENT 2: F EIT CSI MISSING EXPECTED SEQUENCE IDENTIFIERS ON DEVICE B AT THE 600-MH Z ALL - CORE CPU CEILING AND 1000- FRAMES / S TARGET. E ACH TRIAL EXPECTS 100,000 IDENTIFIERS . E NTRIES GIVE MEAN ± SAMPLE STANDARD DEVIATION ACROSS THE TEN COMPLETED TRIALS .

CPU (MHz) Target (Hz) Missing/trial Loss (%)

600 1000 45483.6 ± 458.0 45.484 ± 0.458

bined process-memory demand approaches the installedmemory capacity. The ten 600-MHz trials establish reproducible memory growth and swapping. Motivated by the improved short-burst retention observed at higher CPU ceilings in Experiment 1, we attempted the same 100,000-frame stress workload at 1500 MHz. The acquisition process crashed before usable resource or kernel traces were preserved. Consequently, this run does not establish the 1500-MHz memory trajectory or the cause of failure. Its occurrence alongside the repeated nearcapacity behavior at 600 MHz is consistent with memory pressure, but does not prove that memory pressure caused the crash. The memory sampler records proportional resident memory (PSS) and proportional swapped memory (SwapPSS) from /proc/PID/smaps_rollup, at a configured sampling rate of 10 Hz. The figures use each receiver trace’s local elapsed time, referenced to the recorded start of the active phase, and convert KiB to MiB. As in Experiment 1, this phase includes startup, injection, drain, verification, and termination overhead. PSS describes resident pages attributed to the process; SwapPSS describes attributed pages placed in the RAMbacked swap area described in Subsection VII-A. Their sum is used here as a combined process-memory demand. It is not a measurement of simultaneously occupied physical RAM and excludes other processes and kernel memory. Figure 8 shows substantial memory growth in the mean trajectory, with the shaded bands describing variation between sessions. At each plotted time, the mean and sample standard deviation use ten equally weighted interpolated observations, with the standard deviation calculated using nine degrees of freedom. For the combined panel, PSS and SwapPSS are summed within each run before computing these statistics; the two component standard deviations are not added. The following ranges summarize the original individual traces rather than extrema of the plotted mean. Initial sampled PSS is 14.51– 15.31 MiB, whereas the maximum sampled resident PSS

Assignment I

FeitCSI

600 MHz

800 MHz

1000 MHz

1200 MHz

1500 MHz

600 MHz

800 MHz

1000 MHz

1200 MHz

1500 MHz

4 3 2 1

Assignment II

SoC temperature rise (°C)

VesperCSI

4 3 2 1 0

1

2.5

0

1

2.5

0

1

2.5

0

1

2.5

0

1

2.5

Target traffic rate (10³ frames/s)

Fig. 7. Mean active-phase SoC temperature rise relative to each trial’s mean pre-acquisition baseline. Each point is the mean of ten baseline-referenced trial rises; error bars show their sample standard deviation. The two rows report the assignments separately. Active phases differ in duration across traffic rates. Mean (10 runs)

Resident PSS

Swapped SwapPSS

Combined PSS + SwapPSS

1536

1024

512

0

2048

Process memory (MiB)

2048

Process memory (MiB)

2048

Process memory (MiB)

±1 sample standard deviation

1536

1024

512

0 0

50

100

140

Time since collector active (s)

1536

1024

512

0 0

50

100

140

Time since collector active (s)

0

50

100

140

Time since collector active (s)

Fig. 8. Mean FeitCSI memory trajectories across the ten Experiment 2 trials at the 600-MHz all-core ceiling and 1000-frames/s target. The panels distinguish resident PSS, swapped SwapPSS, and their sum, using a common memory scale. Time is relative to each trial’s recorded collector-active phase. Solid curves show the mean across runs; shaded bands show ±1 sample standard deviation across runs at each time point. Traces are linearly interpolated onto a common 1-s grid from 3 to 133 s, restricted to the interval observed in all ten runs. The trajectories include acquisition and subsequent control/drain overhead; injection boundaries are not separately marked in the resource logs. reaches 1572.13–1634.35 MiB across the ten trials. The first nonzero SwapPSS sample occurs 65.10–68.60 s after the recorded active-phase start. Thereafter, resident PSS decreases while SwapPSS increases, with the maximum swapped footprint reaching 1488.45–1536.57 MiB.

The reduction in resident memory therefore accompanies substantial displacement to swap; it does not indicate that the combined memory demand has returned to its initial level. By the last available samples, approximately 133.70–137.79 s after the active-phase start, that demand

require addressing the observed growth or applying explicit session and resource limits. Nevertheless, the ten 600-MHz trials complete, so this experiment does not establish a universal maximum run duration or prove that every longer session must fail. It demonstrates that stable memory use, a prerequisite for dependable long-duration edge acquisition, is not achieved during the measured sessions.

Peak combined process demand (MiB)

Installed RAM: 2048 MiB (reference) Resident PSS Swapped SwapPSS

2048

1536

1024

H. Experiment 3: Sustained VesperCSI Acquisition

512

0 1

2

3

4

5

6

7

8

9

10

Repetition

Fig. 9. Peak sampled combined FeitCSI memory demand in each 600-MHz trial. Each stack uses PSS and SwapPSS from the same sample at which their sum is maximal, rather than adding their separately observed maxima. The dashed line is a nominal 2048MiB installed-memory reference for the 2-GB platform; the stacked quantity includes swapped pages and is not physical RAM occupancy. remains close to 2 GiB. The traces do not identify the allocation mechanism responsible for this growth, but they directly establish a large process footprint and sustained swapping during the tested workload. Figure 9 quantifies the capacity pressure across repetitions. Peak combined demands range from 1972.73 to 2019.24 MiB. Their numerical ratio to the nominal 2048-MiB installed-memory reference is 96.32–98.60%, but this is a scale comparison, not the fraction of physical RAM occupied: the combined metric includes swapped pages. Separately, the resident peaks alone amount to approximately 77–80% of that reference, before accounting for the operating system and other host workloads. The substantial swapped component demonstrates that completion of these finite trials depends on memory behavior beyond a small, stable resident acquisition footprint. Process-memory samples do not establish that FeitCSI alone occupies every byte of the Pi’s RAM, but the near-capacity combined demand and repeated swapping document severe memory pressure on this platform. For the tested FeitCSI build and acquisition configuration, these results support restricting operation to short, bounded sessions rather than relying on unattended longduration capture on a 2-GB Raspberry Pi. Each nominal 100-s traffic workload already produces a footprint of the same order as the installed RAM, leaving little margin in the memory budget for a larger workload or additional applications. Extended deployment would

Experiment 3 evaluates the ability of VesperCSI to retain CSI records over repeated hour-scale sessions while maintaining a small resident footprint. Only device A, running VesperCSI, is enabled. The 600-, 1000-, and 1500-MHz all-core CPU ceilings are each tested in ten consecutive trials, with four million numbered frames injected per trial at a target rate of 1000 frames/s. The injector encodes each frame’s sequence number in the final four bytes of its source MAC address. Each trial uses a fresh acquisition process, a 5-s startup interval, and a 10-s post-injection drain interval. To accommodate the storage requirements of the extended runs, capture files are written to an 8-TB Western Digital My Book external drive connected to the receiver via USB. A configured 900-s (15-min) cooldown separates successive trials. All thirty injector logs report four million successful sendto calls, every trial reaches receiverside sequence verification, and no collector crashes are recorded. The nominal injection duration is 4000 s, or approximately 66.7 min per trial. In the receiver captures, the earliest and latest timestamps attached to matching expected identifiers are separated by 4000.023–4000.034 s. Thus, matching records bracket the intended hour-scale workload; this first-to-last span does not imply that every intervening identifier was retained. Together, the trials cover 120 million expected identifiers and approximately 33.3 h of injected traffic. This total represents thirty separate acquisition sessions with cooldown, rather than one uninterrupted 33-h run. The recorded active phases are longer, averaging 75.98, 75.27, and 74.86 min at 600, 1000, and 1500 MHz, respectively, because they also include startup, drain, verification, and termination overhead; these durations exclude the separate cooldowns. Resource summaries below use the active phases and each receiver trace’s local elapsed time. 1) Retention Throughout the Extended Workloads: Table VIII reports sequence accounting for every configuration. Each row pools the ten equal-sized trials (40 million expected identifiers per CPU ceiling); retention is 99.985453% at 600 MHz, 99.997278% at 1000 MHz, and 99.963528% at 1500 MHz. Across all thirty trials, 119,978,503 of the 120,000,000 expected identifiers are retained, giving 99.982086% aggregate retention and

TABLE VIII E XPERIMENT 3 SEQUENCE RETENTION . E ACH CONFIGURATION COMPRISES TEN TRIALS OF FOUR MILLION EXPECTED FRAMES AT A 1000- FRAMES / S TARGET. R ETENTION USES ALL 40 MILLION EXPECTED IDENTIFIERS PER CONFIGURATION . CPU (MHz) Total missing Retention (%) 600 1000 1500

5,819 1,089 14,589

1500 MHz 9829

1000 MHz

0.25

0.20

9

10

1

2

3

4

5

6

1785 617

8

457

7

Repetition

440

6

129

104

5

121

96

4

Repetition

103

95

3

79

2

79

1

79

10

113

9

102

8

187

7

148

6

111

5

255

4

276

254

3

247

92

2

85

1

272

0.00

70

0.05

1004

0.10

4155

0.15

113

Missing expected identifiers (%)

600 MHz

99.985453 99.997278 99.963528

8

9

7

10

Repetition

Fig. 10. Missing-sequence percentages for all thirty Experiment 3 trials, grouped by the all-core CPU ceiling. Each trial expects four million identifiers. Bar annotations give the corresponding missing-record counts, including the larger-loss trials that affect the configuration averages. TABLE IX E XPERIMENT 3 ACTIVE - PHASE RESOURCE SUMMARIES . M EAN CPU OCCUPATION , TRIAL - MEAN PSS, ENDPOINT PSS CHANGE , AND BASELINE - REFERENCED MEAN S O C RISE ARE REPORTED AS MEAN ± SAMPLE SD ACROSS TEN TRIALS . M AXIMA USE ORIGINAL SAMPLES OVER ALL TEN TRIALS . CPU IS NORMALIZED TO ONE LOGICAL CORE ; ALL FOUR CORES REMAIN AVAILABLE . N O S WAP PSS IS RECORDED . CPU (MHz) Process CPU (%) Mean PSS (MiB) Max PSS (MiB) PSS change (MiB) Mean ∆T (◦ C) Max T (◦ C) 600 1000 1500

107.03 ± 0.19 105.55 ± 0.14 100.21 ± 0.14

79.15 ± 0.12 79.25 ± 0.41 79.10 ± 0.08

21,497 missing identifiers. No duplicate or out-of-range identifiers are recorded. These counts establish high end-to-end retention of the expected sequence; they do not locate individual losses within the radio, firmware, driver, or userspace acquisition path. Figure 10 shows that the high aggregate retention is accompanied by variation between sessions. The first 600-MHz trial loses 4155 identifiers (0.103875%), whereas the remaining nine lose 70–276 each. At 1000 MHz, all ten trials lose 79–187 identifiers, with a worst-trial loss of 0.004675%. At 1500 MHz, the seventh trial loses 9829 identifiers (0.245725%), and several later trials also exceed the losses of the earlier repetitions. Even this largest-loss trial retains 99.754275% of its

79.77 80.79 79.51

0.80 ± 0.17 0.93 ± 0.50 0.76 ± 0.10

7.75 ± 0.41 12.14 ± 0.19 15.82 ± 0.13

61.84 65.24 68.65

expected sequence. The observations support sustained high retention across the tested hour-scale sessions, including operation at 600 MHz, while also showing that retention is neither perfect nor monotonically improved by a higher frequency ceiling. The ordered repetitions do not isolate environmental drift or identify the cause of the larger losses, so the aggregate result should be read together with the individual trials. 2) Resident Memory and CPU Occupation: Table IX summarizes the active-phase process and temperature measurements for each frequency configuration. Mean CPU occupation is calculated from accumulated process CPU ticks divided by the observed elapsed sampling span and normalized to one logical core. Memory

Mean (10 trials)

600 MHz

±1 sample SD

1000 MHz

1500 MHz

Process PSS (MiB)

79.8 79.6 79.4 79.2 79.0 78.8 78.6 0

20

40

60

Time since collector active (min)

80

0

20

40

60

Time since collector active (min)

80

0

20

40

60

80

Time since collector active (min)

Fig. 11. Mean process PSS during the extended VesperCSI trials, with separate panels for the three CPU ceilings. Solid curves show the mean of ten trial sample means in each 30-s bin; shaded bands show ±1 sample standard deviation across those ten values. Bins are shown only while all ten trials contribute. The magnified vertical scale makes small footprint changes visible. Table IX uses original samples for maxima. No nonzero SwapPSS samples occur in any trial. summaries use the sampled PSS from /proc/PID/ smaps_rollup, converted to MiB; endpoint change is the last active PSS sample minus the first. Reported ± values are sample standard deviations across ten trial summaries, whereas sampled maxima retain the largest original observation across the configuration. Figure 11 shows a mean resident footprint that remains close to 79 MiB throughout the sessions, with small changes rather than growth on the scale of the acquired record count. The means of trial-mean PSS are 79.15, 79.25, and 79.10 MiB at 600, 1000, and 1500 MHz, respectively. Their mean first-to-last increases are 0.80, 0.93, and 0.76 MiB, and the largest original PSS sample in the entire experiment is 80.79 MiB. Thus, the sampled process footprint remains below 4% of a nominal 2048-MiB installed-memory reference, with no recorded swapping. The small increases remain relevant, but these measurements support resident-memory stability over the observed four-million-frame workloads. PSS excludes other host memory, so it does not establish a bound on total system RAM use. Figure 13 shows mean process CPU occupation of approximately one logical core over the extended active phases. Configuration means are 107.03% at 600 MHz, 105.55% at 1000 MHz, and 100.21% at 1500 MHz. The normalization permits values above 100% when execution spans multiple threads; it does not imply a single-core affinity constraint. The lower panels show appreciable activity on all four cores. This host-wide activity cannot be attributed solely to VesperCSI, and the resource-monitoring workload is not independently subtracted. The results establish the observed process CPU cost of sustained acquisition, without treating one-

core normalization as a measurement of total host load or energy consumption. 3) Temperature Rise During Hour-Scale Operation: For each trial, SoC temperature rise is referenced to the sample mean of its pre-acquisition baseline. All retained traces use the cpu-thermal sensor; these are SoC readings rather than individual-core temperatures. The configuration summaries use the mean active temperature minus that baseline, with original samples retained for the maximum absolute temperature. Figure 12 documents the thermal response during the extended acquisition workload at each CPU ceiling. Mean active rises are 7.75 ± 0.41, 12.14 ± 0.19, and 15.82 ± 0.13 ◦ C at 600, 1000, and 1500 MHz, respectively, with maximum sampled absolute temperatures of 61.84, 65.24, and 68.65 ◦ C. The mean trajectories approach elevated plateaus. At 600 MHz, the wider SD band after roughly 30 min reflects increased variation between sessions. Inspection of the original traces shows that one 600-MHz trial departs markedly from the other nine after roughly 30 min and falls substantially later in the session; the available measurements do not establish the cause. Configuration means therefore do not describe every session’s thermal trajectory. All sessions still remain available for verification. The larger mean rise at higher ceilings is a deployment consideration alongside retention and CPU occupation. Temperature measurements alone do not establish electrical power, energy per record, or the absence of frequency throttling, and the configured cooldown limits transfer of these results to uninterrupted operation without equivalent thermal conditions.

Mean (10 trials)

600 MHz

±1 sample SD

1000 MHz

1500 MHz

SoC temperature rise (°C)

16 14 12 10 8 6 4 2 0

20

40

60

80

0

Time since collector active (min)

20

40

60

80

0

Time since collector active (min)

20

40

60

80

Time since collector active (min)

Fig. 12. Mean baseline-referenced SoC temperature rise across ten trials of each Experiment 3 configuration. For each trial, 30-s active-temperature sample means are referenced to that trial’s mean baseline. Solid curves show the mean of these ten trial values in each bin; shaded bands show ±1 sample standard deviation across trials. Bins are shown only while all ten trials contribute. Core 0

Core 1

System activity per core (%)

Process CPU (% of one core)

600 MHz

Core 2

Core 3

1000 MHz

1500 MHz

120

120

120

100

100

100

80

80

80

60

60

60

40

40

40

20

20

20

Mean (10 trials) ±1 sample SD

0

0

0

100

100

100

80

80

80

60

60

60

40

40

40

20

20

20

0

0 0

20

40

60

80

Time since collector active (min)

0 0

20

40

60

80

Time since collector active (min)

0

20

40

60

80

Time since collector active (min)

Fig. 13. Active-phase CPU behavior during Experiment 3. Upper panels show the mean process CPU occupation across ten trials, normalized to one logical core, with shaded ±1 sample standard deviation bands. Each trial contributes a duration-weighted mean in each 30-s bin; dotted lines mark 100%. Lower panels show per-core total system activity from /proc/stat, averaged across the ten trial means in each 30-s bin. Bins in both rows are shown only while all ten trials contribute. System activity includes the acquisition process, samplers, and other host workloads.

4) Endurance Interpretation: Taken together, completion of all thirty hour-scale acquisitions, 99.982086% aggregate sequence retention, a sampled process footprint below 81 MiB, and the absence of recorded swapping or collector failure support VesperCSI as a sustained acquisition component on the tested CM4 platform. This conclusion includes the 600-MHz configuration and does not depend on discarding the larger-loss sessions. It applies to the recorded build, driver, radio parameters, and storage path at a 1000-frames/s target. Separate process launches and cooldown intervals, the single enabled receiver, and the finite per-session duration leave uninterrupted multi-day capture and other deployment conditions for future evaluation. VIII. L IMITATIONS AND F UTURE W ORK VesperCSI is currently limited to Intel AX200/AX210 interfaces and requires a CSI-enabled backport-iwlwifi build compatible with the host kernel. The evaluation covers CM4 hosts, VHT/80-MHz traffic, and two spatial streams; other PHY formats, channel widths, radios, and amd64 performance remain outside its scope. Exact driver revisions and CSIenabling changes must accompany future reproduction packages. The software crossover is a package-level comparison on fixed device/driver combinations. It demonstrates a repeated performance ordering but does not independently vary drivers, hardware, and userspace. Sequence accounting quantifies missing expected identifiers without locating losses within the acquisition path. Injectorreported sent counts and retained verifier logs strengthen the audit, but raw CSI binaries and independent overthe-air transmission traces are not included. Verification of active files also leaves possible pending-write effects unresolved. Ten consecutive repetitions per condition and an ordered sweep limit inference about independence, environmental drift, and thermal history. Unequal burst durations affect temperature comparisons, even after baseline subtraction. Resource samplers and SSH control introduce load that is common to the experiment but is not separately quantified. Process PSS excludes other system memory; polling CPU occupation and SoC temperature cannot substitute for measured energy consumption. Some exported UTC timestamps differ between devices and campaign metadata; analysis uses each trace’s relative elapsed time and does not infer cross-host event coincidence from absolute clocks. The FeitCSI stress experiment comprises ten completed 600-MHz runs and one 1500-MHz run that ends in an acquisition-process crash. The failure traces are empty, and no kernel out-of-memory evidence is retained. The completed runs establish the 600-MHz

memory-growth behavior, but the failed run does not establish the 1500-MHz memory trajectory or failure mechanism. Memory pressure is plausible in view of the repeated near-capacity 600-MHz measurements, but remains unproven and does not establish a specific allocator defect or a universal maximum duration. The VesperCSI endurance result consists of thirty separate hour-scale sessions with cooldown; it does not establish uninterrupted multi-day operation. Its larger-loss trials remain relevant, even when overall retention is high. Preallocated pools provide bounded buffering rather than lossless capture. Their capacities are selected before compilation; a slow synchronous plugin can still create backpressure, triggering the configured discard or failfast policy. No plugin workload is exercised here. Further evaluation will vary drivers independently, measure allocation and queue behavior, retain kernel failure logs and raw captures, quantify power and storage throughput, and evaluate longer uninterrupted sessions. We also plan to develop interfaces for Python and MATLAB, with Lua as a possible additional target, to integrate VesperCSI with analysis and experiment-control workflows. These language interfaces could broaden the system’s use in edge-hosted sensing. IX. C ONCLUSION This paper presented VesperCSI, an edge-focused CSI acquisition system for Intel AX200/AX210 interfaces. Its userspace pipeline combines fixed-capacity preallocated pools, record validation, explicit overflow handling, a managed capture lifecycle, and a versioned plugin interface. Together, these mechanisms provide a boundedbuffer foundation for separating CSI reception from experiment-specific consumption. The evaluations show both the performance opportunity and the operational trade-offs. In the 600MHz, 2500-frames/s burst condition, VesperCSI retained 99.017% and 99.087% of the expected 10,000-frame sequences, compared with 46.553% and 43.972% for FeitCSI; this ordering persisted when the userspace programs were exchanged between receivers while their drivers remained fixed. The comparison is therefore evidence about the tested software-and- driver packages, not an isolated userspace effect. In a separate FeitCSI stress study, the 600-MHz trials showed substantial residentplus-swapped memory growth, while the higher-ceiling trial ended in an acquisition-process crash whose cause was not established. Across thirty separate hour-scale VesperCSI sessions, each injecting four million frames at 1000 frames/s, aggregate sequence retention was 99.9821%. Sampled process PSS remained at or below 80.792 MiB, with no recorded swapping or acquisition-process failure. These results demonstrate high-retention, extended CSI acqui-

sition on the evaluated Raspberry Pi CM4 platform. They do not establish lossless capture or performance across other hosts, drivers, workloads, or uninterrupted multiday operation; the observed CPU and thermal costs, occasional losses, and study scope remain important deployment constraints. R EFERENCES [1] D. Halperin, W. Hu, A. Sheth, and D. Wetherall, “Tool release: Gathering 802.11n traces with channel state information,” ACM SIGCOMM Computer Communication Review, vol. 41, no. 1, p. 53, 2011. [Online]. Available: https://doi.org/10. 1145/1925861.1925870 [2] Y. Xie and M. Li, “Atheros CSI Tool,” WANDS Group, accessed: Oct. 8, 2026. [Online]. Available: https://github.com/xieyaxiongfly/Atheros-CSI-Tool [3] F. Gringoli, M. Schulz, J. Link, and M. Hollick, “Free your CSI: A channel state information extraction platform for modern Wi-Fi chipsets,” in Proc. WiNTECH, 2019, pp. 21–28. [Online]. Available: https://doi.org/10.1145/3349623.3355477 [4] F. Gringoli, M. Cominelli, A. Blanco, and J. Widmer, “AX-CSI: Enabling CSI extraction on commercial 802.11ax Wi-Fi platforms,” in Proc. WiNTECH, 2021, pp. 46–53. [Online]. Available: https://doi.org/10.1145/3477086.3480833 [5] M. Hutar, P. Brida, and J. Machaj, “FeitCSI, the 802.11 CSI tool,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/KuskoSoft/FeitCSI [6] Z. Jiang et al., “Eliminating the barriers: Demystifying Wi-Fi baseband design and introducing the PicoScenes Wi-Fi sensing platform,” IEEE Internet of Things Journal, vol. 9, no. 6, pp. 4476–4496, 2022. [Online]. Available: https://doi.org/10.1109/JIOT.2021.3104666 [7] Y. C. Çelik, E. B. Emiroğlu, S. Baghaee, and I. Ulusoy, “Evaluating the impact of CSI preprocessing on WiFi-based human activity recognition,” in Proc. 34th Signal Processing and Communications Applications Conf. (SIU), 2026. [Online]. Available: https://doi.org/10.1109/SIU71813.2026.11636472 [8] E. B. Emiroğlu, Y. C. Çelik, S. Baghaee, and I. Ulusoy, “REAL-CSI: Benchmarking DL architectures for Wi-Fi CSI human activity recognition,” in Proc. 34th Signal Processing and Communications Applications Conf. (SIU), 2026. [Online]. Available: https://doi.org/10.1109/SIU71813.2026.11636516 [9] D. Halperin, “Linux 802.11n CSI Tool,” accessed: Oct. 8, 2026. [Online]. Available: https://dhalperi. github.io/linux-80211n-csitool/

[10] Y. Xie, “Atheros CSI Tool UserSpace APP,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/xieyaxiongfly/ Atheros-CSI-Tool-UserSpace-APP [11] SEEMOO Lab, “Nexmon CSI,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/ seemoo-lab/nexmon csi [12] ——, “Nexmon CSI extractor source and licensing notice,” also see the Nexmon license at https://github.com/seemoo-lab/nexmon/ blob/master/LICENSE.txt. Accessed: Oct. 8, 2026. [Online]. Available: https://github.com/seemoo-lab/ nexmon csi/blob/master/src/csi extractor.c [13] Advanced Networking Systems, University of Brescia, “AX-CSI,” accessed: Oct. 8, 2026. [Online]. Available: https://ans.unibs.it/projects/ax-csi/ [14] PicoScenes, “Developing Your PicoScenes Plugins,” accessed: Oct. 8, 2026. [Online]. Available: https://ps.zpj.io/manual/plugin.html [15] ——, “PicoScenes Plug-In Development Kit,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/wifisensing/PicoScenes-PDK [16] ——, “Features & License,” accessed: Oct. 8, 2026. [Online]. Available: https://ps.zpj.io/manual/ features pricing.html [17] ——, “PicoScenes Installation & Upgrade,” accessed: Oct. 8, 2026. [Online]. Available: https://ps.zpj.io/manual/installation.html [18] D. Zhang, L. Fang, X. Xie, S. Yang, J. Chen, and Y. Chen, “Enhancing CSI-based wireless sensing with open-source Linux 802.11ax CSI tool,” IEEE Sensors Journal, vol. 25, no. 10, pp. 18 041–18 052, 2025. [Online]. Available: https://doi.org/10.1109/JSEN.2025.3553130 [19] D. Zhang et al., “IAX: An open-source CSI extraction tool,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/fflq/iax [20] Espressif Systems, “ESP-CSI: Applications based on Wi-Fi channel state information,” accessed: Oct. 8, 2026. [Online]. Available: https://github. com/espressif/esp-csi [21] Z. Wang et al., “Wi-Fi sensing tool release: Gathering 802.11ax channel state information from a commercial Wi-Fi access point,” arXiv:2506.16957, 2025. [Online]. Available: https://arxiv.org/abs/2506.16957 [22] ——, “ZTE Wi-Fi Sensing,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/ WiFiZTE2025/ZTE WiFi Sensing [23] X. Jiao et al., “openwifi: A free and open-source IEEE 802.11 SDR implementation on SoC,” in Proc. IEEE VTC-Spring, 2020. [Online]. Available: https://github.com/open-sdr/openwifi

[24] openwifi, “Channel State Information,” accessed: Oct. 8, 2026. [Online]. Available: https://github.com/open-sdr/openwifi/blob/ master/doc/app notes/csi.md [25] K. Baydemir, “VesperCSI: A High-Performance and Extensible CSI Acquisition Framework for Edge Wi-Fi Sensing,” accessed: Aug. 16, 2026. [Online]. Available: https://github.com/ technicaluserx/vespercsi [26] G. Forbes, “CSIKit: Python CSI processing and visualisation tools,” accessed: Jul. 29, 2026. [Online]. Available: https://github.com/Gi-z/CSIKit [27] S. Tan, “csiread: A fast channel state information parser for Intel, Atheros, Nexmon, ESP32 and PicoScenes,” accessed: Jul. 29, 2026. [Online]. Available: https://github.com/citysu/csiread [28] Intel Corporation, “Intel Wi-Fi 6 AX200 (Gig+) product specifications,” accessed: Jul. 29, 2026. [Online]. Available: https: //www.intel.com/content/www/us/en/products/sku/ 189347/intel-wifi-6-ax200-gig/specifications.html [29] ——, “Intel Wi-Fi 6E AX210 (Gig+) product specifications,” accessed: Jul. 29, 2026. [Online]. Available: https: //www.intel.com/content/www/us/en/products/sku/ 204836/intel-wifi-6e-ax210-gig/specifications.html [30] Linux Wireless, “iwlwifi,” accessed: Aug. 15, 2026. [Online]. Available: https://wireless.docs. kernel.org/en/latest/en/users/drivers/iwlwifi.html [31] Intel Linux Wireless, “iwlwifi/backportiwlwifi.git,” accessed: Aug. 15, 2026. [Online]. Available: https://git.kernel.org/pub/scm/ linux/kernel/git/iwlwifi/backport-iwlwifi.git

Related documents

• Context-Enhanced CSI Tracking Using Koopman-Inspired Dual Autoencoders in Dynamic Wireless Environments#176991
• Masked Latent Prediction of CSI for Indoor Localization in Integrated Sensing and Communication Systems#985858
• Physical Layer Anomaly Detection via Adaptive Gaussian Mixture Model#1344769
• Physical Layer Anomaly Detection via Adaptive Gaussian Mixture Model#1335946
• UniCSI Towards a Universal Wi-Fi CSI Encoder for Ubiquitous Human Sensing#1233598