<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi to all, see at the bootom.<br>
<br>
<div class="moz-cite-prefix">El 24/03/16 a las 13:59, Jim Unroe via
chirp_devel escribió:<br>
</div>
<blockquote
cite="mid:CADnO8U7j5MaJSEV7T-9JMy7+RrrYLV1uxd41LQXonkE=VqOvdQ@mail.gmail.com"
type="cite">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Looking the data we have now I realize that we only have one case of
<span class="moz-txt-citetags">>> </span>this with a family of radios with two magics to try (BTECH UV-5001),
<span class="moz-txt-citetags">>> </span>with just one UV-5001 Gen 2v2 with a different magic from the other 4
<span class="moz-txt-citetags">>> </span>members of the family.
<span class="moz-txt-citetags">>></span>
<span class="moz-txt-citetags">>> </span>As pre-production and alpha units never got into the market, we only
<span class="moz-txt-citetags">>> </span>have the 1st, 2nd & 2nd ver 2 generation on the street and being just
<span class="moz-txt-citetags">>> </span>this last the only that need a different magic there is a chance of just
<span class="moz-txt-citetags">>> </span>33% of getining the wait on the radio ident.
<span class="moz-txt-citetags">>></span>
<span class="moz-txt-citetags">>> </span>That's just about 6-7 seconds of wait on the ident before the clone
<span class="moz-txt-citetags">>> </span>start if you have that radio (just 33% chance), and also the progress
<span class="moz-txt-citetags">>> </span>bar will be moving all time to show you progress.
<span class="moz-txt-citetags">>></span>
<span class="moz-txt-citetags">>> </span>IMHO that's not a big issue, so I vote for keeping it in the actual way
<span class="moz-txt-citetags">>> </span>as long the count of magics in the list don't climb higher. I have
<span class="moz-txt-citetags">>> </span>already a note in the driver about this to make the changes if the issue
<span class="moz-txt-citetags">>> </span>get complicated in the future.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>Personally I think it's a big issue. I 6-7 seconds is not really
<span class="moz-txt-citetags">> </span>reasonable, IMHO, but definitely not once we have to add even another
<span class="moz-txt-citetags">> </span>magic to the list.
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>So, I can't make you do anything and I don't have a sample of radios in
<span class="moz-txt-citetags">> </span>order to test a refactor myself. I would just say that on the list of
<span class="moz-txt-citetags">> </span>things I think need to change in this driver, that's in my top five or so.
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>Maybe some other people can share their opinions.
<span class="moz-txt-citetags">></span>
</pre>
</blockquote>
<pre wrap="">This is to support a single radio. I believe all we have to do is
switch back to the way I had it originally. Add the "ident"
fingerprint for this one-of-a-kind radio to the WACCOM/MINI-8900 radio
class (since that it sends the "magic" that this radio needs and have
the user select that vendor/model combination to program that
one-of-kind radio.
Or have that radio sent back to the vendor to be used for repair parts
so it doesn't need to be supported at all.
We need to start collecting the idents and fingerprints from the other
radio variants to determine what the extent of the variations are. We
will just have to have a separate class for each magic and do our best
on the supported radio models list to let the CHIRP user know which
vendor/model selection to use.
Then I will have to figure out what to do with the Baofeng radios that
have this issue. I would hoping to use whatever solution was arrived
at here to resolve that. I see now I may have to approach it
differently.
Jim</pre>
</blockquote>
<br>
We may have a storm in a tea cup here, we need to get some points
clear before going on about that radio.<br>
<ul>
<li><b>Is this radio unique?</b> We are working with various
pre-production units and alphas that was unique (or in very
small lots) and directed to the brand owner to test, so there is
a chance that this radio is a unique test unit?<br>
If so, then putting it on the "end of the list" is safe as just
one or a small count of users will be affected. Jim can you
check with Adrew and John about this?<br>
</li>
<li><b>Can we craft some way of shorten the wait between tries?</b>
If we can make it, and it's short enough (for example, less than
a second) then we can safely put a small amount of magics to try
in a list as the delay will be negligible. I'm sure this area
has a lot of improvement potential as the early tests about it
was light and mixed with other issues.<br>
</li>
</ul>
<p>The first is the fast one, and the second will require more work
and test but it's doable and worth it.<br>
</p>
<p>I'm agree with Jim, I think that getting some portmon serial logs
for the other alike radios will reveal some intel about this being
a isolated issue or a common practice, and in any case we will
gain knowledge about this radios.<br>
</p>
<p>Jim, can you post a request of this kind of serial logs in the
alike radios issue page?<br>
</p>
<p>73<br>
</p>
<p><br>
</p>
</body>
</html>