No shortcuts. Work for it.

Category: GNSS Receiver Development

hexadecimal to binary converter

The C-code snippet below is something I wrote to read a hex character from a file and convert each bit into a sample of byte length. Because how my hex file was written I had to decode even characters before the odd ones, you’ll notice in the code. If you need something similar feel free to tweak the code below.

Input hex file format (filename.dat):


Output file format(filename.bin):

00 01 00 00 01 00 00 00 01 01 00 00 00 00 01 00

If you notice the converter takes the even character first and reads LSB to MSB and then reads the previous odd character (LSB to MSB) and so on…
There are many ways of doing this in C or Python but MATLAB is not one of them! Why? Because it is just too SLOW.
This is a good binary file reader.

FPGA-based software GNSS receiver: Tracking issues (Progress Update 1)

Mini-update (01.10.2018): DATASET2** has 8 sample bits packed in bytes which the MATLAB receiver doesn’t like to deal with – even if you specify the data type as ubit1. Best way forward would be to write a script to separate out the bits and create a new data file. (I wrote a C-based converter to take hex values converts it to bits and stores it as individual samples in an int8 format. That seems to work with the receiver.)

My last post talked about how tracking occured periodically. After extensive debugging I found out that the input GPS signal data stream lost about 3 sample bits everytime I would switch between FIFOs (I have two FIFOs acting like ping-pong buffers). In retrospect it is probably not the way to design input buffer streams. Also the test bench I wrote for testing FIFOs would have never caught the problem/bug (now I know).

My new tracking plots look like this (Figure 1):


Figure 1: Tracking results

As you know ideally all the power should appear in the I arm only. This is not the case according to the results.


Figure 1: DLL and FLL discriminator errors

I implemented a Costas loop according to the design and parameters in Scott Gleason’s software receiver. The hardware accumulators pass the values to the microprocessor/ARM every 5ms for tracking loop corrections. So the update to the tracking loops occurs every 5ms or so. Changing filter constants didn’t help my case at all either.

As a different approach to this, I used a DMA to collect about 256 ms of 1-bit GPS data and processed it with various software receivers.

With Kai Borre’s receiver, it acquires the satellites but can’t track them. (I wonder if it is the data format… I do specifiy the data type to be ‘ubit1’ though.)

I tested with my own software receiver and observed the same results, can acquire but can’t track.

Figure 4 below are the ideal results… and Figure 5 is what happens when I process 1-bit GPS data with the same receiver.


Figure 4: Tracking result using Kai Borre’s software receiver (2-bit GPS signal) (DATASET1*)


Figure 5: Tracking result using Kai Borre’s software receiver (1-bit GPS signal) (DATASET2**)

I’m starting to think it is something to do with the dataset itself!

I found a 1-bit GPS dataset online here (DATASET2**). The two software receivers behave similarly. Acquire but don’t track. I think there’s something I’m definitely missing… related to the format perhaps?

DATASET1* GPSdata-DiscreteComponents-fs38_192-if9_55.bin

DATASET2** see link.

DATASET3 (click to download from Google Drive)

[DATASET3 is a short 256ms long 1-bit GPS L1 dataset where each sample is of the type int8, sampling frequency: 16.368 MHz, IF: 4.092 MHz, satellites present: 1, 5, 11, 12, 17, 30]

DATASET4 (click to download from Google Drive)

[DATASET4 is a 500 ms long 1-bit GPS L1 dataset where each sample is of the type int8, sampling frequency: 16.368 MHz, IF: 4.092 MHz, satellites present: 1, 11, 14, 17, 19, 20, 22, 30]

Note: A big thank you to Michele Bavaro for taking interest and providing some suggestions that indeed helped me move ahead (onto the next problem!).



MAX2769 Evaluation Kit: Clock for GPS Receiver

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.


© 2019

Theme by Anders NorenUp ↑