[chirp_users] OSX and the TH-D72 with CHIRP
Greetings,
I've had an interesting ride with CHIRP so far! I'm glad it's being worked on..
My question is two fold..
1. Has there been a patch for the TH-D72 2. Does this patch include support for the serial device (cu.SLAB_USBtoUART) that is presented to the OS when the TH-D72 is plugged in?
I'd love to not have to use the Kenwood application on Windows if at ALL possible!
73 de K6EF
- Has there been a patch for the TH-D72
Yep.
- Does this patch include support for the serial device (cu.SLAB_USBtoUART) that is presented to the OS when the TH-D72 is plugged in?
Should, yeah. Just type in the path ("/dev/...") into the serial port box when you go to download from the radio.
On Apr 21, 2011, at 6:41 AM, Dan Smith dsmith@danplanet.com wrote:
- Has there been a patch for the TH-D72
Yep.
Where is this patch, the stock download fails to detect the radio.
- Does this patch include support for the serial device (cu.SLAB_USBtoUART) that is presented to the OS when the TH-D72 is plugged in?
Should, yeah. Just type in the path ("/dev/...") into the serial port box when you go to download from the radio.
This doesn't work. With the current stock download you get an out of bands error unless you modify the py file and change the /dev/cu.usbserial* entry to /dev/cu.* which then picks up the devices.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Hi Dan,
In help/about I see "CHIRP 0.1.11" GTK 2.16.6 PyGTK 2.14.1
When I click "Download from radio" I see the following :
Traceback (most recent call last): File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/mainapp.py", line 552, in mh self.do_download(*args) File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/mainapp.py", line 283, in do_download d = clone.CloneSettingsDialog(parent=self) File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/clone.py", line 140, in __init__ self.__make_ui(settings) File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/clone.py", line 115, in __make_ui self.__port = self.__make_port(settings and settings.port or None) File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/clone.py", line 61, in __make_port port = ports[0] IndexError: list index out of range
I see no pop-up for the radio/version/port etc..
In chirp/platform.py there is the following block :
def list_serial_ports(self): return sorted(glob.glob("/dev/ttyS*") + glob.glob("/dev/ttyUSB*") + glob.glob("/dev/cu.usbser*") + glob.glob("/dev/term/*") + glob.glob("/dev/tty.KeySerial*"))
On my system with device presented by the radio when plugged in it uses /dev/cu.SLAB_USBtoUART (Only when plugged in)
When I changed it to this : def list_serial_ports(self): return sorted(glob.glob("/dev/ttyS*") + glob.glob("/dev/ttyUSB*") + glob.glob("/dev/cu.usbser*") + glob.glob("/dev/term/*") + glob.glob("/dev/cu.SLAB_USBtoUART") + glob.glob("/dev/tty.KeySerial*"))
I see the Radio window pop up with the serial port listed, vendor and model. I select the radio and model and see the following :
PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: --- Exception Dialog: Unable to probe radio model --- Traceback (most recent call last): File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/clone.py", line 160, in run cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port) File "/Users/mark/CHIRP/chirp-0.1.11/chirp/detect.py", line 101, in detect_kenwoodlive_radio raise errors.RadioError("Unable to probe radio model") RadioError: Unable to probe radio model
It never iterates through the possible kenwood radios.
I then noticed in the detect.py that r_id = kenwood_live.get_id(s) is commented out and the tmv71_ll.get_id(s) is not as below.
def detect_kenwoodlive_radio(port): s = serial.Serial(port=port, baudrate=9600, timeout=0.5) r_id = None
for rate in [9600, 19200, 38400, 57600]: s.setBaudrate(rate) s.write("\r") s.read(25) try: #r_id = kenwood_live.get_id(s) r_id = tmv71_ll.get_id(s) break except errors.RadioError: pass s.close()
When I tried to reverse the comments, the radio detection stops after the first iteration.
So, here is where I'm stuck! :)
Mark (K6EF)
On Apr 21, 2011, at 8:16 AM, Dan Smith wrote:
Where is this patch, the stock download fails to detect the radio.
It's in 0.1.11. Does Help->About still show 0.1.10?
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Mark Cohen markc@binaryfaith.com
Science is a way of skeptically interrogating the universe with a fine understanding of human fallibility. -Carl Sagan, 1996
IndexError: list index out of range
Oops, okay, that needs to be fixed.
It never iterates through the possible kenwood radios.
Yeah, it shouldn't. They all identify themselves the same way, so it only needs to happen once.
When I tried to reverse the comments, the radio detection stops after the first iteration.
So, here is where I'm stuck! :)
Okay, fair enough. I don't have a D72 to test with, unfortunately.
Vernon, when you get a chance, could you maybe take a look and see if I broke D72 support in 0.1.11?
Mark, since you seem fairly technical, you might edit the shell script and change it to fetch a different CHIRP version, starting with the most recent and working backwards:
http://chirp.danplanet.com/download/beta/
Make sure that Help->about shows the right version each time. To avoid making the tweak to the serial port enumeration each time, you might make yourself a symlink:
# ln -s /dev/cu.SLAB_USBtoUART /dev/cu.usbserial1
Thanks!
Hi Dan,
Here's what I did...
1. added the symlink 2. downloaded all of the *b* tar.gz files here are the results from my tests.
b1 - Freezes at the first detected device (PC->D7: ID) b2 - Iterates through, but seems to not get beyond the first try
PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC:
Message "Unale to probe radio model"
b3 - same as b2 b4 - same as b2, b3 except it appears that the typo was fixed. :) b5 - same as b4 (added radio vendors show up) b6 - same as b5 b7 - same as b6, b5
So, there you have it...
Mark
On Apr 21, 2011, at 8:50 AM, Dan Smith wrote:
IndexError: list index out of range
Oops, okay, that needs to be fixed.
It never iterates through the possible kenwood radios.
Yeah, it shouldn't. They all identify themselves the same way, so it only needs to happen once.
When I tried to reverse the comments, the radio detection stops after the first iteration.
So, here is where I'm stuck! :)
Okay, fair enough. I don't have a D72 to test with, unfortunately.
Vernon, when you get a chance, could you maybe take a look and see if I broke D72 support in 0.1.11?
Mark, since you seem fairly technical, you might edit the shell script and change it to fetch a different CHIRP version, starting with the most recent and working backwards:
http://chirp.danplanet.com/download/beta/
Make sure that Help->about shows the right version each time. To avoid making the tweak to the serial port enumeration each time, you might make yourself a symlink:
# ln -s /dev/cu.SLAB_USBtoUART /dev/cu.usbserial1
Thanks!
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Mark Cohen markc@binaryfaith.com
Science is a way of skeptically interrogating the universe with a fine understanding of human fallibility. -Carl Sagan, 1996
So, there you have it...
Hmm, I suspect something else must be going on, because there have definitely been successful D72 users along that path.
Could you open a terminal to your D72's serial port and see if you can talk to it? If you send "ID" followed by a carriage return, it should reply with something like "TH-D72".
Hi Dan,
So, I have a completely fresh machine here (not running any fink/darwinports packages etc) and did the following..
1. Downloaded the pkg file with python2.5/gtk/pySerial, installed 2. Ran the shell script 3. Result -- Still can't connect and probe the radio.
I then connected to the radio (9600 8N1 Hardware Handshake enabled) Typed ID<cr>
Here is the ouput.
A 110421174857 cmd:MY K6EF-7 MYCALL was NOCALL ID TH-D72
As you can see, ID TH-D72 is returned.
So, I don't think this is anything with my setup AFAIK
Here is the output from the terminal during the probe :
PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: --- Exception Dialog: Unable to probe radio model --- Traceback (most recent call last): File "/Users/mark/CHIRP/chirp-0.1.11/chirpui/clone.py", line 160, in run cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port) File "/Users/mark/CHIRP/chirp-0.1.11/chirp/detect.py", line 101, in detect_kenwoodlive_radio raise errors.RadioError("Unable to probe radio model") RadioError: Unable to probe radio model
Hope this helps,
73 de K6EF
On Apr 21, 2011, at 9:42 AM, Dan Smith wrote:
So, there you have it...
Hmm, I suspect something else must be going on, because there have definitely been successful D72 users along that path.
Could you open a terminal to your D72's serial port and see if you can talk to it? If you send "ID" followed by a carriage return, it should reply with something like "TH-D72".
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
A 110421174857 cmd:MY K6EF-7 MYCALL was NOCALL ID TH-D72
As you can see, ID TH-D72 is returned.
Yeah, but I think the problem here is that you're talking to the TNC interface. I think that you either need to turn off the TNC in the radio first, or use a different port. On the TM-D710, there are different ports for TNC and programming.
Vernon (or someone who has used the D72) would know better than I.
Hi Dan,
The TNC is off actually..
With the TNC on this is what I see
bbRAM loaded with defaults
Kenwood Radio Modem AX.25 Level 2 Version 2.0 Release 16/Nov/2010 2Chip Version 1.00 Checksum $7772 cmd:DA 110421181102 cmd:MY K6EF-7 MYCALL was NOCALL cmd:
If I type ID<cr> with the TNC on, it just returns the cmd: prompt.
Mark
On Apr 21, 2011, at 11:07 AM, Dan Smith wrote:
A 110421174857 cmd:MY K6EF-7 MYCALL was NOCALL ID TH-D72
As you can see, ID TH-D72 is returned.
Yeah, but I think the problem here is that you're talking to the TNC interface. I think that you either need to turn off the TNC in the radio first, or use a different port. On the TM-D710, there are different ports for TNC and programming.
Vernon (or someone who has used the D72) would know better than I.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Hi Dan,
So, having the resources that I do... I brought up a linux VM on my host here (CentOS 5.5) and did the following..
I downloaded CHIRP-0.1.11 (GTK 2.10.4, PyGTK 2.10.1)
I was able to connect to the radio and download the contents. (So I have to assume there is a problem with pyserial in the package I downloaded... )
Here is the bad news, the linux version doesn't show any of the memory locations I downloaded, they are all 0.0000 and grayed out. When I save the file, I can run strings on it and see that the data is indeed there..
Hope this helps!
Mark (K6EF)
On Apr 21, 2011, at 11:12 AM, Mark Cohen wrote:
Hi Dan,
The TNC is off actually..
With the TNC on this is what I see
bbRAM loaded with defaults
Kenwood Radio Modem AX.25 Level 2 Version 2.0 Release 16/Nov/2010 2Chip Version 1.00 Checksum $7772 cmd:DA 110421181102 cmd:MY K6EF-7 MYCALL was NOCALL cmd:
If I type ID<cr> with the TNC on, it just returns the cmd: prompt.
Mark
On Apr 21, 2011, at 11:07 AM, Dan Smith wrote:
A 110421174857 cmd:MY K6EF-7 MYCALL was NOCALL ID TH-D72
As you can see, ID TH-D72 is returned.
Yeah, but I think the problem here is that you're talking to the TNC interface. I think that you either need to turn off the TNC in the radio first, or use a different port. On the TM-D710, there are different ports for TNC and programming.
Vernon (or someone who has used the D72) would know better than I.
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
I was able to connect to the radio and download the contents. (So I have to assume there is a problem with pyserial in the package I downloaded... )
Hmm, I dunno about that. I think it's more likely that the USB serial driver that's handling whatever chip is in the radio isn't quite right on MacOS. The python-serial library just handles opening the device, attaching a file handle to it, and setting the baud rate.
Here is the bad news, the linux version doesn't show any of the memory locations I downloaded, they are all 0.0000 and grayed out. When I save the file, I can run strings on it and see that the data is indeed there..
Well, not having anything to test with, I really have to plead ignorance and hope that Vernon can offer some insight :)
Hi Dan,
Had some more time to play with CHIRP tonight..
It gets stranger!
I just installed Ubuntu 11.04 beta2 and ran chirp w/o issue! (I was able to get the memories off of my TH-D72)
The only thing I can think of is that Python, GTK and PyGTK are different on this system
I'm running Python 2.7.1+ with GTK 2.24.4 and PyGTK 2.22.0
Anyway, I'm totally at a loss as to why both OSX and Centos 5.5 have problems but Ubuntu doesn't.
Mark (K6EF)
On Apr 21, 2011, at 11:28 AM, Dan Smith wrote:
I was able to connect to the radio and download the contents. (So I have to assume there is a problem with pyserial in the package I downloaded... )
Hmm, I dunno about that. I think it's more likely that the USB serial driver that's handling whatever chip is in the radio isn't quite right on MacOS. The python-serial library just handles opening the device, attaching a file handle to it, and setting the baud rate.
Here is the bad news, the linux version doesn't show any of the memory locations I downloaded, they are all 0.0000 and grayed out. When I save the file, I can run strings on it and see that the data is indeed there..
Well, not having anything to test with, I really have to plead ignorance and hope that Vernon can offer some insight :)
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
The only thing I can think of is that Python, GTK and PyGTK are different on this system
Ah. I hadn't thought of it until just now, but I bet that that's it (or at least, related). CentOS5 has a very old version of python, which often causes issues if I'm not real careful. The stack trace you pasted before doesn't show anything indicating such a thing, but most of the detect functions are run with a blanket exception handler I think, which might hide that.
Good call, I'll have to take a look through it and see what I can come up with.
Thanks!
On Fri, Apr 22, 2011 at 6:29 AM, Dan Smith dsmith@danplanet.com wrote:
The only thing I can think of is that Python, GTK and PyGTK are different on this system
Just wanted to chime in here and say that the 0.1.11 release works fine for me in Ubuntu 10.10. I can't really think of anything that chirp does that would be system specific with the serial port that would prevent it from working on OSX. It opens it, sets the baud rate, writes a few bytes, reads a few bytes, changes the baud rate, checks CTS, sets RTS, does some more reads and writes and closes the port.
Ah. I hadn't thought of it until just now, but I bet that that's it (or at least, related). CentOS5 has a very old version of python, which often causes issues if I'm not real careful. The stack trace you pasted before doesn't show anything indicating such a thing, but most of the detect functions are run with a blanket exception handler I think, which might hide that.
CentOS5 also has a fairly old kernel, which would have older drivers, so that could be another difference.
Good call, I'll have to take a look through it and see what I can come up with.
An interesting patch might be one that changes all the blanket exception handlers into raise statements if 'debug mode' is turned on.
def print_backtrace(): a,b,c = sys.exc_info() ...
try: do some stuff except: if debug: print_backtrace()
That way you could normally quiet all the annoying stuff during a normal run, but you could gather useful information if you are looking for a bug. In some cases if you are getting too much junk, the blanket except handlers might be better turned into a series of excepts to allow a certain type of exception to pass, while catching others.
--Vernon
Thanks!
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
An interesting patch might be one that changes all the blanket exception handlers into raise statements if 'debug mode' is turned on.
Yeah. I have log_exception() now, but maybe I need another one that checks an environment variable or something and then sweep through the code and make sure at least one of each is in every handler.
Mark, since you're running from source maybe I'll cook you up a patch to do that and let you apply/run it to see if we can figure out why it's not happy on OSX (and EL5).
participants (4)
-
Dan Smith -
Mark Cohen -
Mark Cohen -
Vernon Mauery