Bug #10082
closed"can't concat str to bytes" when downloading from Baofeng UV-5R on py3 branch
0%
Description
Error message on terminal:
ERROR: Failed to clone: Failed to communicate with radio: can't concat str to bytes
Steps to reproduce
- Clone the py3 branch
- Create a new Python3 venv:
python3 -mvenv venv - Activate it:
source venv/bin/activate - Install the requirements:
pip install -r requirements.txt - Start CHIRP:
./chirpwx.py - Connect the radio and try to download the config
Environment: MacOS Monterey 12.5.1
Updated by Dan Smith over 2 years ago
- Status changed from New to Incomplete
Can you run with CHIRP_DEBUG=y and attach the output?
Updated by Lars V over 2 years ago
Thanks for taking a look!
Starting after the last few lines of the initial startup. Let me know if you need the full output from the launch.
INFO: Registered Icom_IC-T70 = ICT70Radio INFO: Registered Retevis_RT26 = RT26Radio WARNING: Last vendor/model not found INFO: Sending Magic: 000: 50 bb ff 20 12 07 25 00 P.....%. INFO: Valid response, got this: DEBUG: 000: aa 30 76 04 00 05 20 dd .0v..... INFO: Radio Version is b'HN5RV011\xff\xff\xff\xff\xff\xff' DEBUG: downloading main block... DEBUG: done. DEBUG: downloading aux block... ERROR: Failed to clone: Failed to communicate with radio: can't concat str to bytes
Updated by Dan Smith over 2 years ago
Are you up to date with the git branch? I'm not pulling changes from there back to mercurial for py3, FYI.
You might want to try with the content from this PR:
https://github.com/kk7ds/chirp/pull/83
Specifically 7c245dc which will log a traceback for errors encountered in the radio thread. That should make the log more useful so we can see where it's actually failing.
Updated by Tony Fuller over 2 years ago
I think radio.Model may be a string and not bytes looking at https://github.com/kk7ds/chirp/blob/83379aa6c93680b8d188a23df0c045ca8d0fa5bc/chirp/drivers/uv5r.py#L506
(The classes do declare them as strings https://github.com/kk7ds/chirp/blob/83379aa6c93680b8d188a23df0c045ca8d0fa5bc/chirp/drivers/uv5r.py#L725 )
Since b"HN5RV" appears in the radio version, we know that append_model = True (https://github.com/kk7ds/chirp/blob/83379aa6c93680b8d188a23df0c045ca8d0fa5bc/chirp/drivers/uv5r.py#L567) and if radio.Model is a string then line 605 would fail with exactly that message (https://github.com/kk7ds/chirp/blob/83379aa6c93680b8d188a23df0c045ca8d0fa5bc/chirp/drivers/uv5r.py#L605)
I don't have a UV-5R to try to debug with however
Tony
Updated by Dan Smith over 2 years ago
Right, this is the same sort of thing we have to do with all the drivers during conversion, and why it's not as simple as 2to3. You're probably right on the model detection part, but getting stack traces will make it much easier to track as there's likely another one right after the model comparison.
Shockingly all my UV-5Rs are out of pocket right now, else I'd try to reproduce.
Updated by Lars V over 2 years ago
Tony's analysis was spot on. After encoding the model name into a byte string, things work. I sent a PR with the fix: https://github.com/kk7ds/chirp/pull/84
As for debugging, I rebased to make sure I have PR #83 and 7c245dc in particular but they didn't provide additional debug output.