Thanks Dan, this might be the trick. Yes, I was jumping through various hoops because the radio wants the port open. Then I was doing some close because, at least on windows, i was getting access denied when I tried to open the port a second time ;) But all of this may be a moot point.
The attached patch seems to work fine for me on linux and winxp.
Will all other radios be fine with this change? I know that some radios might have some procedures (power cycle, etc), and was slightly concerned that this might create junk chars on the serial lines. Would it be worthwhile doing a flush on the line before calling the clone procedure?
Note that I moved port open before clone instructions only on do_upload, not do_download, as: 1. I only needed it there, and 2. if there is some chance of noise, i thought it might come from the radio side (e.g., power cycle, connecting cables, etc), and shouldn't be a problem on do_upload, but might cause some junk bytes waiting for chirp on do_download... (this also might be over-paranoid conjecture ;)
-Jens
On Tuesday, October 29, 2013 6:32 PM, Dan Smith dsmith@danplanet.com wrote:
# radio likes to have port open self.pipe.open() + time.sleep(5)
Hmm, why are you closing and re-opening the serial port? Does the radio need to start within five seconds of opening the port? That would be ...uncool.
So, why wouldn't this solve the problem?
diff -r 0c72e698e212 chirpui/mainapp.py --- a/chirpui/mainapp.py Sun Oct 27 09:00:01 2013 -0700 +++ b/chirpui/mainapp.py Tue Oct 29 16:31:11 2013 -0700 @@ -612,8 +612,6 @@ # User does not want to proceed with experimental driver return
- self._show_instructions(rclass, rclass.get_prompts().pre_download) - print "User selected %s %s on port %s" % (rclass.VENDOR, rclass.MODEL, settings.port) @@ -630,6 +628,8 @@ d.destroy() return
+ self._show_instructions(rclass, rclass.get_prompts().pre_download) + radio = settings.radio_class(ser)
fn = tempfile.mktemp()