PaperlayerView exact revision on arXiv

Source-linked AI summary

OctoSense: Building a Unified Ecosystem for Open-Source Wireless Sensing

Weiying Hou, Xie Zhang, Chenshu Wu

arXiv:2610.12405v1cs.NI

TL;DR

Wireless sensing research is fragmented by heterogeneous data and incompatible processing and benchmarking workflows, limiting reproducible comparison. OctoSense unifies data abstraction, signal operators, and specification-driven benchmarking; representative evaluations report closely matched accuracy and substantially less boilerplate code.

  • Problem

    Heterogeneous wireless-sensing data, non-interoperable processing, and missing standardized benchmarks leave the field fragmented and impede reproducible comparison.

    Source: §1 · pp. 1–2

  • Method

    OctoSense decouples model logic from data and signal nuances through unified data abstraction, standardized signal operators, and a specification-driven benchmark engine.

    Source: §1 · p. 2

  • Results

    Accuracy matched paired hand-engineered implementations within 0.8% points, and boilerplate code was reduced by over 80%.

    Source: §1 · p. 2

  • Takeaways & Limitations

    OctoSense provides a foundation for wireless-sensing datasets and models to be interoperable, reusable, and reproducible.

    Source: §8 · p. 13

    OctoSense primarily serves DWS workflows and does not directly solve model generalization or domain adaptation; for conventional signal-processing-centric sensing, its contribution focuses on Data and Transform layers.

    Source: §6 · pp. 11–12

Abstract

from arXiv · show

As AI enters the physical world, wireless sensing has emerged as a key modality for enabling non-intrusive physical intelligence. However, unlike the mature ecosystems of vision and language models, wireless sensing research remains highly fragmented. The field faces a growing "reproducibility wall" caused by heterogeneous data formats, non-interoperable processing pipelines, and the lack of standardized benchmarks. To dismantle this barrier, we present OctoSense, a unified platform designed to propel wireless sensing toward an "ImageNet-style" research ecosystem. OctoSense introduces a holistic framework that decouples high-level model logic from ad-hoc data nuances through three distinct components: a unified data abstraction for streamlined dataset access, standardized signal operators for efficient model development, and a rigorous benchmark engine for rapid and fair comparison. To support existing datasets and models, OctoSense integrates a comprehensive suite of widely used datasets and models, reducing the effort required for data and model adaptation to a few lines of declarative code. We demonstrate the efficacy of OctoSense through a set of usage examples that reproduce representative models on popular datasets. By providing a foundational open-source infrastructure, OctoSense enables community efforts to accumulate rather than fragment, paving the way for wireless sensing research that is interoperable, reusable, and reproducible by design.

1 Introduction

Wireless sensing research is fragmented by heterogeneous data and non-interoperable workflows, making fair reproduction difficult. OctoSense unifies dataset access, signal processing, model use, and benchmarking, and reports reduced implementation effort in representative evaluations.

1 Introduction

  • Wireless sensing lacks the shared data language and standardized ecosystem available in vision and language research, leaving dataset access, model interoperability, and rigorous benchmarking fragmented.Heterogeneous, hardware-dependent signals and inconsistent preprocessing make results difficult to verify fairly across studies.Source: §1 · pp. 1–2
  • OctoSense expresses an STFNet-on-Widar3.0 workflow in about ten lines and saves its experimental configuration so the same baseline can be reproduced with one command.The interface connects dataset selection, signal processing, dataloader construction, model invocation, and benchmark execution.Source: Figure 1 · p. 1, §1 · p. 2
  • OctoSense combines unified data abstraction, standardized signal operators, and specification-driven benchmarking to decouple model logic from heterogeneous data and signal formats.The data abstraction attaches physical semantics such as frequency, sampling rate, and antenna configuration; the benchmark specification records and restores evaluations.Source: §1 · p. 2
  • The platform supports representative wireless-sensing datasets and mainstream models, aiming to make existing resources reusable and reproducible.The paper lists datasets including Widar3.0, SignFi, HuPR, and MMFi, and models including STFNet, UniTS, and ResNet.Source: §1 · pp. 2–3
  • Accuracy matched paired hand-engineered implementations within 0.8% points, while boilerplate code fell by over 80%.The evaluation uses representative implementations of OctoSense.Source: §1 · p. 2

2 Background and Motivation

Wireless-sensing workflows require repeated, dataset-specific work across data preparation, model development, and benchmarking. An ecosystem survey and review of prior tools point to recurring practical burdens in data semantics, preprocessing, and reproducibility.

2.1 DWS Research Workflow

  • Dataset preparation must reconcile differences in hardware, acquisition conditions, physical meaning, labels, and preprocessing, so structurally similar datasets may still be fragile to reuse.DWS workflows also encode signal interpretation through sample construction, tensor layout, and metadata retention.Source: §2.1 · pp. 3–4
  • Model-specific signal transformations and under-specified preprocessing can silently change inputs, while baseline reimplementation makes comparisons vulnerable to mismatched assumptions.Reported performance differences may partly reflect implementation assumptions rather than genuine algorithm advances.Source: §2.1 · p. 4
  • OctoSense responds to workflow fragmentation with name-based dataset selection, standardized transforms, and specification-driven benchmarking and reproduction.The survey describes existing tools as covering isolated workflow parts, with limited coverage across the full research cycle.Source: §2.1 · p. 4, §2.2 · p. 5

2.2 Current DWS Ecosystem

  • Across 554 manually reviewed GitHub issue threads, recurring discussions concern data semantics, preprocessing, and reproducibility, though the threads are not an unbiased prevalence estimate for the field.The survey linked published papers to public repositories and analyzed issue discussions after repository deduplication.Source: Figure 3 · p. 3, §2.2 · pp. 4–5

3 OctoSense Design

OctoSense is a PyTorch-native platform for deep wireless sensing that separates model logic from device-specific RF formats. Its data, transformation, model, and benchmark abstractions make heterogeneous sensing workflows more consistent and reusable.

3 OctoSense Design

  • OctoSense provides a PyTorch-native platform that incorporates wireless signals’ physical characteristics into a standardized, interoperable pipeline.It aims to replace isolated scripts with a familiar PyTorch environment for handling complex RF data.Source: §3 · p. 5

3.1 OctoSense Overview

  • The overview standardizes dataset access, model development, and baseline benchmarking through a shared representation and configurable workflows.Dataset creators adapt raw signals through a driver script; users can switch datasets, use versioned preprocessing, and reproduce baselines from configuration.Source: §3.1 · p. 5

3.2 Data Abstraction

  • A unified representation attaches RF semantics to samples, while a metadata layer supports consistent dataset access and reuse.Task-dependent labels are attached as metadata coordinates, and metadata-backed views allow filtering and splitting before RF tensors are loaded on demand.Source: §3.2 · pp. 6–7, Figure 4 · p. 6, Figure 5 · p. 6

3.3 Operators and Models

  • Composable operators use semantic contracts to track preprocessing assumptions, while model-specific adaptations connect transformed RF data to standardized baselines.Operators define preconditions and postconditions; the model boundary allows different input layouts while normalizing outputs for task-level comparison.Source: §3.3 · pp. 7–8, Figure 6 · p. 7

3.4 Benchmark Engine

  • The benchmark engine combines reusable execution pipelines with serialized specifications that record and restore complete benchmark configurations.Specifications capture datasets, transforms, models, and runtime parameters as a versionable record that can be shared and rerun.Source: §3.4 · p. 8, Figure 7 · p. 9

4 Implementation

OctoSense is implemented as a modular PyTorch stack spanning signal input/output, datasets, transforms, and benchmark models.

4 Implementation

  • The implementation organizes reusable reader-dataset-transform-model combinations rather than isolated benchmark-specific scripts.Raw-signal readers support IWL5300, Atheros, ESP32, Nexmon, and TI DCA1000 capture formats.Source: §4 · p. 9
  • The dataset layer covers Wi-Fi, mmWave, and multimodal benchmarks spanning gesture and activity classification, pose estimation, and respiration monitoring.Supported datasets include Widar3.0, WiFi Gait, SignFi, FallDar, CSI-Bench, HuPR, MM-Fi, XRF55, and OctoNet.Source: §4 · p. 9
  • Reusable signal-processing components include filtering, normalization, preprocessing, and cuFFT-based spectrum generation, alongside representative baseline models.The listed models include STFNet, UniTS, RFNet, Widar3, Swin-Transformer, and ResNet.Source: §4 · p. 9

5 Evaluation

OctoSense is evaluated through paired implementations that hold task and training conditions fixed while changing data binding and preprocessing. The evaluation reports reduced pipeline code, preserved paired accuracy, early detection of injected semantic errors, and case studies of baseline reproduction and modular workflows.

5.1 OctoSense Effectiveness

  • 80% to 91% lower LLOC across 13 paired configurations, with paired test-accuracy gaps at most 0.8% points.OctoSense introduced no additional peak memory usage; first-batch latency and epoch time varied by dataset-model pair, and representative loss curves remained closely aligned.Source: §5.1 · pp. 9–10, Figure 8 · p. 9, Table 2 · p. 10
  • In the autonomous reproduction case, the agent failed without OctoSense after 15 attempts and 4.95M tokens, but reproduced the benchmark on its first attempt with OctoSense using 1.94M tokens.The failure involved a spectrogram implementation that discarded one side of the STFT spectrum for complex CSI; with OctoSense, outputs matched the reference implementation.Source: §5.1 · p. 10
  • OctoSense identified every injected semantic error before model training across the evaluated cases.The checks included schema validation, operator constraints, metadata consistency, split validation, and model-boundary verification.Source: §5.1 · p. 10, Figure 9 · p. 10

5.2 Case Study

  • The case studies show workflows for baseline inference, custom-model benchmarking, declarative pipeline composition, and integration of heterogeneous datasets.Users can replace components while retaining standard datasets and processing, or define custom readers that map raw data into shared RF semantics.Source: §5.2 · pp. 10–11
  • Explicit physical semantics at ingestion turn isolated laboratory data into interoperable modules for reuse across the workflow.The described connection runs from hardware collection to deep learning models and provides a basis for sharing heterogeneous datasets.Source: §5.2 · p. 11

6 Discussions and Future Work

OctoSense supports DWS workflows with reusable pipelines for inference, benchmarking, signal processing, and custom dataset integration. Its primary scope is DWS; for conventional signal-processing-centric sensing, its contribution focuses on data and transform layers.

Scope and Applicability

  • OctoSense primarily serves DWS workflows; for conventional signal-processing-centric sensing, its contribution focuses on the Data and Transform layers.The unified metadata specification centralizes reader adaptation and reduces repeated manual parsing in downstream workflows.Source: §6 · p. 11

Inference pipeline

  • A pre-packaged pipeline lets users inspect input and output semantics and run inference with a pretrained STFNet model using minimal configuration.The example accepts Wi-Fi CSI with named axes and returns predictions with scores.Source: §6 · p. 11

Custom models

  • Researchers can inject a custom model into a standard benchmark, align RF input semantics to its tensor shape, and train it through OctoSense.The example uses a custom transformer in place of the pretrained model.Source: §6 · p. 11

Signal processing

  • Declarative signal-processing pipelines compose dataset loading, transforms, dataloader construction, and model training.The example includes pilot interpolation, axis normalization, PCA, and spectrogram extraction.Source: §6 · p. 11

Custom datasets

  • A custom reader maps raw hardware data into semantic tensors with metadata, after which the dataset can reuse existing operators, models, and evaluation workflows.The example wraps the reader output and labels as a dataset, then loads a Widar3 default task with STFNet.Source: §6 · p. 12

Limitations and future work

  • OctoSense does not directly solve open problems such as model generalization or domain adaptation; planned work includes streaming and online pipelines, metadata inference, and versioning tools.The authors also plan a governance mechanism to support community contributions.Source: §6 · p. 12

7 Related Work

Prior wireless-sensing tools address parsing, signal processing, datasets, or benchmarking, but the work describes them as fragmented across pipeline stages. OctoSense positions itself as an open-source framework joining dataset support, model development, and baseline benchmarking.

Ecosystems in Adjacent Domains

  • Adjacent CV, NLP, and other domain ecosystems combine data management, preprocessing, and model integration under shared APIs, inspiring OctoSense’s reusable RF pipelines.The passage names ecosystems in computer vision, audio, geospatial research, medical imaging, recommender systems, physics, biology, and graph processing.Source: §7 · p. 12

RF Sensing Ecosystem

  • Existing wireless-sensing tools cover parsing, radar processing, public datasets, or baselines, but the described systems lack a unifying infrastructure across the research pipeline.The passage notes missing physical metadata and semantic axis validation in parsing tools, and customized preprocessing around many dataset-specific models.Source: §7 · p. 12

Our Positioning and Contribution

  • OctoSense connects dataset support, model development, and baseline benchmarking through a common core and a unified data language.Its reusable operator interfaces make signal-processing steps composable pipelines.Source: §7 · p. 12
  • The authors describe the platform’s software-side semantic safety layer as a way to help future research accumulate around a shared system and focus on algorithmic innovation rather than repeated reimplementation.They characterize the integration of unified data representations, semantic operators, and reproducible workflows as novel to their knowledge.Source: §7 · pp. 12–13

8 Conclusion

The conclusion presents OctoSense as infrastructure addressing fragmented datasets, incompatible preprocessing, and missing standardized benchmarks in wireless sensing. It combines unified data abstraction, standardized signal operators, and specification-driven benchmarking to support an interoperable, reusable, and reproducible ecosystem.

  • Wireless sensing research faces fragmented datasets, incompatible preprocessing pipelines, and a lack of standardized benchmarking that hinder reproducible and cumulative research.Source: §8 · p. 13
  • OctoSense combines a unified data abstraction, standardized signal operators, and a specification-driven benchmarking engine.Source: §8 · p. 13
  • The authors aim for a unified, sustainable ecosystem in which community efforts are interoperable, reusable, and reproducible.Source: §8 · p. 13

A Survey scope and GitHub issue analysis

The appendix describes an auditable process for building a wireless-sensing paper and repository corpus and analyzing repository issues. Manually verified issue discussions repeatedly raised data-semantics, preprocessing, and reproducibility concerns, but the authors do not treat those discussions as a field-wide prevalence estimate.

Corpus construction

Paper-to-repository mapping

Repository and issue collection

Issue analysis

  • An LLM extracted candidate evidence sentences on data semantics, preprocessing, and reproducibility, after which researchers manually verified labels supported by explicit evidence.The prompt excerpts and output rules are presented to make the extraction procedure transparent.Source: A Survey scope and GitHub issue analysis · p. 16, Figure 11 · p. 17

Workflow

Findings and scope

  • Issue discussions repeatedly surfaced unclear data meaning, opaque preprocessing, and missing implementation details needed for reproduction.The authors treat the threads as evidence of community reuse burden, not an unbiased estimate of field-wide prevalence.Source: A Survey scope and GitHub issue analysis · pp. 16–17
Loading 2610.12405v1…