Generic spatial accessory receives LED reports but never produces an AccessoryAnchor

Hi @tony5423

A few things to try:

• Run the Working with generic spatial accessories sample unmodified against your hardware and .referenceaccessory to rule out any unintended bugs introduced by your app.
• Use the Tracking Camera Debug View. With Developer Mode enabled: Settings → Developer → Debug View → Tracking Camera. Your accessory should appear under Connected Devices. If you do not see the accessory listed, there is an issue with initial recognition. You can click on your device to bring up an expanded view, where you can do some verification on the Uniform Type Identifier (UTID), the IMU, and the LED visibility.
  • UTID: ensure that the UTID received via Bluetooth matches what your trained model and app expect.
  • IMU: as you rotate the IMU, ensure that the correct axes are showing movement.
  • LEDs: toggle Illuminate LEDs to sync the LEDs with the tracking-camera exposure. As a rough heuristic: if blobs are missing, merged, or saturated in that feed, detection is the likely bottleneck; if they look clean and no anchor still appears, look at the reference file and constellation geometry, paying particular attention to scale and coordinate systems used to define the LED points and the IMU. Also make sure that the size of the LED glow in the Debug View is similar to the size of your LEDs in the training object relative to the rest of the object. You may have to adjust the brightness of the LEDs if the blobs are too small or too big.
• We expect sub-millimeter precision in the provided locations of the constellation LEDs. From looking at the screenshots of the trained vs. built model, the LEDs you are using are offset from the PCB itself. In modeling the LED constellation, make sure that you are putting the center of the modeled LED at the center of the emitting LED. In this case where the LED looks to be raised, you might have to add a perpendicular offset along the face of the LED to better represent the constellation.
• A volumetric window is fine as a host; the sample itself demonstrates this with its VolumeView. Just confirm the ARKitSession and AccessoryTrackingProvider both reach a running state and your app has Accessory Tracking authorization.
• Walk through the Accessory Design Guidelines, specifically the Spatial Accessories section (Reference Tutorial and Spatial Accessories Verification) for the checklist confirming the constellation and .referenceaccessory are accepted.

If the sample also fails, please file a Feedback Assistant request with a sysdiagnose captured shortly after the failure, and reply here with the FB number.

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.

@tony5423

Thanks for the feedback. I can confirm this is a known issue, and there is no workaround at this time. If I learn of one, I'll follow up on both this thread and the one you referenced.

Hi @tony5423

I posted a work around to this thread.

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.

@tony5423

Thanks for the reply. Can you confirm that when you view the accessory through the debug view (as explained in Explore enhancements to visionOS object tracking around 10:20) the LEDs are lit?

Also, could you describe what the sample app displays? Specifically, which of these three does the app window show?

• "No accessory connected"
• "Unable to resolve the reference accessory"
• The settings form with Accessory locations, Tracking mode, and Metrics

Finally, two things would help a lot if you can attach them to your existing Feedback Assistant report:

1. A new sysdiagnose captured while the app is running. Please launch the app with the accessory connected, leave it in the foreground for about 30 seconds, then trigger the sysdiagnose without closing the app. It's useful regardless of which of the three screens above the app displays. The previous sysdiagnose was captured during pairing with the app closed, so they don't contain the app side of the pipeline, and the logs we need age out quickly.

2. Your .referenceaccessory file. If you'd prefer not to share the full asset, the metadata.json and assets/*objectClass*/asset.json files from inside it are enough (it's a zip archive, so unzip -p Your.referenceaccessory 'assets/*objectClass*/asset.json' will pull that file out).