[srslte-users] Center frequency offset (CFO) with doubles instead of floats?

Mon Mar 6 16:11:02 UTC 2017

Thanks for your input. I have measured the latency of our channel emulator and it does seem to add about 8ms. However, I can still attach and perform an Iperf test as long as I keep my frequency shift between +- 80 Hz (The CFO jumps around with the PSS algorithm and standard B210s).

I can still see the jumping behavior if I directly connect the two B210s with 40 dB attenuators and SMA cables. I also see the sweeping CFO if I directly connect the two modified synced boards.

Without the emulator in the setup, I can get a stable CFO to report with the standard and modified B210s if I switch the CFO estimation algorithm to Cyclic prefix. If I put the emulator back into my lab setup, I can now reach +- 100 Hz frequency shift.

I'll try switching to wireless to see how that affects performance.
________________________________
From: Paul Sutton [paul at softwareradiosystems.com]
Sent: Monday, March 06, 2017 10:21 AM
To: Patrick Cutno; srslte-users at lists.softwareradiosystems.com
Subject: Re: [srslte-users] Center frequency offset (CFO) with doubles instead of floats?

Hi Patrick,
You manually adjust the uplink and downlink frequencies.
At this point, I don't believe any of the issues you're seeing are related to CFO but rather could be related to latencies introduced by your lab setup. The HARQ procedure of LTE requires a 4ms turn-around time including signal reception, buffering and bus transfer, demodulation, transmission preparation and bus transfer back to the RF front-end. Introduction of additional equipment such as your channel emulator makes it unlikely that this 4ms deadline can be met.

Regards,
Paul

On 06/03/17 15:15, Patrick Cutno wrote:
If you don't mind, could you tell me how to manually specify an offset? Is there an offset parameter in srsUE and the Amarisoft stack?

Or do I manually change the uplink and downlink frequencies?

--Previous email (I didn't include the mailing list in my last reply, so its added here)--
Sorry for the late response, I am using Amarisoft's eNB setup with a B210 (and another B210 for srsUE).

Here is my lab setup with the emulator:
srsUE B210 TX -> 20 dB attenuator -> emulator CH 1 IN -> emulator CH 1 OUT -> Amarisoft B210 RX
Amarisoft B210 TX -> 20 dB attenuator -> emulator CH 2 IN -> emulator CH 2 OUT -> srsUE B210 RX

I wasn't aware you could specify an offset with the config files, I'll look into when I can. Do you think the config change would improve the CFO calculations I am seeing over the hardware changes in my current setup?
________________________________
From: Paul Sutton [paul at softwareradiosystems.com<mailto:paul at softwareradiosystems.com>]
Sent: Friday, March 03, 2017 11:10 AM
To: Patrick Cutno; srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] Center frequency offset (CFO) with doubles instead of floats?

What was your lab setup with the Spirent channel emulator? What eNB/EPC were you using?
To apply a fixed frequency offset, you could simply set manual offsets for the DL and UL frequencies in the srsUE configuration and/or eNB configuration.

On 03/03/17 14:59, Patrick Cutno wrote:
Thanks for the response Paul.

When using the default PSS CFO algorithm, the CFO estimation tends to jump around by a few hundred Hz during normal operation. We at GIRD Systems, Inc. didn't think much of it, because everything worked and were within the LTE spec. However when we use a Spirent SR5500 channel emulator to apply a fixed frequency offset on the uplink and downlink channels to simulate a persistent Doppler shift, we could only apply +/- 80 Hz before we got a link failure reported by srsUE.

>From there, we decided have all of our B210's output a continuous sine wave and observed all of the B210's we had are all off frequency and not properly tuned. We fixed this by injecting a reference signal directly into two of the boards, thus removing the need to call the UHD function that enables the external reference. With this modification, the CFO no longer jumped around at normal operations, but had a odd sweeping nature with a negative bias. Observing the frequency error of the eNB TX port, we could clearly see that the frequency offset was never greater than +/- 10 Hz. Yet, srsUE's trace and log were reporting a moving CFO that ranged from +240 to -240 Hz. Once the CFO fell to -240 Hz, it would wrap around to +240 Hz and cause a link failure. I assume it has to do with the massive change in CFO? I also noticed that 'q->peak_value' in sync.c spiked to +200 during the CFO wrap around instead of staying around 30 like normal (If that helps).

The odd sweeping CFO on two frequency locked boards led us to believe that something was happening with the CFO calculation. We also noticed that a Cyclic prefix estimation was used previously and srsUE only switch to PSS for 'better performance'. For the fun of it, we decided to switch the code back to using the Cyclic prefix estimation as the code was still present. This fixed the odd sweeping nature we were seeing and the CFO estimation was much more stable (always +/- 50 Hz). Further reinforcing our belief that our issue is with the CFO estimation.

I still have more testing to do, mainly trying the channel emulator again, but I will report back any new results I find.

Thanks,
Pat
________________________________
From: Paul Sutton [paul at softwareradiosystems.com<mailto:paul at softwareradiosystems.com>]
Sent: Friday, March 03, 2017 6:40 AM
To: Patrick Cutno; srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] Center frequency offset (CFO) with doubles instead of floats?

Hi Patrick,

The subcarrier spacing for LTE is 15KHz and the cfo estimation/correction algorithm should detect/correct up to at least 7.5KHz.
Can you provide more detail on what segfaults and/or link-failures you're seeing and why you think CFO is the problem?

Thanks,
Paul

On 27/02/17 21:33, Patrick Cutno wrote:
Hello world,

I am having an issue with the CFO reported by srsUE. By default srs uses the PSS algorithm to estimate the cfo, but in my tests, the cfo value tends to jump around or sweep across a large range of frequencies. Even using two boards that are locked together with the same reference signal, actually causes segfaults or link-failures because of the odd behavior of the CFO.

With the default PSS algorithm I can at most get a CFO value of +/- 80 Hz because the offset jumps around a lot. With the two locked boards and the default PSS algorithm, the sweeping nature causes segfaults no matter what the initial CFO is.

My coworkers and I assume the sweeping has something to do with the fact that a lot of the variables are stored as floats. As numbers are multiplied and dividend, precision is lost and the rounding is causing a slight negative bias that is sweeping the CFO from 0 to -240 Hz and wrapping around to +240 Hz.

1) Obviously floats take up less memory than doubles but is it worth it to change the variables to doubles to increase precision? Has srs looked into this?

2) What issues were encountered with the cyclic prefix method that the code was changed to use the PSS method of CFO estimation?

Thanks,
Pat

------------------------------------
P.S. Changing the algorithm to use the cyclic prefix meathod for cfo estimation, the cfo reported is about +/- 50 Hz, which is great, except any CFO value introduced between 0 and 110 Hz will always lead to a link-failure. With the exception of the 'dead zone', I can reach offsets of +/- 6 kHz with the cyclic prefix algorithm! Even +/- 7 kHz with higher probabilities of segmentation faults.
------------------------------------

_______________________________________________
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

--
________________________________________________________________
Paul Sutton Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

+353-87-9813473 | paul at softwareradiosystems.com<mailto:paul at softwareradiosystems.com>

PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
________________________________________________________________

--
________________________________________________________________
Paul Sutton Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

+353-87-9813473 | paul at softwareradiosystems.com<mailto:paul at softwareradiosystems.com>

PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
________________________________________________________________

--
________________________________________________________________
Paul Sutton Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

+353-87-9813473 | paul at softwareradiosystems.com<mailto:paul at softwareradiosystems.com>

PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20170306/bc968fcf/attachment.htm>