Thread: [Hamlib-developer] Icom R7000 report
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Chuck H. <n2...@am...> - 2002-03-02 07:46:49
|
Thanks for creating the entries for the Icom R7000, 910, and the AOR 5000.
First, I wish to apologize. My friend has an Icom 970, not a 910. If someone
would be kind enough to create an entry for a 970, I'll happily test it when I
get over there.
Just think of it as being nice to the future users of the 910. :)
Now for the Icom R-7000:
On 27-Feb-02 Stephane Fillod wrote:
>> Now to set the CIV address to 0x42, issue:
>> rig_set_conf(rig, TOK_CIVADDR, 0x42);
>
> Chuck, could you confirm this is 0x08 for the R-7000?
Yes it is.
> In order to ease Hamlib hacking, there are some guidelines to test the cvs
> version, available at the following URL:
You said you wanted beta testers. Here it is. :)
I did some testing of the Icom r7000. I have a few notes, then some stuff out
of rigctl, and a then a dumpcaps with some notes. Hopefully I havn't
overloaded you with too much information.
Feel free to let me know if you have any questions, comments, things you want
me to check or anything else. Also, I don't mean to cause alot of work for
other people. If you want any help implementing any of this let me know. I'm
getting better at my understanding the internals to hamlib and I could probably
figure out how to do a bunch of this.
---
A few things to start with:
1. This is an early computer controlled rig so many of the features of the radio
are set using mechanical switches and are not computer controllable. This
makes it a bit strange. And it's also a bit different from the other
Icom rigs. This probably makes this report a lot longer then it would be for
most radios. There are also several things in here that I've noted, but I'm
not sure that hamlib should care about.
Just figured I'd warn you. :)
2. The default for the speed of the CI-V bus seems wrong. The hamlib default
serial speed is the max speed of the radio. According to the CI-V docs
that I have, the factory default serial speed for CI-V is 1200 bps. My
radio also happens to be 1200. I'll try to find out if it is settable and if
so to what values.
What I'm wondering is if there should be some sort of default speed for a
radio which could be set to the factory default rather then defaulting to
the max speed. Or maybe this should just be rolled into the future
preferences file mentioned in the TODO file.
Because of this, I couldn't run either testtrn or dumpmem to test them.
3. With tranceive enabled on the radio, rigctl gets confused if you do things on
the front panel of the radio. This is because the radio sends things and the
input buffer isn't flushed or processed before the responses from the
commands are looked for. I ended up quiting and restarting rigctl most of
the times I touched the radio.
4. I currently don't have a copy of the owners and/or service manual for this
radio. I should be able to get a copy of the owners manual in a few days.
That will hopefully answer some of my questions about a few things. For the
CI-V items (which aren't in the owners manual anyways) I've been using the
pdf file I mentioned the other day.
5. In looking through riglist.h the other day, I noticed that a couple of the
Icom radios and the Optoelectronics had duplicate numbers. This is
probably because the Optoelectronics rigs are also CI-V controlled and
someone added Icom rigs without noticing that the numbers were being used:
#define RIG_MODEL_IC910 RIG_MAKE_MODEL(RIG_ICOM, 44)
#define RIG_MODEL_ICR78 RIG_MAKE_MODEL(RIG_ICOM, 45)
/*
* Optoelectronics (CI-V)
*/
#define RIG_MODEL_MINISCOUT RIG_MAKE_MODEL(RIG_ICOM, 44)
#define RIG_MODEL_XPLORER RIG_MAKE_MODEL(RIG_ICOM, 45)
6. When installing the CVS version the other day after configuring it with a
--prefix, I noticed that it tried to install some of the perl files in
/usr/lib/perl5/... Not knowing the perl directory structure, I don't know if
this is a feature or a bug.
Work around: ./configure --without-perl-binding
This is out of "make install" with prefix set to /opt/hamlib, installing as
myself rather than root. (Sorry about the line wraps. Hopefully you can
understand it.)
Warning: You do not have permissions to install into
/usr/lib/perl5/site_perl/5.6.0/i386-linux at
/usr/lib/perl5/5.6.0/ExtUtils/Install.pm line 62.
mkdir /usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Hamlib: Permission
denied at /usr/lib/perl5/5.6.0/ExtUtils/Install.pm line 112
make[2]: *** [pure_site_install] Error 255
make[2]: Leaving directory `/export/swami/kmh/hamlib/cvs/hamlib/perl/Hamlib'
--------------
Now some testing with rigctl:
set and get frequency 25-999 MHz: good
Note: it ignores the last 2 digits on set and returns 00 on get
Rig command: F
Frequency: 123456789
TX 12 bytes
0000 ff fe fe 08 e0 05 89 67 45 23 01 fd .......gE#..
RX 12 bytes
0000 ff fe fe 08 e0 05 89 67 45 23 01 fd .......gE#..
RX 6 bytes
0000 fe fe e0 08 fb fd ......
Rig command: f
TX 7 bytes
0000 ff fe fe 08 e0 03 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 03 fd .......
RX 6 bytes
0000 fe fe e0 08 03 00 ......
RX 1 bytes
0000 67 g
RX 1 bytes
0000 45 E
RX 1 bytes
0000 23 #
RX 1 bytes
0000 01 .
RX 1 bytes
0000 fd .
Frequency: 123456700
---
set and get frequency 1025-1999 MHz: not quite right
Note: there is a separate 1ghz switch on the front panel. When it's on, a
"1GHz" lights up in the display and the radio tunes 1025-1999.9999. It looks
like the computer interface doesn't know it exists. It always returns 0 in the
ghz digit on get and errors if the ghz digit is 1 on set. I don't know if
hamlib should care. Since I'm already supporting downconverters in my software
for 2.4 GHz I'll probably implement it as a manually controlled downconverter
that happens to be installed in the radio. The only thing I could see hamlib
MIGHT want to do is to mask out the 1ghz digit so the program could ask for 1234
MHz and hamlib sends 234 MHz to the radio. And leave it up to the user to push
the button.
With 1ghz switch on:
Rig command: F
Frequency: 1123456789
TX 12 bytes
0000 ff fe fe 08 e0 05 89 67 45 23 11 fd .......gE#..
RX 12 bytes
0000 ff fe fe 08 e0 05 89 67 45 23 11 fd .......gE#..
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_set_freq: ack NG (0xfa), len=1
set_freq: error = Command rejected by the rig
Rig command: F
Frequency: 123456789
TX 12 bytes
0000 ff fe fe 08 e0 05 89 67 45 23 01 fd .......gE#..
RX 12 bytes
0000 ff fe fe 08 e0 05 89 67 45 23 01 fd .......gE#..
RX 6 bytes
0000 fe fe e0 08 fb fd ......
Rig command: f
TX 7 bytes
0000 ff fe fe 08 e0 03 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 03 fd .......
RX 6 bytes
0000 fe fe e0 08 03 00 ......
RX 1 bytes
0000 67 g
RX 1 bytes
0000 45 E
RX 1 bytes
0000 23 #
RX 1 bytes
0000 01 .
RX 1 bytes
0000 fd .
Frequency: 123456700
---
Checking getting modes:
This radio is a bit weird in that rather than computer controllable USB and
LSB, it has a computer controllable "SSB" mode. In the US version there is a
mechanical USB/LSB switch on the back of the radio. I believe the international
version is USB only. (I guess they assumed very few people use LSB above 25
MHz.)
It reports the SSB mode as 0500. Not to be confused with FM(wide) 05 (and maybe
0501), and FMnarrow 0502.
Not sure how much special case code you want for the r7000 because it's
different from every other icom rig.
If you do want to have special code for the R7000, but don't want to create a
separate "SSB" mode, get_mode could return USB, and set for either USB or LSB
could set the radio to SSB. And leave it up to the controlling software to care
if it wants to.
(there is also a mechanical switch on the back that switches both FM modes to
even wider. That should probably be ignored)
AM: good
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 02 ......
RX 1 bytes
0000 fd .
Mode: AM
Passband: 6000
FM: (FM wide) good
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 05 ......
RX 1 bytes
0000 fd .
Mode: FM
Passband: 6000
FMn: (FM narrow) good
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 05 ......
RX 1 bytes
0000 02 .
RX 1 bytes
0000 fd .
Mode: FM
Passband: 0
ssb: bad
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 05 ......
RX 1 bytes
0000 00 .
RX 1 bytes
0000 fd .
Mode: FM
Passband: 6000
---
Checking setting modes:
Looks like if you set it to what you got with get it works for AM, FM wide, and
FM
narrow. Not sure how it's supposed to work.
For SSB, I couldn't figure out how to send a 0500.
AM: good
Rig command: M
Mode: AM
Passband: 0
TX 8 bytes
0000 ff fe fe 08 e0 06 02 fd ........
RX 8 bytes
0000 ff fe fe 08 e0 06 02 fd ........
RX 6 bytes
0000 fe fe e0 08 fb fd ......
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 02 ......
RX 1 bytes
0000 fd .
Mode: AM
Passband: 6000
FM wide: good
Rig command: M
Mode: FM
Passband: 0
TX 8 bytes
0000 ff fe fe 08 e0 06 05 fd ........
RX 8 bytes
0000 ff fe fe 08 e0 06 05 fd ........
RX 6 bytes
0000 fe fe e0 08 fb fd ......
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 05 ......
RX 1 bytes
0000 fd .
Mode: FM
Passband: 6000
FM narrow: good
Rig command: M
Mode: FM
Passband: 02
TX 9 bytes
0000 ff fe fe 08 e0 06 05 02 fd .........
RX 9 bytes
0000 ff fe fe 08 e0 06 05 02 fd .........
RX 6 bytes
0000 fe fe e0 08 fb fd ......
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 05 ......
RX 1 bytes
0000 02 .
RX 1 bytes
0000 fd .
Mode: FM
Passband: 0
SSB: bad (or at least I couldn't figure out a way)
Rig command: M
Mode: FM
Passband: 00
TX 8 bytes
0000 ff fe fe 08 e0 06 05 fd ........
RX 8 bytes
0000 ff fe fe 08 e0 06 05 fd ........
RX 6 bytes
0000 fe fe e0 08 fb fd ......
Radio was set to FM wide rather than SSB.
Rig command: m
TX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 04 fd .......
RX 6 bytes
0000 fe fe e0 08 04 05 ......
RX 1 bytes
0000 fd .
Mode: FM
Passband: 6000
Let try USB/LSB:
Note: 06 01 and 06 02 do not work on this radio. See above.
Rig command: M
Mode: USB
Passband:
0
TX 8 bytes
0000 ff fe fe 08 e0 06 01 fd ........
RX 8 bytes
0000 ff fe fe 08 e0 06 01 fd ........
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_set_mode: ack NG (0xfa), len=1
set_mode: error = Command rejected by the rig
Rig command: M
Mode: LSB
Passband: 0
TX 8 bytes
0000 ff fe fe 08 e0 06 00 fd ........
RX 8 bytes
0000 ff fe fe 08 e0 06 00 fd ........
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_set_mode: ack NG (0xfa), len=1
set_mode: error = Command rejected by the rig
---
Tuning steps are not computer controlable (set via a mechanical switch)
Rig command: n
TX 7 bytes
0000 ff fe fe 08 e0 10 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 10 fd .......
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_get_ts: wrong frame len=0
get_ts: error = Command rejected by the rig
---
Memory:
There are 99 memories.
It looks like to reading and writing to memories without going through the vfo
is not supported.
Selecting a memory (08 xx) is supposed to work.
It looks like you need to do thing like this:
To read a memory: select it with 08xx then get_freq.
To write a memory: select channel with 08xx, set_freq, then write with 09.
To clear a memory: select channel with 08xx, then clear with 0b.
(I got this from the ci-v docs. I havn't tested it yet)
I'm not sure how many radios do things like this. Therefore I'm not sure if
hamlib should support this directly, or through a higher level routine that
looks at the rig capabilities and does this if need be, or leave it up to the
user software.
---
Select blank memory from front panel and attempt to get_freq: bad
Note: CI-V docs say frequency FF is a blank memory.
Rig command: f
TX 7 bytes
0000 ff fe fe 08 e0 03 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 03 fd .......
RX 6 bytes
0000 fe fe e0 08 03 ff ......
RX 1 bytes
0000 fd .
icom_get_freq: wrong frame len=1
get_freq: error = Command rejected by the rig
Select memory channel 01: bad
Note: This radio has 99 memories. The CI-V docs I have say to select memories
less than 100, use only 1 byte (two digits). Should this be 08 01 fd?
Rig command: E
Memory#: 01
TX 9 bytes
0000 ff fe fe 08 e0 08 00 01 fd .........
RX 9 bytes
0000 ff fe fe 08 e0 08 00 01 fd .........
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_set_mem: ack NG (0xfa), len=1
set_mem: error = Command rejected by the rig
Attempt to read channel 01: bad
Note: Command 1a not supported by this rig. Don't know if this should just be
unavailable or implemented as described above.
Rig command: h
Channel: 01
TX 10 bytes
0000 ff fe fe 08 e0 1a 00 00 01 fd ..........
RX 10 bytes
0000 ff fe fe 08 e0 1a 00 00 01 fd ..........
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_get_channel: wrong frame len=0
get_channel: error = Command rejected by the rig
---
Setting Mode to memory: bad
Docs say it should work. There is also a M-SET momentary button on the front
panel that when depressed selects the freq from the current memory channel
rather
than the vfo. When released it switches back. I'll have to read the manual on
this one. :)
Rig command: V
VFO: MEM
TX 7 bytes
0000 ff fe fe 08 e0 08 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 08 fd .......
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_set_vfo: ack NG (0xfa), len=1
set_vfo: error = Command rejected by the rig
Setting mode to vfo: not supposed to be supported
Doc's say this isn't supported.
Rig command: V
VFO: VFO
TX 7 bytes
0000 ff fe fe 08 e0 07 fd .......
RX 7 bytes
0000 ff fe fe 08 e0 07 fd .......
RX 6 bytes
0000 fe fe e0 08 fa fd ......
icom_set_vfo: ack NG (0xfa), len=1
set_vfo: error = Command rejected by the rig
---
I guess there isn't anything to report.
Rig command: _
Info: None
---
Dumpcaps:
A few notes on the right.
[kmh@swami tests]$ ./dumpcaps 340
rig: loading backend icom
icom: _init called
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (319)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (334)
rig_register (344)
rig_register (340)
rig_register (342)
rig_register (304)
rig_register (307)
rig_register (300)
Rig dump for model 340
Model name: ICR-7000
Mfg name: Icom
Backend version: 0.2
Backend copyright: LGPL
Backend status: Untested
Rig type: Receiver
PTT type: None
DCD type: None
Port type: RS-232
Serial speed: 300..19200 bauds, 8N1 I'll have to check the manual for the
specs.
Factory default is 1200
Write delay 0ms, timeout 200ms, 3 retry
Post Write delay 0ms
Has targetable VFO: no
Has transceive: yes
Announce: 0x0
Max RIT: -9.999kHz/+9.999kHz Don't see this, I'll have to check the
manual in a few days.
Max XIT: -0.0kHz/+0.0kHz
Max IF-SHIFT: -0.0kHz/+0.0kHz
Preamp: 10dB Don't think it has one
Attenuator: 20dB
Get functions: Don't think it has any functions/levels
Set functions: FAGC NB TSQL APF
Get level: PREAMP ATT SQL APF AGC SQLSTAT STRENGTH
Set level: PREAMP ATT SQL APF AGC
Get parameters:
Set parameters:
Number of banks: 12 Looks like it has 1 bank of 99
memories.
Memory name desc size: 0
Memories: none
TX ranges status, region 1: OK (0)
RX ranges status, region 1: OK (0)
TX ranges status, region 2: OK (0)
RX ranges status, region 2: OK (0)
Tuning steps:
100Hz: AM USB LSB FM WFM
1kHz: AM USB LSB FM WFM
5kHz: AM USB LSB FM WFM
10kHz: AM USB LSB FM WFM
12.5kHz: AM USB LSB FM WFM
25kHz: AM USB LSB FM WFM
Tuning steps status: OK (0)
Filters: Have to check on filters
2kHz: USB LSB
15kHz: AM FM
6kHz: AM FM
150kHz: WFM
Has priv data: Y Not sure what these are
Has init: Y
Has cleanup: Y
Has open: N
Has close: N
Can set conf: Y Not sure what these are
Can get conf: Y
Can set frequency: Y
Can get frequency: Y
Can set mode: Y
Can get mode: Y
Can set vfo: Y
Can get vfo: N
Can set ptt: N
Can get ptt: N
Can get dcd: N
Can set repeater duplex: N
Can get repeater duplex: N
Can set repeater offset: N
Can get repeater offset: N
Can set split freq: N
Can get split freq: N
Can set split mode: N
Can get split mode: N
Can set split: N
Can get split: N
Can set tuning step: Y Not computer settable
Can get tuning step: Y Not computer settable
Can set RIT: N
Can get RIT: N
Can set XIT: N
Can get XIT: N
Can set CTCSS: N
Can get CTCSS: N
Can set DCS: N
Can get DCS: N
Can set CTCSS squelch: N
Can get CTCSS squelch: N
Can set DCS squelch: N
Can get DCS squelch: N
Can set power stat: N
Can get power stat: N
Can get reset: N
Can get ant: N
Can set ant: N
Can set transceive: N
Can get transceive: N
Can set func: Y Don't think it has any
functions/levels
Can get func: N
Can set level: Y Don't think it has any
functions/levels
Can get level: Y Don't think it has any
functions/levels
Can set param: N
Can get param: N
Can send DTMF: N
Can recv DTMF: N
Can send Morse: N
Can decode events: Y
Can set bank: N
Can set mem: Y
Can get mem: N
Can set channel: Y See notes on memory above
Can get channel: Y See notes on memory above
Can ctl mem/vfo: Y See notes on mem/vfo above
Can scan: N
Can get info: N
Overall backend warnings: 0
|
|
From: Stephane F. <f4...@fr...> - 2002-03-05 00:43:27
|
On Sat, Mar 02, 2002, Chuck Hemker wrote:
> First, I wish to apologize. My friend has an Icom 970, not a 910. If someone
> would be kind enough to create an entry for a 970, I'll happily test it when I
> get over there.
done. However, I'm not sure about what feature this rig has. To be tested.
> Just think of it as being nice to the future users of the 910. :)
Sure, and Francois will use it I guess.
> Now for the Icom R-7000:
>
> > Chuck, could you confirm this is 0x08 for the R-7000?
>
> Yes it is.
good.
> other people. If you want any help implementing any of this let me know. I'm
> getting better at my understanding the internals to hamlib and I could probably
> figure out how to do a bunch of this.
The internal of Hamlib are not very well documented to say the least. We
try to use common sense, so it's self documented :) However, feel
free to ask questions, it sometimes help showing off errors in API design,
etc.
> 2. The default for the speed of the CI-V bus seems wrong. The hamlib default
> serial speed is the max speed of the radio. According to the CI-V docs
> that I have, the factory default serial speed for CI-V is 1200 bps. My
> radio also happens to be 1200. I'll try to find out if it is settable and if
> so to what values.
okay, fixed. Let me know if it can be set higher.
> What I'm wondering is if there should be some sort of default speed for a
> radio which could be set to the factory default rather then defaulting to
> the max speed. Or maybe this should just be rolled into the future
> preferences file mentioned in the TODO file.
yep. The min and max are there to check bounds. The preference file should
be pretty easy to implement, but I reserve that for 1.1.4.
> Because of this, I couldn't run either testtrn or dumpmem to test them.
testtrn and dumpmem are developer's limited test programs. rigctl can dump
a single channel using 'h' aka get_channel command. And maybe I should add
support for trn in rigctl. Good idea (not done yet).
> 3. With tranceive enabled on the radio, rigctl gets confused if you do things on
> the front panel of the radio. This is because the radio sends things and the
> input buffer isn't flushed or processed before the responses from the
> commands are looked for. I ended up quiting and restarting rigctl most of
> the times I touched the radio.
A serial_flush was missing in icom_transaction. This is fixed.
> 5. In looking through riglist.h the other day, I noticed that a couple of the
> Icom radios and the Optoelectronics had duplicate numbers. This is
> probably because the Optoelectronics rigs are also CI-V controlled and
> someone added Icom rigs without noticing that the numbers were being used:
Ouch, darn copy-paste. fixed.
> 6. When installing the CVS version the other day after configuring it with a
> --prefix, I noticed that it tried to install some of the perl files in
> /usr/lib/perl5/... Not knowing the perl directory structure, I don't know if
> this is a feature or a bug.
> Work around: ./configure --without-perl-binding
Yeah, I know. There're currently 2 problems left to be fixed for the perl
binding. First one is install somewhere else than default location.
Second is support for VPATH. I'll try to come out with something.
In the mean time, --without-perl-binding is your friend.
> Now some testing with rigctl:
>
>
> set and get frequency 25-999 MHz: good
> Note: it ignores the last 2 digits on set and returns 00 on get
yep, this is the expect behaviour: truncating.
> ---
>
> set and get frequency 1025-1999 MHz: not quite right
> Note: there is a separate 1ghz switch on the front panel. When it's on, a
> "1GHz" lights up in the display and the radio tunes 1025-1999.9999. It looks
> like the computer interface doesn't know it exists. It always returns 0 in the
> ghz digit on get and errors if the ghz digit is 1 on set. I don't know if
> hamlib should care. Since I'm already supporting downconverters in my software
> for 2.4 GHz I'll probably implement it as a manually controlled downconverter
> that happens to be installed in the radio. The only thing I could see hamlib
> MIGHT want to do is to mask out the 1ghz digit so the program could ask for 1234
> MHz and hamlib sends 234 MHz to the radio. And leave it up to the user to push
> the button.
I like the idea. Will do that for set_freq in the coming days.
However, the get_freq won't have any clue to whichever position the switch
is set.
> ---
>
> Checking getting modes:
> This radio is a bit weird in that rather than computer controllable USB and
> LSB, it has a computer controllable "SSB" mode. In the US version there is a
> mechanical USB/LSB switch on the back of the radio. I believe the international
> version is USB only. (I guess they assumed very few people use LSB above 25
> MHz.)
>
> It reports the SSB mode as 0500. Not to be confused with FM(wide) 05 (and maybe
> 0501), and FMnarrow 0502.
>
> Not sure how much special case code you want for the r7000 because it's
> different from every other icom rig.
This could be implemented as r7000_[sg]et_mode in icom/icr7000.c
But it turns out it's simpler as workaround in frame.c, because the
IC-R7000 seems to be the only exception.
> If you do want to have special code for the R7000, but don't want to create a
> separate "SSB" mode, get_mode could return USB, and set for either USB or LSB
> could set the radio to SSB. And leave it up to the controlling software to care
> if it wants to.
good compromise
> ssb: bad
>
should be fixed now
> ---
>
> Checking setting modes:
> Looks like if you set it to what you got with get it works for AM, FM wide, and
> FM
> narrow. Not sure how it's supposed to work.
> For SSB, I couldn't figure out how to send a 0500.
>
> Rig command: M
> Mode: FM
> Passband: 02
^^
Arg! Passband is the real passband width in Hz!!
i.e. 6kHz for narrow AM on the IC-R7000. You're lucky the code uses <
operator to check narrow or wide :)
> SSB: bad (or at least I couldn't figure out a way)
Let me know if the fix helped a little bit.
> Let try USB/LSB:
> Note: 06 01 and 06 02 do not work on this radio. See above.
should be fixed now.
> ---
>
> Tuning steps are not computer controlable (set via a mechanical switch)
okay, removed set_ts/get_ts.
> ---
>
> Memory:
> There are 99 memories.
added to caps
> It looks like to reading and writing to memories without going through the vfo
> is not supported.
>
> Selecting a memory (08 xx) is supposed to work.
>
> It looks like you need to do thing like this:
> To read a memory: select it with 08xx then get_freq.
> To write a memory: select channel with 08xx, set_freq, then write with 09.
> To clear a memory: select channel with 08xx, then clear with 0b.
> (I got this from the ci-v docs. I havn't tested it yet)
may make sense since there's no MEM->VFO function, and the VFO->MEM looks
suspicious without 07 cmd to select VFO mode.
> I'm not sure how many radios do things like this. Therefore I'm not sure if
> hamlib should support this directly, or through a higher level routine that
> looks at the rig capabilities and does this if need be, or leave it up to the
> user software.
The user software will have to comply with a defined behaviour.
However, every rig should look the same, and memory handling should be
seamless. I'll try to come up with something.
> ---
>
> Select blank memory from front panel and attempt to get_freq: bad
> Note: CI-V docs say frequency FF is a blank memory.
bug of mine. should be fixed.
> Select memory channel 01: bad
> Note: This radio has 99 memories. The CI-V docs I have say to select memories
> less than 100, use only 1 byte (two digits). Should this be 08 01 fd?
No idea. Could this be verified from the rig manual?
> Attempt to read channel 01: bad
> Note: Command 1a not supported by this rig. Don't know if this should just be
> unavailable or implemented as described above.
oops, the IC-R7000 should use generic get_channel and set_channel.
Let me know if it's better now.
> ---
>
> Setting Mode to memory: bad
> Docs say it should work. There is also a M-SET momentary button on the front
> panel that when depressed selects the freq from the current memory channel
> rather
> than the vfo. When released it switches back. I'll have to read the manual on
> this one. :)
Dang, this rig is really, ahem, fun? :)
> Rig command: V
> VFO: MEM
> TX 7 bytes
> 0000 ff fe fe 08 e0 08 fd .......
> RX 7 bytes
> 0000 ff fe fe 08 e0 08 fd .......
> RX 6 bytes
> 0000 fe fe e0 08 fa fd ......
> icom_set_vfo: ack NG (0xfa), len=1
> set_vfo: error = Command rejected by the rig
The "selects MEMORY mode" should work according to the CI-V manual.
I'm wondering if it needs to be in some special condition to work.
> Setting mode to vfo: not supposed to be supported
> Doc's say this isn't supported.
>
> Rig command: V
> VFO: VFO
> TX 7 bytes
> 0000 ff fe fe 08 e0 07 fd .......
> RX 7 bytes
> 0000 ff fe fe 08 e0 07 fd .......
> RX 6 bytes
> 0000 fe fe e0 08 fa fd ......
> icom_set_vfo: ack NG (0xfa), len=1
> set_vfo: error = Command rejected by the rig
Alright, at least this is what was expectable, even if a pity.
> ---
>
> I guess there isn't anything to report.
>
> Rig command: _
> Info: None
right.
> ---
>
> Dumpcaps:
> A few notes on the right.
>
> [kmh@swami tests]$ ./dumpcaps 340
> rig: loading backend icom
> icom: _init called
> rig_register (309)
> rig_register (310)
> rig_register (311)
> rig_register (319)
> rig_register (330)
> rig_register (326)
> rig_register (327)
> rig_register (334)
> rig_register (344)
> rig_register (340)
> rig_register (342)
> rig_register (304)
> rig_register (307)
> rig_register (300)
> Rig dump for model 340
> Model name: ICR-7000
> Mfg name: Icom
> Backend version: 0.2
> Backend copyright: LGPL
> Backend status: Untested
> Rig type: Receiver
> PTT type: None
> DCD type: None
> Port type: RS-232
> Serial speed: 300..19200 bauds, 8N1 I'll have to check the manual for the
> specs.
> Factory default is 1200
> Write delay 0ms, timeout 200ms, 3 retry
> Post Write delay 0ms
> Has targetable VFO: no
> Has transceive: yes
> Announce: 0x0
> Max RIT: -9.999kHz/+9.999kHz Don't see this, I'll have to check the
> manual in a few days.
forget about it. This was a copy-paste from the icr-8500.
> Max XIT: -0.0kHz/+0.0kHz
> Max IF-SHIFT: -0.0kHz/+0.0kHz
> Preamp: 10dB Don't think it has one
> Attenuator: 20dB
> Get functions: Don't think it has any functions/levels
> Set functions: FAGC NB TSQL APF
> Get level: PREAMP ATT SQL APF AGC SQLSTAT STRENGTH
> Set level: PREAMP ATT SQL APF AGC
ditto
> Get parameters:
> Set parameters:
> Number of banks: 12 Looks like it has 1 bank of 99
> memories.
ditto
> Memory name desc size: 0
> Memories: none
> TX ranges status, region 1: OK (0)
> RX ranges status, region 1: OK (0)
> TX ranges status, region 2: OK (0)
> RX ranges status, region 2: OK (0)
> Tuning steps:
> 100Hz: AM USB LSB FM WFM
> 1kHz: AM USB LSB FM WFM
> 5kHz: AM USB LSB FM WFM
> 10kHz: AM USB LSB FM WFM
> 12.5kHz: AM USB LSB FM WFM
> 25kHz: AM USB LSB FM WFM
> Tuning steps status: OK (0)
> Filters: Have to check on filters
> 2kHz: USB LSB
> 15kHz: AM FM
> 6kHz: AM FM
> 150kHz: WFM
got them from the specs:
http://www.icomamerica.com/support/archive/receivers/ic-r7000a.html
> Has priv data: Y Not sure what these are
This is internal stuff of the backend, like 4 chars for freq dat, etc.
> Has init: Y
> Has cleanup: Y
> Has open: N
> Has close: N
> Can set conf: Y Not sure what these are
> Can get conf: Y
backend stuff to change the CI-V address when talking to the rig, etc.
> Can set frequency: Y
> Can get frequency: Y
> Can set mode: Y
> Can get mode: Y
> Can set vfo: Y
> Can get vfo: N
> Can set ptt: N
> Can get ptt: N
> Can get dcd: N
> Can set repeater duplex: N
> Can get repeater duplex: N
> Can set repeater offset: N
> Can get repeater offset: N
> Can set split freq: N
> Can get split freq: N
> Can set split mode: N
> Can get split mode: N
> Can set split: N
> Can get split: N
> Can set tuning step: Y Not computer settable
> Can get tuning step: Y Not computer settable
ok, removed.
> Can set RIT: N
> Can get RIT: N
> Can set XIT: N
> Can get XIT: N
> Can set CTCSS: N
> Can get CTCSS: N
> Can set DCS: N
> Can get DCS: N
> Can set CTCSS squelch: N
> Can get CTCSS squelch: N
> Can set DCS squelch: N
> Can get DCS squelch: N
> Can set power stat: N
> Can get power stat: N
> Can get reset: N
> Can get ant: N
> Can set ant: N
> Can set transceive: N
> Can get transceive: N
> Can set func: Y Don't think it has any
> functions/levels
> Can get func: N
> Can set level: Y Don't think it has any
> functions/levels
> Can get level: Y Don't think it has any
> functions/levels
ok, removed.
> Can set param: N
> Can get param: N
> Can send DTMF: N
> Can recv DTMF: N
> Can send Morse: N
> Can decode events: Y
> Can set bank: N
> Can set mem: Y
> Can get mem: N
> Can set channel: Y See notes on memory above
> Can get channel: Y See notes on memory above
> Can ctl mem/vfo: Y See notes on mem/vfo above
removed icr8500 specific set_channel/get_channel.
mem/vfo can do : RIG_OP_FROM_VFO and RIG_OP_MCL
> Can scan: N
> Can get info: N
>
> Overall backend warnings: 0
>
Thank you very much Chuck for this high quality testing. Let me know how
the new cvs version works on your rig.
Phew, that was a good report!
cu agn
Stephane F8CFE
|
Thanks for helping keep SourceForge clean.
X