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

[Ismael Gomez]

Thank you very much Doug. We merged your changes.

On Fri, 4 Mar 2016 at 01:41 Anderson, Douglas J. <danderson at its.bldrdoc.gov>
wrote:

> A lot of my confusing in the issue stemmed from the number of samples
> being written to file.
>
> I just realized that only 1 full frame was being written no matter how
> many frames I requested.
>
> I've created a pull request on github to correct the issue. Now
> pdsch_enodeb -o some_file will write the correct number of frames.
>
> https://github.com/srsLTE/srsLTE/pull/56
>
> -Doug
> ------------------------------
> *From:* srslte-users [srslte-users-bounces at lists.softwareradiosystems.com]
> on behalf of Anderson, Douglas J. [danderson at its.bldrdoc.gov]
> *Sent:* Wednesday, March 02, 2016 6:17 PM
> *To:* srslte-users at lists.softwareradiosystems.com
> *Subject:* [srslte-users] Modyfing cell_search.c to take a buffer of data
>
> 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
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20160304/80ddb2fb/attachment.htm>