PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Kaan Baydemir, Sajjad Baghaee, Ilkay Ulusoy

arXiv:2610.22581v1cs.NIcs.PFeess.SP

TL;DR

High-rate CSI acquisition on compact hosts must handle bursty input while remaining adaptable to experiment needs. VesperCSI redesigns FeitCSI with bounded preallocated pools, separate capture and consumer threads, and a plugin interface. In the tested burst crossover, its sequence retention exceeded FeitCSI’s, although the comparison reflects software-and-driver packages rather than isolated userspace effects.

  • Problem

    Compact-host CSI acquisition must handle bursty netlink input without per-record allocation, reject malformed or irrelevant records, and keep output work from obstructing ingestion.

    Source: §I · p. 1

  • Method

    VesperCSI redesigns FeitCSI with fixed-capacity preallocated pools, separated capture and consumer work, and a versioned plugin interface for experiment-specific workflows.

    Source: §I · p. 1, §IX · p. 23

  • Results

    At 600 MHz and 2500 frames/s, VesperCSI retained 99.017% and 99.087% of expected 10,000-frame sequences, versus FeitCSI’s 46.553% and 43.972%; the ordering persisted after userspace programs were exchanged between receivers.

    Source: §IX · p. 23

  • Takeaways & Limitations

    The results support VesperCSI as a bounded-buffer acquisition component for edge-hosted sensing under the evaluated workload and platform conditions.

    Source: §IX · p. 23

    The burst comparison is package-level rather than an isolated userspace effect, and no plugin workload was exercised.

    Source: §VIII · p. 23

Abstract

from arXiv · show

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, GPL-3.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 experiment-specific 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.

I. INTRODUCTION

VesperCSI redesigns FeitCSI for high-rate, extensible CSI acquisition on edge hosts, addressing burst handling and workflow needs. The paper situates it among reusable acquisition platforms and distinguishes runtime plugins from other forms of extensibility.

I. INTRODUCTION

  • Compact-host acquisition must process bursty netlink input without per-record allocation, reject malformed or irrelevant records, and avoid obstructing ingestion with output work.VesperCSI was motivated by prior FeitCSI studies and plans to move experiments to aarch64 edge hosts.Source: §I · p. 1
  • VesperCSI redesigns FeitCSI’s userspace internals around preallocated pools, consumer-driven exchange, overflow policies, and a loadable plugin interface.It targets amd64 and aarch64 Linux hosts with compatible Intel AX200/AX210 interfaces and uses a CSI-enabled backport-iwlwifi driver.Source: §I · p. 1
  • The paper’s three contributions are a bounded-buffer pipeline, a versioned plugin interface demonstrated for activity labeling, and corrections to inherited FeitCSI bugs.The retention comparison is package-level evidence and does not isolate userspace changes from the respective drivers.Source: §I · p. 3

II. CSI TOOL LANDSCAPE

  • Table I compares reusable acquisition platforms by openness, extension, concurrency, bandwidth, hardware, host architecture, and deployment constraints, not by head-to-head performance.“ND” means a capability was undocumented or could not be established from reviewed materials; it does not establish that no implementation exists.Source: Table I · p. 2, §II · p. 3

A. Source Availability and Extensibility

  • VesperCSI is distributed under GPL-3.0, while the surveyed tools vary in source availability, licensing, and runtime composition.A public repository without an identified license is reported as public source rather than open source.Source: A. Source Availability and Extensibility · p. 3, §II · p. 3
  • VesperCSI provides a runtime plugin boundary for experiment-specific monitoring, data handling, and control, but loads exactly one plugin per process.PicoScenes documents multiple plugins and active plugin instances; VesperCSI callbacks operate on consumer-local records, avoiding a mandatory socket hop, though the performance impact was not measured.Source: A. Source Availability and Extensibility · pp. 3–4

B. Concurrency and High-Rate Acquisition

The survey distinguishes explicit acquisition concurrency, radio bandwidth, and deployment architecture across CSI platforms. VesperCSI’s target deployment requires both a compatible Intel AX-series interface and a CSI-enabled driver stack.

B. Concurrency and High-Rate Acquisition

  • VesperCSI separates reception into a capture thread and storage/plugin execution into a consumer thread, with fixed pool capacities bounding buffering and overflow behavior.This keeps ordinary file or plugin work out of the reception thread.Source: B. Concurrency and High-Rate Acquisition · p. 4

C. Bandwidth and Radio Generation

  • VesperCSI, FeitCSI, and other listed Intel AX platforms reach 160 MHz; PicoScenes documents 320-MHz SDR measurement, not 320-MHz support on Intel AX NICs.The Linux 802.11n and Atheros tools are limited to 20/40 MHz, while Nexmon CSI documents up to 80 MHz on supported Broadcom devices.Source: C. Bandwidth and Radio Generation · p. 4

D. Host Architecture and Software Baseline

  • VesperCSI supports amd64 and aarch64 Linux hosts with a compatible PCIe AX200/AX210 interface and CSI-enabled backport-iwlwifi driver.It has been verified with Linux 6.8 and 6.12, including Debian 13 and Raspberry Pi CM4; these are tested configurations, not compatibility bounds.Source: D. Host Architecture and Software… · p. 4

III. INTEL AX200/AX210 FIRMWARE AND DRIVER REQUIREMENTS

  • CSI acquisition requires replacing the distribution’s standard iwlwifi driver with a CSI-enabled build from Intel’s maintained backport-iwlwifi tree; custom replacement firmware is not required.The backport modules must be built for and installed on the target kernel, and the selected branch or commit must be compatible with it.Source: §III · pp. 4–5

IV. VESPERCSI IMPLEMENTATION

VesperCSI manages radio configuration and process lifecycle while separating capture from consumer work. Its two statically reserved pools are sized from compile-time capacity parameters, and the storage estimate excludes bookkeeping and alignment overhead.

A. System Architecture and Bounded Capture Pipeline

  • At startup, VesperCSI configures the monitor interface and channel, enables CSI through the CSI-enabled driver, and starts consumer and capture workers.A shared shutdown flag and pollable pipe coordinate termination with the main thread and receive loop.Source: A. System Architecture and Bounded… · p. 5

1) Pool Layout and Memory Estimate:

  • Each pool’s capacity N is determined by nominal record rate Rmax multiplied by buffering window Tmax; these parameters size arrays rather than impose a runtime rate limit.The two pools contain 2 × N nodes; Rmax is not a measured sustainable rate, and Tmax does not guarantee loss-free buffering.Source: 1) Pool Layout and Memory Estimate · p. 5
  • Each record reserves a header and fixed-capacity CSI data array, with 4 bytes per subcarrier–antenna-path combination; the estimate excludes pointers, bookkeeping, and alignment padding.A shorter payload does not shrink a reserved node.Source: 1) Pool Layout and Memory Estimate · p. 5
  • The producer and consumer reuse reserved pool storage without per-record heap allocation, while enqueue and dequeue still copy individual CSI objects.Pool roles swap without copying queued records between pools.Source: 1) Pool Layout and Memory Estimate · p. 6, Figure 1 · p. 6

2) Consumer-Driven Ownership Exchange:

The consumer drains its pool before exchanging ownership when producer data are pending. Producer capacity remains limited to its own pool while the consumer processes a batch, and shutdown does not guarantee queued records are written.

2) Consumer-Driven Ownership Exchange:

  • The consumer exchanges pool pointers only when its pool is empty and producer data are pending; no timer, minimum batch size, or full-pool threshold triggers the handoff.The producer inserts at the front and the consumer removes from the back, providing FIFO service within each batch.Source: 2) Consumer-Driven Ownership Exchange · p. 6

3) Consumer Delay and Overflow:

  • If the producer pool runs out of free nodes, the default policy discards its oldest queued record; free nodes in the consumer-owned pool cannot be borrowed before exchange.A slow callback or output operation can cause discards despite separate workers.Source: 3) Consumer Delay and Overflow · p. 6

4) Shutdown and Pending Records:

  • Shutdown joins workers but does not drain either pool, so queued records can remain unwritten when the process exits.The consumer may finish its current record but does not explicitly drain pending records.Source: 4) Shutdown and Pending Records · p. 6

B. Record Validation and Filtering

VesperCSI validates CSI records before pool admission and moves experiment-specific work into a plugin-driven consumer path. Its redesign also replaces several FeitCSI memory and I/O practices, while the infrared-labeling workflow demonstrates extensible collection with a caveat: slow plugins can increase loss.

B. Record Validation and Filtering

  • Header, payload-length, and size checks precede pool admission; optional filters constrain transmitter and CSI parameters, and capture timestamps use the wall clock before later checks.Plugin callbacks and file output run synchronously on the consumer; short or failed writes are warned about but not retried.Source: B. Record Validation and Filtering · pp. 6–7

D. Inherited Issues and Implementation Corrections

  • Fixed-capacity reusable pool slots replace FeitCSI’s unreleased per-record allocations, avoiding heap allocation per record and bounding capture-buffer memory.FeitCSI’s dynamically allocated CSI objects could allow memory use to grow.Source: D. Inherited Issues and Implementation… · p. 7
  • VesperCSI removes plotting-only coefficient transformations from acquisition and keeps output files open, writing header and payload together with vectored I/O.It also offers a quiet option for suppressing FeitCSI’s routine per-record console messages.Source: D. Inherited Issues and Implementation… · p. 7

V. PLUGIN SYSTEM AND INFRARED-CONTROLLED ACTIVITY LABELING

  • Because plugin callbacks run on the consumer thread, work slower than incoming records can fill the producer pool and increase record loss.Under the default overflow policy, the oldest queued record is discarded to admit a new one.Source: §V · p. 7
  • The infrared-controlled plugin lets an operator start, stop, or discard captures and select activities remotely, while labeling each measurement with activity and repetition.It stores labels alongside CSI data in the same output stream; configurable durations, pauses, and repetition counts support operator-led or scheduled collection.Source: §V · pp. 7–8, Figure 2 · p. 8

C. Plugin-Based Research Workflows

  • The versioned plugin SDK enables runtime-loaded experiment extensions for monitoring, storage, processing, or control without changing the capture core.Plugins are loaded at startup; the per-record callback runs synchronously on the consumer thread.Source: §V · pp. 7–8, C. Plugin-Based Research Workflows · p. 7

VI. POSITIONING FOR ARM EDGE ACQUISITION

VesperCSI is positioned for Intel AX200/AX210 acquisition on aarch64 edge hosts with Linux 6.x, where several other platforms are not direct testbed substitutes. The evaluation compares the closest applicable baseline and includes burst, memory-growth, and sustained-session experiments on CM4 receivers.

VI. POSITIONING FOR ARM EDGE ACQUISITION

  • Linux 6.8 and 6.12 deployments demonstrate VesperCSI’s target combination of AX200/AX210 acquisition, aarch64 edge deployment, and Linux 6.x, subject to a compatible CSI-enabled driver.These tests do not establish support for every Linux 6.x or later kernel; PicoScenes requires amd64, while IAX specifies a Linux 5.15.x baseline incompatible with the cited Ubuntu 6.8 configuration.Source: §VI · p. 8
  • FeitCSI is the closest directly applicable baseline: both it and VesperCSI support AX200/AX210 acquisition and were evaluated on CM4 hosts, but their driver stacks differ.The authors state that design differences motivate testing under constrained CPU resources but do not themselves establish a performance advantage.Source: §VI · p. 8

VII. BENCHMARKING BURST-TRAFFIC AND LONG-DURATION CSI ACQUISITION

  • The evaluation comprises burst-traffic comparison, FeitCSI memory-growth and swapping tests at 600 MHz, and repeated hour-scale VesperCSI sessions.The second experiment also records an acquisition-process crash under a higher frequency ceiling and the same extended workload.Source: §VII · p. 8

A. Receiver Platforms

  • The comparison used two identical CM4 receivers with AX210 cards and Debian 13, running Linux 6.12 with distinct driver stacks; VesperCSI used default scheduling and overflow behavior.The hosts had 2 GB RAM and onboard eMMC; the configured pool storage estimate was 79.65 MiB across both pools, excluding metadata and other process allocations.Source: A. Receiver Platforms · pp. 8–9

B. Traffic Generation & Radio Characteristics

The benchmark uses controlled probe-response traffic with sequence numbers encoded in source MAC addresses, then tests acquisition under system-wide CPU ceilings. A controller coordinates paired receiver trials, resource sampling, and capture-file sequence verification.

B. Traffic Generation & Radio Characteristics

  • A monitor-mode MT7612U adapter injects scheduled VHT probe responses at 5 GHz; multicast addressing and no-acknowledgment settings avoid soliciting replies or acknowledgment-based retransmissions.MCS 0 was selected to reduce PHY decoding or frame-check-sequence failures that could otherwise appear as acquisition losses.Source: B. Traffic Generation & Radio… · p. 9

C. Sequence Numbers Inside MAC Addresses

  • A fixed magic prefix distinguishes benchmark frames, while a configurable source-MAC suffix carries each frame’s sequence number for deterministic drop identification.The example reserves two address bytes for an unsigned 16-bit sequence number.Source: C. Sequence Numbers Inside MAC Addresses · p. 9

D. CPU Constraints

  • CPU ceilings of 600, 800, 1000, 1200, and 1500 MHz were applied simultaneously to all four cores, making each ceiling system-wide.The ceiling was configured before each experimental condition.Source: D. CPU Constraints · pp. 9–10

E. General Benchmark Methodology

  • The controller uses Ethernet and SSH to coordinate receiver trials while a desktop USB adapter injects traffic; it samples process and system resources, then verifies received sequence identifiers in active receivers’ capture files.Trials run configured rate and ceiling combinations sequentially; after injection, a fixed drain delay does not confirm receiver-side delivery, and process failures are tracked separately from packet loss.Source: Figure 3 · p. 10, E. General Benchmark Methodology · pp. 10–11

F. Experiment 1: Burst-Traffic Comparison

In 10,000-frame burst trials, VesperCSI retained more expected sequence identifiers than FeitCSI across the tested conditions, including after the programs were exchanged between receivers. VesperCSI used more CPU but had a smaller, less condition-dependent combined process-memory footprint.

F. Experiment 1: Burst-Traffic Comparison

  • Each of five all-core CPU ceilings and seven target rates was tested in ten repetitions of 10,000-frame bursts under each assignment.The two campaigns comprised 700 bursts and 1,400 receiver observations; injector send counts did not verify over-the-air transmission or reception.Source: F. Experiment 1: Burst-Traffic… · p. 11
  • The crossover exchanged userspace tools while retaining each device’s driver, so the consistent ordering applies to tested device/driver combinations, not isolated userspace effects.Campaigns were sequential and conditions were not randomized; sequence accounting also cannot locate where absent identifiers were lost.Source: F. Experiment 1: Burst-Traffic… · p. 11, 1) Sequence Retention Across CPU and… · p. 11

1) Sequence Retention Across CPU and Traffic Conditions:

  • At 600 MHz and 2500 frames/s, VesperCSI lost 0.983% on device A and 0.913% on device B, versus FeitCSI’s 53.447% on device B and 56.028% on device A.The large separation persisted after exchanging the programs between devices.Source: 1) Sequence Retention Across CPU and… · p. 11, Figure 4 · p. 13
  • VesperCSI had lower mean missing-record percentages in all 35 configurations under both assignments.Across conditions, its mean loss ranged from 0.077–1.166% in assignment I and 0.046–0.999% in assignment II; FeitCSI ranged from 0.313–53.447% and 0.231–56.028%, respectively.Source: 1) Sequence Retention Across CPU and… · p. 11, Figure 4 · p. 13

2) Process CPU Occupation and Memory Footprint:

  • At 600 MHz and 2500 frames/s, VesperCSI used 99.52±0.21% and 98.86±0.29% of one logical core across assignments, versus FeitCSI’s 12.39±0.38% and 11.51±0.26%.VesperCSI’s condition means spanned 98.86–100.99% across assignments; higher occupation remained visible at lower traffic rates.Source: 2) Process CPU Occupation and Memory… · pp. 12–13, Table V · p. 14, Table VI · p. 15
  • VesperCSI’s condition means for combined process memory ranged from 78.63–80.38 MiB, compared with FeitCSI’s 110.22–230.98 MiB.The metric sums process-attributed resident and swapped memory; it is not simultaneously occupied physical RAM.Source: 2) Process CPU Occupation and Memory… · pp. 13–14
  • The burst memory results support a more stable VesperCSI footprint, but do not diagnose a FeitCSI allocation defect or establish long-duration memory behavior.Condition summaries are ten-trial means; smaller variation does not imply an identical footprint in every repetition.Source: 2) Process CPU Occupation and Memory… · pp. 14–16

3) Baseline-Referenced Temperature Rise:

VesperCSI had a higher baseline-referenced SoC temperature rise than FeitCSI in every condition mean. The separation accompanies higher CPU occupation, but these measurements do not directly establish power or energy efficiency.

3) Baseline-Referenced Temperature Rise:

  • VesperCSI’s baseline-referenced temperature rise was higher than FeitCSI’s in every condition mean, spanning 1.61–4.13 °C versus 0.91–1.51 °C.The measure is the trial’s active-phase mean minus its pre-acquisition baseline mean.Source: 3) Baseline-Referenced Temperature Rise · p. 17
  • At 2500 frames/s, VesperCSI’s mean rise increased from 1.61±0.06 to 3.15±0.09 °C in assignment I as the ceiling rose from 600 to 1500 MHz.In assignment II, it rose from 1.72±0.04 to 3.05±0.08 °C under the same ceiling change.Source: 3) Baseline-Referenced Temperature Rise · p. 17
  • The thermal separation accompanies the CPU-occupation difference, but does not directly measure electrical power or energy efficiency.Active phases vary in duration and include control and drain time, so cross-rate differences are not steady-state responses to traffic intensity alone.Source: 3) Baseline-Referenced Temperature Rise · p. 17

G. Experiment 2: FeitCSI Memory Growth at 600 MHz

In ten 600-MHz trials of 100,000 frames at 1000 frames/s, FeitCSI missed 45.484±0.458% of expected identifiers while its process memory grew and swapped. Peak combined process-memory demand approached the platform’s nominal installed-memory reference, but the tests do not establish a universal run-time limit.

G. Experiment 2: FeitCSI Memory Growth at 600 MHz

  • The ten trials each injected 100,000 numbered frames at a target 1000 frames/s, with a nominal 100-second injection interval and a fresh process per trial.All ten trials reached receiver-side verification without a recorded collector failure.Source: G. Experiment 2: FeitCSI Memory Growth… · p. 17
  • FeitCSI missed 45483.6±458.0 of 100,000 expected identifiers per trial, or 45.484±0.458% loss, across ten completed 600-MHz trials.The standard deviations describe between-trial variation, not uncertainty in the mean or the location of losses.Source: G. Experiment 2: FeitCSI Memory Growth… · p. 17, Table VII · p. 17
  • Resident PSS rose from 14.51–15.31 MiB initially to 1572.13–1634.35 MiB at its sampled maximum; SwapPSS first appeared 65.10–68.60 seconds after active-phase start.Maximum swapped footprints reached 1488.45–1536.57 MiB, while falling resident memory accompanied substantial displacement to swap.Source: G. Experiment 2: FeitCSI Memory Growth… · pp. 17–18, Figure 8 · p. 18
  • Peak combined demand ranged from 1972.73–2019.24 MiB, a scale comparison of 96.32–98.60% of the nominal 2048-MiB reference, not physical RAM occupancy.The combined measure includes swapped pages; resident peaks alone were approximately 77–80% of the reference before other host workloads.Source: G. Experiment 2: FeitCSI Memory Growth… · p. 19, Figure 9 · p. 19
  • For this tested FeitCSI build and configuration, the results support short, bounded sessions on a 2-GB Raspberry Pi, not a universal maximum run duration.The ten 600-MHz trials completed; the 1500-MHz stress run crashed before usable traces were preserved, and does not establish the cause.Source: G. Experiment 2: FeitCSI Memory Growth… · pp. 17, 19

H. Experiment 3: Sustained VesperCSI Acquisition

Across thirty hour-scale VesperCSI sessions, sequence retention remained above 99.96% at each tested CPU ceiling. The results also show session-to-session variation and describe thirty separate acquisitions, not one uninterrupted run.

H. Experiment 3: Sustained VesperCSI Acquisition

  • The thirty trials injected four million frames each at 1000 frames/s, spanning approximately 33.3 hours of traffic across separate sessions.Each trial included startup and drain intervals, and successive trials were separated by a configured 15-minute cooldown.Source: H. Experiment 3: Sustained VesperCSI… · p. 19

1) Retention Throughout the Extended Workloads:

  • Retention was 99.985453% at 600 MHz, 99.997278% at 1000 MHz, and 99.963528% at 1500 MHz; aggregate retention was 99.982086%.Across all thirty trials, 119,978,503 of 120,000,000 expected identifiers were retained.Source: 1) Retention Throughout the Extended… · p. 19, Table VIII · p. 20
  • The largest single-trial loss was 9,829 identifiers at 1500 MHz, yet that trial retained 99.754275% of its expected sequence.The first 600-MHz trial lost 4,155 identifiers, while the remaining nine lost 70–276 each; retention was not monotonically improved by a higher frequency ceiling.Source: Figure 10 · p. 20, 1) Retention Throughout the Extended… · p. 20
  • No duplicate or out-of-range identifiers were recorded, but sequence accounting cannot locate losses within the radio-to-userspace acquisition path.The aggregate retention therefore describes end-to-end sequence accounting, not attribution to an individual component.Source: 1) Retention Throughout the Extended… · p. 20

2) Resident Memory and CPU Occupation:

During the extended VesperCSI sessions, sampled resident memory remained near 79 MiB, while mean process CPU occupation was about one logical core. Mean baseline-referenced SoC temperature rise increased with the CPU ceiling.

2) Resident Memory and CPU Occupation:

  • Mean trial-mean PSS was 79.15 MiB at 600 MHz, 79.25 MiB at 1000 MHz, and 79.10 MiB at 1500 MHz, with no recorded swapping.The largest original PSS sample was 80.79 MiB; PSS excludes other host memory, so these measurements do not bound total system RAM use.Source: Figure 11 · p. 21, 2) Resident Memory and CPU Occupation · p. 21

3) Temperature Rise During Hour-Scale Operation:

  • The observed thermal rise describes trial-level SoC readings, and one 600-MHz session diverged from the other nine after roughly 30 minutes.The measurements do not establish the cause of that trajectory or whether equivalent conditions would hold without the configured cooldown.Source: 3) Temperature Rise During Hour-Scale… · p. 21, Figure 12 · p. 22
  • Mean active SoC temperature rises were 7.75 ± 0.41 °C at 600 MHz, 12.14 ± 0.19 °C at 1000 MHz, and 15.82 ± 0.13 °C at 1500 MHz.Maximum sampled absolute temperatures were 61.84, 65.24, and 68.65 °C, respectively; temperature alone does not establish power or energy use.Source: 3) Temperature Rise During Hour-Scale… · p. 21, Figure 12 · p. 22

2) Resident Memory and CPU Occupation:

  • Mean process CPU occupation was 107.03% at 600 MHz, 105.55% at 1000 MHz, and 100.21% at 1500 MHz, normalized to one logical core.Values above 100% are possible when execution spans multiple threads; the four-core system activity shown includes other host workloads.Source: 2) Resident Memory and CPU Occupation · p. 21, Figure 13 · p. 22

4) Endurance Interpretation:

VesperCSI combines bounded-buffer acquisition mechanisms with a versioned plugin interface. The reported burst and endurance results support high-retention acquisition on tested CM4 systems, while the comparison and deployment conclusions remain bounded by the study’s package, platform, and workload scope.

4) Endurance Interpretation:

  • All thirty hour-scale acquisitions completed with 99.982086% aggregate sequence retention and a sampled process footprint below 81 MiB on the tested CM4.The result includes the 600-MHz configuration but applies to the recorded build, driver, radio parameters, and storage path at a 1000-frames/s target.Source: 4) Endurance Interpretation · p. 23

VIII. LIMITATIONS AND FUTURE WORK

  • VesperCSI is limited to Intel AX200/AX210 interfaces and compatible CSI-enabled backport-iwlwifi builds; evaluation covers CM4, VHT/80-MHz traffic, and two spatial streams.Other PHY formats, channel widths, radios, and amd64 performance remain outside scope.Source: §VIII · p. 23
  • The software crossover holds device/driver combinations fixed, so it does not independently isolate driver, hardware, and userspace effects.Sequence accounting identifies missing expected IDs but not where losses occur; raw CSI binaries and independent over-the-air traces are absent, and pending-write effects remain unresolved.Source: §VIII · p. 23
  • Ten consecutive repetitions per condition and an ordered sweep limit inference about independence, environmental drift, and thermal history.Sampler and SSH-control load is not separately quantified; PSS excludes other system memory, and CPU occupation and temperature do not measure energy.Source: §VIII · p. 23
  • The FeitCSI 1500-MHz run crashed without establishing its memory trajectory or failure mechanism, while VesperCSI’s separate hour-scale sessions do not establish uninterrupted multi-day operation.Memory pressure remains plausible but unproven; larger-loss VesperCSI trials remain relevant.Source: §VIII · p. 23
  • Fixed-capacity pools bound buffering rather than guarantee lossless capture; slow synchronous plugins can cause backpressure, and no plugin workload was evaluated.Future work includes independent driver variation, allocation and queue measurements, power and storage-throughput measurement, and longer uninterrupted sessions.Source: §VIII · p. 23

IX. CONCLUSION

  • 99.017% and 99.087% versus 46.553% and 43.972%: VesperCSI retained more expected frames than FeitCSI in 600-MHz, 2500-frames/s bursts, with ordering preserved after userspace exchange.The crossover compares software-and-driver packages, not isolated userspace effects.Source: §IX · p. 23
  • Across thirty separate hour-scale sessions, aggregate retention was 99.9821%; sampled PSS stayed at or below 80.792 MiB, with no recorded swapping or acquisition-process failure.The conclusion limits this evidence to the evaluated CM4 platform and does not establish lossless capture or uninterrupted multi-day operation.Source: §IX · pp. 23–24
Loading 2610.22581v1…