[srslte-users] Issue running examples

[Eric Sollenberger]

I just pulled the latest version and it worked like a charm, thanks for the
quick response and support!

- Eric

On Wed, Apr 15, 2015 at 4:28 AM, Ismael Gomez <
ismael.gomez at softwareradiosystems.com> wrote:

> 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/18e8515d/attachment.htm>