[chirp_users] No response from radio, TM-V71 and DR-235, Debian
These are my first attempts at using CHIRP and I'm not having much luck. I've tried connecting to two different radios from two different computers with a total of three different CHIRP versions and three different cables. I could easily be missing some tribal knowledge known to experienced users, so hopefully someone can point me in the right direction for a solution.
CONFIGURATION #1 Computer: Gigabyte GA-MA790X-UD4P motherboard, MCS9865 serial card, running Debian 7 (Wheezy) Radio: Kenwood TM-V71, connected with Kenwood PG-5G PC Serial Programming Cable CHIRP Version: 0.1.12 (from the Debian repository) Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: The timestamp on /dev/ttyS0 updates when the radio is turned on.
CONFIGURATION #2 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Kenwood TM-V71, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested with and without the “console=serial0,115200” setting in the /boot/cmdline.txt file Additional Info: Serial speed on radio tested at both 9600 and 19200
CONFIGURATION #3 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Alinco DR-235 MkIII, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested without the “console=serial0,115200” setting in the /boot/cmdline.txt file
CONSOLE WINDOW OUTPUT captured for Configuration #2 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:911): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 1430, in mh self.do_download(*args) File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 691, in do_download radio = settings.radio_class(ser) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 159, in __init__ radio_id = get_id(self.pipe) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 121, in get_id raise errors.RadioError("No response from radio") chirp.errors.RadioError: No response from radio
root@compass:/usr/local/bin/chirp-daily-20160717#
CONSOLE WINDOW OUTPUT captured for Configuration #3 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:980): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/clone.py", line 249, in run self.__radio.sync_in() File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 196, in sync_in self._mmap = self._download(self._memsize) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 116, in _download_chunk raise errors.RadioError("No response from radio") RadioError: No response from radio
ERROR: ---------------- ERROR: Clone failed: No response from radio ERROR: --- Exception Dialog: No response from radio --- ERROR: None
ERROR: ----------------------------
root@compass:/usr/local/bin/chirp-daily-20160717#
Since I also just started using Chirp I'm no expert, but I had a similar first-time experience (Ubuntu 16.04 and Baofeng BF-F8HP). It turned out that all that I had to do was turn up the audio volume on the radio and everything started to work fine.
Great program!
73, /Jack de K3FIV
On 07/22/2016 08:30 PM, CN85rq wrote:
These are my first attempts at using CHIRP and I'm not having much luck. I've tried connecting to two different radios from two different computers with a total of three different CHIRP versions and three different cables. I could easily be missing some tribal knowledge known to experienced users, so hopefully someone can point me in the right direction for a solution.
CONFIGURATION #1 Computer: Gigabyte GA-MA790X-UD4P motherboard, MCS9865 serial card, running Debian 7 (Wheezy) Radio: Kenwood TM-V71, connected with Kenwood PG-5G PC Serial Programming Cable CHIRP Version: 0.1.12 (from the Debian repository) Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: The timestamp on /dev/ttyS0 updates when the radio is turned on.
CONFIGURATION #2 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Kenwood TM-V71, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested with and without the “console=serial0,115200” setting in the /boot/cmdline.txt file Additional Info: Serial speed on radio tested at both 9600 and 19200
CONFIGURATION #3 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Alinco DR-235 MkIII, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested without the “console=serial0,115200” setting in the /boot/cmdline.txt file
CONSOLE WINDOW OUTPUT captured for Configuration #2 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:911): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 1430, in mh self.do_download(*args) File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 691, in do_download radio = settings.radio_class(ser) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 159, in __init__ radio_id = get_id(self.pipe) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 121, in get_id raise errors.RadioError("No response from radio") chirp.errors.RadioError: No response from radio
root@compass:/usr/local/bin/chirp-daily-20160717#
CONSOLE WINDOW OUTPUT captured for Configuration #3 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:980): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/clone.py", line 249, in run self.__radio.sync_in() File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 196, in sync_in self._mmap = self._download(self._memsize) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 116, in _download_chunk raise errors.RadioError("No response from radio") RadioError: No response from radio
ERROR: ---------------- ERROR: Clone failed: No response from radio ERROR: --- Exception Dialog: No response from radio --- ERROR: None
ERROR: ----------------------------
root@compass:/usr/local/bin/chirp-daily-20160717# _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Jack at k3fiv@arrl.net To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
Hello, In my recent experience programming an Yaesu FT60R, two issues popped up: 1) finding the correct driver for the cable chipset, and 2) holding the PTT button long enough. The chipset driver information was here: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41
About half way down the page, in red is a link to an app that identified the Prolific the chipset. Other chipset manufacturers may have similar tools. "Run PL2303 CheckChipVersion tool..." This helped tremendously in identifying the correct driver. Holding the PTT button long enough came from page 65 of the FT-60R manual, in the section on Cloning. After resolving these two issues, I was able to download memory contents to CHiRP, edit, and upload back to the HT.
Hope this helps. 73, Ken KI7EIH
Ken Cone kencone@gmail.com KI7EIH
On Sun, Jul 24, 2016 at 10:30 AM, Jack Haverty k3fiv@arrl.net wrote:
Since I also just started using Chirp I'm no expert, but I had a similar first-time experience (Ubuntu 16.04 and Baofeng BF-F8HP). It turned out that all that I had to do was turn up the audio volume on the radio and everything started to work fine.
Great program!
73, /Jack de K3FIV
On 07/22/2016 08:30 PM, CN85rq wrote:
These are my first attempts at using CHIRP and I'm not having much luck. I've tried connecting to two different radios from two different computers with a total of three different CHIRP versions and three different cables. I could easily be missing some tribal knowledge known to experienced users, so hopefully someone can point me in the right direction for a solution.
CONFIGURATION #1 Computer: Gigabyte GA-MA790X-UD4P motherboard, MCS9865 serial card, running Debian 7 (Wheezy) Radio: Kenwood TM-V71, connected with Kenwood PG-5G PC Serial Programming Cable CHIRP Version: 0.1.12 (from the Debian repository) Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: The timestamp on /dev/ttyS0 updates when the radio is turned on.
CONFIGURATION #2 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Kenwood TM-V71, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested with and without the “console=serial0,115200” setting in the /boot/cmdline.txt file Additional Info: Serial speed on radio tested at both 9600 and 19200
CONFIGURATION #3 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Alinco DR-235 MkIII, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested without the “console=serial0,115200” setting in the /boot/cmdline.txt file
CONSOLE WINDOW OUTPUT captured for Configuration #2 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:911): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 1430, in mh self.do_download(*args) File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 691, in do_download radio = settings.radio_class(ser) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 159, in __init__ radio_id = get_id(self.pipe) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 121, in get_id raise errors.RadioError("No response from radio") chirp.errors.RadioError: No response from radio
root@compass:/usr/local/bin/chirp-daily-20160717#
CONSOLE WINDOW OUTPUT captured for Configuration #3 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:980): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/clone.py", line 249, in run self.__radio.sync_in() File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 196, in sync_in self._mmap = self._download(self._memsize) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 116, in _download_chunk raise errors.RadioError("No response from radio") RadioError: No response from radio
ERROR: ---------------- ERROR: Clone failed: No response from radio ERROR: --- Exception Dialog: No response from radio --- ERROR: None
ERROR: ----------------------------
root@compass:/usr/local/bin/chirp-daily-20160717# _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Jack at k3fiv@arrl.net To unsubscribe, send an email to
chirp_users-unsubscribe@intrepid.danplanet.com
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Ken at kencone@gmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
Ken: Thanks for your suggestions. Since both radios are mobiles with serial ports, the PTT isn't an issue. I was testing with both USB-to-serial cables (with chips) and serial-to-serial cables (no chips). The CheckChipVersion appears to be Windoze-only (an OS I haven't had in over a decade), and I don't see an equivalent linux tool.
Tom: I appreciate you pointing me in the right direction on breaking the problem in half, and the "ID" command for the TM-V71. I moved over to testing with a 3rd computer, one known to connect with my Kantronics 9612. Using the serial port monitor in Outpost PM and the linux minicom utility I was able to isolate issues, solve part of the problem, and better characterize the remaining difficulties.
All: The dual-port MCS9865-based serial card on the Gigabyte GA-MA790X-UD4P motherboard uses /dev/ttyS1 and /dev/ttyS2. The USB-to-serial cable uses /dev/USB0 on both the Gigabyte motherboard and the Raspberry Pi. Both USB-to-serial cables (FTDI and unknown) and the Kenwood PG-5G PC Serial Programming Cable all work. Note to self: In order to make problem isolation easier, clearly mark the three special APC 940-0024C cables so they don't get mixed in with the other serial cables.
So, chirp works with the Kenwood TM-V71 using both a straight serial cable and the both USB-to-serial cables. Neither chirp, minicom, nor the serial port monitor in Outpost PM will communicate with the Alinco DR-235 MkIII. In fact, when I put the mini-tester in line on the serial cable, there is no signal (neither a green nor a red LED lit) on the Receive Data line. This is true for all three computers using both cable types.
Is a special cable needed for the Alinco DR-235 to work with chirp?
Tom Hayward wrote on 07/24/2016 11:19 AM:
You might try removing Chirp from the equation and test just the serial port on the TM-V71. First, note the rate set in menu 519, PC.SPD. Then launch a terminal emulator at this rate. Type ID and hit enter. You should get the model number of the radio printed to your console. If not, you've got a problem with your computer/USB serial port, cable, or the radio's serial port.
If you do get a response, move on to Chirp. Use only the latest daily build, available on the PPA or here: http://trac.chirp.danplanet.com/chirp_daily/LATEST/
Tom KD7LXL
Ken Cone wrote on 07/24/2016 10:58 AM:
Hello, In my recent experience programming an Yaesu FT60R, two issues popped up:
- finding the correct driver for the cable chipset, and 2) holding the PTT
button long enough. The chipset driver information was here: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41
About half way down the page, in red is a link to an app that identified the Prolific the chipset. Other chipset manufacturers may have similar tools. "Run PL2303 CheckChipVersion tool..." This helped tremendously in identifying the correct driver. Holding the PTT button long enough came from page 65 of the FT-60R manual, in the section on Cloning. After resolving these two issues, I was able to download memory contents to CHiRP, edit, and upload back to the HT.
Hope this helps. 73, Ken KI7EIH
Ken Cone kencone@gmail.com KI7EIH
At the risk of offending our highly technical brethren, I'd like to compliment CHIRP for producing an excellent "plug - n-play" version for Mac.
Honestly, aside from having to maintain separate files for each Baofeng firmware set, my experience in up/down-loading from Baofeng to Mac, via CHIRP, has truly been just that easy.
Good thing too... The frustrations and technical details that you discuss in this thread are beyond me. Good luck with that...
I will offer that *cable quality* has popped up in various threads as a likely culprit in the case of up/down-load fails
Keith On Jul 24, 2016 23:56, "CN85rq" chirp-info@aberle.net wrote:
Ken: Thanks for your suggestions. Since both radios are mobiles with serial ports, the PTT isn't an issue. I was testing with both USB-to-serial cables (with chips) and serial-to-serial cables (no chips). The CheckChipVersion appears to be Windoze-only (an OS I haven't had in over a decade), and I don't see an equivalent linux tool.
Tom: I appreciate you pointing me in the right direction on breaking the problem in half, and the "ID" command for the TM-V71. I moved over to testing with a 3rd computer, one known to connect with my Kantronics 9612. Using the serial port monitor in Outpost PM and the linux minicom utility I was able to isolate issues, solve part of the problem, and better characterize the remaining difficulties.
All: The dual-port MCS9865-based serial card on the Gigabyte GA-MA790X-UD4P motherboard uses /dev/ttyS1 and /dev/ttyS2. The USB-to-serial cable uses /dev/USB0 on both the Gigabyte motherboard and the Raspberry Pi. Both USB-to-serial cables (FTDI and unknown) and the Kenwood PG-5G PC Serial Programming Cable all work. Note to self: In order to make problem isolation easier, clearly mark the three special APC 940-0024C cables so they don't get mixed in with the other serial cables.
So, chirp works with the Kenwood TM-V71 using both a straight serial cable and the both USB-to-serial cables. Neither chirp, minicom, nor the serial port monitor in Outpost PM will communicate with the Alinco DR-235 MkIII. In fact, when I put the mini-tester in line on the serial cable, there is no signal (neither a green nor a red LED lit) on the Receive Data line. This is true for all three computers using both cable types.
Is a special cable needed for the Alinco DR-235 to work with chirp?
Tom Hayward wrote on 07/24/2016 11:19 AM:
You might try removing Chirp from the equation and test just the serial port on the TM-V71. First, note the rate set in menu 519, PC.SPD. Then launch a terminal emulator at this rate. Type ID and hit enter. You should get the model number of the radio printed to your console. If not, you've got a problem with your computer/USB serial port, cable, or the radio's serial port.
If you do get a response, move on to Chirp. Use only the latest daily build, available on the PPA or here: http://trac.chirp.danplanet.com/chirp_daily/LATEST/
Tom KD7LXL
Ken Cone wrote on 07/24/2016 10:58 AM:
Hello, In my recent experience programming an Yaesu FT60R, two issues popped up:
- finding the correct driver for the cable chipset, and 2) holding the
PTT
button long enough. The chipset driver information was here: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225&pcid=41
About half way down the page, in red is a link to an app that identified the Prolific the chipset. Other chipset manufacturers may have similar tools. "Run PL2303 CheckChipVersion tool..." This helped tremendously in identifying the correct driver. Holding the PTT button long enough came from page 65 of the FT-60R
manual,
in the section on Cloning. After resolving these two issues, I was able
to
download memory contents to CHiRP, edit, and upload back to the HT.
Hope this helps. 73, Ken KI7EIH
Ken Cone kencone@gmail.com KI7EIH
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Keith Murlless at kmurlless@gmail.com To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
On Fri, Jul 22, 2016 at 8:30 PM, CN85rq chirp-info@aberle.net wrote:
These are my first attempts at using CHIRP and I'm not having much luck. I've tried connecting to two different radios from two different computers with a total of three different CHIRP versions and three different cables. I could easily be missing some tribal knowledge known to experienced users, so hopefully someone can point me in the right direction for a solution.
CONFIGURATION #1 Computer: Gigabyte GA-MA790X-UD4P motherboard, MCS9865 serial card, running Debian 7 (Wheezy) Radio: Kenwood TM-V71, connected with Kenwood PG-5G PC Serial Programming Cable CHIRP Version: 0.1.12 (from the Debian repository) Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: The timestamp on /dev/ttyS0 updates when the radio is turned on.
CONFIGURATION #2 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Kenwood TM-V71, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested with and without the “console=serial0,115200” setting in the /boot/cmdline.txt file Additional Info: Serial speed on radio tested at both 9600 and 19200
CONFIGURATION #3 Computer: Raspberry Pi 1 Model B, running Raspian (Jesse) with Compass mods by NW Digital Radio Radio: Alinco DR-235 MkIII, connected (first) with a generic USB-Serial cable (unknown chipset) and (second) with a Sabrent CB-FTDI USB-Serial cable (FTDI chipset) CHIRP Versions: (first) 0.4.0 and (second) chirp-daily-20160717 Symptom: “Download From Radio” results in a “No response from radio” message Additional Info: Tested without the “console=serial0,115200” setting in the /boot/cmdline.txt file
CONSOLE WINDOW OUTPUT captured for Configuration #2 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:911): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up ERROR: Timeout waiting for data ERROR: Giving up Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 1430, in mh self.do_download(*args) File "/usr/local/bin/chirp-daily-20160717/chirp/ui/mainapp.py", line 691, in do_download radio = settings.radio_class(ser) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 159, in __init__ radio_id = get_id(self.pipe) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/kenwood_live.py", line 121, in get_id raise errors.RadioError("No response from radio") chirp.errors.RadioError: No response from radio
root@compass:/usr/local/bin/chirp-daily-20160717#
CONSOLE WINDOW OUTPUT captured for Configuration #3 root@compass:/usr/local/bin/chirp-daily-20160717# ./chirpw
(process:980): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ./chirpw:135: GtkWarning: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed a.show() ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/usr/local/bin/chirp-daily-20160717/chirp/ui/clone.py", line 249, in run self.__radio.sync_in() File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 196, in sync_in self._mmap = self._download(self._memsize) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/usr/local/bin/chirp-daily-20160717/chirp/drivers/alinco.py", line 116, in _download_chunk raise errors.RadioError("No response from radio") RadioError: No response from radio
ERROR: ---------------- ERROR: Clone failed: No response from radio ERROR: --- Exception Dialog: No response from radio --- ERROR: None
ERROR: ----------------------------
root@compass:/usr/local/bin/chirp-daily-20160717#
You might try removing Chirp from the equation and test just the serial port on the TM-V71. First, note the rate set in menu 519, PC.SPD. Then launch a terminal emulator at this rate. Type ID and hit enter. You should get the model number of the radio printed to your console. If not, you've got a problem with your computer/USB serial port, cable, or the radio's serial port.
If you do get a response, move on to Chirp. Use only the latest daily build, available on the PPA or here: http://trac.chirp.danplanet.com/chirp_daily/LATEST/
Tom KD7LXL
participants (5)
-
CN85rq -
Jack Haverty -
Keith Murlless -
Ken Cone -
Tom Hayward