QO-100 transponder LO offset investigation

Introduction

I recently converted my QO-100 outdoor unit to allow me to use it with a single transceiver (in my case a Yaesu FT-817), inspired by the “minimal amount of components constest” by PE1CKK and PA3FYM. Previously, I used an SDR setup in full duplex mode using a custom GNU Radio SSB transceiver including PSK beacon phase locking as described in a previous post. The SDR setup, although very flexible, suffered from extreme latency (up to 5 seconds) which became very annoying. Moreover, I wanted to use the transponder without a computer, just using a single transceiver.

The outdoor unit now contains a LNB reference generator (used in receive) at 25.8 MHz, and a transmit local oscillator (LO) at 1972.5 MHz. This allows 427.5 MHz IF for both transmit and receive. The LO generation is done with a single ADF4351 clocked with 10 MHz from a Leo Bodnar GPSDO. In receive, a 51.6 MHz LO is generated which is then divided by 2 in a 74AC74 to obtain the 25.8 MHz LNB reference, hence 10489.5 – (390 x 25.8) = 427.5 MHz. In transmit, a 1972.5 MHz LO feeds a HMC213 mixer which upconverts the 427.5 MHz signal to 2400 MHz.
The LNB used is a Starcom SR-320.

I expected to be (near) zero beat with this setup. However, after checking this by whistling, and listening to my own echo, I discovered that there was a frequency shift larger than the (approximately) + and – 26 Hz due to the Doppler shift. This shift is the result of minute imperfections in QO-100’s orbit, which is typical for geostationary satellites.

Measurement

Recently, several Dutch amateurs discussed the same issue and reported seeing about 70 Hz offsets when using setups that were fully disciplined by a GPSDO. Something was going on? Although ‘almost unbelievable’, after some elaboration Remco PA3FYM and I suspect(ed) the accuracy of the transponder LO (8089.5 MHz). So, we decided to try to measure downlink signals using an adaptation of my GNU Radio flowgraphs originally developed for beacon tracking. It was set up to measure the PSK beacon frequency by using a Costas loop, which outputs the frequency of the (suppressed) carrier and logs it to a file.

This method assumes that the PSK beacon (which is assumed to be transmitted from AMSAT-DL’s Bochum station) is exactly ‘on frequency’, i.e. its uplink frequency is 2400.250(000) MHz. In order to have an independent signal source Remco PA3FYM contacted Rene PE1CMO. Rene transmitted a  carrier through the QO-100 transponder, with about 7 dBm into a 88 cm wide offset dish. Rene used a BG7TBL GPSDO to lock his transmitter.

My GNU Radio flowgraph was modified to measure the frequency offset of Rene’s beacon and the PSK beacon simultaneously. The SDR used at PE4WJ is an Ettus Research USRP E320, which is locked to its internal GPSDO. The SDR input is at 427.5 MHz from the outdoor unit. This unit has its own Leo Bodnar GPSDO to generate the LNB reference as explained at the beginning of this post.

The measurement was conducted between Thursday March 18^th 12:00 UTC (approximately) and Friday March 19^th 14:00 UTC. The data has been “windowed” to a single Sidderial day (23.9344696 hours) which equals a single complete revolution of both the Earth as well as QO-100 in its orbit.
This was rounded down to a total time of 86164 seconds. Figure 1 provides the difference in the measured frequency of the QO-100 PSK beacon with respect to the “expected” frequency. A number of features can be spotted.

Figure 1 QO-100 PSK (middle) beacon frequency offset measurement results

First of all, the curve has a sine-wave appearance, which is due to the small amount of Doppler shift mentioned earlier. Secondly, a “wiggle” can be seen at around 37000 seconds. This wiggle was present on a previous measurement day as well, and is believed to be the result of a firing of the on-board propulsion system to perform a “stationkeeping” maneuver a drop in on-board temperature due to eclipse (tnx! EA4GPZ and others). Similar “wiggles” have also been reported by others such as EA4GPZ. Thirdly, at around 75000 and 85000 seconds, there are peaks visible which may be caused by (deliberate) QRM on the beacon signal.

To verify whether our measurements were correct and accurate, Remco asked Paul M0EYT to determine the exact frequency of Rene’s carrier approximately three hours after our measurements started. Paul did not know ‘what’ and ‘why’ he had to measure, other than requested to determine ‘a carrier frequency’. With a totally different method Paul’s GPS locked receive system reported exactly the same carrier frequency we measured (at the same time). The estimated accuracy of Pauls measurement was +/- 0.5 Hz.

Figure 2 provides a similar graph but then for the difference in the measured frequency of PE1CMO’s carrier relative to the expected frequency, which -of course- should be the sum of the uplink frequency and the LO of 8089.5 MHz inside QO-100. When the QO-100 LO is exactly ‘on frequency’ the offset should be 0 Hz plus or minus Doppler. Rene’s carrier shows a similar ‘sine shape’ and wiggle. Unfortunately PE1CMO switched off his beacon signal at around 40000 seconds in the observation (and switched it back on the next day but these measurement points have been discarded in the data processing).

Figure 2 PE1CMO carrier beacon frequency offset measurement results

The next step is to compare the measurement of the PSK beacon frequency offset and the PE1CMO beacon frequency offset during the time window where both were active. This reveals that the frequency difference of the signal generated by PE1CMO and transmitted back by the QO-100 transponder, and the QO-100 PSK beacon was very small as can be seen in Figure 3 and on average (averaged over the observation period until he switched off). This results in an average frequency difference of only 0.18 Hz. It should be noted that due to the difference in location between PE1CMO and Bochum, there is a very small differential Doppler component, but its magnitude is likely much smaller than the inherent noise on the frequency measurement and can therefore be neglected.

Figure 3 Difference in PSK middle beacon offset and PE1CMO beacon offset

The fact that this difference is so small can mean at least two things:

1) Either both the PSK beacon and PE1CMO’s beacon are exactly ‘on frequency’;

or

2) Both the PSK beacon and PE1CMO’s beacon have the same frequency error.

Point 2) is considered highly unlikely because it would mean that the exact same frequency offset is present on two completely independent (and likely different) setups.

Now, if we assume 1) is true, we can determine the actual transponder LO offset over a day by inspecting the curve of Figure 1. To obtain an estimate, the data over 1 sidderial day has been averaged, which yields a value of -67.2 Hz. Thus, a 2400 MHz uplinked signal will be downlinked at 10489.5 MHz 67.2 Hz lower in frequency than expected. It has to be noted that the method of averaging may not be exactly accurate since the curve may not be fully sinusoidal (which it clearly is not due to the “wiggle” discussed earlier). Nevertheless, this number is believed to provide a good estimate of the actual transponder LO offset, and hence, frequency.

It is very difficult to obtain information about the frequency reference used on QO-100 to generate the transponder LO. It is possible that this frequency reference also feeds other transponders in the satellite and I would expect it to have a very good stability (like a Rubidium reference). Our measurements show that there may be a certain inaccuracy of the reference, although it is questionable whether that is a problem in the applications on board the satellite. Nevertheless, the resulting uplink / downlink frequency difference is large enough though to be noticed during narrowband operation.

It would be interesting if these measurements could be repeated by other amateurs to obtain an independent data source, and furthermore to repeat these measurements over time to determine whether the LO offset is stable or whether there could be a long term drift.

I would like to acknowledge Rene PE1CMO for his help in generating a stable CW beacon, M0EYT for providing an independent measurement, and Remco PA3FYM for his coordination, reflecting off ideas and reviewing this post.

Remote HF Antenna Tuner build part 2 – Considerations on the S-match circuit and its “match space”

In the previous post, I mentioned the S-match design. After running some simulations I figured that the theoretical S-match circuit might not be able to match loads on a significant portion of the Smith chart. Inspired by the work of K6JCA on determining the match space and his wonderfully documented automatic tuner build, this post is about investigating the theoretical match space for an S-match antenna tuner and describes my decision to go for a “traditional” L-network instead.

S-match circuit topology

In principle, the S-match is based on an L network matching section. From PA0FRI’s site:

S-match topology (from: https://pa0fri.home.xs4all.nl/ATU/Smatch/smatcheng.htm)

The components are arranged such as to cleverly balance out the parasitics which could lead to imbalance in a balanced tuner. As can be seen, the S-match is a highpass “C-series, L-shunt” L-network. When the antenna is connected over the capacitor terminals (for which PA0FRI mentions that “With some antenna systems a better efficiency may be achieved if the antenna is connected to the capacitor[…]”), the network becomes a lowpass “L-series, C-shunt”.

Simulated match space for the type 1 and type 2 L-networks

If we ignore the influence of the transformer (which may be significant, more on that later in this post) for now, we can have a look at the theoretical “match space” that the L-network can match. This document nicely describes the match space of the various possible L-network topologies, as can be seen, the two S-match topologies (“type 1” and “type 2” respectively in the aforementioned document) lead to a circle in the Smith Chart in which no match can be found.

The above consideration applies to the ideal (i.e. no parasitics) antenna tuner. In a practical realization of the circuit there will always be parasitics. I have run some Python simulations using the scikit-rf package to confirm the match space, simulating a practical L network (including some parasitics) which resembles my LC bank with L_min = 0.9 uH (yikes, quite high, but partly due to wire inductance in the measurement setup), L_max = 17 uH, C_min = 170 pF, C_max = 3.3nF. The simulation is done using K6JCA’s method for determining the outline of the match space. This simulation was run on 3.5 MHz in order to limit the effect of the parasitics on the match space. At 28 MHz, the plot looks quite different (read: uglier!) due to the large value of the parasitics in my setup. As can be seen the plot matches the figures in the aforementioned document and confirm that there is a portion of the chart which cannot be reached by the network. Also, the effects of parasitics and the finite range of inductance / capacitance can be seen as the areas near the edge of the Smith chart can not be reached. But that latter issue is likely not to be a major problem on a practical antenna.

Simulated matchspace at 3.5 MHz of the “type 1” and “type 2” L-network in one plot

Influence of the transformer on the match space

Furthermore ON9CVD has nicely explained the effect of the transformer on the match space in his article, which shows that the transformer will further affect the match space.

Now, whether this really is a problem in my situation where I have a fixed antenna is one of the questions to answer. If it turns out that the feedpoint impedance of the antenna across all amateur bands from 160 to 10 m falls within the match space, there should not be an issue. But if it falls outside, then no match can be found there.

The need for symmetry in the ATU

As mentioned earlier in this post, the S-match nicely minimizes unbalance in parasitics while only using a single inductor and capacitor. This means that if used with an antenna that is also nicely balanced, common mode currents will be minimized. In addition the tuner offers galvanic isolation. However, after a bit more thinking I realized that since my proposed antenna system consisting of a wire fed “against” the metal roof, the antenna is already highly unbalanced by itself, and any effort to minimize unbalance in the tuner would be worthless. This, in combination with the limited matchspace that an S-match can offer, I decided to implement the tuner as a “conventional” lowpass L network, with either a “Type 1” or “Type 3” topology. Such a topology theoretically provides a nice “Ying Yang” type of matchspace in the Smith chart, i.e. no “hole” where it cannot match. This means a series inductor with a shunt capacitor which is either on the transceiver side or the antenna side of the inductor, depending on the impedance to be matched.

Whether the unbalance in the antenna system causes a problem is to be seen in practice, I plan to use my LZ1AQ magnetic loop as my main receive antenna, and will use the wire antenna mostly for transmit. Therefore, common mode currents should not have an effect on my system’s receive performance. The only remaining area where the unbalance and resulting radiation from common mode currents is in transmit mode, where it could cause RFI.

One problem remains though, which is the requirement of galvanic isolation. Therefore I looked for a “conventional” transformer design (1:1) which is broadband enough to cover 1.8-30 MHz, and low loss at the same time. This transformer is then to be placed between the transceiver and the ATU. It should have a good (>20 dB or so) S₁₁ and S₂₂ to minimize influence on the matchspace.

I stumbled upon a nice presentation by PE1FOD on measuring ferrites (in Dutch), in this presentation he performs measurements on a galvanically isolated (“fluxtransformer”) 1:1 transformer on slide 12.

Slide 12 from “Het meten van spoelen met Ferriet” by Timo, PE1FOD – link

S₂₁ over 1.8-30 MHz appears to be low (i.e. low losses) and S₂₁ looks pretty acceptable as well. I built my own version of the transformer on a Wurth ring core of 4W620 material (similar to Amidon “43” type), initial VNA measurements showed that I got close, but not quite there yet as the S11 at 30 MHz is only around 10 dB:

blue trace: S21, red trace S11, over 1-30 MHz, 10 dB/div

After adding 2 33 pF parallel compensation capacitors (one at the input, one at the output) I got decent results, see below. 0.17 dB insertion loss at 30 MHz, and S₁₁ better than – 20 dB over 1-30 MHz.

blue trace: S21, red trace S11, over 1-30 MHz, 10 dB/div

Next step: connect the transformer to the LC bank, and measure its actual matchspace.

Remote HF Antenna Tuner build – part 1

We have recently moved house to a place that allows putting up a wire antenna for HF. A dipole fed with open wire line would have had my preference, but that is not possible. Instead, a single wire from the roof down to the garden is possible, and the large metal roof can then act as the “counterpoise” for the antenna. Since I would like this antenna to cover all HF amateur bands from 160m to 10m, a tuner is needed. The tuner would have to be mounted outside, and therefore my preference is for a remote controlled tuner.

One option could be an autotuner, but I decided I wanted something different. Essentially my idea is the following:

Since I will only be using the tuner with this single antenna, it should be possible to pre-determine the optimum tuner settings (inductance, capacitance and topology) once and then use a Look Up Table that sets the proper values depending on the operating frequency which can be queried from the transceiver.

I started reading up on various tuner topologies, and since the metal roof appears to be floating with respect to Protective Earth, I wanted a tuner that offers galvanic isolation. This lead me to the design of the S-match tuner, “invented” by Frits PA0FRI. The S-match is elegant in the sense that it is a balanced matching network yet requires only a single variable inductor and single variable capacitor. However, I suspected that the “match space” – i.e. the range of impedances it would be able to match, to be limited. In particular, the influence of the transformer is what caught by interest. ON9CVD has done a nice analysis on the transformer influence, which can be found here (in Dutch only). Unfortunately, his “ultimate” transformer – a transmission line type transformer, does not offer galvanic isolation whenever the antenna is connected over the inductor, so that will not be an option for me as I expect the impedance of my antenna to vary over frequency in such a way that I need to either connect it over the capacitor or over the inductor, depending on the sign of the complex part of the antenna’s impedance.

My plan is to use a bank of swiched inductors and switched capacitors, using a (very) cheap “Arduino” relay board which can be found online everywhere. I used this one. This board has a few quirks, including a quite silly one as it includes optocouplers but the output transistor shares the same 5V rail as the input LED’s, so there is no galvanic isolation at all essentially making the optocouplers useless overhead. Furthermore, the inputs are active LOW, but that can be fixed in software. This page has more details on the “funnies” of these boards. In addition to the above, it appeared that the switched mode regulator on my board did not really work, so I simply clipped its pins and bypassed it with a wire as I will be powering the board from 5V anyway.

First, I started building the L/C banks, and while doing so added 100 nF decoupling capacitors on each relay between the point where it connects to the open collector of the driver circuit and ground. These capacitors serve to minimize issues due to EMI from the transmit signal back into the control circuit. I also added a couple of big fat (read: low impedance) traces using copper tape on top of a layer of polyimide tape, one for the ground connection for these capacitors and 2 more for the inductor and capacitor bank respectively.

LC bank top side, showing inductors and 100 nF decoupling caps

LC bank bottom side showing Silver Mica capacitor bank and additional traces made from copper tape

To check whether it worked, I wrote a small Python script to characterize the inductance and capacitance. I used my VNWA3 for that, in combination with this nice script to automate taking measurements. I used an S11 measurement at a frequency of 1 MHz, 1000 points are taken and then averaged. The inductance / capacitance is then calculated from the S11 value. Probably, the RF IV method provides more accurate results especially at impedances significantly lower or higher than 50 Ohms, but since I still need to build my RF IV head, I settled for the S11 method.

A couple of PCF8574 IO expanders controlled by a Teensy microcontroller which in turn is commanded by a Python script, control the relays.

VNWA3 used to characterize the LC bank

Below are some initial results:

Measured inductance

Measured capacitance

As can be seen, the curves are fairly linear, with a few issues in the inductance curve probably caused by inaccuracies in the inductor values and / or parasitic inductance. What is also visible is parasitic inductance and capacitance at the “all off” settings (commanded value = 0xFF), which is partly due to the wires connecting the LC bank to the VNA, partly due to layout capacitance on the LC bank. Also, since the relays control inputs are active low, the inductance / capacitance decreas with increasing commanded value, but that can be fixed in code later.

In the next post, I plan to have a look at determination of the “match space” for the tuner, and compare that to the actual impedance of my planned wire antenna.

Phaselocking to Es’Hailsat-2 / QO-100’s upper PSK400 beacon

Introduction

I have been playing with a downlink receiver flowgraph for the QO-100 narrowband transponder in GNU Radio. There appear to be a multitude of interesting methods people use to cancel LNB drift, ranging from the “classic” GPSDO approach to using a stable 10 GHz source injected into the LNB (PA0SSB does that). Also, some FFT-based approaches for locking to the upper PSK400 beacon are in use as well as systems that lock to the Engineering beacons in the “commercial” Ku band such as the one developed by DB8TF. I wanted to try phaselocking to the 400 baud PSK beacon at the upper edge of the passband, this post describes how it was done.

QO-100 upper beacon

The upper beacon is a Binary Phase Shift Keying (BPSK) beacon at 400 bit/s (uncoded), identical to AO-40’s uncoded beacon. Manchester encoding is used, which is a clever way of embedding the data clock into the signal, and this removes energy at DC which for some applications can be helpful. It is uncoded, meaning that no Forward Error Correction (FEC) is used. For QO-100, that is fine, as there is no spin fading to counteract like on AO-40 and the SNR is large enough such that bit errors are minimal.

Carrier recovery for phase shift keyed signals

BPSK (manchester encoded or not) with 180 degrees phase difference between each symbol is a form of suppressed carrier modulation, and is in fact the digital equivalent of analog Double Sideband (DSB) modulation. This means, that there is no carrier to lock onto. An ordinary PLL (acting on a real signal) is unable to properly track such a signal. However, a Costas loop (which is a complex form of a PLL) is able to do that. In fact, Costas loops are used to coherently demodulate PSK signals, where the Costas loop locks to the (suppressed) carrier, regenerates this carrier coherently (meaning that it is in-phase with the original carrier), and therefore can be used to demodulate BPSK by multiplying that carrier with the incoming data stream and subsequently low pass filtering it. Mathematically, it can be proven that this form of demodulation is optimal, yielding the theoretically expected performance in terms of bit error rate as a function of SNR (or its digital equivalent, the” Energy per bit divided by the noise power spectral density” ratio or Eb/N0 in short).

Application in cancelling LNB drift

Now, if we use a Costas loop to demodulate QO-100’s beacon signal, we can recover the original carrier phase. Since frequency is mathematically speaking the time derivative of phase, we automatically also recover the frequency. And that is what we can use to cancel LNB drift.

All signals coming from the LNB, including the beacon, will experience the same frequency drift as the LNB’s reference crystal (typically 25 or 27 MHz) drifts a bit with frequency. Note that for a 25 MHz crystal, and an LNB set to receive the “low” Ku band between 10700 and 11700 GHz, the LO frequency is 9750 MHz which means that the LNB reference is multiplied by 9750 / 25 = 390. So if the crystal drifts by 100 Hz, the LNB LO drifts by a whopping 39 kHz… way too much for narrowband signals such as SSB or CW (or digimodes).

So, if we can generate a local copy of the beacon carrier, and determine its frequency offset relative to the expected frequency of the beacon, we can then frequency shift the entire incoming frequency band by that amount. The result is that the LNB drift is cancelled.

Loop bandwidth and such

Now there is a bit of a caveat, any feedback control loop (and the Costas loop is a feedback control loop) can only counteract disturbances which fall within its loop bandwidth. So that means that if the LNB LO frequency (and thereby phase) varies a lot with time, the loop is unable to compensate. Time variation of phase is equivalent to phase noise, so theoretically it means that the carrier regenerated by the Costas loop has a phase noise which is dictated by its reference (the beacon signal), within its loop bandwidth. (There is a whole lot more mechanism playing a part here but I am leaving that out for clarity’s sake).

Implementation in GNU Radio

So, let’s get to work. Fortunately, GNU Radio includes all the blocks we need as part of its source tree, so no need to install Out Of Tree (OOT) blocks.

SSB receiver – input stage

First, signals from the LNB enter the flowgraph through the USRP source block. There they are mixed in a complex mixer (i.e. one that simply shifts the frequency spectrum) by a signal generated by the drift correction receiver. But let’s assume that that signal has 0 Hz frequency right now, so the mixer does not do any frequency translation. Then, the signal is passed to a waterfall and FFT sink  for displaying the transponder signals. 2 subsequent mixers and associated oscillators perform tuning by translating the input spectrum such that the wanted signal (suppressed carrier) appears at 0Hz (note that the SSB demodulation happens here). 2 mixers are used, one for coarse tuning and one for fine tuning. The complex conjugate operator is used to convert from positive to negative frequencies to ensure the frequency translation direction is correct. The coarse tuning oscillator can be set by double-clicking on a signal in the waterfall. (Can also be done from the FFT, for that, connect the “freq” message port of the QT GUI Frequency sink to the coarse tuning oscillator “freq” message port as well.

The USRP center frequency is determined by a slider which sets the approximate LNB reference frequency (labelled “LNB frequency correction”). From that, the LNB LO is calculated and from that, the IF frequency is calculated (around 739 MHz). This IF frequency is then set in the USRP.

SSB receiver – filtering and decimation

Note that now that the SSB signal has been downconverted, we can reduce the sample rate. This will greatly limit the amount of computations required in filtering that is performed on the SSB signal. A rational resampler is used to convert to 44.2 ksamples/sec. After that, a bandpass filter that filters positive frequencies (USB) between 300 and 2700 Hz is used as the SSB filter. After that, a fast attack / slow decay AGC controls the output level. Then, in order to be able to process the signal as a float (and since we have rejected the opposite sideband), we can convert the signal to a real signal. Optionally, a tone from another oscillator can be added to the audio which is representative of the level of the beacon. This can be used for aiming the dish, more on that later. Note that for the SSB receiver, I was inspired by Alex OZ9AEC’s flowgraph which can be found here, thank Alex! Note that the sample rate of the receiver is slightly higher than that of the audio sink (44.2 kHz instead of 44.1 kHz), in this way, the common two-clock problem can be avoided, at the expense of slight frequency inaccuracy in the reproduced output signal.

Beacon receiver

Up till now, the flowgraph behaves like a normal SSB receiver, which can be tuned anywhere within the transponder bandwidth. Now, let’s look at the receiver chain for the beacon.

The beacon signal receiver is centered around the expected beacon frequency, assuming that the transponder center frequency is at zero frequency it would appear at + 125 kHz.

A frequency translating FIR filter is used to downconvert the beacon signal to approximately 0 Hz. (Note that in fact, the SSB receiver described above could simply be replaced by such a frequency translating FIR filter, as it does exactly the same). The filter also performs decimation by a factor of 10, to 48 ksamples/sec. Next, the signal passes through an AGC, this AGC is there because the Costas loop behaviour (in particular, its loop gain) is dependent on the magnitude of the input signals. The AGC makes sure that this magnitude is kept constant. The output of the ferquency translating FIR filter is also passed to a block that measures the average power of the beacon signal, this value is then converted (using a probe signal block) to a tone by means of an oscillator whose signal (at audio) can be optionally added to the audio from the SSB receiver. This can act as a beacon strength indicator, helpful for aiming the dish. The downside is that there is a bit of latency on this signal so moving the dish should be done very slowly.

The Costas loop outputs a number of streams, first of all a complex stream which is the “downconverted” spectrum (i.e., the input signal multiplied by the regenerated carrier). This stream is connected to an FFT sink which can act as a lock indicator. When the loop is locked, the “null” of the beacon signal (i.e. the valley in the middle) coincides with 0 Hz.

The other output of the Costas loop labeled “freq” outputs a float representing the frequency of the recovered carrier, in radians per sample. This is the output we will use to correct frequency drift.

Closing the loop

The floats (at 48 ksample/sec) out of the Costas loop representing frequency are passed to a multiplier, which multiplies with either 0 or 1, depending on whether “beacon track” is enabled. a Probe signal block is used to tap off the frequency value, and display it in the GUI. Since we have to ultimately multiply the locally generated carrier with the incoming stream at 480 ksamples/sec, a rational resampler interpolates back to that rate. Finally, a VCO block is used to generate the mixing signal. Its sensitivity is set to 48000 / (radians per sample) to  set the proper output frequency scaling. The minus sign is used to ensure that the drift correction term is applied in the proper direction. Like the SSB receiver, a “Complex Conjugate” block could have been used just as well here. The VCO output is fed to the first mixer in the flowgraph, described in the SSB receiver section. Now, when the loop is locked, the input to the SSB receiver is automatically drift-corrected.

Notes on Costas loop bandwidth

Note that in GNU Radio, the Costas loop bandwidth is expressed in terms of normalized frequency relative to the sample rate. Next to that, it is expressed as angular frequency in radians per second. Remember that 1 Hz = (2*PI) rad /sec. So for a sample rate of 48 ksamples/sec, a loop bandwidht of 1 kHz would be expressed as (1000/48000) * (2*PI) = 0.131 radians per sample. The “magic” recommended loop bandwidth for the Costas loop commonly used in GNU Radio is 2*PI / 100 = 0.0628 rad / sample which in our case equates to 480 Hz. I made the loop bandwidth adjustable by means of a slider so I could experiment to find the best setting. For me what works, is to start at 0.01 rad/sec, set the slider labelled “LNB frequency correction” such that the beacon is at approx 125 kHz, and then lower the loop bandwidth to 0.002 after the loop locks.

Notes on input SNR

It appears that the system needs a certain minimum SNR of the beacon to lock reliably. Trials by the author with a 35×45 cm dish have shown that it is possible to achieve lock, but there is not much margin. Larger dishes should work better.

Download & operation

The flowgraph can be found in this Github repository

Operation of the flowgraph is as follows.

1. Adjust the slider “LNB frequency correction” such that the upper beacon appears at approximately +125 kHz in the “corrected input spectrum” FFT and waterfall. If another frequency is preferred, change the “expected beacon frequency” value. Bandwidth of the beacon tracking receiver is set to +/- 10 kHz (so 20 kHz in total). Some experimentation may be required to set a good value depending on the total amount of LNB drift.
2. Check that the beacon signal is visible in the Costas loop output FFT. Since the loop is not yet locked at this stage, the valley between the 2 “humps” will most likely be not near 0 Hz
3. Tick “beacon track enable”, and check that the valley moves to 0 Hz exactly
4. Lower the loop bandwidth to 0.002 or any other value that works best. I set the SSB receiver to the lower beacon (tune to -124 kHz to receive it with 1 kHz pitch, assuming a beacon frequency of + 125 kHz), and listen to the quality of the tone while I adjust the loop bandwidth slider
5. Tune the SSB receiver to listen to the transponder.

Next steps

The following steps are planned:

1. integrate EA4GPZ’s GNU Radio QO-100 beacon decoder (https://destevez.net/2019/02/decoding-the-qo-100-beacon-with-gr-satellites/ )
2. integrate with my uplink generator flowgraph to yield a complete SSB transceiver.

 

 

Getting ready for Es’hailsat 2 – GNU Radio SSB generation flowgraph

With Es’hailsat-2 in orbit, I thought it was time to start thinking on how to generate an uplink and receive the downlink of the narrowband transponder. Instead of using an existing radio + transverter I plan to use my USRP B205-mini for this, since it can directly generate an SSB (USB) signal at 2.4 GHz, while at the same time (full duplex) receive an IF at approx 739 MHz from an LNB. It would then need a driver amp + final stage and perhaps some bandpass filtering to generate 10-20W PEP. So, I set out to develop a flowgraph to generate an USB signal on 2.4 GHz. Next step will be to include a downlink receiver into the same flowgraph but since I have not yet acquired an offset dish and LNB, I decided to focus on the uplink first.

I took inspiration from Alex OZ9AEC’s SSB generation flowgraph, tweaked this to suit my needs and came up with this:

In addition to taking a microphone input, it can also generate a (pulsed) two-tone, which can be used for checking IMD levels, noise (to check the SSB filter transfer) and a CW beacon which can be used as a test-loop while trying to find one’s downlink. It is of course not advised to use the noise and two-tone modes on the transponder, as that will not make other users very happy :).

The two sine waves of the two tone generator have an amplitude of “0.5”, to ensure that upon modulation peaks, the summed output of these 2 tones into the USRP has an amplitude of “1”.

You will notice that I set the audio sample rate to 47000 samples/sec whereas the audio source (soundcard) uses a sample rate of 48000 samples/sec. This is done to avoid the “two-clock” problem, which is described here (search for “2-clock” on the page).

The CW beacon is contained inside a wav file, I wrote a small script in Python to generate a wav containing a custom CW beacon, the CW beacon generator script can be found here.

One notable downside of the SDR approach is the additional delay between the audio entering the system and the corresponding RF being sent out. This adds up to the propagation delay from Earth to the satellite and back. Practice will tell if it is acceptable.

Next step: include a downlink receiver with a waterfall / FFT, which can be tuned synchronously with the uplink.

The flowgraph can be downloaded here.

 

 

Golden Oldies

Sometimes, old stuff is fun. I especially like listening to medium wave broadcast stations, and remember the days when there was a national station on 828 kHz broadcasting classic rock music. Just that warm AM sound can be very pleasant to listen to. Recently, the Dutch regulator has issued Low Power AM licenses on a number of frequencies, including 828 kHz. I hooked up my LZ1AQ active loop antenna to my homebrew HF receiver (transceiver actually) and scanned the band. To my surprise could receive Radio Wereldstad from Hoogvliet (approx 25km) during the whole day. They were playing some nice golden oldies!

Homebrew HF TRX tuned to 828 kHz

GPSDO finally boxed!

I have finally boxed the GPSDO. Still some remaining work on the software (lat/lon display is missing a decimal point for instance), but so far it works nicely and does a good job of reflocking my USRP and VNWA3E. I have included calculation of the Maidenhead gridsquare from the lat/lon data.

Today I attached a surplus active GPS antenna and battery to the GPSDO and took it for a walk. I happen to live very close to a gridsquare junction, so by walking 100 meters I could verify that the Maidenhead gridsquare calculation showed 3 different gridsquares during the walk as expected:)

GPSDO with temporary GPS antenna attachment

 

Eggbox radio

My new USRP has arrived, and since the case has not been delivered yet but I wanted to play with it already, I had to come up with a temporary case. Eggboxes do an excellent job of protecting their fragile contents, so that is what I used.

 

Ultimately, next to using it as an SDR development tool, I would like to use it for the Es´Hailsat Phase 4 amateur transponder. First tests with GNUradio look very promising, I put together an NBFM transceiver. Now I need to improve my antenna since the indoor magmount was not good enough to listen to PI2NOS, but at least I could open the local repeater with the TX. No QSO´s made yet.

 

GPSDO revitalization

Back in 2006, I built a GPSDO based on James Miller (G3RUH)´s design which can be found here. The PCB ended up in the junkbox eventually.

Now, with AMSAT Phase 4 around the corner, I have a need for a stable 10MHz, from which I can derive stable higher frequencies (for a 10GHz LNB, 2.4GHz upconverter etc).

Therefore, I started doing some ¨revitalization¨ (tnx PA3FYM for the term!)

As the Jupiter GPS RX was missing, I got a new one (used of course still, these GPS engines are about 20 years old!). I replaced the 7805 regulator by a TRACO DC/DC converter (I don´t think those were available yet 10 years ago), and started rewriting the PIC code.

I used the JALv2 language (see here). Why? because JAL (Just Another Language), from which JALv2 is derived, was first used by ¨De Jonge Onderzoekers¨, an electronics club for youth in my former hometown Amersfoort. I was a member of this club in the nineties, and got bitten by the RF virus around that time.

Instead of using the NMEA protocol, I opted for using the Zodiac Binary protocol, which is more efficient and contains much more information. It is also easier to implement IMHO.

A video showing the GPSDO acquiring a GPS fix and subsequent 10MHz lock can be found here.

RX antenna switchbox

I am using an Elecraft KX3 + KXPA100 linear amplifier, sometimes with separate RX antennas such as LZ1AQs excellent loop. Since the KX3 (and KXPA100) do not have a provision for a separate RX antenna input, I built my own switchbox using fast DPST reed relays (I know, SPDT would have done the job easier with less components, but I happened to have these on hand).

A basic schematic is provided below. (Note, as with all projects on this blog, use of this switchbox is at your own risk, I am not accepting any responsibility for burnt-out finals, destroyed radios, grumpy (X)YL´s (hi) etc. etc.)

Normally speaking, the PTT input controls the switchover. For the case where the PTT input is not connected / not working for whatever reason, an RF VOX  is included to protect the RX antenna. This VOX is however slower than when using the PTT input and it is not very practical when using SSB (chattering relays), but it does provide an extra degree of protection. On my box, I have added a yellow ¨VOX¨ LED (not shown on the schematic), which shows the user that the VOX is engaged and that he / she should fix the PTT input 🙂