Revisiting this to get some feedback from other developers. Looks as if this change has is giving at least one other person problems: http://chirp.danplanet.com/issues/1397

As this perhaps doesnt work for everyone, I was thinking of doing this to resolve: 1. add a boolean property "open_port_before_pre_upload_message" (or similar) that defaults to false to chirp_common.RadioPrompts class. 2. override this to true on the radio(s) which require this (currently: ft-90.py) 3. in mainapp.py, only open port before showing prompts if this is true, else do old behavior (show prompts first, then open port after accepting message)

This would set this on a per-radio basis. Another thought was that this could be some environmental/local/cable issue that only affects individual users, and therefore perhaps needs to be a user-level setting (chirp.config)?

Thoughts on the most general way to approach this?

-Jens

________________________________ From: Jens J. kd4tjx@yahoo.com To: "chirp_devel@intrepid.danplanet.com" chirp_devel@intrepid.danplanet.com Sent: Wednesday, October 30, 2013 8:41 AM Subject: Re: [chirp_devel] [ft-90] radio will not go into clone rx mode without port open #1187

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()