[srslte-users] radios don't hear each other

Sat Nov 18 04:08:27 UTC 2017

Thank you Keith and Andre for your help! I've been cranking on this all 
day, and I think I'm very close! Here's what I've got so far. As a quick 
reminder, my system configuration has two machines (a laptop and a 
desktop) both running 17.04 with kernel 4.10.0-19-lowlatency. The CPUs 
are similar, both 4-core Intel IvyBridges, with the laptop's CPU being 
slightly less powerful than the desktop's.

-The TX and RX frequencies were lined up, but by changing them back to 
the default values they were able to chat with each other! Not quite 
sure why this fixed the initial problem, but I'm happy about it.

-The desktop computer that I'm running the eNodeB on continues to suffer 
from lots of underflows and lates, to the point that it appears to 
disrupt the communication process - sometimes the UE can connect, and 
sometimes it can't. The laptop that I'm running the UE on does NOT have 
any underflow or late problems at all.

-I swapped the UE and eNB roles and in this configuration the laptop has 
no problem acting as the eNB, and connection succeeds much more often, 
no Us or Ls. The desktop continues to have lots of Us and Ls even acting 
as the UE... this leads me to believe that the issue is wholly contained 
on the desktop computer system configuration somehow.

- I monitored the CPU frequencies of both machines using "watch -n 0 
"lscpu | grep 'MHz'" and I noticed that (1) the desktop's CPU was 
ranging all over the place, ranging from the minimum (1.6 GHz) to the 
maximum (3.4 GHz). Meanwhile, the laptop's CPU was VERY stable, hanging 
out right at 1.2 GHz with no movement at all. Note that this is actually 
the very bottom of the laptop's CPU range, which goes from 1.2 GHz to 
3.3 GHz. This is leading me to believe that the CPU components of the 
basic SDR aren't really  that high, just require strong consistency.

- I've been trying to disable frequency scaling for the desktop, but 
don't know if I've succeeded or not? If it's disabled, would I see a 
consistent CPU frequency, as I do on the laptop? I've turned off 
"SpeedStep" in the BIOS, downloaded cpufreq and set the governor to 
"performance." When I do a cpufreq-info it says that it's set 
accordingly and that the governor may decide which speed to use within 
the {1.6-3.4} range. Meanwhile, cpufreq on the laptop says it's set to 
"powersave." Not quite sure what else to try in order to disable this 
scaling, but I've got a hunch that if I can somehow set a constant CPU 
speed I'll be up and running.

I've been wading through a lot of less-than-helpful stackoverflow posts 
on this, but not quite sure if I'm getting anywhere or not? I'd 
super-appreciate it if someone could point me on the right track, or at 
least confirm that yes, what I want is a constant, unchanging CPU 
frequency? Thanks!!!

Spencer

11/17/17 3:08 AM, Keith E. Fleming wrote:
> I too have the issue of a commercial handset will not even discover my 
> srsENB instance. I started using a real-time kernel (Centos 7 
> 3.10.0-693.2.2.rt56.623.el7.x86_64) and the underflow and "RF Warning 
> Late" errors all went away. This is on an i5-7600k with 32gb memory. 
> Make sure to use a real-time kernel and to have CPU scaling turned off 
> in BIOS
> On Friday, November 17, 2017, 3:22:29 AM EST, Andre Puschmann 
> <andre.puschmann at softwareradiosystems.com> wrote:
>
>
> Hey Spencer,
>
> looking at the issue again we think you may have other fundamental
> issues with your setup there that let the UE not even find a cell. Make
> sure you are using the right frequencies and gain settings on both
> sides, the signal looks good and use pdsch_ue to verify the correct
> reception first.
>
>
> Cheers
> Andre
>
>
>
>
> On 16/11/17 19:43, Spencer Sevilla wrote:
> > Thanks Andre! Im out of the office today but will try all these things
> > and report back tomorrow morning. I know I've got a pretty powerful CPU
> > here, so off the top of your head do you have any other potential
> > configuration suggestions/parameters or good instuctional resources? I'm
> > a bit new to SDR but know a lot about wireless communications, and am
> > happy to get myself up to speed.
> >
> > Thanks again!
> >
> > Spencer
> >
> > On 11/16/17 1:30 AM, Andre Puschmann wrote:
> >> Hi,
> >>
> >> there are many lates and underflows on the eNB console. They are very
> >> likely messing up the transmitted signal. Please make sure you are
> >> configuring frequency scaling accordingly and use a potent enough CPU.
> >>
> >> Once you fixed those, please try again the UE. In case it still doesn't
> >> work, please send the ue.log.
> >>
> >> Hope that helps!
> >>
> >> Cheers
> >> Andre
> >>
> >>
> >>
> >> On 16/11/17 01:19, Spencer Sevilla wrote:
> >>> Hi all,
> >>>
> >>> I'm trying to get a very very basic testbed setup, but no matter 
> what I
> >>> do, srsue and srsenb don't want to talk to each other. Here's my setup
> >>> and logs:
> >>>
> >>> eNB:
> >>>
> >>> Running Ubuntu 17.04, hardware is a USRP B200, local EPC based on OAI
> >>> (openair-cn). I'm just using the standard sample config files,
> >>> {enb,rr,drb,sib}.conf.example. Terminal output for starting the eNB is
> >>> as follows:
> >>>
> >>> spencer at spencertower 
> <mailto:spencer at spencertower>:~/Desktop/srsLTE$ sudo 
> ./build/srsenb/src/srsenb
> >>> enb.conf
> >>> linux; GNU C++ version 6.3.0 20170406; Boost_106200;
> >>> UHD_003.010.002.000-3-g122bfae1
> >>>
> >>> ---  Software Radio Systems LTE eNodeB  ---
> >>>
> >>> Reading configuration file enb.conf...
> >>> Opening USRP with args: type=b200,master_clock_rate=30.72e6
> >>> -- Detected Device: B200
> >>> -- Operating over USB 3.
> >>> -- Initialize CODEC control...
> >>> -- Initialize Radio control...
> >>> -- Performing register loopback test... pass
> >>> -- Performing CODEC loopback test... pass
> >>> -- Asking for clock rate 30.720000 MHz...
> >>> -- Actually got clock rate 30.720000 MHz.
> >>> -- Performing timer loopback test... pass
> >>> Setting frequency: DL=2630.0 Mhz, UL=2510.0 MHz
> >>> -- Asking for clock rate 23.040000 MHz...
> >>> -- Actually got clock rate 23.040000 MHz.
> >>> -- Performing timer loopback test... pass
> >>> Setting Sampling frequency 5.76 MHz
> >>>
> >>> ==== eNodeB started ===
> >>> Type <t> to view trace
> >>> t
> >>> Enter t to stop trace.
> >>> ULULLLLLLLLLLLLLLLLULLLLLLLLLLLLLLLL^C^C^CU^C^C^C--- exiting  ---
> >>>
> >>>
> >>> Once the "eNodeB started" comes up, I can see both green and red 
> lights
> >>> (TX and RX) on the SDR stay constantly lit. This goes on for about a
> >>> minute until I control-C.
> >>>
> >>>
> >>> UE:
> >>>
> >>> Running Ubuntu 17.04, hardware is a USRP B210. Again, I'm just 
> using the
> >>> standard sample config file ue.conf.example. Terminal output for 
> the UE
> >>> (which I starts after the eNB) is as follows:
> >>>
> >>> Reading configuration file ./srsue/ue.conf.example...
> >>> ---  Software Radio Systems LTE UE  ---
> >>>
> >>> Opening RF device with 1 RX antennas...
> >>> Opening USRP with args: type=b200,master_clock_rate=30.72e6
> >>> -- Detected Device: B210
> >>> -- Operating over USB 3.
> >>> -- Initialize CODEC control...
> >>> -- Initialize Radio control...
> >>> -- Performing register loopback test... pass
> >>> -- Performing register loopback test... pass
> >>> -- Performing CODEC loopback test... pass
> >>> -- Performing CODEC loopback test... pass
> >>> -- Asking for clock rate 30.720000 MHz...
> >>> -- Actually got clock rate 30.720000 MHz.
> >>> -- Performing timer loopback test... pass
> >>> -- Performing timer loopback test... pass
> >>> Waiting PHY to initialize...
> >>> ...
> >>> Searching cell in DL EARFCN=2850, f_dl=2630.0 MHz, f_ul=2510.0 MHz
> >>> ...........................................................
> >>> RRC PLMN Search: timeout expired. Searching again
> >>> ...........................................................
> >>> RRC PLMN Search: timeout expired. Searching again
> >>> ..........................................................
> >>> RRC PLMN Search: timeout expired. Searching again
> >>> ..................................................^C--- exiting  ---
> >>>
> >>>
> >>> After it boots, it just keeps searching for the PLMN (with the green
> >>> light on the SDR blinking to indicate RX) to no avail; this goes on
> >>> until I control-C.
> >>>
> >>> I double-checked the clock-rates, and made sure that downlink and 
> uplink
> >>> frequencies are the same (2630.0 MHz  and 2510.0 MHz, respectively). I
> >>> was also able to get the exact same behavior using the OAI eNodeB, so
> >>> I'm sure I'm doing something wrong here. Any 
> thoughts/wisdom/advice? Are
> >>> there good other things for me to look into, or to make sure I'm doing
> >>> right? Any great way to debug the SDRs and make sure they're doing 
> what
> >>> they're supposed to? I'd appreciate any advice or leads anyone might
> >>> have, cause I'm pretty stumped at the moment.
> >>>
> >>> Thanks!!!
> >>> Spencer
> >>>
> >>>
> >>> _______________________________________________
> >>> srslte-users mailing list
> >>> srslte-users at lists.softwareradiosystems.com 
> <mailto:srslte-users at lists.softwareradiosystems.com>
> >>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> >>>
> >
>
>
> -- 
> Andre Puschmann
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> PGP/GnuPG key: 6C42AB31
> fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com 
> <mailto: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/20171117/e13ca9a1/attachment.htm>