[Openlte-discuss] Issue in measuring Timing Advance 2
An open source 3GPP LTE implementation.
Status: Alpha
Brought to you by:
bwojtowi
From: <co...@ch...> - 2016-12-27 14:46:11
|
Hi dear, Thank you very much for your answer. In my previous question, mentioned below, I asked about timing advance and you answered that I can tune PRACH offset using LTE_fdd_enb_radio.cc where rx_synced is set to true. I tried so much, but I couldn't do. If it is possible, please learn me how to use LTE_fdd_enb_radio.cc to tune this offset. Best regards. -------------------------------------------- Hello, First of all thanks for your kind words about the project! Regarding PRACH processing, I never tuned the receive signal time alignment to have a zero PRACH offset. This leads to your observation of non-zero timing advance values. If you would like to tune this, you should take a look at LTE_fdd_enb_radio.cc where rx_synced is set to true. The reason that the eNodeB still functions correctly is that the timing of the received samples is aligned by the timing advance value. In this case, the timing advance does not indicate propagation delay, but rather processing/buffering delay in the eNodeB receiver. One other note, there is non-zero chance that the eNodeB will detect a PRACH when there is no actual PRACH present. These will have random timing advance values and are safe to disregard. Hope this helps, Ben Hi all At first, I would like to thanks the designers and providers of openlte package for this usefull software. I am working with this package. But I has an important issue. I use openlte as a enodeb and try to connect my mobile phone to it. My aim is measuring the parameter "timing advance" of my phone. This parameter is estimated via PRACH channel using the function "liblte_phy_detect_prach". Timing advance has direct relation with delay of received signal. In my tests, the phone is very near to usrp (with distance about 20 cm) an so it is expected that the timing advance to be zero. But, non-zero values are reported by "liblte_phy_detect_prach" function such as "9" or "17". These results are not valid. I tried to find the reason of this fact. I saved the inputs "samps_re" and "samps_im" for the subframe containig PRACH. It is seen that some initial elements of these signals are about zero (are noise values) and the PRACH samples are not lied at the first entries. For exmaple, the PRACH samples are observed in elemenst index 61,62,63,... and the elemenst 0,1,2,...,60 are near to zero. This observations means that the first sample on rx_buffer has not been aligned with the first sample of PRACH. In other words, the receiver of usrp saves the received samples in the corresponding buffer earlier than the reception of PRACH. But, I don't know which codes in the openlte package should be modified. I appreciate if any one can help me. Best Regards. |