CHIRP

This is apparently a radio having the new PCB which has a new identification string that is unknown to CHIRP. The debug log is needed to determine what the identification string is.

Jim Unroe wrote in #note-1:

This is apparently a radio having the new PCB which has a new identification string that is unknown to CHIRP. The debug log is needed to determine what the identification string is.

Indeed. However, Chirp does not dump a debug.log file... Searched the whole file system, nothing.

This is what's printed in the console:

ERROR: Failed to clone: Radio returned unknown identification string
Traceback (most recent call last):
File "/home/user/.local/lib/python3.8/site-packages/chirp/wxui/clone.py", line 69, in run
self._fn()
File "/home/user/.local/lib/python3.8/site-packages/chirp/drivers/mml_jc8810.py", line 479, in sync_in
data = do_download(self)
File "/home/user/.local/lib/python3.8/site-packages/chirp/drivers/mml_jc8810.py", line 350, in do_download
_enter_programming_mode(radio)
File "/home/user/.local/lib/python3.8/site-packages/chirp/drivers/mml_jc8810.py", line 291, in _enter_programming_mode
raise errors.RadioError("Radio returned unknown identification string")
chirp.errors.RadioError: Radio returned unknown identification string

F Let wrote in #note-2:

Jim Unroe wrote in #note-1:

This is apparently a radio having the new PCB which has a new identification string that is unknown to CHIRP. The debug log is needed to determine what the identification string is.

Indeed. However, Chirp does not dump a debug.log file... Searched the whole file system, nothing.

This is what's printed in the console:

ERROR: Failed to clone: Radio returned unknown identification string
Traceback (most recent call last):
File "/home/user/.local/lib/python3.8/site-packages/chirp/wxui/clone.py", line 69, in run
self._fn()
File "/home/user/.local/lib/python3.8/site-packages/chirp/drivers/mml_jc8810.py", line 479, in sync_in
data = do_download(self)
File "/home/user/.local/lib/python3.8/site-packages/chirp/drivers/mml_jc8810.py", line 350, in do_download
_enter_programming_mode(radio)
File "/home/user/.local/lib/python3.8/site-packages/chirp/drivers/mml_jc8810.py", line 291, in _enter_programming_mode
raise errors.RadioError("Radio returned unknown identification string")
chirp.errors.RadioError: Radio returned unknown identification string

Printed the 'ident' variable in mml_jc8810.py ==> value is b'\x00\x00\x00(\x00 \xd4\x04'

F Let wrote in #note-2:

Jim Unroe wrote in #note-1:

This is apparently a radio having the new PCB which has a new identification string that is unknown to CHIRP. The debug log is needed to determine what the identification string is.

Indeed. However, Chirp does not dump a debug.log file... Searched the whole file system, nothing.

What happens when you click Help -> Open debug log ?

Jim Unroe wrote in #note-4:

What happens when you click Help -> Open debug log ?

There's no such menu entry.

Tried with the latest Windows version of Chirp-next (Chirp-next-231209 on Python 3.10.08.
This is what's dumped in the "open debug log" window:

[2023-12-13 11:03:20,942] chirp.logger - DEBUG: CHIRP next-20231209 on Win32 (Unknown 10.0:19044) (Python 3.10.8)
[2023-12-13 11:03:20,996] chirp.wxui - DEBUG: Using locale: fr_FR (318)
[2023-12-13 11:03:20,996] chirp.wxui - DEBUG: Translation loaded=True for CHIRP: fr_FR (de,el,en_US,es,fr,hu,it,ja_JP,nl,pl,pt_BR,ru,tr_TR,uk_UA,zh_CN) from C:\Program Files (x86)\CHIRP\chirp\locale
[2023-12-13 11:03:20,996] chirp.wxui - DEBUG: Translation loaded=True for wxstd: fr_FR (af,an,ar,ca,ca@valencia,co,cs,da,de,el,es,eu,fa_IR,fi,fr,gl_ES,hi,hr,hu,id,it,ja,ka,ko_KR,lt,lv,ms,nb,ne,nl,pl,pt,pt_BR,ro,ru,sk,sl,sq,sv,ta,tr,uk,vi,zh_CN,zh_TW)
[2023-12-13 11:03:21,227] main - INFO: Python/3.10.8 // Windows/Windows-10-10.0.19044-SP0 // CHIRP/next-20231209 // wx/4.2.0 msw (phoenix) wxWidgets 3.2.0
[2023-12-13 11:03:21,597] chirp.wxui.main - INFO: Server reports next-20231209 is latest
[2023-12-13 11:03:26,783] chirp.wxui.clone - DEBUG: Using port 'COM13'
[2023-12-13 11:03:26,783] chirp.wxui.clone - DEBUG: Selected
[2023-12-13 11:03:26,783] chirp.wxui.clone - DEBUG: Serial opened: Serial(port='COM13', baudrate=57600, bytesize=8, parity='N', stopbits=1, timeout=0.25, xonxoff=False, rtscts=False, dsrdtr=False) (rts=True dtr=True)
[2023-12-13 11:03:26,783] chirp.drivers.mml_jc8810 - DEBUG: download
[2023-12-13 11:03:26,852] chirp.drivers.mml_jc8810 - DEBUG: 000: 00 00 00 2c 00 20 d8 04 ...,....

[2023-12-13 11:03:26,852] chirp.wxui.clone - ERROR: Failed to clone: Radio returned unknown identification string
Traceback (most recent call last):
File "chirp\wxui\clone.py", line 69, in run
File "chirp\drivers\mml_jc8810.py", line 479, in sync_in
File "chirp\drivers\mml_jc8810.py", line 350, in do_download
File "chirp\drivers\mml_jc8810.py", line 291, in _enter_programming_mode
chirp.errors.RadioError: Radio returned unknown identification string
[2023-12-13 11:03:29,721] chirp.wxui.clone - WARNING: Stopping clone thread

I performed a few tests, and for what I saw it works!

Mark Wiseley wrote in #note-12:

Hey all, new to this forum, but I picked up a new 470x the other day and all was good, then updated it from 2.11 to the new 2.13a. Now I'm having the same issue with Chirp as this bug reported. I have gone to the developer mode and tried this test module, but still same issue. I will attach the debug log. Thanks in advance for any help, hoping to figure out how to get rid of the squelch tail on some frequencies! :)

This new identification string will have to be added.

Jim Unroe wrote in #note-13:

Mark Wiseley wrote in #note-12:

Hey all, new to this forum, but I picked up a new 470x the other day and all was good, then updated it from 2.11 to the new 2.13a. Now I'm having the same issue with Chirp as this bug reported. I have gone to the developer mode and tried this test module, but still same issue. I will attach the debug log. Thanks in advance for any help, hoping to figure out how to get rid of the squelch tail on some frequencies! :)

This new identification string will have to be added.

In the mean time would you download the RT-470 Menu List v2.11a (00-57).txt list that is attached to this issue, make a copy and update it for the v2.13a firmware? Thanks.

Jim Unroe wrote in #note-14:

Jim Unroe wrote in #note-13:

Mark Wiseley wrote in #note-12:

Hey all, new to this forum, but I picked up a new 470x the other day and all was good, then updated it from 2.11 to the new 2.13a. Now I'm having the same issue with Chirp as this bug reported. I have gone to the developer mode and tried this test module, but still same issue. I will attach the debug log. Thanks in advance for any help, hoping to figure out how to get rid of the squelch tail on some frequencies! :)

This new identification string will have to be added.

In the mean time would you download the RT-470 Menu List v2.11a (00-57).txt list that is attached to this issue, make a copy and update it for the v2.13a firmware? Thanks.

I'm really sorry as I want to help, but I can't figure out how to update that menu list? I have searched all over trying to figure out how?

Mark Wiseley wrote in #note-15:

I'm really sorry as I want to help, but I can't figure out how to update that menu list? I have searched all over trying to figure out how?

It is a text file of the menus of the radio and their choices. You go through the radios menus one-by-one to see if any were move around to different menu numbers, any new menus were added or any previous menus were removed. Then you check to see that the choices have remained the same and update any choices when you find that they are differet.

Mark Wiseley wrote in #note-18:

Jim Unroe wrote in #note-17:

The attached test driver module should include support for the v2.13a identification string. How to use it:LoadingTestModules

Ok, I will work on that. I also tried that test module, but I get the same error. Uploaded new debug. Thanks again!

My bad. You should have opened a different ticket for the RT-470X. This one is for the RT-470 so I added it to the RT-470 instead of RT-470X.

Jim Unroe wrote in #note-19:

Mark Wiseley wrote in #note-18:

Jim Unroe wrote in #note-17:

The attached test driver module should include support for the v2.13a identification string. How to use it:LoadingTestModules

Ok, I will work on that. I also tried that test module, but I get the same error. Uploaded new debug. Thanks again!

My bad. You should have opened a different ticket for the RT-470X. This one is for the RT-470 so I added it to the RT-470 instead of RT-470X.

Shoot sorry. Would you like me to open up a new ticket?

Mark Wiseley wrote in #note-20:

Jim Unroe wrote in #note-19:

Mark Wiseley wrote in #note-18:

Jim Unroe wrote in #note-17:

The attached test driver module should include support for the v2.13a identification string. How to use it:LoadingTestModules

Ok, I will work on that. I also tried that test module, but I get the same error. Uploaded new debug. Thanks again!

My bad. You should have opened a different ticket for the RT-470X. This one is for the RT-470 so I added it to the RT-470 instead of RT-470X.

Shoot sorry. Would you like me to open up a new ticket?

On a positive note, if I choose the 470 it does let me read the radio now. Not sure how different they are so I won't write anything back to the radio until I hear from you. Thanks again and sorry for the mixup.

Mark Wiseley wrote in #note-20:

Shoot sorry. Would you like me to open up a new ticket?

That would be great if you would. Attach the same debug.log(s) and I will attach a corrected fix and a menu list for the RT-470X.

Jim Unroe wrote in #note-22:

Mark Wiseley wrote in #note-20:

Shoot sorry. Would you like me to open up a new ticket?

That would be great if you would. Attach the same debug.log(s) and I will attach a corrected fix and a menu list for the RT-470X.

Done, Bug #11027