[chirp_devel] [PATCH] [TK-270] Allow programming Kenwood commercial UHF radios in the 70cm band. #4709

[Pavel Milanes Costa]

El 13/04/17 a las 12:56, Dan Smith escribió:
>>> I think you don't read the full driver, at the end there is a section with
>>> the specific limits for each radio the lib supports and all of it's known
>>> (to me and by the software)
> Pavel, you asserted that this _breaks_ something. Can you explain that?
>

Yes right, it does not really _breaks_ the code, sorry, but it breaks 
the users experience and can lead to problems; let me explain:

The use min() function in this line:

self._range = [min(440, low) * 1000000, high * 1000000]


Will affect all models of radios supported by the lib, not only the 
TK-360, but the all the rest: 260, 270, 272, 278, 370, 372 and 378. 
(VHF/UHF radios)

In the case of the VHF radios (2xx) this will not harm, but in the case 
of the UHF (3xx) ones it does in some cases; as there are some variants 
in which the OEM low band edge is way beyond the 440 Mhz, for example 
variants F2 and F3 for al UHFs: (see the code)

F2 type is 470 to 490: 440 is way 30 Mhz down.
F3 type is 490 to 512: 440 is way 50 Mhz down.

The same for TK370, 372 and 378 type F2 & F3

I can testify that kenwood radios do come off from OEM band edges and 
works a few Mhz outside them, but 30/50 is excessive and I'm almost sure 
that they will not work properly.

This can lead to this tested and verified problems:

1 - Radio will beep and/or flash LCD numbers when RX VCO PLL is fully 
unlocked. (depending on model/firmware)
2 - RX VCO PLL can lock and RX will work, but TX VCO can't and on TX PLL 
VCO will dance spreading noise all over the full fringe zone, in the 
short fringe zone it will produce a loud audible tone for the people 
that are receiving the signal...
3 - The inverse of #2 (RX VCO PLL is partially unlocked, funny but 
true), Radio will be deaf and TX will work.

Been there done that, we tried to re-purpose a pair of kenwood base 
stations (precisely Type "F2") for a UHF link in our local radioclub and 
get #1 in one radio and #2 in the other...

Physically touching the VCO's parameters and retuning the BPF on RX 
fixed it on our case, but we get about a week to understand #2 ad #3... 
as TX was working but with a ~1Khz tone on top. (VCO jumping from 
unlook/look), not every body can do hardware VCO fine tuning. (and 
RTL-SDR was very helpful in that)

#2 is the worst scenario for an unexperienced user, user will think 
Chirps programing has broken his radio and will complain in chirps 
site/maillist causing a snowball of comments/emails....

Tom's fix can work out as a "proof of limits test" to asset the 
different radio models but not as a definitive fix, at least in my opinion.

That's why I followed a policy of just mod the limits when somebody 
tested it and prove it worked ok (that can be done with the OEM software 
FYI), at least with that we are safe from users complain (justified 
complaints from my point of view)

If you look at the TK760g.py file (bottom) you will find what I'm 
talking about.

I have tested almost all the variants of the VHF radios personally, 
courtesy of CO7ETY, a ham friend that had a fleet working with them, now 
migrated to modern base HYT TM800V and a plethora of HYT handhelds, 
kenwoods are now on hands of local ham operators: Yahoo!!!)

And the VHF models that can safety work in the 2m ham band are there.

The UHF models are other story, I had only tested a few of them, and as 
a rule of thumb it does not move more that 10 to 15 Mhz down/up before 
they fall apart with problems #1 and or #2.

So I think the solution lies in a mix: using Tom's fix as a dev solution 
to test/characterize the specific radio model/variant limits and 
ultimately updating the specific radio model/variant with proven limits 
(my fix) to be safe and not trick the users that his factory 470-510 Mhz 
radio will work in 440 Mhz.

Note: the Tom's Idea of showing OEM limits beside the ones we have 
modified is a good one, I may bring a solution for this in the UI.

I hope this can bring some light on the issue.

> I'm holding off on these until we reach some resolution.
>
> Thanks!
>
> --Dan

Thanks, Pavel CO7WT