usb_radio: set_frequency/set_tx_power/etc. are stubs — live radio reconfiguration silently does nothing

[zindello]

Summary

While adding configure_radio to SX1262Radio (see #81), we audited all LoRaRadio implementations for live reconfiguration support. USBLoRaRadio has a gap worth investigating.

Finding

The individual setter methods in usb_radio.py are stubs — they update the local attribute and return True, but do not push anything to the firmware:

def set_frequency(self, frequency: int) -> bool:
    self.frequency = frequency
    return True

def set_tx_power(self, power: int) -> bool:
    self.tx_power = power
    return True

# ... same pattern for set_spreading_factor, set_bandwidth

Compare this with tcp_radio.py, which has the same setter pattern but each one calls _push_config_live() to send CMD_SET_CONFIG to the firmware immediately.

USBLoRaRadio does have CMD_SET_CONFIG available and uses it correctly in begin() at init time — the infrastructure is there, the setters just don't use it.

Is this a bug?

Maybe not — it depends on how the USB radio type is used in practice:

• If radio settings are only ever changed at startup (before begin() is called), this is harmless — begin() pushes the full config to firmware on connect
• If the UI or any caller expects to update settings live on a running USB radio (same use case as the SX1262 fix), the new values are silently ignored at the firmware level while the host attributes appear updated — the same class of bug as the SX1262 issue

What to check

1. Does anything in the repeater call these setters on a live USBLoRaRadio instance?
2. Should USBLoRaRadio get a configure_radio method (using CMD_SET_CONFIG) to match KissModemWrapper and SX1262Radio?
3. Or is the USB radio always fully restarted when settings change, making this moot?

Related

• hardware: add configure_radio to SX1262Radio #81 — adds configure_radio to SX1262Radio