This post discusses the results of hardware acquisition and some of the current issues I’ve come during tracking of the acquired GNSS signals.
My focus has been implementation of a real-time software GNSS receiver using an FPGA.
My equipment setup is such that I have a GNSS simulator generating GPS signals which are fed into the RF front end. The digital GPS signals are now input to the FPGA development board and this is where all the processing is done in real-time.
I spent quite some designing the flow of data signals from the simulator to the FPGA platform. Extensive work was done by me to setup the interfaces and the protocols.
I’ve managed to complete the implementation of the acquisition module and have been successfully able to acquire satellites in real-time!
I do have a persistent tracking issue however…
Issue: Tracking occurs only at regular intervals for a short duration
Below are some figures showing tracking results.
- Figure 1: Represents the correlation strength of the IP accumulator (Inphase-Prompt). Expectations are to have a high correlation strength throughout the tracking duration. High correlation however occurs only at certain intervals.
- Figure 2: This plot compares all the accumulators (Combination of I & Q with Early, Prompt & Late). You immediately notice how all the peaks for all the accumulators occurs at the same time stamps.
- Figure 3: Becomes more obvious with this plot that ALL the accumulators have high values at similar time intervals
- Figure 4: This was an interesting plot! I basically zoomed in on the peaks to see what was going on. I noticed how the power would move from Late, Prompt to Early. Every single time. This was a noticeable trend at all the peaks.
The final figure (4) told me that the PRN in the input GPS signal and the one generated on the board do not align during tracking EXCEPT at those peaks.
I went back to check my PRN generators and they work as expected. So if it is not the local PRN signals then what could it be…
That shifted my attention towards the input GPS signal itself. The sampling frequency I used was 20 MHz but perhaps it is not exactly that number? I say this because according to the set sampling frequency, there are 20,000 samples per millisecond. But clearly the PRN in the input signal is shifting (from Late to Early). So does this mean the sampling frequency (aka number of samples per milliseconds) is shifting too? I’m doubting everything at the moment but if you’ve picked up any leads from the figures please let me know as I struggle on to fix it…
Email: surabhisgp [at] gmail [dot] com
This post exclusively talks about MAX2769CEVKIT.
I have used the evaluation kit for my GPS Receiver development for about ~2+years. When it came to real-time GPS signal processing, things fell apart during the signal tracking phase. After extensive debugging I realised the clock source on the MAX2769C EVKIT was not good enough to support GPS receivers. GPS receivers require a stable and accurate clock for good signal and a reference clock source running via a wire between the front end and the receiver is just a bad idea. Ideally, you want to have the clock source (or the MAX2769 chip) on the same processing board to minimise the phase noise that could be added from the environment or during transmission.
In the board setup image below, ext_clk is the 16.368 MHz clock source. The clock is fed from the front end into the Zybo. I initially wanted to use the 16.368 MHz clock for all the processing as that was the chosen sampling frequency as well. It did not work out how ever as the FIFO in Zybo (FPGA) refused to accept it as a clock signal.
On further investigating, I noticed the deteriorated clock quality received at the Zybo end.
GPS Receiver Setup (copyrighted)
The first waveform (external_ports_clk_in1) is the clock received as is at the input pin. A lot of harmonics and phase noise is present making it a useless source of clock. There was a need for clock conditioning (to remove jitter) which is why I used Xilinx’s inbuilt core Clocking Wizard. The output of the wizard core is the second waveform (clk_wiz_0_clk_out1). it certainly looks better but the FIFO would still not accept it as a legitimate source of clock. This is a very small snippet provided so there’s a possibility the harmonics and jitter show up at other intervals. The third waveform (FCLK) is simply a clock signal produced by an onboard clock available on Zybo, which is the best of all the three clock signals.
Clock signal comparison (on Zybo) (copyrighted)
This shows that using a clock source from the front end of MAX2769C is not the best idea and avoid it if you can. If you used the clock source successfully I would very much be interested in hearing from you!
So why not just use the good quality onboard clock? Here’s the catch… The sampling frequency/reference clock of the front end must match with that of the on board clock. Sampling frequency is set up to be 16.368 MHz. The closest frequency that the onboard clock can produce is 16.392 MHz. This might be reasonable for a lot of applications (works for GPS acquistion too!), but not for GPS tracking unfortunately (needs to be exact! and stable).
As a work around I changed the sampling frequency for MAX2769C to 20 MHz (a round number). But there is no way of confirming if this change was actually implemented on the front end. I’m working on GPS data acquistion and will later process it on my PC-based software GPS receiver to check if the sampling frequency did actually change to 20 MHz.
But another uncertainity with using an onboard clock to reference the arrival of the front end data is the phase difference or the delay between the two signals. I’m not sure how that will work out but its something to test for the future.