Project

General

Profile

Actions

Bug #859

closed

Incorrect tone sent to radio

Added by Russ Bell almost 11 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
05/08/2013
Due date:
% Done:

100%

Estimated time:
Chirp Version:
0.3.0
Model affected:
th-d7ag
Platform:
All
Debug Log:
I read the instructions above:

Files

kenwood_live.py (36 KB) kenwood_live.py fixed Tom Hayward, 05/08/2013 01:09 PM

Related issues

Related to Bug #867: Incorrect tone for Kenwood TM-D700ClosedTom Hayward05/12/2013

Actions
Actions #1

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.

Actions #2

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.

Actions #3

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.

Actions #4

Updated by Tom Hayward almost 11 years ago

I think I adjusted the wrong direction in that last one (off-by-two). Try this one instead.

Actions #5

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'.

Actions #6

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

Actions #7

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.

Actions #8

Updated by Tom Hayward almost 11 years ago

  • File deleted (kenwood_live.py)
Actions #9

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.9

Tones 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.

Actions #10

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

Actions #11

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.

Actions #12

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.

Actions #13

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.

Actions #14

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.

Actions #15

Updated by Tom Hayward almost 11 years ago

  • Status changed from Resolved to Needs Backport
Actions #16

Updated by Tom Hayward over 7 years ago

  • Status changed from Needs Backport to Closed
Actions

Also available in: Atom PDF