Bug #10398
closedQuasnsheng TG-UV2+ needs fixing for -next
Added by Robert Toth over 1 year ago. Updated about 1 year ago.
100%
Description
Failed to communicate with radio: unicode strings are not supported,
please encode to bytes:'\x02PnOGdAM'
Tried the Bug #10257 Baofeng UV-3R fix, but did not work.
Files
tg_uv2p.py (27 KB) tg_uv2p.py | 44055aa1 | Dan Smith, 02/27/2023 01:47 AM | |
chirp.config (275 Bytes) chirp.config | Robert Toth, 02/28/2023 12:08 AM | ||
debug.log (1.34 KB) debug.log | Robert Toth, 02/28/2023 12:08 AM | ||
debug.log (1.34 KB) debug.log | Robert Toth, 02/28/2023 12:20 AM | ||
debug.log (2.83 KB) debug.log | Robert Toth, 02/28/2023 01:41 AM | ||
tg_uv2p.py (27 KB) tg_uv2p.py | 8e25a14b | Dan Smith, 02/28/2023 01:42 AM | |
debug.log (2.48 KB) debug.log | Robert Toth, 02/28/2023 01:50 AM | ||
Cloning from radio_2023-02-27_21-38-47.png (46 KB) Cloning from radio_2023-02-27_21-38-47.png | Robert Toth, 02/28/2023 02:41 AM | ||
tg_uv2p.py (27 KB) tg_uv2p.py | Ran Katz, 02/28/2023 09:43 PM | ||
Безымянный.jpg (63.7 KB) Безымянный.jpg | Й Я, 06/21/2023 12:52 PM | ||
Безымянный-2.jpg (54.6 KB) Безымянный-2.jpg | Й Я, 06/21/2023 12:52 PM | ||
chirp_debug-347u6970.txt (3.03 KB) chirp_debug-347u6970.txt | Й Я, 06/21/2023 12:53 PM |
Updated by Dan Smith over 1 year ago
- File tg_uv2p.py tg_uv2p.py added
- Status changed from New to Feedback
- Target version set to chirp-py3
That fix was specific to that radio, so it wouldn't work for yours. I have attached a module for you to test. Please try it and capture a debug log per How_To_Report_Issues with it applied, even if it works.
Enable developer mode in the help menu, restart chirp, then File->Load Module and select this file. Then try to download the radio. If that works, try uploading. Please have a backup of your radio saved in case the upload fails, which may cause the radio to reset.
Please report whether this works or not and attach a debug log.
Thanks!
Updated by Dan Smith over 1 year ago
- Subject changed from unicode strings to Quasnsheng TG-UV2+ needs fixing for -next
Updated by Robert Toth over 1 year ago
- File chirp.config chirp.config added
- File debug.log debug.log added
Update.
First, the radio is a Quansheng TG-UV2. It's not listed in Chirp, so I went with the Quansheng TG-UV2+ because that was available.
Sorry for the confusion.
Applied the file tg_UV2p.py
New error message up on Download from radio:
Error communicating with radio
Invalid response for address 0x0000
Upload to radio is dimmed.
Updated by Dan Smith over 1 year ago
Okay, I don't know if those are the same radio or not.
Your debug log does not actually capture the attempt to download. Please:
- Open chirp
- Load the module
- Attempt the download
- Capture the debug log
You must do all steps in a single run of CHIRP. The debug log is wiped clean every time you restart chirp.
Updated by Robert Toth over 1 year ago
Same error message
It's not making a new entry in the log file today, with the tg_UV2p.py file loaded.
Updated by Dan Smith over 1 year ago
The debug log shows that you're not loading the module. You have to do it every time you start chirp. It also shows you're not actually starting the download process. The debug log you just attached is literally identical to the previous one you attached. Did you attach the wrong file?
Updated by Dan Smith over 1 year ago
Perhaps you're running from the command line in interactive mode now? The debug.log
is not written when you run it interactively, which would explain why the log you attached has yesterday's date. Either run it non-interactively and grab the log, or run it like this to capture the console output:
$ chirp >debug.log 2>&1
Updated by Robert Toth over 1 year ago
Well I did load the module, when I don't load it, I get the first error message.
The log file is from my home directory from the .chirp folder.
Is there another log file somewhere>
Updated by Robert Toth over 1 year ago
These are the messages I am getting:
File does not exist: >debug.log
File does not exist: 2>&1
Unknown file format
Updated by Robert Toth over 1 year ago
UPDATE
from the console:
(chirp:927611): dbind-WARNING **: 20:20:36.990: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
08:20:37 PM: Debug: Adding duplicate image handler for 'Windows bitmap file'
08:20:37 PM: Debug: Adding duplicate image handler for 'Windows bitmap file'
08:20:37 PM: Debug: Adding duplicate image handler for 'Windows bitmap file'
WARNING: Did not find localedir: /usr/local/lib/python3.8/dist-packages/chirp/locale
WARNING: Replacing existing driver id `Quansheng_TG-UV2+'
ERROR: Failed to clone: Invalid response for address 0x0000
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/chirp/wxui/clone.py", line 66, in run
self._fn()
File "/home/robtoth/Chirp/tg_uv2p.py", line 265, in sync_in
self._mmap = do_download(self)
File "/home/robtoth/Chirp/tg_uv2p.py", line 159, in do_download
raise errors.RadioError("Invalid response for address 0x%04x" % i)
chirp.errors.RadioError: Invalid response for address 0x0000
Updated by Dan Smith over 1 year ago
Its not redirecting to the debug log because you're passing those shell instructions in a way that they get sent to chirp as arguments, which will not work. Are you quoting them? You should not be. You also need to enable debug logging. Try this exactly:
chirp </dev/null
which should cause it to write the debug.log
in the usual spot with debugging enabled. No quotes, do not type the $
(that's the prompt) etc.
If that doesn't work, please show me exactly how you're running chirp.
Updated by Robert Toth over 1 year ago
NEW
debug.log
Updated by Dan Smith over 1 year ago
- File tg_uv2p.py tg_uv2p.py added
Even without the debug log I think I spotted the problem. Here's another module to try.
Updated by Dan Smith over 1 year ago
Yes that debug log looks better, thanks. Please use that method to capture a debug log with the above new module.
Updated by Robert Toth over 1 year ago
Half way through
Unexpected response
Got to go to pick up my son.
Updated by Dan Smith over 1 year ago
Do you mean it seemed to proceed and then fail halfway through? The failure indicates the radio actively refused to send a block on request. That makes me think it's all working, but perhaps the model mismatch is the problem.
Had you ever tried with CHIRP-legacy and this radio? If not, I think we probably can't proceed here until someone else shows up with a TG-UV2+ model to either confirm or deny that it's working for them. I don't know if they're really the same radio or not, but it would be a very common case for the + model to have a larger memory and then running this against an original model causes the radio to participate until CHIRP tries to read past the end of its memory, after which it refuses...
Updated by Robert Toth over 1 year ago
Yes, it was proceeding. The progress bar got half way through.
Here is a screenshot. The progress bar stops at different stages.
Updated by Ran Katz over 1 year ago
- File tg_uv2p.py tg_uv2p.py added
Hi Dan,
I can confirm that your (latest) driver works for me (TG-UV2+, completes download and upload on windows 10 and macOS 13.2.1),
I apologize for not taking care of this (migration to py3 etc.) , the past few months were very busy here...
Robert, I am uploading a driver (based on Dan's latest) that will print the address it fails at,
can you try it a couple of times and see if it always fails at the same spot ?
Updated by Dan Smith over 1 year ago
Sweet, thanks Ran, I'll push this for tomorrow then.
Updated by Dan Smith over 1 year ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset github|ab77d1b71c67c0ef5de3200aa1cf760c52154bdc.
Updated by Й Я about 1 year ago
- File Безымянный.jpg Безымянный.jpg added
- File Безымянный-2.jpg Безымянный-2.jpg added
- File chirp_debug-347u6970.txt chirp_debug-347u6970.txt added
Hi Dan,
Updated by Ran Katz about 1 year ago
Hi,
- this is a closed issue, can you please open a new one
- the only way I could reproduce this (and only the "Radio did not ack..." one) is by disconnecting the serial cable from the radio, the first issue could be caused by a bad connection as well, could this be the case