[TRLog] More Icom Radio Delay
KL7RA
kl7ra@blizzard.gcgo.nasa.gov
Wed, 1 May 2002 07:17:08 -0800
Mike writes:
> I see my that I did not communicate my problem clearly!
> People are talking about tuning the radio then typing a call and hitting
>the space bar which with the 1 second delay is workable.
>What I was use to doing with CT was using the frequency readout
>(bandmap) on the monitor screen as a tuning indicator. I was able
>to tune by a frequency (quickly) and figure out the station ID without
>typing a call or waiting for the station to ID (because I had the call in
>the band map) in this case a 1 second delay is not acceptable.
>
> Mike W9RE
Hi Mike
I ran some tests with TR and a 781 this morning after our private e-mails
on this subject, and you are correct.
For a test I loaded the bandmap with a call every 1 KHz for 5 KHz. Then
tuning the radio, as you suggest in a slow and steady rate, no calls blink
as you go through. The reason is easy to see as the freq stays frozen
until you stop moving the dial.
CT did follow the 781 dial but it uses the IRQ feature. My operating style
is such that I stop often and listen for a second or two so I have never
noticed this to be a problem. I can see where it would be for you.
The Icom Pause and Timeout commands are for outgoing so no use here.
The poll rate is default at one second and the program will not set below
that. With the bandmap guard freq open to 400 Hz vs 200 I was able to
"blink" every call, but again having to pause.
The problem in the past was Icom would download a bad read and
throw the program off into the light band. Tree added a software Icom
filter that makes sure the freq is correct before sending it on into the
program. This is probably why the freq does not update until the dial stops.
He has to wait until the data is stable.
Never the less Icom does work with CT so I suppose it should with TR
as well, just programming...
73 Rich KL7RA