This page is currently a WIP. Please revisit for updates! Kevin G7BCS

This is going to get TL;DR, however, it might be interesting… Once I've arrived at some conclusions I'll create a less wordy summary, the aim being to make 9600 BAUD packet more accessible by discovering some of the issues around using 9600 BAUD packet with commercial off-the-shelf rigs.

I've been on a bit of a journey trying to get 9600 BAUD packet working, especially with off-the-shelf commercial rigs allegedly 9k6 packet capable via their “data” connector. This has been resolved, for me, thanks to Tom M0LTE, who sourced a Tait radio which “just worked”. Such radios are hard to find and costly, however, so I feel that, if we can better understand the problems with commercial rigs on 9k6 packet, we can increase uptake of this mode and speed our packet network up considerably.

9600 BAUD packet, whether using the legacy G3RUH mode or IL2P, uses direct FSK modulation of the carrier as opposed to the more usual 1200 BAUD AFSK modulation whereby audio tones transmitted by the radio are modulated in frequency. The upshot of this is that the audio path through both transmitter and receiver needs to be pretty much flat from almost DC to at least the maximum modulating frequency of 4800Hz, and probably beyond this to around 6 KHz, to work well. It's no longer just carrying the 1200 or 2200 Hz AFSK tones but the complete spectrum resulting from the FSK modulating waveform. This isn't going to work via the rig's usual audio signal path, which will be band limited to 300Hz - 3kHz and include some pre-empasis and de-emphasis.

It used to be commonplace to modify rigs to directly modulate the transmitter using a varactor, and to take the demodulated signal directly from the receiver's discriminator for this reason. Later, manufacturers started adding a DATA connector (usually a 6 pin mini-DIN) to bring out 9600 (and 1200) packet capable signal paths. There doesn't appear to be much standardisation of the characteristics of this connection, however.

I had tried at least 3 commercial rigs for 9k6 packet using a Nino-TNC and a simple connection to the DATA connector. None of these even remotely worked. I got the odd packet through, but nowhere near enough to hold a L2 connection, let alone exploit the speed of 9k6 packet properly.

I set about measuring the performance of each of the rigs I had at my disposal, including the Tait, hoping to find something to explain the poor performance, perhaps even something that could be fixed with a simple modification.

I had a think about what factors might affect a rig's compatibility with 9600 BAUD packet. This gave me some ideas on the things I needed to measure to find, and, hopefully, resolve, blocking issues for 9k6 packet:

1. Modulation frequency response (on Transmit)
2. Demodulation frequency response (on Receive)
3. Receiver phase response and group delay
4. Receiver sensitivity to frequency error
5. Transmit delay and settling time
6. Receive delay and setting time
7. Modulation polarity
8. Demodulation polarity

The first few items are easy enough to test, but once we get to items such as the phase response and group delay of the receiver, it becomes less easy. Many had speculated that “too tight” receiver filtering on commercial rigs designed primarily for the now commonplace 12.5 kHz channel spacing was to blame for poor 9k6 performance, so I thought it necessary to try to capture this somehow. I decided to recreate an eye diagram of the received signal to check the lilkelihood that 9k6 operation would be possible. It's a more subjective test than the others, but one that, I felt, would capture issues that might not be found with more objective tests.

I'm fortunate in having a fair bit of test equipment and, for the majority of the measurements and tests, I used a Rohde & Schwarz CMTA radiocomms analyser. This is a rather long-in-the -tooth “swiss army knife” for testing mobile radios and ideal for this application. It works in both RX and TX test modes. In the former, it can generate a signal at a confugred frequency and level, modulation with a defined deviation can be applied from either one or both of its internal audio generators or an external source, and it can analyse the corresponding demodulated audio from the radio. In TX test mode, it can generate audio for modulating the radio under test, and measure the frequency, transmit power, modulation depth and it can provide an output of the demodulated signal.

One of the problems with “soft” TNCs such as the Nino and Direwolf is that you can't get to the signals needed to observe the “eye” and make a subjective check of whether a received signal is likely to be demodulated successfully. For these tests, I used an old G3RUH modem in test mode, where it transmits pseudo-random bits from its scrambler, to both generate a signal to modulate the R&S test set, and to recover the clock from the received signal from the radio under test to allow an eye diagram to be observed on an oscilloscope. 2.4 kHz deviation was employed.

The three rigs I tested were the Tait TM8200, an Icom IC-E208 and a Yaesu FT-7800. The latter two had both failed to perform at 9k6. The former is well proven to work flawlessly. I had previously also tried a Yaesu FT-817 on 9k6 packet, unsuccessfully, more to have another sample than anything else, but since this radio is limited to 5W TX power, and also uses relays to switch the signal path from RX to TX, I didn't proceed further with this rig, since 9k6 packet will never be its forte.

There isn't really much between these 3 radios here. The Tait is the best, with a pretty much flat response within 0.5db out to 10kHz. The Icom is down 0.5db at 5kHz and 1.8db at 10kHz. The Yaesu isn't as good, rolling off at the LF end by about 1.2db at 50Hz and rolling off 0.5db at 2kHz, 3db at 5kHz and 7db by 10kHz. All three are probably Ok for 9k6 packet with the Yaesu looking a little marginal.

The Tait and Icom have rolled off by less than 1.5db by 5kHz and the Yaesu about 2.5db. They all roll off quite steeply beyond this, probably because the IF bandwidth is limited, but this should be good enough for 9k6 packet.

The “eyes” for each rig looked fine, with that from the “proven good” Tait looking a little more ragged than the other two contenders, if anything. These eye patterns are at about -100 dBm (about an S5 indicated signal strength).

Again, a bit of a subjective measurement. I swept the frequency of the generator in the R&S test box over a range of 2 or 3 kHz either side of the nominal frequency to check what effect it had on the “eye”. It started to close up at more than 2 kHz offset but wasn't too noticeable below that, for any of the rigs. I had used the service menus in the commercial rigs to correct any serious frequency error before the tests. Since the modulation is likely to fill the IF passband of any receiver, it's important that any rig used for 9k6 packet has its frequency reference set as accurately as possible to ensure the IF passband is centred on the signal as accurately as possible.

The “overs” are short for 9k6 packet so agility in switching from RX to TX, including frequency settling and time taken for the modulation to stabilise are likely to be important, or at least need to be known so the local and remote TXDELAY and TXTAIL, SLOTTIME, etc. parameters can be chosen accordingly.

I used a function generator to drive the PTT line so I could cycle the radio between TX and RX and, in addition, trigger both a 'scope and a spectrum analyser from these signals so the timing between PTT going over and activity and the rig's RF and audio interfaces could be established.

When examining modulation at the RF interface, the rig was fed with a tone to the modulation input and this was “slope demodulated” by offsetting the spectrum analyser passband in zero span mode to confirm after what period the modulation looked present and stable.

The IC-E208 seems to take about 80ms for the TX power and modulation to stabilise following PTT.

The FT-7800 is a bit slower, at about 112ms worst case. The timing was cycling around a bit, suggesting that the internal CPU polls the PTT line periodically. 112ms is about the worst case.

The Tait is excellent. Stabilised and transmitting modulation well inside 20ms from PTT being asserted.

To be continued…