Engineering fixture

Test the physical receiver path.

This bounded reference signal is for Xaere XR Receiver 0.3.28 build 2. It contains one public acoustic frame, no API key, no Audience secret and no device identifier.

XR

Reference XR Code

Code xr_5FAs6FwQ0PXqPoLzfbYs6shd, protocol 4, 48 kHz. Core accepted its public resolution on 14 August 2026. It expires on 21 August 2026 at 12:02:21 UTC; after that time a correct receiver must reject its resolution.

Download the reference WAV · Read its integrity metadata

Run it from two devices

  1. Open build 2 on the iPhone and tap Start receiver.
  2. Keep Audience measurement disabled.
  3. Play this WAV from another phone or computer at 50% volume, 20 cm away.
  4. Watch the on-device diagnostics: frames and peak must rise, then decoded must become 1 or more.
  5. A successful online resolution displays the verified https://example.com/ intent without opening it.
  6. Tap Copy privacy-safe diagnostics and paste the JSON into the QA report. It contains no microphone audio, device identifier or decoded XR content.

Complete acceptance order

The reference Code is shared. Complete every active-Code scenario on both Android and iOS before revoking it. An early revocation would make the remaining phone unable to prove a verified resolution.

  1. Confirm the installed application displays version 0.3.28 build 2 on both phones.
  2. On Android, then iOS, run quiet tests at 20 cm, 50 cm and 100 cm.
  3. On each phone, repeat the 20 cm test with normal speech in the room.
  4. For every scenario, replay within eight seconds: the verified-resolution counter must not increase.
  5. Copy and retain the privacy-safe diagnostics after each scenario; do not upload microphone audio.
  6. Only after all eight active tests pass, revoke the reference Code once.
  7. Replay it on both phones and confirm that neither produces a new verified intent.

If iOS hears audio but does not decode

Keep the receiver running and compare these bounded diagnostic renders in order. They carry the same signed XR frame as the baseline. They diagnose amplitude and protocol robustness only; they do not satisfy the release acceptance scenarios.

  1. Play the baseline above first: protocol 4 at render volume 50.
  2. Play protocol 4 at render volume 100. If only this decodes, the physical signal reaching the iPhone is too weak.
  3. Play protocol 3 (more redundant) at render volume 100. If this decodes while protocol 4 does not, the capture path is present but the faster transport is not robust on that route.

Before each comparison, note captured frames, peak and decoded count. Stop if the source is uncomfortably loud in its audible harmonics. Integrity metadata records the exact protocol, byte length and SHA-256 values.

Interpret the result

  • captured_frames = 0: iOS did not deliver microphone samples.
  • Frames increase but peak_level_milli stays below 8: the ultrasonic signal is too weak or filtered by the active input route.
  • decoded_payloads > 0 but no verified resolution: microphone and ggwave succeeded; inspect Core connectivity or code expiry.
  • verified_resolutions = 1: the complete acoustic and signed Core resolution path passed.