Pseudo Channel Synchronization

The process behind generating a solution for pseudo-channel synchronization was a complicated one. A significant amount of time was invested in trying to solve this issue in software. Due to the architecture of GNU Radio, feedback loops are not allowed within a flowgraph, unless they are explicitly bound within a block. This project took a few aggressive approaches to try to get through this problem:

1. Delay by a number of samples as a function of frequency and directly phase shift
2. Estimate the number of samples between each peak of a sinusoid
3. Adaptively calculate phase differences and shift accordingly
4. Synchronize channels based on decoded symbols (see: Symbol Sync Block in GNU Radio)

As it turns out, 1. was the best solution to our problem. The issue with other approaches such as 2. is that it’s impossible to sample at a perfectly consistent rate, even if a user implemented a throttle block to regulate sampling performance. The number of samples in a signal was initially approached using a variety of sampling and holding techniques, eventually abandoned in favor of writing a Python block that counted the number of samples until a signal input told the block to output signals and reset the counter. Adaptively calculating phase difference would require generating a feedback loop. Ordinarily, we would have done this in C++ or Python within a single block for GNU Radio, but this topic was beyond the scope of our expertise and perhaps even the main developers of GNU Radio. There was a fourth approach we tried using the Symbol Sync block in GNU Radio, which uses polyphase filtering and a variety of other techniques to synchronize a channel with a particular codeword, however, this had to be abandoned. There were two reasons this approach was abandoned: The functionality of the block was extremely buggy to the extent that most of the GNU Radio community has had little success with it. Additionally, the block would require us to know some existing information about the decoded satellite telemetry. Not only is it difficult for us to make assumptions about what satellites would be received, but also we would have to redevelop the architecture of the entire software project. This would require having two decoders before the combining blocks. From prior tests, we’ve already had significant difficulty with consistently decoding data from a saved set of samples. Moving forward with the ‘delay and shift’ technique, we derived a variety of models to attack this issue. Our initial derivations were confirmed in an ideal setting using GNU Radio. Our initial model for delaying by a number of samples, d, was a function of the sampling frequency, f_s, a fixed initial reference carrier frequency, f_r, a new carrier frequency that could be anything f_new, and the initial phase difference, Δϕ_0.

d=(f_s f_r Δϕ_0)/f_new

A strong sinusoidal signal was transmitted at 145 and 146 MHz so that it would be easy to distinguish the phase difference between the transmission lines. There are two important notes to keep in mind here: When the channels are out of phase by over half a wavelength, directly phase-shifting two signals will probably make synchronize the wrong symbols together. Additionally, a critical observation was made for examining Figure 7 and its counterpart for 145 MHz : The time delays between the channels were not consistent. After simulating an approximate model for the coaxial lines in MATLAB, it was apparent that the phase differences between the transmission lines were a function of frequency. This forced us to linearly estimate the delay between two channels: Δϕ=(t_2-t_1 )(f_new-f_1 )+t_1

In this case, f_1=145 MHz, t_1 is the delay between the two channels at 145 MHz and t_2 corresponds to the difference in arrival for f_2=146 MHz. Our new value of Δϕ factored into d to become: d=(f_s f_r ((t_2-t_1 )(f_new-f_1 )+t_1 ))/f_new Due to the nature of GNU Radio, the number of samples delayed has to be an integer. Meaning we have to alter our function to be rounded to the nearest integer formally expressed as: d=⌊├ (f_s f_r ((t_2-t_1 )(f_new-f_1 )+t_1 ))/f_new ⌉┤