Re: [Hamlib-developer] Icom R7000 report
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
Re: [Hamlib-developer] Icom R7000 report
|
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
|
