Merge remote-tracking branch 'origin/develop' into threading-rk

This commit is contained in:
Raymond Knopp
2023-04-28 22:28:18 +02:00
120 changed files with 3731 additions and 4181 deletions
+29 -2
View File
@@ -39,11 +39,38 @@ Note 2: when using multiple USRPs they always have to be synchronized using "ext
Last but not least you may specify that only a specfic subdevice of the USRP is used. See also https://files.ettus.com/manual/page_configuration.html#config_subdev
For example on a USRP N310 the following fields will specify that you use channel 0 of subdevice A.
For example on a USRP N310 the following fields will specify that you use channel 0 of subdevice A. You can enter this information after providing the ip addresses of the USRPs in sdr_addrs.
```bash
tx_subdev = "A:0"
rx_subdev = "A:0"
```
Here is an example of the RUs configuration for a setup with 2 USRP N310.
When combining this with the multi USRP feature you can easily create a distributed antenna array with only 1 channel used at each USRP.
```bash
RUs = (
{
local_rf = "yes"
nb_tx = 2
nb_rx = 2
att_tx = 0
att_rx = 0;
bands = [78];
max_pdschReferenceSignalPower = -27;
max_rxgain = 75;
eNB_instances = [0];
##beamforming 1x2 matrix: 1 layer x 2 antennas
bf_weights = [0x00007fff, 0x0000];
sdr_addrs = "addr0=192.168.10.2,addr1=192.168.20.2,clock_source=external,time_source=external"
tx_subdev ="A:0 B:0"
rx_subdev ="A:1 B:1"
}
);
```
Hint:
You cannot see TX/RX spread over multiple USRPs, if you use "internal" as a refrence of the clock and time source.
Furthur information about synchronization on the USRP N3xx devices can be found here: https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
When combining this with the multi USRP feature you can create a distributed antenna array with only 1 channel used at each USRP.
+2 -2
View File
@@ -75,7 +75,7 @@ U[HW]I ru thread Writing file header to /tmp/iqfile
```
### Playback/replay mode
When replaying iq's received by eNB or gNB The option works only for 5MHz bandwidth because the information stored in the iq's file header regarding bandwidth is not yet properly processed.
When replaying iq's received by eNB or gNB The option works only for 40MHz bandwidth 3/4 sampling because the information stored in the iq's file header regarding bandwidth is not yet properly processed. In addition the current implementation has only been validated with nr-uesoftmodem in 5G SA configuration.
In this version, mismatch between file content and run time parameters might lead to unpredictable results. In addition a file recorded on a AVX2-capable processor cannot be replayed on a non-AVX2-capable processor (this is to be further investigated).
options for replay mode are:
* `subframes-replay` Activate replay mode
@@ -159,6 +159,6 @@ The replay feature is implemented as a oai device.
* s device is automatically, dynamicaly loaded when the player feature is activated at runtime when the boolean `device.recplay.subframes-replay` option is set.
### iq's file format
The recorder adds a header containing the device type, the bandwith and a format identifier. Using these information when replaying a file has not yet been implemented, so the player only supports USRP B2xx device and 5MHz bandwith.
The recorder adds a header containing the device type, the bandwith and a format identifier. Using these information when replaying a file has not yet been implemented, so the player only supports USRP B2xx device and 40MHz bandwith 3/4 sampling.
[oai Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)