<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/05/2019 20:00,
<a class="moz-txt-link-abbreviated" href="mailto:chirp_users-request@intrepid.danplanet.com">chirp_users-request@intrepid.danplanet.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:mailman.1.1556737205.3875.chirp_users@intrepid.danplanet.com">
<pre class="moz-quote-pre" wrap="">Date: Tue, 30 Apr 2019 22:37:25 -0500
From: Joshua Richardson <a class="moz-txt-link-rfc2396E" href="mailto:oilfieldradios@consultant.com" moz-do-not-send="true"><oilfieldradios@consultant.com></a>
Subject: [chirp_users] Chirp (Not Responding) before uploading or
downloading radio.
To: <a class="moz-txt-link-rfc2396E" href="mailto:chirp_users@intrepid.danplanet.com" moz-do-not-send="true">"chirp_users@intrepid.danplanet.com"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:chirp_users@intrepid.danplanet.com" moz-do-not-send="true"><chirp_users@intrepid.danplanet.com></a>
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:0LedlQ-1gzI3n1ore-00qVxW@mail.gmx.com" moz-do-not-send="true"><0LedlQ-1gzI3n1ore-00qVxW@mail.gmx.com></a>
Content-Type: text/plain; charset="utf-8"
About four days ago, my Chirp began acting strange. It opened normally, and a profile opened normally. But then, when I used the Alt+U command (and later using the menu options in the menu bar), Chirp went to (Not Responding) for about twenty seconds, after which the program resumed normal function. The only time I experience this issue is when I am asking Chirp to Upload or Download a radio.
I was using an older version of Chirp from December, as I loathe updating software. I used the App menu in the Setting App to uninstall Chirp, and installed the latest version to no avail. I then manually deleted the individual program files from its location in File Explorer and reinstalled. I performed these two actions twice with no improvement.
Then I used the Disk Cleanup tool in Windows, deleted temporary files, ran a Defrag, used the Microsoft Malicious Software Removal Tool, ran DISM <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>Online /Cleanup-Image /CheckHealth, DISM /Online /Cleanup-Image /ScanHealth, DISM /Online /Cleanup-Image /RestoreHealth, sfc<span class="moz-txt-tag">/</span></i> scanner, and chkdsk C: /f.
These actions all improved Windows performance as a whole, but I am still experiencing Chirp?s (Not Responding) issue. This is only a minor inconvenience, but after eight months of using Chirp with zero issues, it concerns me that it just decided to start having a brain fart one day.
What further diagnosis steps can I take to prevent a complete system reset? I?d like to not go through the process of a complete system restoration more than once a year.
Any help is appreciated,
Josh</pre>
</blockquote>
<hr width="100%" size="2">
<p>Hi Josh.</p>
<p>Make sure Win 10 has not done something (updates?) to block the
use of any I/O adapters you use to connect to the radio.</p>
<p>Also, that any such adapters "show up" to the system as the same
COM port you expect.</p>
<p>Check using Device Manager.<br>
</p>
<p>If not, either tell Chirp the new assigned port, or use Windows
own tools within Device Manager, to nail it's feet to the ground,
so that the next time you plug it in, to the same USB hole, it'll
show up the same (so long as nothing else got there first!)</p>
<p>For example, (but not the only method):-</p>
<p><a class="moz-txt-link-freetext" href="http://www.w1hkj.com/doku/doku.php?id=howto:taming_the_wild_comport_in_windows">http://www.w1hkj.com/doku/doku.php?id=howto:taming_the_wild_comport_in_windows</a><br>
</p>
<p>Just identifying the current COM port the radio is attached to,
and using "That" new info, to tell Chirp what to use, should get
you going, if it used to work OK with that adapter+radio in the
past.</p>
<p>If not, then there are other issues, possibly device driver
related.<br>
</p>
<p>73.</p>
<p>Dave G0WBX.</p>
<p>PS: Just so it is said, Linux etc can have the same/similar
issues, if anyone has experienced this sort of thing. Again one
needs to identify what /dev/ttyUSBx device was assigned to the
interface. But, in the case of FTDI based interfaces, you can
reliably "Fix" the issue using "udev rules". But that is beyond
the scope of this list. PM me if needed. I'm not aware of any
similar native facility in Windows.</p>
<p>><<br>
</p>
<pre class="moz-signature" cols="72">--
Created on and sent from a Unix like PC running and using free and open source software.
::
</pre>
</body>
</html>