PaperlayerView exact revision on arXiv

Source-linked AI summary

Open-Source Live-Reconfigurable Multi-Mode Wearable Ultrasound

Cédric Hirschi, Federico Villani, Luca Benini, Andrea Cossettini

arXiv:2610.01602v1eess.SPcs.AR

TL;DR

Resource-constrained wearable ultrasound needs different hardware configurations for complementary measurement modes, and switching between them adds latency. This paper presents an open-source transition-aware control stack for in-session reconfiguration of TinyProbe; on a pulsatile-flow phantom, MCU scheduling reduced transition overhead to 3.1 ms and enabled a 16.0 Hz repetition rate for 75-shot Doppler blocks. The reconstructions demonstrate time-multiplexed flow and structural measurements in one acquisition session.

  • Problem

    Resource-constrained wearable ultrasound modes generally cannot share one configuration, and time-multiplexing them introduces reconfiguration latency that reduces repetition rate and creates gaps in physiological signals.

    Source: §I · p. 1

  • Method

    An open-source transition-aware stack models operating modes as hardware configurations and plans block-based schedules with transition-specific peripheral operations.

    Source: §I · p. 1, C. Operating Mode and Transition… · p. 2

  • Results

    For 75 Doppler shots at 1.43 kHz PRF followed by one structural acquisition, MCU scheduling reduced mean transition overhead from 30.2 ms to 3.1 ms and raised repetition rate from 8.6 Hz to 16.0 Hz.

    Source: §IV · p. 4

  • Takeaways & Limitations

    Concurrent Doppler-flow and lumen-diameter reconstructions demonstrate that functional and structural measurements can be time-multiplexed within one acquisition session.

    Source: §IV · p. 4

Abstract

from arXiv · show

Wearable ultrasound enables continuous deep-tissue monitoring, and a single programmable probe can operate in multiple complementary modes, such as structural A-mode and Doppler flow measurement. However, each operating mode requires dedicated measurement parameters and peripheral states, with no single configuration serving all modes on resource-constrained devices. Time multiplexing of operating modes introduces reconfiguration latency that lowers the effective mode repetition rate. To address this limitation, we present an open-source, transition-aware control stack for low-latency, in-session reconfiguration of the 32-channel TinyProbe wearable platform. Operating modes are described as hardware configurations, and host-side shadow registers track the peripheral states, enabling transition-specific register updates. Transition sequences are executed either by the host (over Wi-Fi 6) or by a firmware loop on the probe MCU. We validate the stack on a pulsatile-flow phantom by interleaving blocks of 25 to 100 pulsed-wave Doppler shots at 1.43 kHz PRF with single 16-channel A-mode acquisitions, changing channel configurations at every transition. Compared to full reconfiguration, the overhead per transition decreases from 30.2 ms to 11.6 ms (host-scheduled) and 3.1 ms (MCU-scheduled). For 75-shot Doppler blocks, the multi-mode repetition rate reaches 16.0 Hz (MCU-scheduled), 90.1% of the theoretical maximum of 17.7 Hz. Concurrent reconstruction of a Doppler spectrogram and a lumen-diameter trace demonstrates the functionality of time-multiplexed flow and structural monitoring.

I. INTRODUCTION

Wearable ultrasound supports complementary structural and flow measurements, but resource-constrained probes need different configurations for different modes, and switching adds latency. This work presents an open-source transition-aware control stack and validates faster in-session switching on TinyProbe.

I. INTRODUCTION

  • A programmable wearable probe can support A-mode, M-mode, B-mode, and Doppler measurements for applications including cardiovascular monitoring, muscle sensing, and human-machine interfaces.Source: §I · p. 1
  • Resource-constrained wearable probes generally cannot use one configuration for every mode, while time-multiplexed switching adds latency and gaps in physiological signals.Doppler needs kHz-range PRF but few receive channels; structural imaging benefits from more channels but operates at a lower frame rate.Source: §I · p. 1
  • The open-source control stack represents mode changes as transition-specific peripheral operations rather than rewriting every setting.The stack is publicly released at https://github.com/pulp-bio/TinyProbe.Source: §I · p. 1
  • A multi-mode schedule planner supports block-based acquisition, hardware-profile reuse, and cyclic sequence caching.Source: §I · p. 1
  • 30.2 ms full-reconfiguration overhead falls to 11.6 ms with host scheduling and 3.1 ms with MCU scheduling for 75 Doppler shots at 1.43 kHz PRF followed by one structural frame.The corresponding repetition rates rise from 8.6 Hz to 12.5 Hz and 16.0 Hz, respectively.Source: §I · p. 1

II. MATERIALS AND METHODS

The control stack runs on TinyProbe, where host-generated configuration RPCs travel to the probe MCU and acquired data returns to the host through a separate path.

A. TinyProbe Architecture

  • TinyProbe combines a wearable, runtime-programmable acquisition pipeline with a TX7332 pulser, AFE5832LP analog front end, FPGA acquisition subsystem, and SiWG917 Wi-Fi 6 MCU.Source: A. TinyProbe Architecture · pp. 1–2
  • During configuration, the host batches FPGA, AFE, and pulser operations into RPC methods sent over TCP to the MCU, which executes them and returns status.Operations include SPI-target selection, register writes, power control, delays, and acquisition triggering.Source: A. TinyProbe Architecture · p. 2, Figure 1 · p. 2
  • During acquisition, the FPGA acquires and buffers AFE data, relays it through the MCU, and serves it to the host over UDP at up to 35.7 Mbps.Source: A. TinyProbe Architecture · p. 2

B. State-Aware Hardware Control

Host-side peripheral models track configuration in shadow registers, enabling the control stack to batch changed fields into register writes instead of immediately communicating each parameter change.

B. State-Aware Hardware Control

  • Typed peripheral parameters update host-side shadow registers, while register fields marked dirty are batched into RPCs at the end of configuration.Source: B. State-Aware Hardware Control · p. 2
  • Modified fields in the same register are combined, minimizing register writes; dirty flags clear after the MCU reports successful execution.Source: B. State-Aware Hardware Control · p. 2
  • The session groups writes by peripheral and switches SPI targets only when needed, relying on all hardware changes going through the shared session to avoid full register readback.Optional immediate readback can check for shadow-state divergence, but adds overhead and was disabled during final measurements.Source: B. State-Aware Hardware Control · p. 2

C. Operating Mode and Transition Planning

The planner treats each measurement mode as a hardware configuration and organizes acquisition into blocks and ordered schedules, then prepares and caches transitions for execution.

C. Operating Mode and Transition Planning

  • An operating mode is the complete set of FPGA, AFE, pulser, and data-transfer parameters for a measurement; a block is consecutive shots in one mode, and a schedule orders blocks.A transition comprises the control operations needed to change modes.Source: C. Operating Mode and Transition… · p. 2
  • Planning setup, acquisition, and teardown phases applies parameters to shared hardware models and collects register updates and control operations without transmitting them immediately.Source: C. Operating Mode and Transition… · p. 2
  • Setup fully configures the first block and preloads pulser delay and pattern profiles; computed transition method sequences are cached for reuse.Caching avoids repeated host-side planning.Source: C. Operating Mode and Transition… · p. 2
  • Transitions place affected subsystems in a configuration-ready state, apply only needed register or profile changes, and restore operation.Pulser transitions select preloaded delay and pattern profiles instead of rewriting profile memory.Source: C. Operating Mode and Transition… · p. 2

D. Execution Backends

The execution backends run planned configuration sequences over the host-to-probe link or loop them on the MCU. Host scheduling incurs network-control latency, while MCU looping removes control communication between blocks.

1) Host-Scheduled:

  • Long host RPC requests are partitioned to fit the network link’s maximum packet size.The host backend executes the planned method sequences as emitted.Source: 1) Host-Scheduled · p. 2
  • TCP setup, packet transmission, and response latency contribute to host-scheduled switching overhead, while raw-data throughput uses an independent UDP path.The reported raw-data throughput is 35.7 Mbps.Source: 1) Host-Scheduled · p. 2

D. Execution Backends

  • A queued command can loop the block sequence using a repetition count and a target queue index, removing control communication between blocks.Source: 2) MCU-Scheduled · p. 2

2) MCU-Scheduled:

The validation interleaves Doppler and structural acquisitions on a pulsatile-flow artery phantom, measuring transition overhead and reconstructing flow and diameter signals.

2) MCU-Scheduled:

  • The MCU-scheduled backend loops a queued section, such as the complete block sequence, using a repetition count and target queue index.This removes control communication between acquisition blocks.Source: 2) MCU-Scheduled · p. 3

E. Experimental Validation

  • The validation used a 6 mm wall-less channel 12 mm beneath a silicone phantom surface, with pulsatile flow at 60 BPM and 0.7 m/s peak velocity.A syringe pump moved blood-mimicking fluid through the phantom into an open reservoir.Source: E. Experimental Validation · p. 3
  • The T-shaped transducer arrangement assigns the longitudinal view to Doppler velocity and the transverse view to structural diameter measurement, switching active channel sets at transitions.The transducers use separate subsets of the 32 TinyProbe channels.Source: E. Experimental Validation · p. 3, Figure 2 · p. 3
  • Each cycle interleaves a 25, 50, 75, or 100-shot Doppler block at 1430 Hz PRF with one 4 ms structural acquisition.Source: E. Experimental Validation · p. 3
  • Repetition rate was measured from MCU timestamps at Doppler-block starts, using seven complete cycle intervals per backend and shot count.The mean measured cycle duration was converted to repetition rate.Source: E. Experimental Validation · p. 3
  • The per-transition overhead includes excess critical-path time between acquisitions, including device reconfiguration and host-to-MCU communication for host scheduling.The measurements compare full, host-scheduled, and MCU-scheduled reconfiguration.Source: E. Experimental Validation · p. 3
  • Doppler reconstruction suppresses stationary clutter, selects receive-channel and depth gates by directional energy and signal power, then estimates velocity from a windowed spectrum.The pipeline uses 64-shot Hann windows with 75% overlap and converts Doppler frequency to flow velocity.Source: E. Experimental Validation · p. 3
  • Structural processing tracks near- and far-wall echoes by normalized template correlation, then combines accepted channel diameter estimates using a median and 3 Hz low-pass filter.Echo pairs are initialized using the phantom’s nominal 6 mm diameter.Source: E. Experimental Validation · p. 3

A. Transition Latency

MCU scheduling substantially reduces transition overhead and brings the 75-shot interleaved acquisition close to its overhead-free repetition-rate limit.

A. Transition Latency

  • For ND = 75, host and MCU scheduling reduce mean transition overhead by 61.5% and 89.8%, respectively, relative to full reconfiguration.MCU scheduling reaches 90.1% of the overhead-free 17.7 Hz repetition rate and has the lowest transition variability.Source: A. Transition Latency · p. 3
  • Transition overhead is approximately independent of Doppler block length, so its relative contribution decreases as ND increases.Fig. 3 shows achievable repetition rates across varying Doppler shots per frame.Source: A. Transition Latency · p. 3

B. Multimodal Acquisition

Concurrent reconstruction demonstrates time-multiplexed flow and structural monitoring, while the reported figures characterize repetition rates and transition overhead across configurations.

B. Multimodal Acquisition

  • For ND = 75, Table I reports each backend’s mean and variance of end-to-end reconfiguration overhead and its maximum repetition rate.The values are calculated from seven complete cycle intervals.Source: Table I · p. 4
  • Fig. 3 reports mean repetition rates by Doppler shots per frame across three configurations, with the theoretical maximum and standard-deviation error bars.Source: Figure 3 · p. 4
  • The Doppler spectrogram and lumen-diameter trace are reconstructed without visible gaps despite time-multiplexing limited hardware resources.The measurement used MCU-scheduled execution.Source: B. Multimodal Acquisition · pp. 3–4

IV. CONCLUSION

An open-source, transition-aware stack reconfigures TinyProbe between modes using complete hardware configurations and device-state tracking. For 75-shot interleaving, MCU scheduling reaches 16.0 Hz, while remaining overhead is dominated by device-side reconfiguration.

IV. CONCLUSION

  • On 32-channel TinyProbe, modes are complete hardware configurations; host-side state tracking generates transition-specific FPGA, AFE, and pulser updates, scheduled by the host or probe MCU.Source: §IV · p. 4
  • 30.2 ms fell to 11.6 ms (host-scheduled) and 3.1 ms (MCU-scheduled); for 75-shot interleaving, repetition rate rose from 8.6 Hz to 12.5 Hz and 16.0 Hz.The 75-shot schedule uses 1.43 kHz PRF; MCU scheduling reaches 90.1% of the theoretical maximum.Source: §IV · p. 4
  • Concurrent Doppler-flow and lumen-diameter reconstruction demonstrates time-multiplexed functional and structural monitoring in one acquisition session.Figure 4 shows the Doppler spectrogram and diameter trace for MCU-scheduled execution with ND = 75.Source: §IV · p. 4, Figure 4 · p. 4
  • Remaining switching overhead is dominated by device-side reconfiguration and, with host scheduling, network communication between acquisition blocks.Source: §IV · p. 4
  • The control stack is publicly available on GitHub.Source: §IV · p. 4
Loading 2610.01602v1…