Trying to understand Cyclic Prefix Synchronization

[jarodcs]

Hi everyone,

i would appreciate your help on the following question. Here I am studying the steps for LTE synchronization (from gr-lte) and I am currently at the very first step: The Cyclic Prefix Synchronization to achieve symbol synchronization:

From what I could see, the cyclic prefix sync can be achieved by using the Gnuradio-Block: "CP-based Rough Symbol Sync Vec" as shown below (From the grc file "lte_top_block_siso").

After doing a "locate rough_symbol_sync_cc" command on my terminal, I found the following files: 1) gr-lte/grc/lte_rough_symbol_sync_cc.xml
2) gr-lte/include/lte/rough_symbol_sync_cc.h
3) gr-lte/lib/rough_symbol_sync_cc_impl.h
4) gr-lte/lib/rough_symbol_sync_cc_impl.cc

and after checking the source code of them I could see that File 1 "calls" for File 2, and File3 and FIle4 are the implementations of File 2, right? Then, from what I can understand the hole correlation operation & cyclic prefix calculation happens on File 4 but I need some help understanding the following doubts please:

1. What is this sentence for: gr::io_signature::make( 1, 1, sizeof(gr_complex)*vlen)

2. What does fftwf_malloc on d_cp0=(gr_complex)fftwf_malloc(sizeof(gr_complex)d_cpl0*d_vlen) Image for question 1&2.

3. What does rough_symbol_sync_cc_impl::forecast(int noutput_items,gr_vector_int &ninput_items_required)

4. What does
   memcpy(d_cp0,in+id_vlen ,sizeof(gr_complex)d_cpld_vlen); memcpy(d_cp1,in+(i+d_fftl)d_vlen ,sizeof(gr_complex)d_cpld_vlen);

5. I understand that here it happens the correlation: rough_symbol_sync_cc_impl::corr(gr_complex res, gr_complex x, gr_complex *y, int len) But can somebody point where the multiplication of the sequences happen?

I would really appreciate your help on this under the promise to keep contributing on the understanding this great library.

Cheers jarodcs

[jdemel]

Hi! Please start with the GNU Radio Guided Tutorials. This will answer your questions 1 and 3. Also, it explains the code structure. Why are there multiple files etc. How are these files structured...

Q2: fftwf_malloc is a function that returns a buffer which is aligned for use in SSE/AVX. Please read the FFTW Docs or alter the code such that it uses "volk_malloc" which essentially provides the same functionality but is better suited for use with GR since it is part of VOLK.

Q4: Please read the C++ STL memcpy doc.

Q5: Please get familiar with VOLK. It provides the functionality for SIMD optimized code.

[jarodcs]

Professor Demel, please I need your help on the follwing issue ... I am running the grc file "lte_top_block_siso" with an USRP Source instead of the File Source block. I have a USRP B210 (no GPSDO) and when using openlte (LTE_fdd_dl_scan) and also srsLte (pdsch_ue) at a known dl_earfcn of a local Telco I can get the correctly cell ID (I mean the number matches with my collegues info) on both. Also srsLTE shows signal SINR around 11 - 12.

But when running the grc file in all possible manners (i.e. only throttle enabled // with Deinterleave - add - Head - Throttle enable // etc.) I get a different Cell ID (every time a different value, I have tested more times: USRP source - Throttle - CP-based Rough....) which leads me to think that maybe the input data from USRP to the "CP-base Rough Symbol Sync" block is not being properly passed ... or maybe is another thing (I dont think is poor signal given my SINR is around 12, also when running uhd_fft I can see the LTE band strong, 50dB above noise floor with B210 maximum gain).

So the question is, in your opinion what might be happening and what are your suggestions for testing if my setup is correct (although I can't figure out what else can I do). I was trying to compare the streams at the output of the USRP vs the streams at output of the CP-Based Rough SYmbol Sync Block ... but I failed on the attempet given that I dont know how to do that ... and maybe it is worthless. I will appreciate your suggestions.

[jdemel]

Hi!

First, the Throttle block exists in order to keep the computational load on your machine in check in case you DO NOT RUN hardware. With a USRP Source, you use hardware. Remove the throttle block.

Next, the deinterleave and add blocks won't be necessary.

You should check if 'O's are printed to the shell. This is an indicator for dropped samples. And this will make the whole flowgraph fail. Please note, that gr-lte is usually not able to keep up with LTE sample rates. It is intended to make it easier to understand the LTE signal processing flowgraph.

The 'cell ID' is published by the LTE SSS Sync block. You may deactivate all blocks behind this one for test purposes.

[ceren58]

Hi @jdemel , I am using lte_top_block_siso.grc with an USRP and I have the problem you are just talking about. I receive some "O" wtih the message "ofdm_lte_remove_cp_cvc_0 OUT of sync!". I know it is because of the USRP's overflow but I don't know haw to solve it. I would be grateful if you have the solution :)

[jdemel]

Your PC can't process samples fast enough. Record a sample file (a couple of seconds) and use this in your flowgraph afterwards.

[ceren58]

thank you for your quick answer and your help. I recorded a sample file using the USRP and I don't have problems of overflow anymore but still the same message of "ofdm_lte_remove_cp_cvc_0 OUT of sync!". I may have something else wrong...

[jarodcs]

Hi guys!

Correct me if I am wrong, but it seems that those are samples that USRP took but they are out of frame or in other words are not cyclic prefix sync ... and it seems to me that it removes the ofdm cyclic prefix and finds out that is not sync ... That is my guessing, hope Prof. Demel can explain that error a little bit more. So those errors are normal because at first the system is not sync with the "listened eNB".

Thanks

2017-08-11 11:52 GMT+00:00 ceren58 notifications@github.com:

thank you for your quick answer and your help. I recorded a sample file using the USRP and I don't have problems of overflow anymore but still the same message of "ofdm_lte_remove_cp_cvc_0 OUT of sync!". I may have something else wrong...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kit-cel/gr-lte/issues/11#issuecomment-321793086, or mute the thread https://github.com/notifications/unsubscribe-auth/AF6sVGZq--WH5a0fKG7lBETVZb_uZts4ks5sXEB7gaJpZM4M--MZ .

[jdemel]

Something goes wrong. There are many possible reasons. For example, the flowgraph expects samples at certain sample rates. These sample rates are not supported by all USRPs. Resampling is required. The SNR of your recording might be too low. Or you experienced overflows during the recording. You need to analyse the error in more detail in order to tell why things do not work as expected. Also, you need to describe your whole system setup in order to allow others to guess what the source of the error is.

[Keskebeu]

I have lte on a core i7 quadcore and overflow does not occur. But in my core i5 dual-core it does overflow. You can work on 2g and 3g but not on lte. So a better processor would be good to have to experiment on lte.

[mingli001]

@jarodcs Hi,i meet the same question.did you solve it?could you help me ?thank you