[srslte-users] overflow problem with usrp x310

Tue Nov 24 15:53:14 UTC 2015

Attached the new log (not much more information)

Nicola Bui

Research Engineer
IMDEA Networks Institute
Av. Mar del Mediterraneo, 22
28918 - Leganés (Madrid) - Spain
mobile: +34 657 633 987
phone: +34 91 481 6986
fax: +34 481 6965

On Tue, Nov 24, 2015 at 3:57 PM, Ismael Gomez <
ismael.gomez at softwareradiosystems.com> wrote:

> Can you run it with -vv and paste again the log?
>
> On Tue, 24 Nov 2015, 12:50 Nicola Bui <nicola.bui at imdea.org> wrote:
>
>> Dear Ismael,
>>
>> thanks a lot for the reply.
>> For what concerns the clock, I tried with both clock configurations with
>> no different outcome. The log with the default clock is attached. The only
>> difference with the other setting is the line "-- Radio 1x clock:200",
>> which reads instead "-- Radio 1x clock:184.32".
>>
>> I tried the following benchmarks:
>> 1) ./benchmark_rate --rx_rate 20e6
>> 2) ./benchmark_rate --rx_rate 30.72e6
>> 3) ./benchmark_rate --rx_rate 30.72e6 --args master_clock_rate=184.32e6
>>
>> The first two ended with no errors (no drops, no overflows), but the
>> third got some (Num received samples: 288290793, Num dropped samples:
>> 18887815, Num overflows detected: 1019)
>>
>> Any other test I can do to better understand the problem?
>>
>> Thanks a lot again,
>>
>>
>> Nicola Bui
>>
>> Research Engineer
>> IMDEA Networks Institute
>> Av. Mar del Mediterraneo, 22
>> 28918 - Leganés (Madrid) - Spain
>> mobile: +34 657 633 987
>> phone: +34 91 481 6986
>> fax: +34 481 6965
>>
>> On Mon, Nov 23, 2015 at 5:09 PM, Ismael Gomez <
>> ismael.gomez at softwareradiosystems.com> wrote:
>>
>>> Have you tried without specifying the clock rate argument? The clock
>>> rate during the initial synchronization and PBCH decoding is different than
>>> during normal operation (ie PDSCH decoding). The software changes from one
>>> to another at runtime using the UHD driver.
>>>
>>> You can get more info using the "-v" argument, for verbose and using tee
>>> tool to save the output in a log file (if you do so, send us that file so
>>> we can take a better look on what's going on).
>>>
>>> To make sure the connection is not the problem, run the gnuradio
>>> benchmark_tx and benchmark_rx examples at 20 Mhz bandwidth. You should not
>>> see any O or U message.
>>>
>>> It is also possible to read a signal from a file, but that signal should
>>> be synchronized and start with subframe idx 0. Another requirement is that
>>> the sampling rate is the one the software expects. I can give more
>>> information on that if necessary.
>>>
>>>
>>> On Mon, 23 Nov 2015 at 17:23 Nicola Bui <nicola.bui at imdea.org> wrote:
>>>
>>>> Hi Ismael,
>>>>
>>>> I was just trying the first example on the readme file of the git
>>>> repository: pdsch_ue -f <frequency> to see whether it could decode the SIB1
>>>> from the network
>>>> My parameters are "-f 1815.1e6" (for movistar LTE in Spain) -a
>>>> master_clock_rate=184.32e6 (cause x310 has a 200 MHz default clock).
>>>>
>>>> The procedure seems to run normally until the "Searching for cell..."
>>>> then it writes "Using Volk machine: avx2_64_mmx". After that I only get a
>>>> sequence of Os.
>>>> My best guess is that the overflows are due to how I connect the x310
>>>> to the host (1Gb ethernet), but testing the connection with gnuradio makes
>>>> me feel I also have problems with the way I am using srsLTE.
>>>>
>>>> What I am missing now is a way to troubleshoot what is going wrong. If
>>>> it is on the connection part, in the configuration part or anywhere else.
>>>> Also, it would be good to have an option to run the software on some
>>>> prerecorded data which I can obtain with a different board that does not
>>>> support uhd. Is this possible?
>>>>
>>>> Thanks a lot,
>>>>
>>>> Nicola Bui
>>>>
>>>> Research Engineer
>>>> IMDEA Networks Institute
>>>> Av. Mar del Mediterraneo, 22
>>>> 28918 - Leganés (Madrid) - Spain
>>>> mobile: +34 657 633 987
>>>> phone: +34 91 481 6986
>>>> fax: +34 481 6965
>>>>
>>>> On Mon, Nov 23, 2015 at 4:44 PM, Ismael Gomez <
>>>> ismael.gomez at softwareradiosystems.com> wrote:
>>>>
>>>>> Hi Nicola,
>>>>>
>>>>> Please try to give us as many details of your setup as possible. Are
>>>>> you using the pdsch_enodeb example to generate the signal? Can you send the
>>>>> exact commands you are using? What bandwidth is the signal are you trying
>>>>> to decode?
>>>>>
>>>>> What processor are you running the pdsch_ue example in?
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 23 Nov 2015 at 14:53 Nicola Bui <nicola.bui at imdea.org> wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I just tried to run the pdsch_ue example on a usrp x310 board. After
>>>>>> the initial configuration I just received a series of "O" (overflow).
>>>>>>
>>>>>> Any advice on how to debug the issue?
>>>>>>
>>>>>> Thanks,
>>>>>> Nicola Bui
>>>>>>
>>>>>> Research Engineer
>>>>>> IMDEA Networks Institute
>>>>>> Av. Mar del Mediterraneo, 22
>>>>>> 28918 - Leganés (Madrid) - Spain
>>>>>> mobile: +34 657 633 987
>>>>>> phone: +34 91 481 6986
>>>>>> fax: +34 481 6965
>>>>>> _______________________________________________
>>>>>> srslte-users mailing list
>>>>>> srslte-users at lists.softwareradiosystems.com
>>>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> srslte-users mailing list
>>>>> srslte-users at lists.softwareradiosystems.com
>>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> 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/20151124/042eac26/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x310_usrp.log
Type: text/x-log
Size: 934 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20151124/042eac26/attachment.bin>