On Mon, Apr 10, 2017 at 6:43 AM, Pavel Milanes Costa pavelmc@gmail.com wrote:

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,

I understood the existing code and intentionally rewrote the range to support 440 MHz on all sub-models. I used min() for the low side of the range, so that models that already span 440 are unaffected, but models with higher sub-bands now are "valid" all the way down the 440 MHz. This will allow testing of these models down to 440 MHz.

I follow a policy of just modify the ones that I can confirm by my/others test, in your image I sport that you has a F1 version (see attached image, 450 to 470MHz as dealer states) and you have confirmed that it works down to 440, which is great.

So the right change must be this (and not in the Kenwood_P60_Radio class):

================================

@directory.register class TK360_Radio(Kenwood_P60_Radio): """Kenwood TK-360 Radios""" MODEL = "TK-360" TYPE = "P0360" VARIANTS = { "P0360\x24\x00\x00": (4, 440, 470, "F1"), # original 450-470 "P0360\x25\x00\x00": (4, 470, 490, "F2"), "P0360\x26\x00\x00": (4, 490, 512, "F3"), "P0360\x23\x00\x00": (4, 406, 430, "F4"), }

===============================

I intentionally did not modify the VARIANT specifications. I left these as-is, so that Chirp still reports the F1 model as rated for 450-470 in the settings pane, even though valid_bands is slightly more permissive. I don't want to mislead the users about the capabilities of their radio, but I do want to allow them to test their radios in the 440 band.

From the little reading I did about these radios, the Kenwood software

is happy to let you take them out of band (it warns you, but allows it). If you take them too far out of band, the PLL will fail to lock and will give you a warning beep. This is a pretty mundane failure mode, so risk of allowing this in Chirp is low.

There might be a better way to do this, but I'd like to still have a scheme where the factory frequency range is reported in the Settings pane. This means not modifying the VARIANT spec (or maybe we could add to it).

Tom

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