At 10:29 PM 2002/03/02 -0600, George, W5YR wrote:
>Larry, thanks for your info and viewpoint.
>
>But, why does using an external keyer avoid the problem?
because the Scout VFO is still shifting frequency from key up to key down
and the time in key up is inadequate to get the count done.
>I am afraid that I don't follow this one . . . see comments below.
>
>Larry Kayser wrote:
> >
> > Re Scout
> >
> > W5YR offers.....
> >
> > "So, taking the keying task away from the cpu by using an external keyer
> > allows the cpu enough time to deal adequately with drift control."
> >
> > Wrong answer. The CPU has enough time but the VFO shifts frequency from RX
> > to TX and there is not enough time to count the VFO frequency during the RX
> > period to set the correction voltage up. Eventually things reach their
> > limits and the thing jumps frequency in the direction of drift.
>
>If "there is not enough time to count . . ." why do you say that my quoted
>statement is wrong?
The cpu could easily do the count, the issue is that the VFO Time slot
available to do the count is less than the minimum time needed. It is a
time problem not a CPU problem.
> Without the need to deal with code elements/characters,
>the CPU *would* have time to count, etc. Hence, an external keyer allows
>the CPU adequate time for frequency management. Right?
No, again, the TIME available, key up, between CW (key down) code elements
is INADEQUATE to get the counting of the VFO frequency done.
>How can "The CPU has enough time . . ." be true when "there is not enough
>time to count the VFO frequency during the RX period . . ." ? Doesn't that
>mean that the CPU is, in fact, too slow to handle both keying and frequency
>management when keying speed reaches or exceeds about 25 wpm?
No again, the CPU can do the job if there is enough TIME with the key up to
get the job done. The TIME interval is to short, there are not enough
cycles of the 2.n MHz VFO signal, with the key up, to get the Count
interval done. Put in the inverse there are to many cycles of the VFO
signal in the TX mode, key down mode if you will - the CPU measures the VFO
frequency ONLY when the key is UP. Since there is no certain knowledge of
how long the key is DOWN the CPU is inhibited from counting during the KEY
DOWN interval.
There are alternatives, the BFO could have been shifted to achieve the same
result.
>
> > The circuit is in fact excellent, the concept is excellent, the change in
> > VFO frequency from RX to TX is what screws up the process. There is not a
> > simple way to keep the VFO on one only one frequency unless one was to
> > switch the BFO frequency as an alternative. There were design options, I
> > have figured out three of them - there may be gotcha's in the alternative
> > designs as well.
>
>I gather then that because the CPU is not fast enough to count the VFO
>frequency during the RX period,
NO. The CPU automagically fast enough, if it can do it with the RX on
continuously then it can do it anytime, there is not enough time for the
minimum key up window period, the CPU counting interval of time, is greater
than the key up interval.
> that is why slow keying with more space
>between code elements and perhaps longer periods of not transmitting gives
>the CPU "time" to catch up and put the PTO back on frequency.
No, again the CPU can do the job, the problem - ie the interval of time
available during the key up period, is less than the CPU has been
programmed to require as a minimum window interval of valid signal.
>Larry, it sounds like you are infinitely more familiar with this rig and
>its problems than I am, so I defer to your opinion, but I sure don't
>understand what you are saying. <:}
George:
I am programming a PIC here at the moment to read the RPM of my boat engine
for commuting to the mainland and back. The interval to measure RPM,
Revolutions per Minute, or Revolutions / Minute, would mean I would in
simple terms have to wait a whole minute to measure the RPM's. That is not
realistic so what I have chosen to do is Measure the Engine revolutions
over 1 second intervals. Then I take the integer value of revolutions in 1
second and do a translate in software to the number of revolutions that
would have occurred in 1 minute, I express, ie display, the measured units
as RPM's. IF HOWEVER I NEVER ALLOWED THE CPU A WHOLE SECOND BUT ALWAYS
ALLOWED EVEN SLIGHTLY LESS THAN A FULL SECOND I WOULD NOT GET ANY DISPLAY
AT ALL. This is the Scout problem.
Regards
Larry
|