On Sun, Mar 3, 2019 at 8:37 PM Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
On the last driver I was going to look at tonight, anytone_ht.py, I get these 2 errors when running the tests...
AnyTone OBLTR-8R Detect ←[1;32m PASSED:←[0m All tests AnyTone OBLTR-8R Settings ←[1;32m PASSED:←[0m All tests AnyTone OBLTR-8R Clone ←[1;32m PASSED:←[0m All tests AnyTone OBLTR-8R Edges ←[1;41m FAILED:←[0m Field `freq' is `14585620 0', expected `145856250' AnyTone OBLTR-8R BruteForce ←[1;32m PASSED:←[0m All tests AnyTone OBLTR-8R CopyAll ←[1;32m PASSED:←[0m All tests AnyTone OBLTR-8R Banks ←[1;32mSKIPPED:←[0m Banks not supported AnyTone TERMN-8R Detect ←[1;32m PASSED:←[0m All tests AnyTone TERMN-8R Settings ←[1;32m PASSED:←[0m All tests AnyTone TERMN-8R Clone ←[1;32m PASSED:←[0m All tests AnyTone TERMN-8R Edges ←[1;41m FAILED:←[0m Field `freq' is `14585620 0', expected `145856250' AnyTone TERMN-8R BruteForce ←[1;32m PASSED:←[0m All tests AnyTone TERMN-8R CopyAll ←[1;32m PASSED:←[0m All tests AnyTone TERMN-8R Banks ←[1;32mSKIPPED:←[0m Banks not supported
All I am doing is adding this...
rf.valid_tuning_steps = [2.5, 5., 6.25, 10., 12.5, 25.]If I remove the 6.25 as below, both radios pass the tests.
rf.valid_tuning_steps = [2.5, 5., 10., 12.5, 25.]Do you have any ideas/hints for what to look for?
This means the test tried to set 145.85625, but when it read that back from the radio, it got 145.85620. If the radio really can store that frequency, then the code in the driver must be wrong. This is what started all of this -- the IC-2730 claimed to support 6.25 step frequencies, but was storing them as a multiple of 5.0 (most Icom radios store frequencies as a multiple of the tuning step), which meant that it wasn't actually storing the frequency asked. Since the test was broken, we didn't notice.
I assume this means those drivers are and have been broken for some time, but we didn't notice because that test was broken. When I made the default list change, the radios stopped "advertising" that they support 6.25, which means the test doesn't require them to work for those frequencies. When you add 6.25 back, that makes the test try to store/retrieve a frequency that requires a 6.25 step, and they fail to store/return the proper thing.
I think if you try to replicate this with the gui, you'll see that storing 145.85625 in a channel and then trying to read it back out, it'll drop the last digit.
Probably the same situation for the anytone.py driver then. Sounds like a project from tomorrow. Thanks.
Jim