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

[M.Sc. Pavel Milanes Costa]

Hi Dan et al, See below.

El 23/03/16 a las 15:52, Dan Smith via chirp_devel escribió:
>> Yes, good to know about the performance issue. Also how can I measure
>> that performance impact to compare for future improvements?
> It's just a general thing: making lots of syscalls for very small bits
> of data is inefficient, and it means you're more likely to be blocked on
> the kernel during periods of high load (which you're contributing to).
> It's far more expensive to make a syscall than a regular function call.
> Also, with the tight timing you've got going on here, it could
> definitely cause you to miss another deadline you're expecting to make
> and manifest itself as instability under load and other varying conditions.

Make sense.

>> Most of the time we got reads with not the amount of data we must have
>> and the driver failing, the other alternative was to use big
>> time.sleep() here and there and we have then a long delayed reads and
>> uploads with occasional resets of the radio.
> Right, you can never depend on a read returning the whole thing you're
> expecting for. That's why you may need a queue which always reads as
> much as the radio has available, from which your code processes the
> frames as soon as they are whole.

I get the idea, and have a kind of schema in mind that may work even 
with bad read recovery to protect me from the radio miss behaviors.

> Okay, but we could just separate them out in the model list. A user may
> not know if they have a v1 or v2 radio, but if you call them out like
> that, they can try both and then continue to use that one in the future.
> Making people with radios that aren't first in the list wait many
> multiples of 5 seconds is not reasonable, IMHO.

I was searching the net about this and most sellers have a "(Gen 2)" or 
something like that in it's advertising but the actual radio have no 
evident marking of the generation or version (at least in the advertised 
pictures)

Also the comments on the end of the file before the radio declarations 
is not accurate and has a lot to do with the former strategy,  the only 
element that has a real impact now in the ident schema is the 
self._magic list now. This has been corrected in the draft version, 
sorry for that.

So it makes sense to separate radios from just one family in the listing 
and tag it as "Gen 2" for example, only if hey have so many magics to 
try for all members in that family.

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.

> Well, first thing this morning there was already a bug about timing issues:
>
>    http://chirp.danplanet.com/issues/3507

You are right, the description of the issue has much to do with what you 
have mentioned about system load.

>> No, this value is NOT mutable.
>>
>> This radios has a REAL mem span of 0x4000 (you can safely read up to
>> there, and write too) but in the read the OEM software get just up to
>> 0x3200 (we get full span in chirp) and in the write just up to 0x3100.
>>
>> We respect the write boundary and this driver will never write beyond
>> 0x3100, see _upload() procedure comments
> 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?

To learn from it.

>> If the JetStream is a clone of this (or vice versa) get support for it
>> is as fast as Jim can get it on it's hands to test it and we will work
>> on that direction ASAP.
> David Fannin has the radio already and will be looking into the changes
> needed for this. I'm hoping he'll also be able to help with some of the
> stability issues.
>
> Thanks Pavel and Jim!

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

Thanks for taking the time to coach me on this. I have a lot of 
"homework" to don now.

73.