Hi to all, see at the bootom.
El 24/03/16 a las 13:59, Jim Unroe via chirp_devel escribió:
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
We may have a storm in a tea cup here, we need to get some points clear before going on about that radio.
* *Is this radio unique?* 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? 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? * *Can we craft some way of shorten the wait between tries?* 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.
The first is the fast one, and the second will require more work and test but it's doable and worth it.
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.
Jim, can you post a request of this kind of serial logs in the alike radios issue page?
73