Conversation
The device does not answer once. It streams progress reports, 02 4A 41 <percent>, stepping to 100 — byte [3] is a percentage, not a status constant. The README's 'status code of 100' is the device saying 100 % complete. Reading a single reply therefore prints 'Done. Recordings deleted. (status: 0)' while the erase has not started. Observed on hardware: the message appeared 2.3 s before the device had finished. krode now reads until 100 %, showing progress on a terminal and staying quiet when redirected so logs do not fill with percents. Losing the device after progress has been reported is treated as a normal ending rather than a failure: the transmitter drops off the bus as soon as it is done. Losing it before any reply is still an error. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Nice catch on this! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces my #3, which duplicated @zinic's #1. This keeps only the part that
does not overlap: reading the reply properly.
It is independent of device support and applies to the Interview PRO too —
it touches
delete_recordings()and nothing else, so it should merge cleanlybefore or after #1.
The bug
The device does not answer once. It streams progress reports as it erases:
Byte
[3]is a percentage, not a status constant — the README's "statuscode of 100" is the device reporting 100 % complete.
Reading a single reply therefore returns at the first report, which is
0:The
(status: %d)in the current message is what makes this visible: it prints0, not100.The fix
Read until byte
[3]reaches 100. Progress is shown on a terminal andsuppressed when redirected, so logs do not fill with percents.
Losing the device after progress has been reported is treated as a normal
ending rather than an error — the transmitter drops off the bus as soon as it
is done. Losing it before any reply is still an error. I added that branch
after hitting exactly that case during testing; it is the one part I have not
been able to re-trigger deliberately since, so it is worth a second pair of
eyes.
Testing
Verified on a Wireless PRO TX (PID
0x0056), which needs #1 or a locally addedPID to be reachable — I built a throwaway copy with the PID added rather than
touching the committed source, so this diff is only the read loop.
I do not have an Interview PRO, so that hardware is untested by me. The change
is device-agnostic, but the timing characteristics may differ.
Builds clean with
-Wall -Wextra. The committedkrodebinary is untouched.