Hi, thank you again for your guidance. I have completed another controlled test using Apple’s “Working with generic spatial accessories” sample. I made no changes to the sample’s tracking logic; I only registered my accessory UTI and replaced the bundled .referenceaccessory. In the Tracking Camera Debug View, the accessory LEDs are lit, stable, clearly separated, and visible simultaneously. The sample displays the settings form rather than “No accessory connected” or “Unable to resolve the reference accessory.” Accessory Tracking authorization is allowed, but Is Tracked remains false and no tracking state is reported. I also corrected the source USDZ to use native meter units (metersPerUnit = 1) while preserving its physical dimensions, then retrained the reference accessory. This produced a measurable change in the visionOS logs: Before retraining: current accessories count=0, and the Accessory Tracking task list was empty. After retraining: current accessories count=1, model.mil is loaded, and three internal tracking tasks are running. The firmware receives continuous fast-blink LED reports. The observed parameters are approximately: emission duration: 300 µs emission interval: 33.332 ms intensity: 0.126667 scheduler late count: 0 queue overflow: 0 The BMI323 IMU stream is also stable at approximately 399–400 Hz, with no dropped reports or timestamp discontinuities. However, visionOS continues to report: Accessory corrections: 0 Accessory POIs corrections: 0 current anchors count=0 (total received=0) Therefore, the accessory and retrained model now appear to enter the ODT tracking pipeline, but initial acquisition still never succeeds and no AccessoryAnchor is produced. Could you confirm whether current accessories count=1 with active internal tasks means that the accessory and reference model have passed the initial validation stage? Is there any supported diagnostic that can distinguish between LED blob rejection, constellation geometry matching failure, and IMU/optical fusion rejection? I can attach the new meter-native .referenceaccessory, the complete firmware serial log, and the latest visionOS logs to FB23958038. Thank you for your continued help.

Hi, and apologies for the delayed follow-up. I was occupied with another project over the past two weeks and have now resumed testing this spatial accessory. I followed your requested procedure using Apple’s unmodified “Working with generic spatial accessories” sample. The LEDs are lit and visible in the Tracking Camera Debug View. The sample displays the settings form with Accessory locations, Tracking mode, and Metrics. Accessory Tracking authorization is allowed and the provider initializes, but Is Tracked remains false, no tracking state is reported, and no AccessoryAnchor is produced. I reproduced the issue again with the accessory connected and the sample app kept in the foreground. I also installed the visionOS Bluetooth logging profile and captured a new sysdiagnose during the active session. The new sysdiagnose and the complete .referenceaccessory file have been added to Feedback Assistant report FB23958038. Thank you for your patience and continued assistance.

Hi, I tested the suggested workaround on our accessory. The firmware no longer gates operation on the host-selected ASA version. After visionOS writes the Host Version payload 00 00 01 79, the firmware reports: asa_host_version status=NO_COMMON_PROTOCOL protocol=0.0 asa_host_version status=ASA_WORKAROUND_ACTIVE runtime=ALLOWED services=TIMESYNC,LED_FAST_BLINK,IMU The remaining runtime paths continue operating: TimeSync clock reaches READY. HID IMU streaming remains stable at approximately 398.9 samples per second. IMU errors, dropped reports, and backpressure remain zero. visionOS continuously sends LED fast-blink output reports. The LED report counter increased from 1 to at least 769. The reports use mode=2. The midpoint scheduler reports late=0 and queue_overflow=0. However, when testing with Apple’s “Working with generic spatial accessories” sample: Accessory Tracking authorization is allowed. Provider State remains unavailable. Is Tracked remains false. Tracking State remains unavailable. No AccessoryAnchor is produced. Therefore, not gating on the unexpected Host Version successfully keeps TimeSync, IMU, and LED fast-blink running, but it does not resolve the AccessoryAnchor issue in our case. This appears functionally similar to the latest result reported by ZemLi. Could you confirm whether the AccessoryTrackingProvider remaining unavailable is an expected consequence of the known ASA Host Version issue, or whether it indicates a separate validation failure? Our existing Feedback Assistant report is FB23958038.

Hi, thank you very much for the detailed guidance. Your suggestions helped me isolate a separate blocker before the optical constellation matching stage. While retesting with Apple’s “Working with generic spatial accessories” sample, I encountered an ASA version-negotiation issue similar to the one reported here: https://developer.apple.com/forums/thread/838291 After a clean pairing, visionOS successfully connects, enables encryption, reads the accessory ASA Version and UTI list, and subscribes to the HID notifications. However, it writes the same Host Version payload, 00 00 01 79, to both of these controlled firmware builds: ASA 1.1: 02 01 01 01 01 ASA 1.0: 02 01 00 01 01 The accessory consequently parses the selected host protocol as version 0.0 and reports NO_COMMON_PROTOCOL. The Vision Pro sysdiagnose also contains: Spatial accessory failed to conform to a supported type. Did not add accessory As a result, the accessory appears as a GCSpatialAccessory, but it is not accepted as a supported spatial accessory and no AccessoryAnchor is produced. I filed this as FB23958038. The report includes the complete accessory serial logs, both controlled firmware builds, and a visionOS-originated sysdiagnose captured approximately three minutes after reproduction. Could you please confirm whether this is a known issue in the current visionOS 27 beta, or whether Host Version 0.0 indicates that another ASA validation requirement has failed? Thank you again for your help.