Basic funcitonality

[Heuber]

Dear Slaaja,

thanks for this great GPS-Blocks for GNU-Radio!!

But I´ve one big problem. Your blocks are working fine in testbench, even with much simulated noise. But in real operation i wasn´t able to track satellites for weeks. I´m using an active GPS-antenna (outdoors) with overall gain 35 dBi and a powerful FMCOMMS-SDR from analog devices. Sometimes acquisition succeeds, but tracking never works, the PLL is going crazy.

To be on safe side, have your blocks ever worked in real operation? I think you use a Blade-RF, but my FMCOMMS should also be enough powerful.

Hoping for help, Heuber (mechatronics student).

[slaaja]

Hello Heuber,

First of all, sorry for the slow response. As you might have noticed, I haven't been actively working on this thing for a while. It's not abandoned, but it's just that I haven't had time to play with it.

I have been able to track satellites using these blocks and a bladeRF with a Morecom RFM4000 active GPS antenna (2,5dBi antenna gain, 30dB LNA with 2dB NF). Here's a picture of my super ghetto antenna arrangement, and a video of it working: http://koti.kapsi.fi/~smau/bladerf/20140828_001.jpg http://koti.kapsi.fi/~smau/bladerf/20141015_001.mp4

As you can see, it loses track in the end of the video. If the signal-to-noise ratio is extremely low, the tracking PLL starts to confuse the PSK modulated navigation data noise with noise and it will just start tuning the frequency all over the place. When there is sufficiently large frequency error, the spread spectrum sequence will not despread correctly and you will not get the despreading SNR gain. If this happens, the system can't recover because it doesn't know which way to tune the chip phase or the frequency correction because all it's receiving is noise.

With the external antenna/LNA and the bladeRF at maximum gain, I'm getting overall 96dB gain before the ADC. I haven't done any link budget analysis for the matter but my receiver is short on gain because I'm not getting anywhere near full scale ADC output. This is probably why the blocks work so badly, but at least they work. :)

Hope this helps.

-samu

[Heuber]

Hello Samu,

great thanks for your answer. It´s good to know that gr-gps generally works and I don´t ned great performance. I´ve been studying your source code for several weeks now and I´m asking if there are a two critical bugs inside, which decrease performance significantly? I hope you have the time to discuss this issues with me.

1.) Bit synchonisation:

// remove navigation data from phase tracking: // ignore fast > pi/2 radian phase jumps if(!fix_done) { if(freqerror_trunc+freqerror_trunc_d > M_PI/2 ) { fix = -M_PI; fix_done = 1; track_counter = 0; // align code tracking with input data } else if(freqerror_trunc+freqerror_trunc_d < -M_PI/2 ) { fix = M_PI; fix_done = 1; track_counter = 0; // align code tracking with input data }

This can´t work? Supposed we have no noise, then freqerror_trunc changes from 0 to PI, wenn navigation bit changes. Then, you are right, track_counter has to be reseted. But before, you remove this important information?:

while(freqerror_trunc > M_PI/2) freqerror_trunc -= M_PI; while(freqerror_trunc < -M_PI/2) freqerror_trunc += M_PI;

So, track_counter never aligns correct?

2.) Bit output

Supposed no noise, the output should be -20460 or 20460 (spreading code length 1023 * repeititions 20). There are always 1023 chips despreaded:

gps_despread_impl::track(const gr_complex in, gr_complex out, int noutput_items, int &noutputs) { int consumed; noutputs = 0;

for(int i = 0; i < noutput_items1023osr_int; ++i)

But in general work, the output always gets reseted:

gps_despread_impl::general_work(int noutput_items, gr_vector_int &ninput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_items) { const gr_complex in = (const gr_complex ) input_items[0]; gr_complex out = (gr_complex ) output_items[0];

int noutputs = 0;

out[noutputs] = 0; // reset integrator

So, the output don´t use the full spreading code repetitions and as a result, it lose much correlation gain?

Thanks for your picture and video! Can you tell me which pll loop filter parameters and low pass coefficients you used? And what means the output "track_mode" on the display? I can´t find this in your source code, maybe theres a newer version? :-)

Hope you can help me. I would be very grateful!!

heuber

[slaaja]

Hi,

I had to study the code myself for a while and wonder what past me had been thinking but I think I got it now.

1) Looks like you're right. The while loops should probably be inside the if(!fix_done) block in their corresponding places. Now it never aligns the track counter.

2) In forecast() it is set that the block only takes in 1023 chips and produces an output sample from them. It doesn't really matter for the output data because the matched filtering (integrate&dump) can be done afterwards for the data to get the full SNR improvement. For the frequency tracking PLL a higher sample rate is needed to be able to track frequency errors that can be in the order of 1kHz. In the code it looks like 4 samples per PRN period is used, so it's running at 4kHz sample rate, i.e. 2kHz .

I think in the video the same settings are used that are enabled in the code by default. I think the track_mode is some old debugging parameter that I used. I have no recollection of what it means.

[Heuber]

Hi,

thanks for your explanation. One question to acquisition-function. How can i set a lower doppler step as preset 1000 Hz, for example 500 Hz? Thanks for your help!

Heuber

[slaaja]

FFT resolution is set by the length of the FFT, so to get 500Hz resolution you need to double the length of the sample vector for the FFT.

[stackprogramer]

@slaaja http://koti.kapsi.fi/~smau/bladerf/20140828_001.jpg http://koti.kapsi.fi/~smau/bladerf/20141015_001.mp4

these links are broken can you update them thanks