Project

General

Profile

Actions

Bug #297

closed

Channels not displayed after reading from Icom IC-Q7A

Added by Jim Unroe over 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
09/08/2012
Due date:
% Done:

0%

Estimated time:
Chirp Version:
0.2.3
Model affected:
IC-Q7A
Platform:
All

Description

CHIRP appears to read from IC-Q7A OK but only channels 194 through 199 have any channel data displayed. All the other channels are greyed out and with default values as if they were blank channels. Removing the tick mark from Show Empty correctly displays only the programmed channels, but as stated before, all channels are greyed out and without any channel data except for channels 194 through 199.
Thanks,
Jim Unroe


Files

debug.log (77.9 KB) debug.log Jim Unroe, 09/08/2012 08:05 PM
IC-Q7A.img (1.94 KB) IC-Q7A.img Jim Unroe, 09/08/2012 08:05 PM
Actions #1

Updated by Dan Smith about 10 years ago

  • Status changed from New to Feedback
  • Assignee set to Jim Unroe

Hi Jim,

Looks like there's some value being decoded that is out of range from what we expect. Since you're a pro now, do you want to take a look at this? I don't have one of these radios, so I'd be stuck going through just the image you provided. If you don't want to look, I can give it a shot.

Actions #2

Updated by Jim Unroe about 10 years ago

  • Status changed from Feedback to Closed
  • Platform changed from Windows to All

Even though the channel information for most of the channels wasn't being displayed in the spreadsheet view, all channel information appeared to be correctly saved in the image file. After investigation, two things appear to be the cause of this problem.

The fist is apparently the software that I used to originally program my IC-Q7A must have written CTCSS values for the channels that don't use CTCSS that are invalid for CHIRP. I hacked a special icq7 driver that downloaded the channels and converted everything that didn't have a valid tone to 88.5. This was then saved to another image file.

The second issue was that I have 2 channels that have a frequency out of CHIRP's range. 1370 KHz (a local AM radio station) and 25.185 MHz (CB channel 19). Apparently CHIRP only allows frequencies down to 30MHz. I just blanked them out with a hex editor. I will probably do without these frequencies.

Everything seems to be fine now. This issue can be closed without making any changes.

Actions #3

Updated by Dan Smith about 10 years ago

Hmm, I'm not sure what to make of the tone issue, since it sure seems like the 6-bit tone fields are right. Can you program the old image back into the radio and see what tone the radio thinks they should be?

For the second one, I think that's a bug in the icq7 driver. CHIRP supports down to 1Hz without any problem (it supports several HF radios). What made you think that 30MHz was the limit? Let me know what I can do to help, but I think we should open this back up and try to fix the range issue.

Thanks!

Actions #4

Updated by Jim Unroe about 10 years ago

  • Status changed from Closed to In Progress

This
rf.valid_bands = [( 30000000, 823995000),
(849000000, 868995000),
(894000000, 1309995000)]

and the fact that I get "Error setting memoryFrequency 29.990000 is out of supported range" with values less then 30.0 MHz led me to believe 30 MHz was the limit. Changing 30000000 to a smaller value didn't help either.

  00 01 02 03 04 05 06 07

CH000 14 65 20 00 00 00 CB 20 <- from originsl image - won't diplay
CH194 11 80 00 00 00 00 20 83 <- from original image - will display
CH000 14 65 20 00 00 00 20 80 <- from 'fixed' image - will display

All non displaying channels have CB in the 06 or 0E byte position

On the IC-Q7A, turning T/T SQL to TONE and looking at R TONE and C TONE shows that they are both OFF.

Jim

Actions #5

Updated by Dan Smith about 10 years ago

This
rf.valid_bands = [( 30000000, 823995000),
(849000000, 868995000),
(894000000, 1309995000)]

and the fact that I get "Error setting memoryFrequency 29.990000 is out of supported range" with values less then 30.0 MHz led me to believe 30 MHz was the limit. Changing 30000000 to a smaller value didn't help either.

Okay, well, the manual says that 30MHz is the lowest frequency the receiver will tune to, which is why I set it that way. If you know that it can tune lower, then we should lower it to something appropriate. Maybe 1MHz?

I just tested changing the lower limit from 30MHz to 1Mhz and it let me enter 25MHz just fine.

  00 01 02 03 04 05 06 07

CH000 14 65 20 00 00 00 CB 20 <- from originsl image - won't diplay
CH194 11 80 00 00 00 00 20 83 <- from original image - will display
CH000 14 65 20 00 00 00 20 80 <- from 'fixed' image - will display

All non displaying channels have CB in the 06 or 0E byte position

Okay, that indicates a tone index 50, which is one higher than the last index (indexes run 0-49). The tone list in the manual matches what CHIRP is using, so perhaps the radio (or some other software) set the tone value to 50 when it disabled it? If you want, you could put a try...except around the lookup of the tone to catch this and do something sane. Something like:

try:
mem.rtone = chirp_common.TONES[_mem.rtone]
mem.ctone = chirp_common.TONES[_mem.ctone]
except IndexError:
mem.rtone = 88.5
mem.ctone = 88.5

Could be an easy fix...

Thanks Jim!

Actions #6

Updated by Jim Unroe about 10 years ago

Almost there...

I had to separate the rtone and ctone checks

    try:
        mem.rtone = chirp_common.TONES[_mem.rtone]
    except IndexError:
        mem.rtone = 88.5
    try:
        mem.ctone = chirp_common.TONES[_mem.ctone]
    except IndexError:
        mem.ctone = 88.5

I also changed 30000000 to 1000000 and that worked. I must have not loaded the module the first time I did it.

The problem I see now is that even if AM is selected, FM is the mode programmed in the HT for freqs below 30.0 MHz. Above 30.0 MHz, the AM selection seems to be OK.

Jim

Actions #7

Updated by Dan Smith about 10 years ago

Meaning the radio appears to assume AM for any frequency below 30MHz? Probably makes sense, so I think I'd just replicate that behavior in chirp. Something like:

if mem.freq < 30000000:
    mem.mode = "AM"
else:
    mem.mode = MODES[_flag.mode]
Actions #8

Updated by Jim Unroe about 10 years ago

The radio shows FM on the display after is is programmed with CHIRP set to FM. The original channels that are below 30 MHz and are displaying AM work. I tried the suggested code anyway and it still behaves the same way.

Actions #9

Updated by Jim Unroe about 10 years ago

I think I got it. The working channel had a tuning step of 10. The non-working was 5. Changing to 10 and uploading still showed AM. I will do some more testing.

Actions #10

Updated by Jim Unroe about 10 years ago

Nope. That wasn't it. Upon further investigation, the channels below 30 MHz that are programmed AM but are FM in the radio also have the 4th byte (fractional?) set to 7F. If I change them to 00 then they are AM as they should be.

Actions #11

Updated by Dan Smith about 10 years ago

Ah, you mean the 7-bit field "unknown" right? If so, then yeah, perhaps you should set that to 0 at the end of set_memory()? What happens if you do it explicitly for all set operations? Is it still happy? There have been several situations with Icoms where chirp fails to clear (i.e. set to all 0x00) a previously-unused memory before setting it. Since it ignores the "unknown" bits when setting, they remain whatever they were before, which is often all 0xFF if the memory has never been used. So, it would be fitting to initialize that unknown bit to 0x00, I think.

Actions #12

Updated by Jim Unroe about 10 years ago

Yes, I guess so. So how do I go about clearing it?

Actions #13

Updated by Dan Smith about 10 years ago

I'd say right after the is-empty escape clause, do this:

_mem.set_raw("0x00" * 8)

That will set the entire structure to eight bytes of 0x00.

Actions #14

Updated by Jim Unroe about 10 years ago

I'd say right after the is-empty escape clause, do this:

_mem.set_raw("0x00" * 8)

That will set the entire structure to eight bytes of 0x00.

Dan. I don't guess I follow you. I don't see an "is-empty" escape clause in the icq7.py driver.
Jim

Actions #15

Updated by Dan Smith about 10 years ago

I mean this (untested) change:

diff -r a132c837fd25 chirp/icq7.py
--- a/chirp/icq7.py     Mon Dec 24 08:17:19 2012 -0800
+++ b/chirp/icq7.py     Tue Dec 25 13:21:35 2012 -0800
@@ -119,6 +119,8 @@
             self._memobj.flags_whole[mem.number] = 0xFF
             return
 
+        _mem.set_raw("\x00" * 8)
+
         if mem.freq > to_GHz(1):
             _mem.freq = (mem.freq / 1000) - to_GHz(1)
             upper = from_GHz(mem.freq) << 4

What I meant by the escape clause, is that just above the lines I added here, it checks to see if the memory being set is empty, and if so, bails without running the code in the rest of the method.

Actions #16

Updated by Jim Unroe about 10 years ago

Perfect! As far as I can tell it all works now.

  • I can fully read my original image without any changes.
  • Frequencies below 30 MHz now work as before and AM mode set correctly.
  • I also programmed in an FRS channel to make sure that 'fractional' still works and it does.

Do you want my new icq7.py as is, or do you want me to figure out how to do it with Mercurial?
Jim

Actions #17

Updated by Dan Smith about 10 years ago

  • Target version set to 0.3.0

Nice!

I want you to get a diff out of mercurial and send that to the mailing list, but seeing as it's christmas, I'll let you slide one more time if you want :-)

Actions #18

Updated by Dan Smith about 10 years ago

  • Status changed from In Progress to Closed
Actions

Also available in: Atom PDF