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).

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 @tony5423

This may be a CreateML issue affecting USD files with a metersPerUnit other than 1. Your USD is authored in millimeters (metersPerUnit = 0.001), and in the .referenceaccessory you shared the IMU rotation and voxelSize are both off by a factor matching metersPerUnit. You can check the second one directly: occupancyGrid.voxelSize is 3.5488293 where it should be 0.0035488293.

Worth trying: rescale the source USD to metersPerUnit = 1 and retrain, then let us know whether tracking recovers.

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 @tony5423

Thanks for the detailed write up.

You reached the settings form, so the reference accessory loaded successfully. That's separate from the system actually tracking the accessory, which is what's still failing.

There's no diagnostic that tells you why tracking isn't happening, so while we investigate further, there are a couple of things worth confirming on your end. The supported checks happen at training time, so review CreateML's pretraining validation warnings. This is most often a problem with the LED layout, so re-verify the model against the documented requirements: four or more LEDs visible at each viewing angle of interest, spacing at least twice the expected blob diameter, submillimeter precision on each LED coordinate and normal, opaque LED material, and a non-reflective, non-transparent body. Full parameters are in the Accessory Design Guidelines. In your image, some surfaces appear to have only 2 LEDs.

Please update your feedback request with the new .referenceaccessory, a sysdiagnose captured right after a failed attempt, and the exact visionOS version. Reply here once it's attached and I'll follow up.