Even thought I had all signals from FT817 that it was not accepting data faster than 1 : 90ms, I wanted to be sure that the radio was not tuning on the missed "steps" and simply not updating the display.
As a mater of fact, the main dial knob accepts updates much faster than one every 90-100 milliseconds.
I set up a simple test using a real-time spectral analysis software (Argo in this case was more than enough), and tuned a carrier at 500 Hz audio. Then let my CATspeedTest firmware run 10x 100 Hz increments at decreasing intervals. The first screen capture compares side-by-side the automatic re-tuning result at 90 and 80 ms intervals:
How to read the picture. Time goes up Y axis: the lower the older. X axis has audio frequency. Color from dark black to bright white indicate signal intensity. So in the 90ms square box, it begins at 500 Hz, counts 10 steps to 1500 Hz beat frequency: 9 dots are clearly visible (plus the last -10th- jump becoming a straight line). The 80ms box shows that the first increment is accepted, then the second is skipped, third accepted and so on. Since only odd commands are accepted, the end frequency is 900 Hz above the starting point (400 + 900 = 1400 Hz) instead of +1000 Hz.
The test continued and at about 30ms intervals between increases it was still taking odd command sequences. At 20ms intervals it accepted one every three commands, so +100, +400, +700 and +1000 Hz ending up at the correct VFO frequency but skipping too many steps: imagine what would you miss if the required step was 500 Hz or 1kHz.
The upmost trace in the second picture shows what happens at ~10ms delay, where even more steps/commands are lost.
My guess is that the FT817 CPU is polling the CAT serial line every 90ms or thereabout. Nothing is mentioned in the documentation, except for a maximum time between bytes of each command sequence: "All commands sent from the computer to the transceiver consist of five-byte blocks, with up to 200 ms between each byte."
No comments:
Post a Comment