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

[Dan Smith]

> 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.

>> Okay, in previous models, there was a reserved region at the end which
>> appeared to be immutable, until we found an extra tool that let a vendor
>> customize what was in this last block...
> 
> Then this will be a real mess...
> 
> I was today inspecting the ident code and it's constructed with data 
> from that region exclusively and the only "non mutable" and unique data 
> for every radio is the one we use now as fingerprint.
> 
> Was the fix to the problem you mentioned?

I don't think we were using it for identification, or maybe it was just
for firmware records or something. I'm just saying: just because it's
not written by the consumer software doesn't mean it's actually
immutable, or that you shouldn't ever expect to see it different in the
field.

> Ok, I wait for David to write me an email to give him a welcome to the 
> team and exchange ideas/code/etc.

In the meantime, I'd surely appreciate you keeping any patches that you
have people try as public in the bug trackers. That helps increase
collaboration with people that might have other ideas. IMHO, there is no
reason to have a patch or other communication be private unless you're
concerned that a particular change might be damaging in some way. In the
history of CHIRP, I can think of only one such situation that warranted
some private communication about a potential fix. In general, we should
leverage the community of users and developers and try to keep that
communication as open as possible.

Thanks!

--Dan