Repository navigation
fix(arbiter): move Polar 65+ 0xA009 to the live 0xFF02 collection - #12
Conversation
#11 shipped the 0xA009 row on 0xFF01, but the board's 0xFF01 collection answers nothing: after the release the reporter could claim the board but getFirmware timed out. The live vendor app (app2.arbiterstudio.com) pairs product 40969 strictly with usagePage 65282 and only claims devices exposing it, and a USB capture shows all vendor traffic on interface 3 (endpoints 0x04/0x84) while interface 2 is silent. Move the row to 0xFF02 and pin it in tests. Also notes the second Polar 65+ variant 0xA010 found in the vendor bundle (no capture yet, no row).
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 24 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
github-actions
Bot
added
area: protocol
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Routes the Polar 65+ to its active 0xFF02 configuration collection, with matching documentation and regression assertions. Vendor-app and USB-capture evidence support the correction, and other models and protocol behavior are unchanged. Notes:
You can add or adjust custom eligibility rules. Learn more. |
|
🎉 This PR is included in version 1.6.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Follow-up to #11, which shipped the
0xA009row on0xFF01. After the release the reporter could claim the board butgetFirmwaretimed out — the board's0xFF01collection answers nothing. Fixes #9 for real this time.How the page was pinned:
0xFF01(usages ...02/...03) and0xFF02(usages ...03/...04).0x04/0x84); interface 2 is completely silent.Polar 65+, vendorId 14108, productId 40969, usagePage 65282and its device picker only claims collections withusagePage == 65282.65282appears 3x in the bundle,65281zero times.So the live configuration interface is
0xFF02. This moves the row there and pins it in tests (0xA009on0xFF02isi2; on0xFF01is undefined).Also noted in docs: the same bundle lists a second Polar 65+ variant, product 40976 (
0x371C:0xA010), on0xFF02with Main+FN, 3 profiles and SuperTap but a different protocol class — no capture exists for it yet, so no row.Verification: full suite
384 pass, 0 fail;npm run buildclean. (The 7 failures seen mid-work were a staledist/after pulling main — rebuild fixed them; unrelated to this change.)Note
Fix Polar 65+ (PID 0xA009) to use usage page 0xFF02 in arbiter catalog
Updates the
ARBITER_PRODUCTSentry for VID 0x371C / PID 0xA009 from usage page 0xFF01 to 0xFF02. The live vendor app pairs this product with 0xFF02, and the board's 0xFF01 collection does not respond. Updates arbiter-support.md and adds catalog-matching assertions in protocol.test.ts. Notes a second Polar 65+ variant (PID 0xA010) with no capture and no catalog row.Macroscope summarized e4c428c.