[srslte-users] srsLTE on Ettus E310

Ismael Gomez ismael.gomez at softwareradiosystems.com
Thu Apr 2 08:06:42 UTC 2015


Yes it is possible. You have to do the following:

1) Record a file, e.g. using uhd_rx_cfile (default complex format)
2) Synchronise the file, so that the first sample is the first sample of
subframe 0. You can do this with the Matlab LTE toolbox if you have it, or
with the sync/test/pss_mex.c file. If CMake finds Matlab/Octave, this file
creates a MEX file srslte_pss() which has the same interface than the LTE
toolbox and returns the offset to subframe 0.
I'll try to create a program to do this more automatically today or
tomorrow.
3) Use pdsch_ue example replacing argument "-f [freq]" by "-i [file_name]
-p [nof_prb] " and editing lines 306 and 310 in srslte/examples/pdsch_ue.c
with your cell. I'll also change it today/tomorrow to allow passing these
as parameters.

I'll post to the list when these changes are ready.

On Wed, 1 Apr 2015 at 20:40 Tom Chatt <tom.j.chatt at gmail.com> wrote:

> I should mention that all the "O" messages occur at the beginning of the
> process, and none took place once the program had hung.  I just ran make
> test and all tests passed.  Is it possible to run srsLTE with data from a
> file, instead of "live" signal data from the USRP?  If so, I could try
> recording data from the USRP B200 connected to my PC and play it back on
> the E310, to try to see if it's a timing issue or some other kind of bug.
>
> When you say that the pos=1545 indicates that synchronization is correct -
> are you referring to PSS / SSS sync?
>
> On Wed, Apr 1, 2015 at 4:07 AM, Ismael Gomez <
> ismael.gomez at softwareradiosystems.com> wrote:
>
>> So you said that exactly the same software version and with the same
>> program arguments runs fine in a desktop PC but not in the E310. That must
>> be some timing issue or a bug that is only seen with the ARM compiler (e.g.
>> uninitialized variable).
>>
>> The "O" messages indicate timing issues, but they don't seem to be a
>> problem if there are only 4 in 10 minutes and the pos=1545 is always the
>> same. That indicates that synchronization is correct.
>>
>> Can you run make test and let me know if all tests are completed
>> successfully?
>>
>> Thanks
>>
>> On Tue, 31 Mar 2015 at 20:13 Tom Chatt <tom.j.chatt at gmail.com> wrote:
>>
>>> Apologies if this doesn't show up in the correct thread; I'm new to this listserv and didn't have digest mode disabled, so I didn't have an email to reply to.
>>>
>>>
>>> >Can you check if the pos=1545 is repeated in all messages? If not that
>>> >would mean that sync is lost, probably because the ARM9 can not process
>>> >fast enough.
>>>
>>> pos= changes early on, but pos=1545 is repeated in all messages after a short time.
>>>
>>>
>>> >Have you compiled srsLTE in the ARM9 with VOLK support?
>>>
>>> srsLTE is compiled with Volk support (neon_hardfp_orc)
>>>
>>> >Also, can you run it without -v and see if you see "O" messages on the
>>> >console output? You should see them on the left of the screen.
>>>
>>> A total of 4 "O" messages showed up after letting it run for ~10 minutes.
>>>
>>> _______________________________________________
>>> 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/20150402/265caf36/attachment.htm>


More information about the srsran-users mailing list