Transceiver timing in Linrad for QSK and RADAR.
(July 29 2008)

Keying a transceiver in QSK/RADAR mode.

From the operators point of view the ideal transceiver would start to transmit immediately when the key is pressed and it would give full receive sensitivity immediately when the key is released. In order to avoid keying clicks and an excessive bandwidth that would be harmful to other band users, a small delay of about 1 ms is necessary to allow the power to ramp up and down in a controlled fashion.

Having a standard PC computer in the system will add time delay however and many systems add a delay that is too long for the operator to listen to his own keying on the loudspeaker output of his computer. To be able to listen in the gaps between dots and dashes it is desireable to have a total time from key-down to tone in the loudspeaker in the order of 50 ms or less.

In Linrad the keying is arranged with a tone into the microphone input so the total delay is the delay of four soundcard devices plus the processing delay of Linrad itself. The figure below shows the Linrad screen with a pulse generator sending 2.5 ms pulses into an analog switch (74HC4053) at a repetition rate of 10Hz. The analog switch is used to key a 8 kHz tone into the microphone input. A signal on 144.030 is picked up by the antenna while Linrad is transmitting pulses on 144.028 MHz.

The S-meter graph has a time scale of 600 pixels for the 0.1 seconds between two pulses. One can clearly see that the input is muted well before the pulse starts and that full receive sensitivity is obtained 7 pixels = 1.2 milliseconds after the point where the output power has fallen by 3 dB. The Linrad screen indicates that the time delay from antenna to loudspeaker is 49 ms, but one can not really trust that because additional delays in the soundcard drive routines might be present.

The oscilloscope image below gives the full picture. The upper trace is the 2.5 ms pulse that repeats at 10 Hz. The second trace is the 8 kHz audio that is sent into the microphone input. The third trace is the transmitted pulse on 144 MHz picked up by a directional coupler at the driver level while the lowest trace is the loudspeaker output.



The delay from the keying input to the antenna is 11 ms and the delay from the antenna to the loudspeaker output is 53 ms for a total delay of 64 ms. This is fast enough for me to do normal hand keying while listening to the loudspeaker output. At a delay of 150 ms hand keying is very difficult. One automatically adds one extra dot because what reaches the ear is synchronized with the hand but delayed by one Morse code clock cycle. I have no problems to do hand heying at a modest speed with delays up to 100 ms so there is some margin for applying narrower filters. As can be seen in the baseband graph, the separation between the FFT bins in the baseband spectrum is about 50 Hz which means that the narrowest baseband filter one can select is about 200 Hz. The size of the baseband FFT is 512 as indicated by the number 7 in the upper right corner of the baseband spectrum. Better baseband filters affect the delay like this:
   Size    Delay
 512 = 27  60 ms
1024 = 28  75 ms
2048 = 29 105 ms
The microphone input is an Ensoniq AudioPCI ENS1371 soundcard sampling at 48 kHz. The transmitter output and the receiver input is a Delta 44 soundcard sampling at 96 kHz while the loudspeaker output is an Intel ICH5 with ALC655 sampling at 48 kHz. The computer is a 2.67 GHz Pentium IV running ALSA v1.0.12rc1 under Debian Etch with the 2.6.18-6 kernel. The parameter for max DMA rate is set to 500 Hz and all the sound card drivers run at a DMA interrupt rate of 375 Hz which means that the delay caused by the input and output buffering is at least 4*2.667 ms. The first FFT bandwidth is set to 200 Hz and the CPU load is about 8%.

Running soundcards in duplex mode.

It is possible to use only two soundcards and run either the ENS1371 or the ICH5 in duplex mode for microphone and loudspeaker. It may however be difficult to find out what mixer program to use and how to set the controls properly. A common problem is that the signal sent to the loudspeaker will appear in the microphone input or the signal sent to the microphone input will appear on the loudspeaker output. Problems with the mixer programs are common, particularly under Windows. Not only missing control buttons, but also various bugs. "Cheap motherboard soundcards" have a poor reputation, but it seems to me that the problem is bad software and not the soundcard hardware.

Comparison between soundcards.

These soundcards work well for separate input or output as well as for simultaneous input and output:

Audigy SE Model number SB0570
Ensoniq AudioPCI ENS1371 Model number CT4810
Ensoniq AudioPCI ENS1371 Model number CT5803
Intel ICH5 with Realtek ALC655 sampling at 48 kHz.

These soundcards have problems:

Aureal Vortex au8820. If this card is used together with the Intel ICH5, then the Delta 44 disappears from the system. This card works properly in duplex.
Yamaha YMF724PCI. ALSA does not recognize this card.
C-Media PCI CMI8738. The microphone input signal is always present in the loudspeaker output. If this card is used together with the Intel ICH5, then the Delta 44 disappears from the system.
SB Live EMU10K1 Model number CT4780. Depending on which PCI slot the card is inserted in the behaviour differs. In some positions it causes the Delta 44 to disappear from the system. It works for receive but when an attempt to open the microphone input is made, the system crashes with a segfault. With alsa-oss the system does not crash, but the Delta 44 looses data when the tx side is turned on.

All problems seem to be related to bugs in ALSA. Under RedHat 9, kernel 2.4.20, with 4Front OSS vers 3994c the combination Delta 44, ICH 5 and SB Live works perfectly well. The CPU load is about 5% but the time delay is about 115 ms with the same parameters that give 65 ms with ALSA. When using the ICH 5 for both input and output the delay drops to 105 ms.

Mandriva 2006 with kernel 2.6.12 and 4Front OSS vers 3.99.4c behaves exactly as RedHat 9.