Yet another SetFrequencySXR/SXT(xxx MHz) - cannot deliver frequency issue

iandiver · 20 March 2024 02:32

Seems this is a common issue, but I have not found a situation similar to mine. I am attempting to bring up an eNodeB using OpenAirInterface (OAI) software, but the LMS library is reporting “cannot deliver frequency” errors. Strange thing is this is the case for all FDD LTE bands I have tried (2, 4, 5, 25, 26), except two (bands 7 and 12). The UE phone I am using does not support band 7 and in the US AT&T uses band 12, so I’d like to use another band.
I cannot reproduce the issue with LimeSuiteGUI, so I don’t think I have a bad board. Quick WCDMA lookback test is working. I’ve played with GNURadio and successfully received FM radio. As far as I can tell nothing else is wrong. The only thing I notice is that for both working and non-working bands the error is reported, but somehow the problem is severe enough to abort the software for bands other than 7 and 12.

Please let me know what I am missing and/or if more information is needed. Thanks.

Output from OAI lte-softmodem eNodeB executable for band 2 (not working):

$ sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band2.master.conf --rf-config-file ../../../radio/LMSSDR/LimeSDR_above_1p8GHz_1v4.ini
...
Connecting to device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1DA1501E4B09D0
[UTIL]   threadCreate for TASK_MCE_APP, affinity ffffffff, priority 50
[ITTI]   Created Posix thread TASK_MCE_APP
[ENB_APP]   [MCE 0] MCE_app_register via M3AP for instance 0
[LIBCONFIG] MCEs.[0]: 1/1 parameters successfully set, (1 to default value)
[LIBCONFIG] MCEs.[0]: 1/1 parameters successfully set, (1 to default value)
Reference clock 40.00 MHz
SetFrequencySXR(1755 MHz) - cannot deliver frequency
SetFrequencySXT(1850 MHz) - cannot deliver frequency
[ENB_APP]   TYPE <CTRL-C> TO TERMINATE
Set sample rate 15.360000 MHz
SetFrequencySXR(1900 MHz) - cannot deliver frequency
Failed to Set Rx frequency: SetFrequencySXR(1900 MHz) - cannot deliver frequency

Assertion (1==0) failed!
In ru_thread() /home/ian/Documents/Code/OpenAirInterface/openairinterface5g/executables/lte-ru.c:1717
Could not start the RF device

Exiting execution
/home/ian/Documents/Code/OpenAirInterface/openairinterface5g/executables/lte-ru.c:1717 ru_thread() Exiting OAI softmodem: _Assert_Exit_
Aborted

Output from OAI lte-softmodem eNodeB executable for band 7 (working):

$ sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.master.conf --rf-config-file ../../../radio/LMSSDR/LimeSDR_above_1p8GHz_1v4.ini
...
Connecting to device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1DA1501E4B09D0
[UTIL]   threadCreate for TASK_MCE_APP, affinity ffffffff, priority 50
[ITTI]   Created Posix thread TASK_MCE_APP
[ENB_APP]   [MCE 0] MCE_app_register via M3AP for instance 0
[LIBCONFIG] MCEs.[0]: 1/1 parameters successfully set, (1 to default value)
[LIBCONFIG] MCEs.[0]: 1/1 parameters successfully set, (1 to default value)
Reference clock 40.00 MHz
SetFrequencySXR(1755 MHz) - cannot deliver frequency
SetFrequencySXT(1850 MHz) - cannot deliver frequency
[ENB_APP]   TYPE <CTRL-C> TO TERMINATE
Set sample rate 15.360000 MHz
Selected TX path: Band 1
Set TX frequency 2685.000000 MHz
Tune Rx Filter: MCU error 2 (CGEN tune failed)
RX ch:0 filter calibration failed, bw:15.360000MHz
SetFrequencySXT(1850 MHz) - cannot deliver frequency
Tune Tx Filter: MCU error 2 (CGEN tune failed)
TX ch:0 filter calibration failed, bw:15.360000MHz
SetFrequencySXT(1850 MHz) - cannot deliver frequency
Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)
RX ch:0 calibration failed, bw:15.360000 MHz
Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)
Tx calibration finished
SR:   15.360 MHz
SR:   15.360 MHz
[PHY]   RU 0 rf device ready
[PHY]   RU 0 Starting steady-state operation
[RLC]   rlc_tick: discontinuity (expected 0.1, got 0.4)
[MAC]   SCHED_MODE = 0

Output from OAI lte-softmodem eNodeB executable for band 12 (working):

$ sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band12.master.conf --rf-config-file ../../../radio/LMSSDR/LimeSDR_below_1p8GHz_1v4.ini
...
Connecting to device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1DA1501E4B09D0
[UTIL]   threadCreate for TASK_MCE_APP, affinity ffffffff, priority 50
[ITTI]   Created Posix thread TASK_MCE_APP
[ENB_APP]   [MCE 0] MCE_app_register via M3AP for instance 0
[LIBCONFIG] MCEs.[0]: 1/1 parameters successfully set, (1 to default value)
[LIBCONFIG] MCEs.[0]: 1/1 parameters successfully set, (1 to default value)
Reference clock 40.00 MHz
SetFrequencySXR(837 MHz) - cannot deliver frequency
SetFrequencySXT(885 MHz) - cannot deliver frequency
[ENB_APP]   TYPE <CTRL-C> TO TERMINATE
Set sample rate 15.360000 MHz
Selected RX path: LNAW
Selected TX path: Band 2
Set TX frequency 736.000000 MHz
Tune Rx Filter: MCU error 2 (CGEN tune failed)
RX ch:0 filter calibration failed, bw:15.360000MHz
SetFrequencySXT(885 MHz) - cannot deliver frequency
Tune Tx Filter: MCU error 2 (CGEN tune failed)
TX ch:0 filter calibration failed, bw:15.360000MHz
SetFrequencySXT(885 MHz) - cannot deliver frequency
Rx calibration finished
Tx calibration finished
SR:   15.360 MHz
SR:   15.360 MHz
[PHY]   RU 0 rf device ready
[PHY]   RU 0 Starting steady-state operation
[RLC]   rlc_tick: discontinuity (expected 0.1, got 0.4)
[MAC]   SCHED_MODE = 0

LimeUtil output:

$ LimeUtil --info
######################################################
## LimeSuite information summary
######################################################

Version information:
  Library version:	v22.09.1-myriadrf1~ubuntu18.04
  Build timestamp:	2022-10-16
  Interface version:	v2022.9.1
  Binary interface:	22.09-1

System resources:
  Installation root:	/usr
  User home directory:	/home/ian
  App data directory:	/home/ian/.local/share/LimeSuite
  Config directory:	/home/ian/.limesuite
  Image search paths:
     - /home/ian/.local/share/LimeSuite/images
     - /usr/share/LimeSuite/images

Supported connections:
   * FT601
   * FX3
   * PCIEXillybus

$ LimeUtil --make
Make device 
  Device name: LimeSDR-Mini_v2
  Expansion name: UNSUPPORTED
  Firmware version: 10
  Hardware version: 7
  Protocol version: 1
  Gateware version: 2
  Gateware revision: 6
  Gateware target: LimeSDR-Mini
  Serial number: 0x1da1501e4b09d0
  Free connection... OK

andrewback · 20 March 2024 09:38

That’s pretty old now. Have you tried a more recent release? Would suggest building the latest tag, v23.11.0, and testing again. After installing this also run a LimeUtil --update just to be sure.

iandiver · 20 March 2024 13:49

Thanks. Made some progress. I first tried building the latest LimeSuite on another Ubuntu PC as a test and the build failed with errors mostly for OpenGlGrahp.h/.cpp. I then tried on the PC I am using for the eNodeB and the build succeeded. I’m unclear why one worked and one didn’t as I had previously installed LimeSuite from packages on both. This leads to a question: If you install from packages and then want to build from source, what needs to be done to uninstall the packages first? I ask as the LimeSuite page mentions, " Note: either install Lime Suite via a package/installer or source code and do not do both!".
After the successful LimeSuite build on the eNodeB PC I tried running the OAI code again, but the result for bands 2 and 7 are the same (2 fails with the same error and 7 also reports same errors but does run).
I then tried the LimeSuite --update command but it failed as follows:

$ LimeUtil --update
Connected to [LimeSDR Mini [USB 3.0] 1DA1501E4B09D0]
--2024-03-20 09:22:21--  https://downloads.myriadrf.org/project/limesuite/23.11/LimeSDR-Mini_HW_2.0_r2.2.bit
Resolving downloads.myriadrf.org (downloads.myriadrf.org)... 165.227.233.124, 2a03:b0c0:1:d0::eed:8001
Connecting to downloads.myriadrf.org (downloads.myriadrf.org)|165.227.233.124|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2024-03-20 09:22:22 ERROR 404: Not Found.

Failed: wget --output-document="/home/ian/.local/share/LimeSuite/images/23.11/LimeSDR-Mini_HW_2.0_r2.2.bit" "https://downloads.myriadrf.org/project/limesuite/23.11/LimeSDR-Mini_HW_2.0_r2.2.bit"

Programming update failed!

I happened to then see the extra step for Linux of installing the udev rules (not sure if this makes much difference):

cd LimeSuite/udev-rules
sudo ./install.sh

After doing I tried the eNodeB again with the same results as above. I then tried the LimeSUite --update once more, but this also failed in a different way:

$ LimeUtil --update
Connected to [LimeSDR Mini [USB 3.0] 1DA1501E4B09D0]
ProgramWrite length should be > 0

Programming update failed!

Not sure what I am doing wrong at this point. I have the latest LimeSuite 23.11 installed (had to reboot after install). Any thoughts?

$ LimeUtil --info
######################################################
## LimeSuite information summary
######################################################

Version information:
  Library version:	v23.11.0-g9dce3b6a
  Build timestamp:	2024-03-20
  Interface version:	v2023.11.0
  Binary interface:	23.11-1

System resources:
  Installation root:	/usr/local
  User home directory:	/home/ian
  App data directory:	/home/ian/.local/share/LimeSuite
  Config directory:	/home/ian/.limesuite
  Image search paths:
     - /home/ian/.local/share/LimeSuite/images
     - /usr/local/share/LimeSuite/images

Supported connections:
   * FT601
   * FX3
   * PCIEXillybus

$ LimeUtil --make
Make device 
  Device name: LimeSDR-Mini_v2
  Expansion name: UNSUPPORTED
  Firmware version: 10
  Hardware version: 7
  Protocol version: 1
  Gateware version: 2
  Gateware revision: 6
  Gateware target: LimeSDR-Mini
  Serial number: 0x1da1501e4b09d0
  Free connection... OK

andrewback · 20 March 2024 13:59

You use the package management system to uninstall them. Although I have had both packages and source builds installed at the same time previously, and just found that priority was given to the latter due to path ordering. Though to rule out any strange issues I would recommend just having one or the other.

OK, just make sure you don’t have a 0 bytes file /home/ian/.local/share/LimeSuite/images/23.11/LimeSDR-Mini_HW_2.0_r2.2.bit (if you do, rm it) and then re-run the update.

Right, it probably created an empty file when you first ran the update and it failed to download. See above to rm it.

iandiver · 20 March 2024 15:07

Thank you. Deleting the zero length image allowed LimeUtil --update to work. Got successful programming, however, the version numbers did not change so I suspect the board was already up-to-date. Having done this there is no change to the issue, so it seems running all the latest software/firmware does not help.
I notice these errors in the output (they appear in both the working and non-working cases) - do these mean anything?

Tune Rx Filter: MCU error 2 (CGEN tune failed)

Rx calibration: MCU error 5 (Loopback signal weak: not connected/insufficient gain?)

In an attempt to research further I found this thread (Calibration Error [Fixed] - #5 by ricardas), so I played around with LimeSuiteGUI to see if I could reproduce the issue and try different CSW_VCO_CGEN and Scales VCO bias current values. I could not cause any error in the GUI, no matter what I try it always seems to work. This seems to suggest there is no hardware issue. If so, why the MCU errors above? If gain is an issue how can I determine the correct values? If not, then what else can I try? Are there any other diagnostics I can run?
Many thanks.

andrewback · 20 March 2024 15:14

I couldn’t say, but at least we have now verified the hardware and know that you are running the latest Lime Suite release and gateware. It could be an issue with these, but then we have this hardware working fine with the Amarisoft stack, so it could be OAI related (it’s not proved the most stable of stacks…)

Tagging @Zack and @ricardas to see if they have any suggestions.

iandiver · 22 March 2024 16:47

Even if OAI is not stable, why do I get these errors in LimeSuiteGUI when loading the configuration file LimeSDR_above_1p8GHz_1v4.ini, and what do they mean? What do I need to do to eliminate them? Or do I just ignore them? I haven’t found any documentation for them.
I’m not convinced my board is working. Besides the quick test reporting no failures and the FM_Receiver example working in GNURadio I cannot get anything to work. How can I verify a signal is actually being transmitted besides the red LED being lit?

iandiver · 22 March 2024 21:53

I believe I can answer one question myself: the meaning of the above errors. It seems the PLLs are not locking with any value of the VCO control voltage. I have found I can make the errors go away by selecting the Enable coarse tuning block button in the GUI. I am not sure what this is doing, but it appears to work in the GUI. However, after saving the configuration file and using it with the OAI software to start the eNodeB, I am still seeing errors apparently indicating a failure to lock. I suspect the OAI code is somehow disabling the coarse tuning block feature, but without knowing how this switch maps to an LMS library API call I am not sure how to check this.

VytautasB · 25 March 2024 07:39

Hi @iandiver,

looks like you have incorrect reference clock settings in your .ini configuration file. LimeSDR-Mini v2 board has 40MHz reference clock and from your image I can see that you have loaded .ini file which has 30.72MHz setting.

Try to change reference clock setting in SXT and SXR tabs to 40MHz and then hit “Calculate”, “Tune” buttons in SXT, SXR and CLKGEN tabs.

Regards,
Vytautas

andrewback · 25 March 2024 11:40

Thanks, @VytautasB.

More generally I wonder if anyone has ever used OAI with a LimeSDR Mini v2. IIRC most of the time it was used with the original LimeSDR USB, which is presumably what this INI file was intended for.

iandiver · 25 March 2024 16:06

Thank you @VytautasB and @andrewback . Changing the reference clock to 40 MHz in the SXR and SXT tabs and saving a new configuration file seems to have eliminated the “cannot deliver frequency” errors. I was not aware that different LimeSDR boards had different reference clocks, or that the frequency needs to match in the configuration file.
For my understanding then, the reference clock frequency in a configuration file must match the clock frequency of the board, if a configuration file is used, correct? Do I understand correctly that a configuration file is not always used (in which case the LimeSDR library finds the correct clock frequency by itself according to the DetectRefClk() function in LimeSuite/src/FPGA_common/FPGA_common.cpp)? If the answer is yes to both questions, then I understand. If not, can you clarify how something like GNURadio works with no apparent configuration file (i.e. how does GNURadio know the correct clock frequency)? Thanks.

andrewback · 26 March 2024 09:24

Yes.

Yes. Most applications simply use LMS API (or some abstraction above) for configuration, whereas some load an INI file with a base configuration. With obvious trade-offs.

It uses API functions, as does the LibreCellular fork of srsRAN, for example.

github.com

myriadrf/srsRAN_4G/blob/lc/main/lib/src/phy/rf/rf_lime_imp.c

/**
 * Copyright 2013-2022 Software Radio Systems Limited 
 * Copyright 2020-2002 Lime MicroSystems Ltd
 *
 * This file is part of srsRAN.
 *
 * srsRAN is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License as
 * published by the Free Software Foundation, either version 3 of
 * the License, or (at your option) any later version.
 *
 * srsRAN is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU Affero General Public License for more details.
 *
 * A copy of the GNU Affero General Public License can be found in
 * the LICENSE file in the top-level directory of this distribution
 * and at http://www.gnu.org/licenses/.
 *

This file has been truncated. show original

Even with this there may be changes required when switching from one LimeSDR variant to another, such as the RF ports to use (different RFIC ports may be connected).

With srsRAN there is also an eNB configuration parameter called time_adv_nsamples (transmission time advance in number of samples to compensate for RF delay from antenna to timestamp insertion), the optimal value for which may vary with SDR architecture.

Hence it may not be that you can take one codebase and set of configuration which is tested with one hardware platform, and then use that with a new SDR, without some changes being required.