32APSK narrowband modem for QO-100

Some time ago I did a few experiments about pushing 2kbaud 8PSK and differential 8PSK through the QO-100 NB transponder. I didn’t develop these experiments further into a complete modem, but in part they served as inspiration to Kurt Moraw DJ0ABR, who has now made a QO-100 Highspeed Multimedia Modem application that uses up to 2.4 kbaud 8PSK to send image, files and digital voice. Motivated by this, I have decided to pick up these experiments again and try to up the game by cramming as much bits per second as possible into a 2.7 kHz SSB channel.

Now I have a definition for the modem waveform, and an implementation in GNU Radio of the modulation, synchronization and demodulation that is working quite well both on simulation and in over-the-air tests on the QO-100 NB transponder. The next step would be to choose or design an appropriate FEC for error-free copy.

In this post I give an overview of the design choices for the modem, and present the GNU Radio implementation, which is available in gr-qo100_modem.

Modem design

Design criteria

The set of design criteria or requirements that I have taken for this modem are the following:

  • The modem should fit into 2.7 kHz bandwidth, making it compatible with SSB voice from the point of view of spectrum management of the NB transponder.
  • The modem should give error-free copy when its downlink power is adjusted to be the same as the BPSK beacon of the NB transponder, which is received at approximately 50 dB·Hz CN0 with a reasonable groundstation.
  • The modem should work with a reasonably stable groundstation frequency reference, which can be an OCXO-based GPSDO, or perhaps even a TCXO-based GPSDO.
  • The modem does not need to take multipath into account. The channel will be AWGN, plus the typical frequency drift given by the groundstation reference.

I think these are very reasonable requirements for this usage. Since the modem is a beacon-power 2.7 kHz signal, we comply with all the NB transponder bandplans. As we are trying to reach the limits of what is possible, we are assuming that the groundstation is well adjusted and uses current technology. In particular, the modem design will probably not work with:

  • Stations that have a reference that drifts several tens of Hz.
  • Conventional radios. Even though the modem fits in 2.7 kHz, a flat frequency response is assumed. Unless it is possible to accurately equalize the filters of a conventional radio, an SDR transceiver should be used.
  • Badly adjusted stations that drive amplifiers into compression or have significant IMD. Good linearity is assumed.

One design criteria that I have decided not to treat is latency. I don’t want to compromise the design so much by targetting low latency, which forces short FEC codewords, and has other considerations regarding synchronization. I don’t want the modem to take several seconds to synchronize or decode a FEC codeword, either, but I think that the data rate is more important than latency. The round-trip-time for a GEO channel is already close to 0.3 seconds. I feel that trying to design a digital voice modem that supports short overs brings extra design considerations that will impact the data rate. So for this modem I’m mainly thinking about a continuous or long transmission to which the receiver can synchronize at any time.

Modulation and baudrate

For the design of the modem I’m taking a lot of inspiration from DVB-S2, since it is engineered very well to push data over an AWGN channel close to the Shannon limit. However, there are some aspects of the modem that need to be changed radically, since DVB-S2 is intended for much higher baudrates.

The modem is an APSK waveform with RRC filtering using an excess bandwidth of 5%. This is the smallest excess bandwidth supported by DVB-S2, and it is already a bit challenging to work with, since the RRC filter must be quite long and inter-symbol interference is significant unless the matched filter is implemented well. On the other hand, this low excess bandwidth allows us to use a higher baudrate while still fitting into 2.7 kHz. I have decided to use 2570 baud, which with an excess bandwidth of 5% has an occupied bandwidth of 2698.5 Hz, just under the target of 2.7kHz.

The next step is to choose the constellation. Table 13 in the DVB-S2 standard can be of help. It is reproduced here for convenience.

Target Es/N0’s for the DVB-S2 MODCODs, taken from the DVB-S2 standard

At a CN0 of 50 dB·Hz and a 2570 baud we have Es/N0 = 15.9 dB. Thus we see that we are around the target Es/N0 for the 8/9 and 9/10 32APSK DVB-S2 MODCODs. Thus, for our use case it seems reasonable to try to use 32APSK together with a good FEC that gives a rate around 8/9 or 9/10.

32APSK is the highest order modulation supported by DVB-S2, but DVB-S2X introduces even higher order modulations, as shown in the table below.

Target Es/N0’s for DVB-S2X high efficiency MOCODs, taken from Table 20a in the DVB-S2X blue book

According to this table, it seems that 64APSK 4/5 might be a good option, but the spectral efficiency it gives is only slightly higher than 9/10 32APSK. Still, this is an area where there is some room for future improvement of the modem.

Pilot symbols

The most tricky part about the modem design is the frequency drift of the groundstation reference. The problem with having a rather low symbol rate is that reference symbols need to be inserted quite frequently. For instance, the scheme of pilot symbols used in DVB-S2 cannot be used, since pilot symbols would be spaced too far apart in time.

A related question is how much frequency drift we need to handle, since in the requirements above I have been quite vague. My post about the coherence time of a typical QO-100 groundstation can give a ballpark estimate. I think that we can safely assume that the drift will be tracked by a PLL with a bandwidth around 10 or 20 Hz. Moreover, since we are using a rather tight constellation, we need to have good loop SNR in the PLL. Perhaps we can aim for 20 dB of loop SNR. This means that it is sufficient to devote 30 dB·Hz of our total 50 dB·Hz budget to phase synchronization.

There are two ways to achieve this. The first is to have a 30 dB·Hz reference signal next to or on top of our waveform. This is a simple approach but it is somewhat unconventional (unless we think about residual carrier modulations). It is also not the best regarding bandwidth efficiency. Still, a 30 dB·Hz CW tone on one of the edges of the signal would not be a too bad idea.

The other way, which is the more common, is to transmit pilot symbols on 1/100 of the symbols. This has the problem that the pilots don’t appear very frequently. In the best case, we spread them apart, so that the first out of every 100 consecutive symbols is a pilot symbol, and so the pilot symbol rate is 25.7 baud. It isn’t too convenient to update the PLL loop, which has a bandwidth of 10-20 Hz, at a rate of only 25.7 Hz (recall that the product of loop bandwidth times update rate, typically called BT, should be a few times smaller than one).

Therefore, I have decided to make pilot symbols more frequent. In my design candidate, one out of 50 symbols is a pilot, so the pilot symbol rate is 51.4 baud, which already makes things much better for the PLL. I’m hesitant to increase the pilot symbol frequency much further, since this impacts the useful data rate, but this is a parameter that can still be fine tuned according to the results of over-the-air tests with stations having different frequency references.

For best performance, pilot symbols need to be modulated with a pseudorandom sequence, so that their contribution to the power spectral density is the same as that of the data symbols. I have decided to modulate pilot symbols using a BPSK 31-bit m-sequence.

It is perhaps more typical to use other modulations, such as QPSK, for the pilots. I think that the main reason is that a QPSK waveform has less zero crossings in average than BPSK, which improves the peak-to-average power ratio. For instance, in DVB-S2 the PLHEADER is modulated using \(\pi/2\)-BPSK. The pilot symbols are 36 consecutive \(\sqrt{2}/2(1 + i)\) symbols, but they are scrambled by multiplication with the PL scrambler, which is a QPSK sequence.

In our case, however, since the adjacent symbols of each pilot symbol are 32APSK data symbols, choosing a BPSK or QPSK constellation for the pilots would give the same amount of zero crossings in average. Moreover, since we are thinking about a continuous signal to which the receiver can synchronize at any time, a BPSK modulated m-sequence gives the optimal synchronization sequence by means of circular correlation.

The m-sequence has been chosen long enough to have a clear autocorrelation peak and good cross-correlation rejection with the random data symbols, but not longer than necessary. Having a longer m-sequence would mean that the m-sequence takes more time to transmit, which impacts the synchronization time if the receiver tries to acquire the signal by circular correlation with the complete m-sequence. I think that a 31-bit m-sequence gives a good balance, because it takes 603 ms to transmit, which is not too long compared with the GEO round trip time of some 270 ms.

Constellation

The DVB-S2 32APSK constellation is shown in the figure below. Its definition depends on two parameters \(\gamma_1\) and \(\gamma_2\) that give the relative radiuses of the three concentric PSK rings. It is interesting that the values of \(\gamma_1\) and \(\gamma_2\) depend on the coding rate, as indicated in the table below the constellation.

DVB-S2 32APSK constellation, taken from the DVB-S2 standard

Lower coding rates use larger values of \(\gamma_1\) and \(\gamma_2\), which have the effect of making the outer rings larger and the inner ring smaller. For now I am using the values for coding rate 9/10 in my tests, but these parameters should be optimized when the FEC is chosen.

The 32APSK constellation needs to be normalized so that the average power, which is given by \((R_1^2 + 3R_2^2 + 4R_3^2)/8\) is one. The BPSK pilot symbols are chosen as +1 and -1.

There is actually additional freedom for trading power between the 32APSK data constellation and the BPSK pilot constellation. It is possible to multiply the the amplitude of the BPSK symbols by \(\alpha\) and the amplitude of the 32APSK symbols by \(\sqrt{(50-\alpha^2)/49}\) while maintaining the average power power of the waveform. Since there is more than enough power in the pilot symbols for the correct operation of the PLL, we could take \(\alpha < 1\), which reduces the power allocated to the pilot symbols and slightly increases the power allocated to the data symbols. The gains in data symbol power are small, since the power we rob from the pilots is spread over 49 data symbols. Therefore, I have decided to set \(\alpha = 1\), since robust synchronization is probably more important that having a little bit more power in the data symbols.

Waveform design summary

The following is a summary of the characteristics of the 32APSK waveform:

  • Single-carrier APSK waveform
  • Baudrate 2570 baud
  • RRC filtering with excess bandwidth 5%
  • Occupied bandwidth 2.7 kHz
  • Pilot symbols in TDD every 50 symbols
  • BPSK pilot symbols with 31-bit m-sequence
  • 32APSK data symbols

Modulator implementation

I have decided to use 8 ksps IQ for the implementation of the modem in GNU Radio, since this is a typical sample rate that can be used to process a 2.7kHz SSB channel. The baudrate of 2570 baud is a bit of an oddball number (in fact 257 is a prime number), so I have decided not to implement the modem using a sample rate that is related to the baudrate by a simple fraction.

At 8 ksps, the samples per symbol is around 3.113. I have decided to use a Polyphase Arbitrary Resampler block to resample the symbols from 2570 baud to 8 ksps, while performing RRC filtering. As remarked above, with an excess bandwidth of only 5% it is critical that the RRC filters are implemented accurately, so I have decided to use 64 arms in the polyphase filter. The length of each of the arms is chosen according to the decay of the RRC taps. I have decided that 47 taps is a good choice.

The figure below shows the prototype filter used for the modulator. As we can see, at 47 taps per filter arm the RRC response has already decayed significantly in the edges of the filter.

The frequency response of the prototype filter has around -35 dB of sidelobe attenuation. This is something that we could improve, but note that at 50 dB·Hz of CN0, the SNR in the occupied bandwidth is 15.7 dB, so the -35 dB sidelobes are already deep below the transponder noise floor.

The passband ripple of this filter is 0.5%.

The book by fred harris gives an interesting way to improve the response of a windowed RRC filter in Chapter 4.3, so that is a possible improvement for the future.

The modulator is implemented in a GNU Radio hierarchical flowgraph qo100_modulator.grc. The data comes in at 5 bits per byte, is mapped and modulated according to the 32APSK constellation, and multiplexed with the BPSK pilot symbols. Resampling and RRC filtering is done with the Polyphase Arbitrary resampler. Constants involved in the modem definition, such as the constellation, baudrate, etc., are defined in the Python module constants.py, since these are also used in the demodulator.

Modulator GNU Radio flowgraph

Demodulator implementation

Symbol synchronization

Since one of the challenges of making this kind of modem work correctly is the frequency drift, I wanted to decouple completely the symbol synchronization from the carrier recovery. Thus, I decided to perform first symbol synchronization and RRC matched filtering with the Symbol Sync block and then work with the pilot symbols already at one sample per symbol for carrier recovery.

The Symbol Sync block is configured with a polyphase filterbank implementing a matched filter and the maximum-likelyhood TED. This works OK, and in fact is able to synchronize quickly in my over-the-air tests. However, the performance is not so great. The clock recovery is too sensitive about the loop bandwidth, and sometimes the clock phase seems to slip slightly, causing some inter-symbol interference. Therefore, this is one of the aspects of the receiver to improve in the future, perhaps by using the know pilot symbols to aid the clock recovery.

I have followed the same approach to design the prototype RRC filter of the Symbol Sync block as in the modulator. I am also using 64 arms in the polyphase filter and this time I am using 127 taps per arm, because the RRC time-domain response is roughly 3 times wider. The impulse response and frequency response of the filter are included in the figures below, which show similar performance to the modulator filter.

Carrier recovery

Carrier recovery uses the BPSK pilot symbols only. It is divided into two steps:

  • An acquisition step that correlates against the 31-bit m-sequence to find the start of the pilot symbol sequence and produce phase and frequency estimates to bootstrap the PLL.
  • A PLL that uses only pilot symbols to compute the phase error and wipes-off the known m-sequence that modulates the pilots.

These run on the stream of symbols produced by the Symbol Sync block.

The acquisition performs the circular correlation of a window of 31*50 symbols against the known 31-bit m-sequence used to modulate the pilot symbols in order to find the start of the pilot symbol sequence. The correlation is implemented using FFTs. In order to search in frequency, a circular shift in the frequency domain is done. All frequency bins are searched simultaneously. To have more frequency resolution, zero padding is done, duplicating the size of the FFTs to perform.

From the correlation peak we obtain the starting position of the pilot symbol sequence, and phase and frequency estimates. These are sent to the PLL using stream tags in the GNU Radio implementation. The PLL uses this data to keep track of the positions of the pilot symbols and to initialize the closed loop.

Note by the design of the waveform any algorithm that performs the correlation of the 31-bit pilot symbol m-sequence will only be able to detect frequency offsets in the ±25.7 Hz range, since the pilot symbol rate is 51.4 Hz. Larger frequency offsets will alias. Therefore, for the correct operation of the receiver it is necessary that the user tunes the signal to within ±25 Hz. As long as the groundstation frequency reference is stable enough, this is easy to do manually just by looking at the spectrum of the signal, which indeed has steep skirts due to the small excess bandwidth of the RRC filter. To help the user, the GNU Radio demodulator GUI plots both the spectrum of the signal and its mirror image. Only when the skirts of these two match well, the signal is correctly tuned. An improved decoder would perform this tuning automatically.

Note that this ±25 Hz frequency error limit refers only to the initial signal acquisition. When the PLL is tracking the carrier, the frequency error may drift further.

Since the acquisition block needs a window of 31*50 samples (in fact 31*50*2 samples in the current implementation, due to the FFT zero padding), it introduces a latency of 0.6 seconds (or 1.2 seconds) in the processing. In the GNU Radio implementation, in order to get lower latency this only happens until the correlation peak is found. After that, the acquisition block just lets samples through as they come in, introducing no latency. The block has a message port that can be used to resynchronize when necessary. Currently this resynchronization is triggered manually by the user with a GUI button, but in the complete modem it could be triggered by the FEC, or by the PLL.

The PLL includes a first order (phase and phase-rate) closed loop that uses the pilot symbols to track the carrier phase of the signal. It keeps track of what is the current received symbol, and when it receives a pilot symbol it wipes-off the m-sequence modulation and uses the phase error to update the loop filter. In its GNU Radio implementation it outputs the phase corrected data and pilot symbols on separate output ports, since after carrier recovery we would typically only care about data symbols.

At this stage, I have adjusted the coefficients of the loop filter by hand to get something that works more or less well with over-the-air tests. In the future I intend to use the ideas in the paper “Controlled-root formulation for digital phase-locked loops” by S.A. Stephens and J.B. Thomas. In this paper they analyse the design of the loop filter directly in discrete time, rather than porting a continuous time design to discrete time by using the bilinear transform. This is advantageous specially for large loop BT, which is the case for this receiver.

The PLL also includes an AGC that uses the pilot symbols as an amplitude reference. Even though there is an AGC earlier in the chain, as the Symbol Sync block requires normalized amplitude, this AGC is able to scale the amplitude more accurately.

GNU Radio implementation

Since the performance of the acquisition and PLL were an important part of the modem waveform design, they were prototyped in Python in this Jupyter notebook and tested with over-the-air recordings before being implemented as GNU Radio C++ blocks.

The figure below shows the GNU Radio implementation of the demodulator as a hierarchical block. The first block is a low pass filter that lets only 3 kHz of bandwidth. Then there is the RMS AGC block from gr-satellites that adjust the amplitude so that the signal has power one. Next we have the Symbol Sync block as described above.

Demodulator GNU Radio implementation

Then we have the Pilot PRBS acquisition block, which is a custom C++ block from the gr-qo100_modem out-of-tree module. This implements the FFT-based acquisition algorithm of the pilot m-sequence described above. Its first output is the stream of symbols, with tags corresponding to the synchronization peaks found. Its second output gives the FFT for the frequency bin where the maximum peak is found. This can be displayed in a GUI.

Finally we have the Pilot symbol PLL block, which implements phase tracking of the pilot BPSK symbols. Its first output gives the phase corrected data symbols, and its second output gives the phase corrected pilot symbols.

BER measurement

For measuring bit error rate, a fixed pseudorandom pattern is transmitted. This pattern is given in a data file. In order to keep synchronization to the pattern simple, the length of the pattern is 31*49 symbols, so that the pattern repeats every time that the pilot symbol m-sequence starts again. Since the PLL block knows the alignment with the m-sequence, it also knows the alignment with the pattern, and marks the first data symbol following the first pilot symbol with a stream tag.

These stream tags are then used to align the received data to the data file, using the Tags to PDU block from gr-pdu_utils. This is probably not the most efficient way to do it, but it is simple to implement.

The BER measurement is done in the GNU Radio hierarchical block shown below. Symbols are decoded using the nearest neighbour from the constellation. After correct alignment with the stream tags, the received data is compared with the reference data and bit errors are counted in windows of 10000 received bits.

GNU Radio BER measurement hierarchical block
Demodulator GUI

The demodulator is embedded in a QT GUI hierarchical flowgraph that plots all its inner workings, so that the user can evaluate the performance. This is shown in the figure below.

GNU Radio demodulator GUI hierarchical flowgraph

The GUI uses tabs to separate the different parts of the demodulator, since there are many plots. The following figures show each of the tabs running on a simulated signal with 50 dB·Hz CN0.

The first tab shows the spectrum of the signal. The mirrored spectrum is also shown to help the user tune correctly. When the sharp skirts of the signal and its mirror overlap, the signal is well centred.

Demodulator GUI: spectrum tab

The next tab shows the clock recovery data. These are just plots of the output of the Symbol Sync block, which gives the average and instant symbol period and the TED error signal.

Demodulator GUI: clock recovery tab

The constellation tab shows the 32APSK data constellation in blue and the BPSK pilot constellation in red. At 50 dB·Hz of CN0 the 32APSK constellation points start to merge, so it is easier to look to the BPSK constellation points to examine the quality of the signal.

Demodulator GUI: constellation tab

The synchronization tab shows the output of the FFT used in the synchronization algorithm on the top and the BPSK pilot symbols versus time on the bottom. The top plot only has data when the correlation is running (which is only until a peak has been found). Here we can see a large correlation peak.

Demodulator GUI: synchronization tab

Finally, the BER tab gives the BER as a number that updates relatively fast (every 0.8 seconds) and as plot giving the history of the last 8 seconds.

Demodulator GUI: BER tab

The GUI has a Resync button at the bottom which the user can press if synchronization is lost. This will enable again the FFT-based synchronization.

Modem tests

My first tests to validate that the design of the modem waveform was reasonable were done with simulated signals with the target CN0 of 50 dB·Hz. I implemented the modulator in GNU Radio as described above, used an AWGN with frequency offset channel model (the Channel Model block) and the Symbol Sync to demodulate the data. The carrier synchronization algorithms were prototyped and tested in this Jupyter notebook.

The results of the simulation were quite good. The constellation plot shown below summarizes the waveform design and the test results. I used this to show my design and the progress of my tests in Twitter. The BER is around 4%.

Simulation test at 50 dB·Hz

Next I passed to over-the-air tests on the QO-100 NB transponder, still using the prototype in Python. I run the GNU Radio transmitter in real time, and I made IQ recordings of the downlink signal for post processing. As usual, the groundstation hardware consisted of a LimeSDR mini for the uplink and the downlink IF, and a Ku-band LNB, with eveverything locked to a GPSDO reference.

The figure below shows Linrad monitoring the test signal. The power has been adjusted so that the downlink power is slightly below the power of the BPSK beacon. The spectrum of the signal shows a noticeable pattern because with the test data for BER testing the signal repeats every 0.6 seconds. When random data is sent, the spectrum looks completely smooth.

Linrad showing the over-the-air test signal

The figure below shows the results of the over-the-air test processed with the Python prototype of the algorithms. The results are very similar to the simulated test. The constellation might seem slightly more noisy, but that is just because there are more symbols plotted. The IQ recording of this test can be found here.

Over-the-air test on QO-100 at beacon power level

The results of the first over-the-air tests were quite encouraging and convinced me that this was a reasonable design for the modem waveform.

It is worth to mention that the frequency reference that I’m using with my groundstation in the over-the-air tests is quite stable. It is the Vectron-MD011 OCXO-based GPSDO that I have used in these experiments (and several others). Moreover, since I’m using the same clock for the uplink and downlink, I’m seeing only 77% of the drift that I would see if I was receiving another station (the uplink drift cancels out part of the downlink drift). It will be interesting to see how the modem performs with less stable frequency references, but for this it makes sense to improve the PLL loop filter as described above.

After being happy with the performance of the waveform and the carrier recovery algorithms in Python, I ported these algorithms to GNU Radio C++ blocks, creating the gr-qo100_modem out-of-tree module to hold them. Then I re-organized my rather messy test flowgraphs into the hierarchical flowgraphs that I have described above.

In its present state, gr-qo100_modem gives example flowgraphs that can be used to run the modulator and demodulator and measure BER in the following scenarios:

  • A simulated AWGN channel model
  • Playback of the provided IQ recording
  • Over-the-air test with SDR hardware

The over-the-air test that is included is prepared to work with my QO-100 groundstation software stack. The SDR sample rate is 600 ksps and the samples are sent to the radio by TCP and received by UDP using the Linrad protocol. This flowgraph needs to be adapted to work with other SDR hardware.

At this stage of the project, tests are greatly encouraged. If anyone is interested in setting up the GNU Radio software, or wants me to put a test signal in the QO-100 NB transponder, just let me know.

Next steps: adding FEC

The next step is to find or develop a suitable FEC that gives error-free copy with the typical 5% BER that I’m finding in my tests. As I have mentioned above regarding the BER tests, the 31-bit m-sequence gives a framing structure of 1519 data symbols (7595 bits). It would be nice if the FEC codewords were 7595 bits long, so that no additional synchronization markers would be needed to find the beginning of the codewords.

DVB-S2 normal FECFRAMES are 64800 bits long, and short FECFRAMES are 16200 bits long. Longer FEC codewords give better performance, but I think that 7595 bits will already give some decent performance. For instance, the CCSDS AR4JA LDPC code with 4096 information bits is said to perform only 0.6 dB worse than the equivalent code with infinite block size (see the discussion in Section 8.1 of the TM Synchronization and Channel Coding Green Book). Moreover, 7595 bit codewords already take some 0.6 seconds to transmit, so I wouldn’t like to make the codewords much longer than this.

The target coding rate I aim for is around 8/9 or 9/10. This idea is supported by the MODCOD tables of DVB-S2 included above. Taking into account the pilot symbols, such coding rates would give an information rate of 11194 or 11334 bps, which is not at all bad for a 2.7 kHz SSB channel. Thus, I think it’s reasonable to expect a user data rate of 11 kbps for this modem.

11 comments

  1. Outstanding work! Couple questions (of course). You said you acquire carrier phase separately from symbol timing, so what’s wrong with a simple CW pilot tone parked in a sidelobe null? Commercial satellites have flux density limits that discourage spectral lines, but we’re hams. Making your signal something other than band-limited noise helps other hams recognize it. E.g., Funcube’s on/off cycling between carrier and data is very distinctive. A CW pilot could do the same. It might even carry a ID.
    Why not adjust your baud rate a little, at least so it’s not a prime number requiring careful resampling?
    Your constellation has 3 amplitude levels. Have you thought about putting the envelope on the signal at high level to make a more efficient 2.4 GHz RF amplifier?
    And…(this will be familiar) are the QO-100 bandwidth and power limits truly optimal here? You’re certainly working with much denser constellations and higher FEC rates than I’m used to. Is power really that cheap and bandwidth really that expensive?

    1. Hi Phil, thanks! Those are very good questions indeed.

      Regarding putting a CW pilot tone in a sidelobe null, nothing is wrong with that. In fact it has the advantage that it is present all the time, so we don’t have this awkward problem where the PLL only gets samples every one in a while, and it can be scaled exactly to whatever CN0 we need for adequate phase tracking.

      There is something interesting when you do this, which is that a subcarrier frequency appears. This is given by the offset between the CW pilot and the centre of the APSK waveform. The phase of this subcarrier needs to be estimated and tracked, since you basically want to transfer the phase measurements you do on the pilot to the APSK waveform, in order to lock the constellation. The subcarrier frequency is small (let’s say 1.5 kHz), so it will change very slowly, and you can track it with a PLL with very small bandwidth or in an open loop manner. But still, you need some phase reference in the APSK waveform in order to measure this subcarrier phase. Any kind of of syncword or unique work will do, and it doesn’t need to be transmitted so frequently (presumably you’ll have a fixed syncword at the start of FEC frames in any case). An alternative approach is to have two CW pilots, say at both edges of the APSK carrier. Then the subcarrier between the CW pilots can be measured directly as the difference in phase between the two CW pilots, and the subcarrier between each CW pilot and the APSK waveform will be just half of this.

      Having this subcarrier (either with one or two CW pilots) also gives an opportunity: if the subcarrier and symbol clock are related, then you might use the subcarrier tracking to help the symbol clock tracking, and even do without symbol clock recovery completely. Unfortunately, this idea doesn’t play well with were you want to put the subcarrier, which is at offset fsym*(1+alpha)/2, where fsym is the symbol rate and alpha is the RRC excess bandwidth. You could put the subcarrier at fsym/2, but then it interferes with your APSK waveform, or at 3fsym/2 or fsym, but then it’s too far (which is only bad because then you don’t fit in a 2.7 kHz channel).

      You raise an interesting point, which is that we’re starting to see all sorts of PSK-like waveforms having different baudrates, constellations and codings, and no clear way to distinguish which of them is being used. Some sort of ID would be nice. This might also happen in the wideband transponder if people start using things which are not DVB-S2.

      About resampling, I haven’t given much thought to this. Maybe there is a number which is still close enough to 2570 but much nicer in terms of its prime factorization. In any case, I don’t see a major problem with this odd sampling rate. Polyphase arbitrary resampling is not much more expensive than resampling by a small rational number, and for clock recovery we still need a polyphase resampler with many branches, or something similar. Also, one could argue that there is nothing bad about 2570, or special about “nice round numbers”. For instance, I run my LimeSDR at 600 ksps in order to fit the 500 kHz wide transponder. But I could also run it at 591.1 ksps (which is 2570 * 230), or even 657.92 ksps (which is 2570 * 256, so that resampling can be very effective by means of half-band filters).

      Regarding a non-linear PA, I think the folks of DVB-S2X have put at least some thought into this. In the Es/N0 performance tables you can see a column for a “non-linear hard limiter channel”. For the APSK constellations the performance is much worse compared to AWGN linear, as would be expected. In my case, I didn’t want to compromise the performance of the modem by thinking about a non-linear PA. I think it is reasonable to design a QO-100 groundstation transmitter (in terms of antenna and PA) to give a signal with the required power and have enough overhead in the PA that it behaves linearly. Maybe I’m a bit biased with this thinking because the PA of my station is pretty large (much more than needed for the NB transponder).

      Regarding your last question, I think that if we speak about a single user, then the answer is basically given by the channel capacity. For a signal having CN0 = 50 dB·Hz we see that at 2.7 kHz of bandwidth we’re bandwidth limited and we could transmit more information with the same CN0 by increasing the bandwidth. In fact, a signal with 50 dB·Hz should be transmitted with 100 kHz bandwidth or more in order to be efficient! (The rule of thumb is transmit at 0 dB Eb/N0 and don’t try to push more than 1 bit/Hz).

      If we consider now N users of the same waveform that are going to share the transponder with FDMA, then I think the question becomes about the transponder design. Basically we’re asking about whether the transponder is power-limited or bandwidth-limited, in the following sense: First figure out how many signals of 50 dB·Hz the transponder can put out simultaneously. Set N equal to this. Then divide the total transponder bandwidth by N. This is the bandwidth you should give to each of your signals. If the bandwidth comes out much larger than you need according to band-limited capacity, then the transponder is power-limited. Else, the transponder is bandwidth-limited. We all know that the NB transponder bandwidth is 500 kHz, but we don’t know N. At least I’m sure that N is much larger than 10, since I’ve seen many more than 10 users with signals of this power. So we see that the transponder is severely bandwidth limited, since we can’t have many more than 10 signals of 100 kHz bandwidth each with FDMA. This way of thinking is just a convoluted way of asking what is the channel capacity of the transponder as a whole. Is it power-limited or bandwidth-limited? I think it’s severely bandwidth limited.

      If you think about the transponder as a whole, you see that using CDMA instead of FDMA is not going to change the outcome a lot. If all you can spread is 500 kHz and you want to transmit at a large bitrate because you have 50 dB·Hz per signal, then you don’t have much processing gain, so you can’t support many users.

      I think, on the contrary, that bandwidth is cheap (we’re in the ham bands, so it’s basically free), while power is expensive. However, if I recall correctly (and I might be not quoting AMSAT-DL accurately enough here, so they can correct me if needed) that the narrowband transponder was designed to be similar to an HF band, and there was some concern that with a very large bandwidth users would get lost tuning around the band (not everyone has a waterfall). The transponder wasn’t design to push the channel capacity to the limits allowed by the theory, which is the thought exercise we are attempting here. I must reckon that with only 500 kHz it’s easy to monitor the whole transponder at once, which is something us hams like to do. If the transponder was, say, 20 MHz wide, then it would be a bit more tricky.

  2. When I thought about this more after last night, I also realized you’d need a pilot on either side to give both a carrier phase and symbol timing reference. When I did the ARISSat-1 design I used DBPSK (fading was a concern) so I was only concerned about (approximate) carrier frequency, not phase or minor errors in symbol rate. Both are concerns here since you’re operating coherently with a big constellation. There’s little Doppler in GEO but you do have a lot of frequency instability at X band. Good point also about where to place the pilots; I used 100% excess BW so I simply parked my (one) pilot in the lower null where it also operated as the CW beacon.

  3. I’ve become a big fan of fast convolution, and I use it for resampling as well as filtering. This lets nearly all of the hard work be done by the FFT/IFFT, and I use FFTW3 because it’s so well tuned for performance. I can use any input or output sampling rate with an integral number of samples per processing block. I typically operate with a 50 Hz block rate, so any sample rate that’s a multiple of 50 Hz is easily handled. Whether this counts as “polyphase” I’m not sure. I bet the underlying math is much the same.

    1. I think “polyphase” and doing convolution in the frequency domain are two completely independent concepts that you can mix if you want.

      The basic idea of polyphase is “don’t compute things that you would end up throwing away”. So if you want to upsample by 3/2, rather than doing upsampling by 3 followed by decimation by 2, what you do is to write a polyphase filter bank that has 3 branches that have a sinc function for delays 0, 1/3 and 2/3 of a sample. Then you step through the 3 branches in steps of 2 branches, so the output you generate is your waveform interpolated at delays 0, 2/3, 4/3, 2, …, which is just what you wanted for 3/2 upsampling. This has the advantage that the FIRs in each branch can be rather short, since only has 1/3rd of the coefficients of the prototype filter (which is the whole sinc function interpolated at 1/3 steps).

      If you wanted (but I’ve never seen this), you could implement the convolution in the FIRs in each of the polyphase branches by doing an FFT. I think this only pays off when the FIR is long enough, but this depends a lot on implementation details.

  4. I wasn’t talking so much about a waveform that could withstand a hardlimiting amplifier, but that works well with hardware designed to maintain linearity while operating its final RF amplifier(s) in saturation for efficiency. This has a long history, starting with high power AM broadcasting. AMSAT-DL (specifically DJ4ZC, who wrote his doctoral on the subject) designed several early AMSAT linear transponders, including AO-7 and the Phase III series.

    I know of at least 3 approaches. Doherty uses two differently biased amplifiers to handle low and high power levels. Envelope elimination and restoration looks like high level (“plate”) modulated AM; the low level drive signal is hard limited and the envelope is added with a baseband power amplifier. And there’s HELAPS, which uses two hard-limited RF amplifiers driven by a phase shifter network to give the proper amplitude when combined at high level.

    Each has its advantages. What made me think of this is that your waveform has only 3 discrete amplitude levels, which might map well to three separate saturated amplifiers, one for each amplitude, feeding a combiner.

    1. Ah, envelope restoration. I now understand where you were trying to get at. That’s quite interesting. I don’t know much about the limits or challenges of this, but I’m vaguely familiar with people using it for SSB on HF.

      I think that even though the constellation has only 3 amplitude levels, the envelope restoration is more difficult than just having 3 pre-set amplitudes. You need to be able to preserve the amplitude of the RRC pulse shape very precisely, or otherwise you would get sidelobes, IMD, or other nasty stuff. This also affects your typical BPSK or QPSK constellation, even though the constellation has a single amplitude level. If you insist on transmitting it at constant amplitude, then you’re basically doing rectangular pulse shaping, so you get huge sidelobes. For QPSK we have GMSK, which is constant envelope and has nice spectrum. It’s not the same as QPSK, but is similar enough for many cases. We could think of a higher order analogy for m-PSK, where you transition between symbols smoothly along the unit circle. I think this ends up being Gaussian minimum shift m/2-FSK, or something like that. But for APSK I can’t think of a good analogy, since you need to change your envelope smoothly to get from one constellation ring to another.

      What I wonder is if you can also add predistortion into the mix in order to solve the IMD problem, while only using 3 amplitude levels at envelope restoration. It seems counter-intuitive, because it seems that you would still have only 3 amplitude levels at your output. But distortion is rather complicated (amplifiers have short-term memory, and so on), so I wouldn’t completely rule out the possibility.

  5. And so…back to our much-discussed bandwidth/power tradeoff. We agree, this is really a question about the capacity of the transponder as a whole, not the (arbitrarily defined) 2.7 kHz wide channel with a 50 dB C/N0. Do we really not know how many 50 dB C/N0 signals the transponder can carry before it runs out of power?

    (I was going to say that’s equivalent to knowing what C/N0 the transponder can provide in a single signal, but that’s not the same thing because the transponder is undoubtedly more efficient near saturation — see my last message!)

    1. I really don’t know. But this can be measured. We could convince AMSAT-DL that we want to measure it at the wee-hours of night, when no one is using it.

      The tranponder has an AGC, by the way, and I’ve rarely seen it kick in, even with huge pileups.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.