[srslte-users] Issue with my SDR

Samie Mostafavi samiemostafavi at gmail.com
Mon Feb 3 14:28:33 UTC 2020


Hello Justin,

After some efforts I could implement a time stamping mechanism that gives
timestamps in nanoseconds for RX buffers and receives timestamps alongside
the TX buffer in order to transmit them in time.
I send/receive the timestamps every time I send/receive a buffer, inside an
async thread and on a IIO channel attribute I defined myself.
I have a late command detection mechanism on the TX side, that subtracts
the timestamp which is sent alongside the TX buffer from the actual time on
the FPGA (It is the same timer that generates the timestamp for RX).

When I run the srsUE program, my ue syncs with the eNodeB successfully,
decodes MIB with a good SNR and starts transmitting the RAs. Then, I get
late command errors from my transmitter with the value of about 30-50
milliseconds. It shows that the timestamp that srsLTE has calculated for
sending the RAs are 30-50ms late. It has to be due to the latency of the
link (Ethernet) between the host and the SDR.

Do you think can I compensate this issue by only setting a timeoffset?
Actually my question is that with this huge latency can my UE connect to
the eNodeB?

Best,
Samie

On Thu, Jan 23, 2020 at 6:23 PM Justin Tallon <
justin.tallon at softwareradiosystems.com> wrote:

> Hey Samie,
>
> The overflows could be caused by a number of different factors although it
> is most likely to be a computational issue if you are trying to run at 5MHz.
>
> The issue in this log is the reception of the RAR which is not occurring.
> This is probably due the timing offset between the ue and the enb. there is
> no timed Tx in the iio drivers by default so this is likely causing your
> timing issues.
>
> Regards,
> Justin
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
> On Thu, Jan 23, 2020 at 6:15 PM Samie Mostafavi <samiemostafavi at gmail.com>
> wrote:
>
>> Hi Justin,
>>
>> Now I have an asynchronous overflow/underflow checking thread and I
>> realized that I have some overflows during running srsue. I am kinda sure
>> that it is not a problem with the buffer sizes since I tested libIIO in
>> another applications out of srsLTE (TX/RX simultaneously with the same
>> buffer sizes) and I didn't get any overflow.
>>
>> I dont know where these overflows are coming from, please check the
>> ue.log file. I know that this overflow happens when both RX and TX buffers
>> are enabled.
>>
>> Regarding my SDR, it is ADRV9361-Z7035. It has AD9361 and a Zynq 7000 and
>> an ARM running in the FPGA. I have the host connected to the SDR over
>> Ethernet and I also checked the CPU usage on the ARM while I get overflows
>> and it is not high at all.
>>
>> Best,
>> Samie
>>
>> On Tue, Jan 21, 2020 at 4:21 PM Justin Tallon <
>> justin.tallon at softwareradiosystems.com> wrote:
>>
>>> Hey Samie,
>>>
>>> The CFO reporting can be affected by the computational resources if
>>> there are overflows occurring, which is entirely possible given the
>>> computational constraints of the Pluto.
>>>
>>> Can you give more information about the resources available on your SDR?
>>> How does it differ from the Pluto?
>>>
>>> Regards,
>>> Justin
>>> ____
>>> Justin Tallon Ph.D.
>>>
>>> Software Radio Systems (SRS)
>>> http://www.softwareradiosystems.com
>>>
>>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>>
>>>
>>> On Tue, Jan 21, 2020 at 4:08 PM Samie Mostafavi <
>>> samiemostafavi at gmail.com> wrote:
>>>
>>>> How can computational resources affect the CFO?
>>>> I see lots of lags during the srsUE running, for example pdsch_ue is
>>>> not getting updated continuously, some times the program stops and then
>>>> after some seconds comes back. How can I become aware of the times when the
>>>> program is blocked by the RX buffer?
>>>>
>>>> Best,
>>>> Samie
>>>>
>>>>
>>>>
>>>> On Tue, Jan 21, 2020 at 3:53 PM Justin Tallon <
>>>> justin.tallon at softwareradiosystems.com> wrote:
>>>>
>>>>> Hey Samie,
>>>>>
>>>>> It could be a problem of the oscillator but also if could be an issue
>>>>> of computational resources. Does your SDR have a mechanism for reporting
>>>>> overflows, underflows, lates etc?
>>>>>
>>>>> Regards,
>>>>> Justin
>>>>> ____
>>>>> Justin Tallon Ph.D.
>>>>>
>>>>> Software Radio Systems (SRS)
>>>>> http://www.softwareradiosystems.com
>>>>>
>>>>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>>>>
>>>>>
>>>>> On Tue, Jan 21, 2020 at 3:51 PM Samie Mostafavi <
>>>>> samiemostafavi at gmail.com> wrote:
>>>>>
>>>>>> Aha I see,
>>>>>>
>>>>>> When I run the pdsch_ue in command line, the CFO value that it shows
>>>>>> starts from a few Hz and after a while it becomes very large, like 14 kHz:
>>>>>>
>>>>>> CFO: -13206.19 Hz
>>>>>> RSRP: +36.6 dBm |  +0.0 dBm
>>>>>> SNR:  +1.3 dB
>>>>>> TM: 1
>>>>>> Rb:   0.00 /   0.14 /   0.00 Mbps (net/maximum/processing)
>>>>>> PDCCH-Miss: 97.90%
>>>>>> PDSCH-BLER:  -nan%
>>>>>> TB 0: mcs=2; tbs=144
>>>>>> TB 1: mcs=0; tbs=0
>>>>>> Press enter maximum printing debug log of 1 subframe.
>>>>>>
>>>>>> Does it show that the local oscillator on my SDR is not performing
>>>>>> correctly? Do you think later it will cause problems?
>>>>>>
>>>>>> Best,
>>>>>> Samie
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 21, 2020 at 3:38 PM Justin Tallon <
>>>>>> justin.tallon at softwareradiosystems.com> wrote:
>>>>>>
>>>>>>> Hey Samie,
>>>>>>>
>>>>>>> The reason it is returning to 1.92 is because the attach procedure
>>>>>>> is failing and it is returning to cell search which occurs at 1.92.
>>>>>>>
>>>>>>> You are not receiving the RAR (Random Access Response) you need to
>>>>>>> check if it is being transmitted. If you are having large delays then I
>>>>>>> doubt it is getting sent by the enodeb.
>>>>>>>
>>>>>>> You can make adjustments to the timing with the time_adv_nsamples
>>>>>>> parameter in the UE config.
>>>>>>>
>>>>>>> To receive the PRACH correctly at the eNodeB you need to see a TA
>>>>>>> (timing advance) of a much lower order than 5000. The tolerance for timing
>>>>>>> offset should be a parameter in the eNodeB, but 5000 would never work.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Justin
>>>>>>> ____
>>>>>>> Justin Tallon Ph.D.
>>>>>>>
>>>>>>> Software Radio Systems (SRS)
>>>>>>> http://www.softwareradiosystems.com
>>>>>>>
>>>>>>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 21, 2020 at 3:31 PM Samie Mostafavi <
>>>>>>> samiemostafavi at gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I added 5khz frequency_offset to the ue.conf file.
>>>>>>>> It is better now (it stays in 5.67 MHz more than before).
>>>>>>>> However, again after a while it goes back to 1.92 MHz. Find the new
>>>>>>>> log attached.
>>>>>>>>
>>>>>>>> eNodeB receives 1 out of 10 RA transmissions with a lot of delay
>>>>>>>> ~5000. That is due to the timing I believe. I dont have the notion of time
>>>>>>>> on the TX side yet. But first I want to be sure about the RX part.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Samie
>>>>>>>>
>>>>>>>> On Tue, Jan 21, 2020 at 3:08 PM Justin Tallon <
>>>>>>>> justin.tallon at softwareradiosystems.com> wrote:
>>>>>>>>
>>>>>>>>> Hey Samie,
>>>>>>>>>
>>>>>>>>> It appears you have a CFO of over 5khz. Can you try manually
>>>>>>>>> compensating for this and repeating the experiment?
>>>>>>>>>
>>>>>>>>> Can you see the PRACH messages that are sent by the UE being
>>>>>>>>> received correctly at the eNodeB?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Justin
>>>>>>>>> ____
>>>>>>>>> Justin Tallon Ph.D.
>>>>>>>>>
>>>>>>>>> Software Radio Systems (SRS)
>>>>>>>>> http://www.softwareradiosystems.com
>>>>>>>>>
>>>>>>>>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 21, 2020 at 3:05 PM Samie Mostafavi <
>>>>>>>>> samiemostafavi at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey,
>>>>>>>>>>
>>>>>>>>>> Sure, please find it attached. Now with --log.all_level info
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Samie
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 21, 2020 at 3:02 PM Justin Tallon <
>>>>>>>>>> justin.tallon at softwareradiosystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Samie,
>>>>>>>>>>>
>>>>>>>>>>> Can you repeat the experiment with "--log.all_level info" as a
>>>>>>>>>>> command-line argument?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Justin
>>>>>>>>>>> ____
>>>>>>>>>>> Justin Tallon Ph.D.
>>>>>>>>>>>
>>>>>>>>>>> Software Radio Systems (SRS)
>>>>>>>>>>> http://www.softwareradiosystems.com
>>>>>>>>>>>
>>>>>>>>>>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 21, 2020 at 2:59 PM Samie Mostafavi <
>>>>>>>>>>> samiemostafavi at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Justin,
>>>>>>>>>>>>
>>>>>>>>>>>> Please find the ue.log attached.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Samie
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jan 21, 2020 at 2:42 PM Justin Tallon <
>>>>>>>>>>>> justin.tallon at softwareradiosystems.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey Samie,
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you send on the ue.log we can take a look for you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Justin
>>>>>>>>>>>>> ____
>>>>>>>>>>>>> Justin Tallon Ph.D.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Software Radio Systems (SRS)
>>>>>>>>>>>>> http://www.softwareradiosystems.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jan 21, 2020 at 1:48 PM Samie Mostafavi <
>>>>>>>>>>>>> samiemostafavi at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have an issue with my custom SDR which is similar to
>>>>>>>>>>>>>> PlutoSDR. I am using srsUE to connect to an EnodeB which is
>>>>>>>>>>>>>> openairinterface.
>>>>>>>>>>>>>> It finds the cell and decodes the MIB in 1.92MHz successfully.
>>>>>>>>>>>>>> Then it switches to 5.76 MHz for RA transmission and it sends
>>>>>>>>>>>>>> them successfully. But for some reason it goes back to 1.92MHz again.
>>>>>>>>>>>>>> This cycle happens over and over again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would be grateful if you can help me why this happens.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Samie
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Samie
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> srslte-users mailing list
>>>>>>>>>>>>>> srslte-users at lists.softwareradiosystems.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Samie
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Samie
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Samie
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Samie
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Samie
>>>>
>>>
>>
>> --
>> Samie
>>
>

-- 
Samie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20200203/a5e1e547/attachment.htm>


More information about the srsran-users mailing list