CHIRP

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:

1. Open chirp
2. Load the module
3. Attempt the download
4. 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.

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?

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

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>

These are the messages I am getting:
File does not exist: >debug.log
File does not exist: 2>&1
Unknown file format

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

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.

Yes that debug log looks better, thanks. Please use that method to capture a debug log with the above new module.

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...

I'll try the CHIRP-legacy this weekend.

Sweet, thanks Ran, I'll push this for tomorrow then.

Hi,

1. this is a closed issue, can you please open a new one
2. 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