[srslte-users] Modyfing cell_search.c to take a buffer of data

[Anderson, Douglas J.]

Hi,

I'm working on modifying the cell_search.c example to take a buffer of samples instead of using a radio or file.

To test it, I output a number of frames using the pdsch_enodeb utility as follows:

./pdsch_enodeb -o lte_test_frames -f 2400 MHz -n 10 -c 369 -p 6

I used 6 PRBs so that I wouldn't have to resample, since the 1.4 MHz channel should be output at 1.92 MS/s, which is what cell_search requires. Is the assumption that if I use the above command, I won't need to resample correct?

When I evaluate the buffer in gdb as floats, I see the

(gdb) x/20f input_buffer
0x7efdd8469fa0:    4.62548144e-07    -2.45921617e-14    -1.95454377e-05    -5.37547518e-09
0x7efdd8469fb0:    1.78484044e-07    1.96418446e-12    -4.98598851e-08    -2.2092614e-15...

Same as reading the file in python as cf.

>>> np.fromfile('lte_test_frames', dtype=np.complexfloating)
array([  4.62548142e-07 -2.45921616e-14j,
        -1.95454375e-05 -5.37547515e-09j,
         1.78484043e-07 +1.96418444e-12j, ...

When I run the above buffer through ue_sync_buffer with debug on, I get the following. Does anything jump out at you? Maybe the cp_offset_pos being consistently 49 (shouldn't it be 0?), or the large CFO?


frames_available: 1
nof_frames_to_scan: 1
[INFO]:  cp_offset_pos=49, abs=0.000305, cfo=-0.461741, mean_cfo=0.024192, nof_symb=69
[DEBUG]: CFO generating new table for frequency 0.0032
[DEBUG]: peak_pos=5454, pl_ub=5457, pl_lb=5453, sl_right: 5477, sl_left: 5438, PSR: 0.01/0.01=1.04
[DEBUG]: peak_pos=5454, pl_ub=5457, pl_lb=5453, sl_right: 5466, sl_left: 5438, PSR: 0.01/0.01=1.01
[DEBUG]: peak_pos=5438, pl_ub=5439, pl_lb=5435, sl_right: 5454, sl_left: 5415, PSR: 0.01/0.01=1.02
[INFO]:  Compensating cfo_i=-1
[DEBUG]: SYNC ret=0 N_id_2=0 find_offset=0 pos=5454 peak=1.04 threshold=1.50 sf_idx=0, CFO=-21.197 KHz
[INFO]:  cp_offset_pos=49, abs=0.000305, cfo=-0.048650, mean_cfo=-0.413148, nof_symb=69
[DEBUG]: CFO generating new table for frequency 0.0007
[DEBUG]: peak_pos=5454, pl_ub=5455, pl_lb=5453, sl_right: 5477, sl_left: 5438, PSR: 0.01/0.01=1.02
[DEBUG]: peak_pos=5454, pl_ub=5455, pl_lb=5453, sl_right: 5466, sl_left: 5438, PSR: 0.01/0.01=1.00
[DEBUG]: peak_pos=5438, pl_ub=5439, pl_lb=5437, sl_right: 5454, sl_left: 5415, PSR: 0.01/0.01=1.01
[INFO]:  Compensating cfo_i=-1
[DEBUG]: SYNC ret=0 N_id_2=1 find_offset=0 pos=5454 peak=1.02 threshold=1.50 sf_idx=0, CFO=-16.276 KHz
[INFO]:  cp_offset_pos=49, abs=0.000305, cfo=0.036315, mean_cfo=-0.085099, nof_symb=69
[DEBUG]: CFO generating new table for frequency -0.0002
[DEBUG]: peak_pos=5454, pl_ub=5455, pl_lb=5453, sl_right: 5477, sl_left: 5438, PSR: 0.01/0.01=1.02
[DEBUG]: peak_pos=5454, pl_ub=5455, pl_lb=5453, sl_right: 5469, sl_left: 5438, PSR: 0.01/0.01=1.00
[DEBUG]: peak_pos=5438, pl_ub=5439, pl_lb=5437, sl_right: 5454, sl_left: 5415, PSR: 0.01/0.01=1.02
[INFO]:  Compensating cfo_i=-1
[DEBUG]: SYNC ret=0 N_id_2=2 find_offset=0 pos=5454 peak=1.02 threshold=1.50 sf_idx=0, CFO=-14.637 KHz


Any leads would be greatly appreciated!
-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20160303/65f9e549/attachment.htm>