Rig support for 9600 BAUD packet

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.

For some, mostly timing related, measurements at the RF interface I used a Rohde & Schwarz FSB spectrum analyser in Zero span mode, with sweep triggered by the PTT line fed into the rig.

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 peak deviation was employed in all scenarios where a modulated signal was generated.

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. All rigs were tested in the 70cm band, at a frequency of 432.625MHz.

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.

The top trace shows PTT being released at the end of a transmission (the RX frequency already has a modulated signal present). Bottom trace shows the demodulated output arriving from the rig as it recovers.

This is a zoomed in version of the section where modulation starts appearing. It takes about 66ms before the demodulation is present and stabilised.

The FT-7800 takes about 90ms to return to RX and stabilise.

Again the Tait is very fast. About 18 or 19ms before the RX is stable.

If we compare the waveform modulating the rig under test with that emerging from the demodulator of the R&S test set, bearing in mind that there's some delay in the chain, it's possible to spot whether the modulation is inverted in polarity or not. This might be the most significant thing we've measured here. “Normal”, in this context, refers to the convention mentioned in the NinoTNC documentation, where a rising voltage coincides with rising frequency at the RF interface.

Through a similar process of comparing the polarity of the signal modulating the R&S test set with the resulting demodulated signal from the rig under test we can examine the polarity of the demodulated signal from the rig

It seemed prudent to record the signal levels for each radio at a nominal 2.4 KHz deviation, for both RX and TX.

Many of these measurements have probably not unearthed anything significant, but in going through this exercise we have developed a suite of measurements that can be easily carried out and which characterise a rig comprehensively from a point of view of its suitability for 9k6 packet. We've also created some benchmark measurements from a “Gold standard” radio, as far as 9k6 packet is concerned, and from two popular rigs from the “big three”. These can be used in future to compare the performance of other rigs.

I fully expected to see issues with narrow IF bandwidth, from which there would probably be no escape other than possibly to fit the rig with an alternative IF filter and deal with any consequences of doing so. Both commercial rigs use the Murata CFWM450E, which is a 15kHz bandwidth IF filter. It's probably on the narrow side of “OK” for 9k6 packet but the eye diagrams obtained from both rigs were at least as good as from the Tait. With tight IF filtering does come a requirement to ensure good frequency accuracy on both ends of the link, however.

We have seen significant variations in the RX-to-TX and TX-to-RX settling times between the radios, and the Tait is especially good in this regard. A link “optimised” by cutting TXDELAY to the bone until two Taits start to degrade will have poor interoperability with commercial radios. The Tait has been deliberately engineered for good performance in this area and this is not something that's a priority for most rigs on the amateur market. A TXDELAY of around 150ms is probably about the minimum to be recommended for good interoperability. Consideration of the turn-around times measured here would also be prudent when setting SLOTTIME and TXTAIL settings. In particular, the Tait has significant delay in the audio signal paths probably resulting from digital processing of the audio signals. Care needs to be taken to ensure the tail of a packet is not truncated by too keen a TXTAIL timing.

Modulation polarity might well be the issue here. This has not historically been an issue with the classic G3RUH modulation scheme because differential encoding is employed, so the polarity of the signals is not significant. This is not the case with IL2P. There also appears to be no convention concerning the polarity of the signals at the DATA interface of commercial rigs. Perhaps some tolerance of inverted received signals needs to be built into IL2P TNCs?

To be continued…