Bug #859
closedIncorrect tone sent to radio
Added by Russ Bell almost 11 years ago. Updated over 7 years ago.
100%
Files
| kenwood_live.py (36 KB) kenwood_live.py | fixed | Tom Hayward, 05/08/2013 01:09 PM |
Related issues
Updated by Tom Hayward almost 11 years ago
- Status changed from New to Feedback
We're going to need a bit more information. See how to report issues.
Updated by Russ Bell almost 11 years ago
Using Chirp 0.3.1 on Windows 7
Radio: Kenwood HT TH-D7(G)
When Tone 162.2 is selected and displayed by Chirp. Actual radio memory shows tone 167.9 in all locations where 162.2 was entered. When radio data is downloaded to Chirp, 162.2 is displayed, however radio memory is actually 167.9.
Problem is repeatable and consistant.
Chirp tone 162.2 works correctly on Boafeng UV-5R+
When radio data was downloaded by Kenwood MD7G110 software, the tone is listed as 167.9.
Updated by Tom Hayward almost 11 years ago
- File kenwood_live.py added
- Status changed from Feedback to In Progress
- Assignee set to Tom Hayward
- Target version changed from 0.3.1 to 0.4.0
- % Done changed from 0 to 100
- Platform changed from Windows to All
Excellent explanation, thanks.
I found the manual for the TH-D7 and it looks like Chirp was assuming the TH-D7 supported a much larger set of tones than it actually does. This causes some of the higher tones to be offset--explaining the behavior you see.
I have a fix prepared that uses the set of tones listed in the manual. Could you test this for me to make sure it works?
Download kenwood_live.py attached to this bug report.¶
Open Chirp¶
Click Help > Enable Developer Functions (if not already enabled)¶
Click File > Load Module¶
Choose kenwood_live.py from your downloads folder¶
Test again with your TH-D7. Please check that tones 67.0, 162.2, and 250.0 read and store to the radio correctly. Also check that Chirp reports a friendly error message if you try to choose tones 69.3 or 159.8 for your TH-D7.¶
Once you confirm this I'll submit the fix for inclusion in an upcoming daily build and the next stable release.
Updated by Tom Hayward almost 11 years ago
- File kenwood_live.py kenwood_live.py added
I think I adjusted the wrong direction in that last one (off-by-two). Try this one instead.
Updated by Russ Bell almost 11 years ago
Chirp is unable to load either module "kenwood_live.py". It gives pop-up error "module has no attribute 'OLD_TONES'.
Updated by Tom Hayward almost 11 years ago
Sorry, you'll need to load it into a daily build, not the 0.3.1 you've been using.
http://trac.chirp.danplanet.com/chirp_daily/LATEST/chirp-daily-20130506.app.zip
Updated by Russ Bell almost 11 years ago
Module kenwood_live.py opened in Chirp Daily Build.
Results:
Tones 67, 91.5, 100.0 stored in D7 correctly.
Tone 159.8 stored as 162.2
Tone 162,2 stored as 167.9
Tones 69.3, 250.3 gave soft error, Invalid, Radio Refused.
Updated by Tom Hayward almost 11 years ago
- Status changed from In Progress to Feedback
Russ Bell wrote:
Module kenwood_live.py opened in Chirp Daily Build.
Results:
Tones 67, 91.5, 100.0 stored in D7 correctly.
Tone 159.8 stored as 162.2
Tone 162,2 stored as 167.9Tones 69.3, 250.3 gave soft error, Invalid, Radio Refused.
This is the exact same behavior as before, right? It sounds like the kenwood_live.py module did not load. Can you try my directions again? If this doesn't work, we'll have to find a new way to test.
Updated by Russ Bell almost 11 years ago
Good idea. I re-downloaded "fixed" file and repeated test.
Chirp Tone D7G Tone
67.0 67.0
162.2 167.9
250.3 Error: Invalid Field.
69.3 Error: Invalid value.
159.8 Error: Invalid Value
FYI: Radio memory tone of 162.2 read by Chirp as 159.8
Updated by Tom Hayward almost 11 years ago
I'm glad you are getting errors for the unsupported tones, but you should be seeing a message like "This radio does not support tone 69.3Hz". I'd like to figure out what's wrong with the error messages before submitting this.
It should be impossible to read 162.2 as 159.8. When you Load Module, it is only temporary. For my fix to take affect, you must load it every time you start Chirp. My guess is the time you got 159.8 my fix was not loaded.
Updated by Russ Bell almost 11 years ago
I'm having troubles explaning things.
OK, just received your recent email. You're correct. Chirp was exited and re-started with re-load module. Please excuse my ignorance. I only heard of Chip 2 days ago.
Anyway, I repeated test again with more promising results.
Chip/ Radio
67.0/ 67.0
162.2/ 162.2
250.3/ 250.3
69.3/ Invalid value. Radio doesn't support tone.
159.8/ Invalid value. Radio doesn't support tone.
I think you have fixed it. Other mistakes were mine.
Sorry 'bout that.
Updated by Tom Hayward almost 11 years ago
- Status changed from Feedback to Resolved
Don't worry, testing bug fixes is the most advanced thing you can do with Chirp outside of writing code and you've been very helpful. I think we've proven that this fix is good. I'll submit it for inclusion in the next release.
Updated by Russ Bell almost 11 years ago
Thankyou very much for your prompt responses. I didn't expect such fast turnaround. I heard about Chirp because of poor software reviews regarding Boafeng UV-5R+ which I just purchased. Chirp worked great for that model. Made me want to update memories in my old D-7G. Thankyou once again for your efforts. 73's.
N7GLN.
Updated by Tom Hayward almost 11 years ago
- Status changed from Resolved to Needs Backport
Updated by Tom Hayward over 7 years ago
- Status changed from Needs Backport to Closed