We are developing a generic spatial accessory for Apple Vision Pro using the “Working with generic spatial accessories” sample and a trained .referenceaccessory file.
Environment:
- visionOS: [version/build]
- Xcode: [version/build]
- Hardware: Apple Vision Pro + nRF52840-based BLE accessory
- IMU: 6-axis IMU, 400 Hz HID reports
- LED constellation: 8 x 850 nm IR LEDs, driven through MOSFETs
The BLE/HID and timing path appears to be working:
- The accessory connects successfully over BLE.
- ASA/HID enumeration succeeds.
- The firmware receives continuous LED Output Reports from visionOS.
- The Accessory Tracking Clock reaches READY.
- PWM scheduling reports no late events and no queue overflow.
- In the Accessory Tracking Debug View, multiple independent IR LED blobs are visible and stable at approximately 0.7 m.
- At least 4 LEDs are visible from normal viewing angles.
- The app resolves the .referenceaccessory and starts AccessoryTrackingProvider.
However, ARKit never produces an AccessoryAnchor. We also have no diagnostic signal indicating whether the failure occurs at:
- LED candidate-point detection,
- constellation matching against the .referenceaccessory, or
- IMU/optical fusion.
Questions:
- Is there a supported diagnostic API, log category, or Debug View indicator that distinguishes candidate-point rejection from constellation-match or fusion rejection?
- Are there known acquisition prerequisites in the current visionOS beta beyond the published Accessory Design Guidelines?
- Can Apple recommend a minimal validation procedure using the generic spatial accessory sample to confirm that the LED constellation is accepted by the tracking system?
- Is this expected to work in a volumetric window, or are there additional lifecycle/session requirements that can prevent initial acquisition?
I can provide sanitized HID LED-report logs, timing data, Debug View captures, and a minimal reproducible project if useful.