Differences

This shows you the differences between two versions of the page.

--- packet:9k6-rig-support [2024/01/14 22:37] – [Receiver sensitivity to frequency error] g7bcs
+++ packet:9k6-rig-support [2025/03/16 16:53] (current) – g7bcs
@@ Line 39: / Line 39: @@
 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.
+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 Rigs =====
-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.
+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.
 ===== The Measurements =====
@@ Line 85: / Line 87: @@
 === IC-E208 ===
 {{:packet:ice208txdelay.jpg?nolink&400|}}
 The IC-E208 seems to take about 80ms for the TX power and modulation to stabilise following PTT.
 === FT-7800 ===
 {{:packet:ft7800txdelay.jpg?nolink&400|}}
 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.
 === Tait ===
 {{:packet:taittotxclose.jpg?nolink&400|}}
 The Tait is excellent. Stabilised and transmitting modulation well inside 20ms from PTT being asserted.
 ==== Receive delay and setting time ====
+=== IC-E208 ===
+{{:packet:ice208torx.png?nolink&400|}}
+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.
+{{:packet:ice208torxclose.png?nolink&400|}}
+This is a zoomed in version of the section where modulation starts appearing. It takes about 66ms before the demodulation is present and stabilised.
+=== FT-7800 ===
+{{:packet:ft7800torxclose.png?nolink&400|}}
+The FT-7800 takes about 90ms to return to RX and stabilise.
+=== Tait ===
+{{:packet:taittorxclose.png?nolink&400|}}
+Again the Tait is very fast. About 18 or 19ms before the RX is stable.
 ==== Modulation polarity ====
+{{:packet:modpol.png?nolink&400|}}
+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.
+^ ^IC-E208^FT-7800^Tait^
+^Mod Polarity|Inverted|Inverted|Normal|
 ==== Demodulation polarity ====
-To be continued...
+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
+^ ^IC-E208^FT-7800^Tait^
+^Demod Polarity|Inverted|Normal|Normal|
+==== Signal Levels ====
+It seemed prudent to record the signal levels for each radio at a nominal 2.4 KHz deviation, for both RX and TX.
+^ ^IC-E208^FT-7800^Tait^
+^TX mod level RMS|324mV|435mV|234mV|
+^RX demod level RMS|168mV|134mV|436mV|
+===== Conclusions =====
+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?
+===== Update =====
+Some time after writing this page I tried the IC-E208 again and found that it actually worked perfectly at 9k6. I didn't record the NinoTNC firmware version that I had used for my initial experimentation and I believe at some point it received an update to make it tolerant of inverted modulation polarity. This might mean other radios are now good candidates for 9600 IL2P links where they weren't before.