[srslte-users] Issue running examples

[Eric Sollenberger]

Hello again,

I had taken a break from working on this for a little while but just
started up again the past couple days. Here is what I've observed:

In order to get a reasonable signal I had to remove the normalization
factor at line 601 of the pdsch_enodeb. After doing so I was able to get a
proper OFDM signal.

It took me probably longer than it should have to realize that the pdsch_ue
will only show equalized constellations when the RNTI is set to 1234 since
this value seems to be hardcoded at the enodeb. Is there a reason the
default is 0xFFFF if it doesn't work with this setting?

After making these two changes I can see a reasonable constellation, but
there are a lot of points at (0,0) and I am missing 20% PDCCH and the PDSCH
BLER is 100%. As a basic test I printed out the subframe symbols before the
IFFT operation at the enodeb and saw that many of the OFDM symbols are all
zeros. Specifically I saw that for all slot 0's, symbols 5 and 6 were alll
zero, and for slot 1 symbols 1, 2, and 3 were all zero. Is this okay or
should the enodeb be filling these symbols as I originally thought?

When I run the pdsch_ue verbose I see that the decoded RNTI's appear to be
random rather than the 1234 that I see in the pdsch_enodeb code.

I've been working with two B210's recently in case there was a problem with
the N210's, but I've actually seen this same behavior on either setup.

Any advice you have would be greatly appreciated.

Thank you,
Eric

On Tue, Mar 31, 2015 at 6:08 AM, Ismael Gomez <
ismael.gomez at softwareradiosystems.com> wrote:

>
>
> On Tue, 31 Mar 2015 at 05:06 Tom Tsou <tom at tsou.cc> wrote:
>
>> On Sun, Mar 29, 2015 at 8:54 PM, Eric Sollenberger <ericps1 at vt.edu>
>> wrote:
>> > I think I read somewhere that you guys have been using USRP B210's for
>> your
>> > development, have you run these examples on USRP N210's by any chance?
>> If
>> > not do you have any expectation for whether or not it should run?
>>
>> The N210 doesn't support reconfigurable clocking, so you can't set the
>> clock to a 'nice' LTE rate that is some multiple or fraction of 30.72
>> MHz. You can get around that by performing sample rate conversion on
>> the host, but that does add a fair amount of overhead and complexity
>> to the application. In summary, running LTE on the N210 is far less
>> convenient than the B200.
>>
>> > I ran uhd_fft on one of the USRPs to verify that a signal was being
>> > transmitted by the USRP running pdsch_enodeb, and I saw periodic bursts
>> > towards the center of the FFT. I'm assuming this is the PSS/SSS and
>> PBCH,
>> > but since there isn't a UE connected, no actual data is being sent and
>> so
>> > the spectrum does not look like a typical OFDM waveform.
>>
>> On an idle downlink, you should still see reference signals and
>> periodic SIB data on the shared channel in addition to the MIB and
>> synchronization symbols in the center. The spectrum should still look
>> very much like an OFDM signal.
>>
>
> The pdsch_enodeb example sends data continuously even if no UE is
> attached. It only reproduces the PHY Downlink functionality, so there is no
> attachment procedure at all. If you don't see the spectrum correctly, it is
> most certainly an amplitude issue. Try running it with -l 1.0 argument,
> which sets the signal amplitude. By default this example sets very low
> amplitude to avoid saturation due to PAPR. We'll solve it very soon (today
> or tomorrow).
>
>
>>
>>  -TT
>> _______________________________________________
>> 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/20150414/089d8b36/attachment.htm>