AFC - automatic frequency control

[sgofferj]

AFC would be an extremely valuable feature (which also to my knowledge no other OSS SDR RX software has) AFC analyzes the signal which is currently within the filter band and adjusts the frequency is necessary and possible. Advantages:

• Doppler shift correction in satellite systems
• Frequency drift in HF signals
• Compensation for imprecise transmitters
• Compensation for RX module drift

=> Best possible signal reception which is especially valuable for decoding data transmissions.

[kitesurfer1404]

I want to give this a little push. This seems to be an useful feature to compensate LNB frequency drift when receiving satellites, e. g. QO-100. See also: https://forum.amsat-dl.org/index.php?thread/136-software-lnb-drift-correction/ There is also an example script included. Some SDR software like SDRConsole added this feature already, see https://www.sdr-radio.com/EsHail-2

Maybe some sort of selecting the signal source, setting the known frequency, calculate the drift and feed this into the "frequency correction" in the input controls tab.

[pe1chl]

Some more clarification on what is desired and an implementation suggestion:

The EsHail-2 satellite carries an amateur radio transponder Qatar-Oscar 100 (QO-100 for short) which has a 13cm uplink and 3cm downlink. A commonly used receiving solution involves a PLL-based Ku-band DTH TV satellite LNB and an SDR receiver using an RTL stick or similar. The narrow-band transponder has a bandwidth of 500 kHz and is to be used for transmissions of up to 3 kHz wide. Commonly used modes are CW, SSB, and digital modes.

Unfortunately the stability of the crystal-locked LNB is not really sufficient for those modes on 3cm (10489.700 MHz). Drift of about 20 kHz is usually observed on these LNBs. Constant tuning is required to keep SSB signals audible, digital modes are usually impossible using such a freerunning setup. It is possible to lock the LNB local oscillator to a GPS-derived frequency standard, but that involves opening and modification of the LNB, either an extra cable or some multiplexing of the reference signal and the downlink signal, and an indoor GPS locked frequency standard.

However, there is another possible approach: the satellite downlink contains beacon signals of a precise frequency. The idea is to "lock" on these beacon signals and make the selected receive frequency relative to these beacon frequencies. When the local oscillator in the LNB drifts, the perceived beacon frequency changes by the same amount as the frequencies of the stations, and that offset can be subtracted so the stations appear at a fixed frequency when the LNB drifts.

There are 3 different beacons. Two of them are FSK-keyed CW beacons (1 kHz shift). The 3rd is a 400 baud BPSK modulated signal. The latter one is probably easiest to use because its center frequency is always the same. 400 baud BPSK demodulator flowgraphs are wellknown and they lock onto this center frequency.

Some other software has already implemented this locking feature, and also some people have created "external" solutions so the SDR software does not have to be modified. However, an integrated solution is easier to use.

There appear to be two different approaches possible:

1. the beacon frequency is examined and the "LNB LO" value is manipulated at some interval to compensate the observed beacon frequency
2. a separate mixer frequency is generated, locked to the beacon frequency and this signal is then mixed with the received signal before it is fed to the general demodulation

The difference is subtle. The first approach appears to be the most logical and will likely involve the least changes in the code, however it could lead to a slightly more "jerky" behavior, of course also depending on the rate at which the LNB LO setting can be updated. I have experimented with some external code that uses the API and in that case it is difficult to update it fast enough to be inaudible, and digital modes are difficult. When integrated with gqrx it may work well. I think the solutions mentioned above all use this method (implemented in their respective programs)

An example of the second approach can be found here: https://github.com/pe4wj/eshailsat2 This is a GNUradio companion flowgraph that either operates standalone (providing a rudimentary SDR receiver that is difficult to use) or it can operate as a frontend that receives the SDR samples, mixes the locked signal with it and outputs a new stream of samples to a FIFO which is then received by gqrx.

It would be very desirable when this is integrated into gqrx. When studying the matter, I found that gqrx internally does not load a .grc file for its GNUradio flowgraph, but rather sets this up using direct function calls. Maybe it could be considered to convert this static flowgraph to a .grc file and load it on startup, so it would be much easier to experiment with the SDR core of gqrx. (adding features like this AFC, but also allowing easier addition of demodulators for digital modes into gqrx)

When that is done, and a GUI widget is added to set parameters and show status, it should be possible to merge this solution with gqrx "relatively easily".

There has been another fork on github that included the required GUI widget, but it has been deleted. I should still have a backup of that code somewhere, when required.

[argilo]

Thanks for the information @pe1chl! Do you have an I/Q recording you could share? That would probably be helpful for anyone who wants to take a stab at implementing this.

[pe1chl]

I have made a recording of 3 minutes, after a minute I have used a trick to introduce some more drift (switched on my sat receiver which is connected to the second port of the LNB). Unfortunately such files are very large, I cannot attach them here. I can host it on my website but only for limited time. It currently is here: https://pe1chl.nl/recording.zip