[srslte-users] Issue running examples

[Ismael Gomez]

Hi Eric,

On Tue, 14 Apr 2015 at 23:28 Eric Sollenberger <ericps1 at vt.edu> wrote:

> 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.
>
>
Yes I think this issue was already fixed. Have you pulled the latest
changes from github? Since we are in continuous development, I recommend
you periodically update your local repo.


> 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?
>
>
Actually this is documented in the project wiki:
https://github.com/srsLTE/srsLTE (at the end of the page). The reason why
the default is 0xFFFF is because this is the System Information RNTI, used
to scramble SIB packets. Many users try srsLTE with live LTE signals only,
so this is why by default we set the RNTI to this value.


> 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?
>
>
The 20% PDCCH is fine, because the pdsch_enodeb example transmits on all
subframes except 0 and 5. The 100% PDSCH was actually a BUG. Thanks for
spotting this. The problem was that the eNodeB was not correctly updating
the subframe index and encoding all subframes as if they were subframe 0.
Thanks agains for spotting this.


> 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.
>

This is normal LTE behaviour. The PDCCH is blindly decoded, which means
that the receiver does not know where the DCI message is being scheduled
and with which format. Thus, it needs to decode all possibilities and use
the CRC checksum to find the one that is addressed to him.


>
> 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
>
>
Thank you eric for your valuable contribution.
Ismael


> 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/20150415/9d4fce8e/attachment.htm>