Revo2 Basic SN misparsed as Revo1AdvancedTouch, breaking auto-detect and Modbus control

[TannerGilbert]

• SDK version: bc_stark_sdk 2.0.2
• OS: Ubuntu 22.04 / Linux 6.8
• Device: Revo2 Basic, S/N BCMTR2027J25xxxxx, FW 1.0.20.U

What I observe

get_device_info() returns hardware_type=Revo1AdvancedTouch for a Revo2 Basic hand:

DeviceInfo: {"sku_type":"MediumRight","hand_type":"Right","hardware_type":"Revo1AdvancedTouch","serial_number":"BCMTR2027J2500001","firmware_version":"1.0.20.U","hardware_version":""}

The SDK appears to derive hardware_type from the serial-number string. The S/N BCMTR2027J2500001 (which the product manual and packaging list as a Revo2 Basic) is being matched against the Revo1AdvancedTouch rule.

Downstream effects

1. auto_detect_modbus_revo2(...) rejects the device — even when given the correct port — because the Revo2-specific detector sees Revo1AdvancedTouch and discards it. Users have to bypass autodetect entirely and hardcode port/baud/slave.
2. Modbus control commands route to the wrong register set. Any GUI/example that trusts get_device_info().hardware_type (e.g. python/gui/connection_panel.py, python/revo2/revo2_utils.py) sends commands that the hand silently ignores.

Workarounds I'm using

• Call set_hardware_type(slave_id, Revo2Basic) after get_device_info() instead of before.
• For the GUI's Modbus path, same post-call override (see gui/connection_panel.py).

Requests

• Could you check the SN-to-model mapping for the BCMTR2027J25xxxxx batch? If the SN was burned correctly, the parser table needs an entry for this format; if the SN was burned wrong, an end-user-reachable factory tool to reflash it would help.

Happy to share revo2_cfg.py console output if useful — autodetect logs show the SN-based decision clearly.