On Thu, Mar 24, 2016 at 1:21 PM, Dan Smith via chirp_devel chirp_devel@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