Pau Espin Pedrol | 3984256 | 2018-09-19 16:36:31 +0200 | [diff] [blame] | 1 | [[osmotrx_device_support]] |
| 2 | == OsmoTRX hardware device support |
| 3 | |
| 4 | OsmoTRX consists of a _common_ part that applies to all TRX devices as well as |
| 5 | _hardware-specific_ parts for each TRX device. The hardware-specific parts are |
| 6 | usually provided by vendor-specific or device-specific libraries that are then |
| 7 | handled by some OsmoTRX glue code presenting a unified interface towards the |
| 8 | rest of the code by means of a _RadioDevice_ class. |
| 9 | |
| 10 | The common part includes the core TRX architecture as well as code for |
| 11 | implementing the external interfaces such as the TRX Manager UDP socket, |
| 12 | control, and VTY interfaces. |
| 13 | |
| 14 | The hardware-specific parts include support for driving one particular |
| 15 | implementation of a radio modem. Such a physical layer |
| 16 | implementation can come in many forms. Sometimes it runs on a general |
| 17 | purpose CPU, sometimes on a dedicated ARM core, a dedicated DSP, a |
| 18 | combination of DSP and FPGA. |
| 19 | |
| 20 | Joining the common part with each of the available backends results in a |
| 21 | different binary with different suffix for each backend. For instance, when |
| 22 | OsmoTRX is built with UHD backend, an _osmo-trx-uhd_ binary is generated; when |
| 23 | OsmoTRX is built with LimeSuite backend, an _osmo-trx-lms_ binary is generated. |
| 24 | Build of different backend can be enabled and disabled by means of configure |
| 25 | flags, which can be found in each subsection relative to each backend below. |
Pau Espin Pedrol | 6b50b62 | 2018-09-19 17:05:30 +0200 | [diff] [blame] | 26 | |
| 27 | [[dev_ettus_usrp1]] |
| 28 | === Ettus USRP1 |
| 29 | |
| 30 | The binary _osmo-trx-usrp1_ is used to drive this device, see <<backend_usrp1>>. |
| 31 | |
Pau Espin Pedrol | 7758542 | 2019-07-30 17:37:37 +0200 | [diff] [blame] | 32 | include::./device-usrp-inband-signaling-usb.adoc[] |
| 33 | |
Pau Espin Pedrol | 6b50b62 | 2018-09-19 17:05:30 +0200 | [diff] [blame] | 34 | [[dev_ettus_b200]] |
| 35 | === Ettus B200 |
| 36 | |
| 37 | The binary _osmo-trx-uhd_ is used to drive this device, see <<backend_uhd>>. |
| 38 | |
| 39 | Comes only with 1 RF channel. It can still be used in a multi-TRX setup by using |
| 40 | the <<multiarfcn_mode>> feature. By using this feature, one can drive up to 3 |
| 41 | TRX (with the restrictions explained there). |
| 42 | |
| 43 | [[dev_ettus_b200]] |
| 44 | === Ettus B210 |
| 45 | |
| 46 | The binary _osmo-trx-uhd_ is used to drive this device, see <<backend_uhd>>. |
| 47 | |
| 48 | Comes with 2 RF channels, which can be used to set up a multi-TRX BTS. However, |
| 49 | due to a shared local oscillator for both RF channels, ARFCN separation can be |
| 50 | up about 25 MHz. |
| 51 | |
| 52 | This device also supports the <<multiarfcn_mode>> feature. By using this |
| 53 | feature, one can drive up to 3 TRX (with the restrictions explained there). |
| 54 | Please note that the above configurations cannot be combined, which means |
| 55 | maximum number of TRX one can achieve is 2 by using separate physical RF |
| 56 | channels, or 3 by using multi-ARFCN method. You cannot support, for example, 6 |
| 57 | ARFCN operation on B210 using 3 TRX on side A and another 3 TRX on side B. |
| 58 | |
| 59 | [[dev_limesdr_usb]] |
| 60 | === LimeSDR-USB |
| 61 | |
| 62 | The binary _osmo-trx-lms_ is used to drive this device, see <<backend_lms>>. |
| 63 | |
| 64 | This device comes with 2 RF channels, so it should theoretically be possible to |
| 65 | run a multi-TRX setup with it, but there are yet no records that this kind of |
| 66 | setup was tested with this device. |
| 67 | |
| 68 | This device has 3 different Rx paths with different antenna connectors in the |
| 69 | PCB, each with a different frequency and bandwidth range. One should make sure |
| 70 | the physical antenna is connected to the correct connector matching the Rx path |
| 71 | you want to use. If one wants to be able to use the device in both 900 and 1800 |
| 72 | MHz GSM bands and easily switch between them, then Rx Path `LNAW` should be used |
| 73 | ,since it is the only one covering both bands, and the antenna physically plugged |
| 74 | accordingly. Following example shows how to then configure _osmo-trx-lms_ to use |
| 75 | that Rx path to read samples. |
| 76 | |
| 77 | .Example: Configure osmo-trx-lms to use LNAW as Rx path and BAND1 as Tx Path |
| 78 | ---- |
| 79 | trx |
| 80 | ... |
| 81 | chan 0 |
| 82 | tx-path BAND1 |
| 83 | rx-path LNAW |
| 84 | ---- |
| 85 | |
| 86 | [[dev_limesdr_mini]] |
| 87 | === LimeSDR-mini |
| 88 | |
| 89 | The binary _osmo-trx-lms_ is used to drive this device, see <<backend_lms>>. |
| 90 | |
| 91 | As a smaller brother of the [[dev_limesdr_usb]], this device comes only with 1 |
| 92 | RF channel. As a result, it can only hold 1 TRX as of today. |