MikeFaith/pm3py
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(hw): repoint Cmd.LED_CONTROL to 0x011B (firmware LED port), hw.led now works

Browse Source 
The firmware fork now provides CMD_LED_CONTROL at 0x011B (payload_led_control_t). hw.led already packs the matching <BBBHH> struct + action codes, so repointing the id makes it functional. Adds Cmd.SET_HF_FIELD_TIMEOUT (0x011A, upstream's use of that slot). README caveat updated: hw.led works with the fork, no-op on stock.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
michael
2026-07-05 02:04:37 -07:00
parent 21107e8de7
commit b87f12253d
2 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
README.md
View File

@@ -89,10 +89,9 @@ print(t["lf"]["125kHz_V"], t["lf"]["134kHz_V"], t["lf"]["peak_freq_kHz"])
print(t["hf"]["13.56MHz_V"])
```
> ⚠️ **`hw.led` needs firmware with `CMD_LED_CONTROL`** (our LED port — currently a
> pending follow-up). On stock/current firmware `0x011A` is `CMD_SET_HF_FIELD_TIMEOUT`,
> so `hw.led` is presently a no-op. The API below is what it will drive once that
> firmware lands.
> **`hw.led` needs our firmware fork** (`CMD_LED_CONTROL` @ `0x011B`). It is not in
> stock upstream firmware — there `0x011A` is `CMD_SET_HF_FIELD_TIMEOUT` and `hw.led`
> is a no-op. With the fork flashed (the `firmware/` submodule) it drives the LEDs as below.
**LED control** is platform-aware — color names map to the correct physical LED on both PM3 Easy and RDV4. Accepts color names (`"green"`, `"red"`, `"orange"`, `"blue"`/`"red2"`, `"all"`), letters (`"a"`-`"d"`), comma-separated combos (`"green,red"`), or a bitmask int. Pick one action kwarg: