surabhig.com

No shortcuts. Work for it.

FPGA-based software GNSS receiver: Tracking issues

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.
Fig1

Figure 1

  • 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.
Fig2

Figure 2

  • Figure 3: Becomes more obvious with this plot that ALL the accumulators have high values at similar time intervals
Fig3

Figure 3

  • 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.
Fig4

Figure 4

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

4 Comments

  1. A bit hard to tell what is going on with such little information!
    Some receiver clock drift needs to be accounted for. It manifests itself as relative velocity both on the carrier and the code. What is the Doppler frequency of that signal above? Normally with a 0.5 ppm oscillator you’d get an approximate range +-6 kHz. One peak every couple of seconds cannot be uncompensated code Doppler though.. at 4 chip/sec it’ll take a long time (about 250 seconds) between two peaks. My feeling is that here the correlator design is breaking the continuity of the input stream.. it’s like you stream packets of samples and align the integration starting point and length only at very coarse steps.

    • surabhig

      August 17, 2018 at 7:38 pm

      “Some receiver clock drift needs to be accounted for. It manifests itself as relative velocity both on the carrier and the code.”
      That’s an interesting point you made. Is there a way to determine this? is the solution for this a high quality external clock? I’m really keen on reading more papers about this, any recommendations would be great!

      The Doppler frequency is 3 KHz (my search window is +-5 KHz).

      I did thorough debugging of the hardware design, starting from the input pin in the FPGA, data buffers, correlators and also the tracking accumulators. I do not see any discontinuity in the data flow (when using Vivado simulations). As soon as I switch to real GPS data from the front end, the tracking loses signal lock… which is why I find this mind boggling. This made me look into the clock quality too. But I haven’t been able to find a solution yet. If there’s any test you think I should run, please let me know.

      Thank you so much for taking the time to read the post and provide your expert opinion, I really appreciate it.

      • A GNSS receiver needs to work on the assumption that its clock is several orders of magnitude worse than the satellite clock. The solution in this case is not to use an atomic clock on the receiver, but rather to make sure that the design can work with a fairly large clock drift (frequency error), provided that the reference still has the required phase noise and stability characteristics.

        I asked about the Doppler of that signal to try and understand if its value could be somewhat associated with the ~1.8 periodicity of your peaks. 3 kHz on the carrier mean 2 chip/second on the C/A code and about 40 samples/sec at 20 MHz (your sampling frequency). In ~1.8 seconds that amounts to about 68 samples. I think that’s close enough to 64 to be suspect. Did you use 64-bit packing anywhere in your signal conditioning?

        I would suggest you first of all verify signal integrity in your DSP chain. Could you record in a memory buffer 1 or 2 seconds of front-end signal as the one that goes to the correlators? It should be easy enough to hack something around using block-RAMs. Then you could store that snapshot on the disk of your PC and we could analyze it with a SDR and double check everything is OK.
        Sharing a block diagram of your DSP chain might also help, assuming if you’d be open to that.

        • surabhig

          August 21, 2018 at 11:42 am

          I completely agree with your first point. I originally wanted to use the reference clock generated by MAX2769 Evkit, in my FPGA design. That however didn’t work out as I observed a lot of phase noise perhaps owing to the quality of wiring between the FPGA and the evkit itself. (The FPGA couldn’t clean up the noise either). For my current design I’m using the clock available on the FPGA itself.

          About the Doppler, those numbers you estimated were a good lead! I spent yesterday trying to look for missing sample bits in the processing chain and I did catch it! I used two FIFOs and when switching between them there would be a loss of about 3 samples of GPS data, which definitely explains the apparent PRN shift that was occuring in the GPS signal. I don’t know how I missed it during testing. However, I fixed it and seem to have made significant progress, the receiver seems to be tracking the signal in real-time. I want to send you an email shortly (hope you don’t mind) updating you with the new tracking plots (better but not perfect) and describing the block diagram.

          Regarding your last point, yes recording the signal in buffer is something I’m working on (perhaps should have been the first step before I jumped in to the hardware core).

          I appreciate your help Michele!

Leave a Reply

© 2018 surabhig.com

Theme by Anders NorenUp ↑