> > For these radios, should frequency be seen to be changing on
> > polling, maybe skip a poll here & there, then resume hitting it
> > with every poll when the received frequency stops changing?
>The radio does not respond to the requests for frequency information
>when the VFO knob is being turned. It saves them all up until the
>knob stops turning, then all of them get responded to.
>So - TR doens't know that the frequency is changing - it just knows
>that there doesn't appear to be a radio hooked up to the computer
>any more. TR could be smart and stop polling the radio - until it
>gets an answer from a previous request - but that really doesn't
>change what happens from the user's perspective.
> > Maybe it wouldn't be so bad if so many polls didn't get queued up
> > in the rig. Compared to no updates, slightly delayed update of
> > displayed frequency with quicker recovery when tuning stops
> > seems preferable. No doubt it wouldn't be as simple as that. ;^(
>It doesn't seem to take long for all of the responses to come back.
If I increase KENWOOD RESPONSE TIME, things seem to get
better, but there is still variability in the amount of time that the
program recovers from a period of tuning the rig, with that amount
of time being some numbers of multiples of KENWOOD RESPONSE
Without watching the data going back & forth between the two to
be sure, it seems almost like sometimes the radio might be better
off if it hadn't have been polled or polled as many times during tuning.
Maybe determining tuning is taking place when so much change in
frequency is seen since the last poll & implementing something like
this is not so simple as it seems to this layman. I could even be
wrong about what I think I'm seeing going on... ;^)
Trlog mailing list