[chirp_devel] [ft-90] radio will not go into clone rx mode without port open #1187

[Jens J.]

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 at yahoo.com>
To: "chirp_devel at intrepid.danplanet.com" <chirp_devel at 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 at 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()


-- 
Dan Smith
www.danplanet.com
KK7DS

_______________________________________________
chirp_devel mailing list
chirp_devel at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers



_______________________________________________
chirp_devel mailing list
chirp_devel at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20140203/b4ab51ae/attachment-0001.html