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

[M.Sc. Pavel Milanes Costa]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160324/ad269517/attachment-0001.html