[chirp_devel] [PATCH] [New Model] Support for the BTECH Mobile Radios, fixes issue #3015

[Jim Unroe]

On Thu, Mar 24, 2016 at 1:21 PM, Dan Smith via chirp_devel
<chirp_devel at intrepid.danplanet.com> wrote:
>> Looking the data we have now I realize that we only have one case of
>> this with a family of radios with two magics to try (BTECH UV-5001),
>> with just one UV-5001 Gen 2v2 with a different magic from the other 4
>> members of the family.
>>
>> As pre-production and alpha units never got into the market,  we only
>> have the 1st, 2nd & 2nd ver 2 generation on the street and being just
>> this last the only that need a different magic there is a chance of just
>> 33% of getining the wait on the radio ident.
>>
>> That's just about 6-7 seconds of wait on the ident before the clone
>> start if you have that radio (just 33% chance), and also the progress
>> bar will be moving all time to show you progress.
>>
>> IMHO that's not a big issue, so I vote for keeping it in the actual way
>> as long the count of magics in the list don't climb higher. I have
>> already a note in the driver about this to make the changes if the issue
>> get complicated in the future.
>
> Personally I think it's a big issue. I 6-7 seconds is not really
> reasonable, IMHO, but definitely not once we have to add even another
> magic to the list.
>
> So, I can't make you do anything and I don't have a sample of radios in
> order to test a refactor myself. I would just say that on the list of
> things I think need to change in this driver, that's in my top five or so.
>
> Maybe some other people can share their opinions.
>

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