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