aboutsummaryrefslogtreecommitdiffstats
path: root/Transceiver52M
AgeCommit message (Collapse)AuthorFilesLines
2020-08-25devices: reset internal smart sample buffers upon stopEric4-2/+22
They are too smart, they keep the timestamps. Change-Id: Idb4b8f03eb5ffdfd6d3fdbc137b20e3ddc4cfa65
2020-08-25osmo-trx-ipcEric Wild19-2/+3636
This adds a IPC backend that uses shared memory interface to communicate with (proprietary) devices. Requires config file option dev-args ipc_msock=/path/to/socket to specify the master socket the ipc backend should connect to. If UHD is avaialble the ipc-driver-test tool can be used to test the backend with a uhd device, this was so far only tested with a b2xx. Change-Id: Ice63d3499026293ade8aad675ff7a883bcdd5756
2020-07-31Use new libosmovty cpu sched config featuresPau Espin Pedrol4-1/+17
Using the new libosmovty features allow for: * Setting different cpu-affinity masks for each thread in the process, both at startup through .cfg file as well as changing it at runtime. * Unified VTY interface to change the scheduling policy of the process inherited by all osmocom processes enabling the feature. Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c Related: SYS#4986 Change-Id: I3798603779b88ea37da03033cf7737a6e4751d6e
2020-07-27Transceiver: Add several rate_ctr for rx error conditionsPau Espin Pedrol1-5/+15
Since there's now a rate counter, we can drop log level for those events which can be bursty and hence print lots of output in short periods of time, which may affect performance. This way setting them to INFO it's enough to avoid getting them in stderr unless explicitly configured by the user (for instance to debug stuff), while still allowing a good enough level to be enabled for other targets such as gsmtap. Related: OS#4679 Change-Id: I000f7112e35ac68d3d922444f78468b1ea74cbba
2020-07-27Transceiver: Check log level before generating burst str representationPau Espin Pedrol1-1/+1
Avoid entering the logRxBurst() function and running a long loop even if not used. Change-Id: I67408bc8643d5d97355f277c4a2007064a83ae90
2020-07-17Transceiver: Lower some log levels which have an associated counterPau Espin Pedrol1-5/+5
They are left as INFO instead of DEBUG since they show possible timing/performance issues in the setup. Change-Id: I8aab10054ac89c29b871259fdbe59636723ddfb6
2020-07-17Transceiver: Restrict conditions where FN gaps are detectedPau Espin Pedrol1-1/+1
In pushRadioVector, like we did for driveTxPriorityQueue already, gaps are possible in any channel for TRX!=0, since TRX0 is the only one expected to be always transmitting. Since we always need to transmit there, it makes no sense to check for channel being not NONE. Change-Id: I3b4b85b9100f69dfa113c54a4357120bd11ec86f
2020-07-15Transceiver: Use already obtained value from Rx msg structurePau Espin Pedrol1-1/+1
Change-Id: I3854f284e6d6a561b3816b467985f59e690a282b
2020-07-15Transceiver: Provide initial value for TransceiverState::mFiller in constructorPau Espin Pedrol1-1/+1
Fixes: Coverity CID#211258 Change-Id: Ic00cc5939ca46407cb5bf8b6fcbcf3dc677041a2
2020-07-10Add rate counter for missing Txbursts when scheduled towards the radioInterfacePau Espin Pedrol1-4/+11
Related: OS#4487 Change-Id: Ibb2c492b3c67cbab11fbb936ae3a090fb5756aa8
2020-07-10Transceiver: Fix race condition obtaining Dl burst from Upper layerPau Espin Pedrol3-23/+17
The queue was being accessed sequentially obtaining and releasing the mutual exclusion zone twice. First in getStaleBurst() dropping all FN<currTime, then in getCurrentBurst() trying to obtain FN=currTime. However, since in between the mutex is released, it could happen that for instance upper layer would introduce currTime-1 in the queue, which would make then getCurrentBurst() detect that one instead of potential currTime in the queue and return NULL. By holding the mutex during the call to both functions we make sure the state is kept during the whole transaction. Related: OS#4487 (comment #7) Change-Id: If1fd8d7fc5f21ee2894192ef1ac2a3cdda6bbb98
2020-07-10Introduce rate counters to detect issues in received Dl bursts from TRXDPau Espin Pedrol2-8/+56
This ones together with rate counters already available in lower layers allows to understand better the source of the problem with stalled tx bursts. Change-Id: Ia34f7e7d780ad1e12f24638a07f05fe91f2afea5
2020-07-01TransceiverState: Initialize ctrs field in constructorPau Espin Pedrol1-0/+1
Coverity dixit: "Non-static class member field "ctrs.tx_stale_bursts" is not initialized in this constructor nor in any functions that it calls." Fixes: CID#211258 Change-Id: I4643a0500e9cad09938c05fab2f358167f72ffa9
2020-06-29Introduce rate counter tx_stale_burstsPau Espin Pedrol2-0/+14
This allows checking if there's timing issues on the downlink side between osmo-bts-trx and osmo-trx. This counter is useful to find information about osmo-bts-trx 'fn-advance' setting, since this counter basically counts if burstrs from it arrived too late to osmo-trx. Change-Id: Id6df00da81f6d6884f4dddc5a2c4b354dca3af97
2020-06-29UHDDevice: catch LookupError/IndexError in set{Rx,Tx}Antenna()Vadim Yanitskiy1-2/+16
Currently configuring 3 channels in multi-ARFCN mode makes the process crash during the Rx/Tx antenna configuration due to uncaught UHD specific LookupError/IndexError exceptions: terminate called after throwing an instance of 'uhd::index_error' what(): LookupError: IndexError: multi_usrp: TX channel 2 out of range for configured TX frontends Let's catch them and terminate gracefully. Change-Id: If66305f2787c6292375e4bfbd60c1d3d764cffd4 Related: OS#4636
2020-06-25{UHD,LMS}Dervice: Log expected resulting TxPower when setting device ↵Pau Espin Pedrol2-7/+11
specific TxGain Change-Id: I3c54c61cd6dd7e40bb2831fd4962ff72130b390d
2020-06-25Drop old TxGain APIs from parent radioDevice abstract classPau Espin Pedrol5-50/+20
All radioDevice subclasses except USRPDevice have already been reworked to use the new SetPowerAttenuation() methods, hence we can drop the compatibility layer that was added to transition from the old API to the new one, and move those functions to USRPDevice. This way we simplify the parent abstract class with methods not needed by most devices and not used anymore by external users of those classes. Change-Id: Ice005cd0a07c49b6e212c06f1228ef93c24db727
2020-06-25LMSDevice: Compute TxGain on LimeSuite API based on expected Tx output powerPau Espin Pedrol2-51/+144
Right now, according to a few measurements taken on LimeMicro devices, we expect the Tx Gain at UHD level to relate 1:1 with the slope in Tx output power given a specific band. If more fine-grained results are wanted or some device doesn't follow a 1:1 slope relationship, functions TxGain2TxPower and TxPower2TxGain need to be adapted/improved. This patch is basically doing the same thing as was done previously for UHDDevice in 992c9bd1cea410e2dd42ce7566299104b5648aff. Related: OS#4583 Change-Id: If154fe4d4cd118aa30ea43c22ee7119117b77da6
2020-06-22Transceiver: Allow sending negative nominal tx power in RSP NOMTXPOWERPau Espin Pedrol1-4/+1
Some SDR devices under some bands may provide only under 0 dBm Tx Power. Change-Id: I8cecb7a37eb80db341a624eb7b826180eac4a1d4
2020-06-19proto_trxd: Fix UndefinedBehaviorSanitizer from ubsanPau Espin Pedrol1-1/+1
From UBSan: proto_trxd.c:65:18: runtime error: 128 is outside the range of representable values of type 'char'. Fixes: OS#4507 Change-Id: I71f815fe794a00934ee0e876848af56f30a21bfe
2020-06-15UHDDevice: Compute TxGain on UHD API based on expected Tx output powerPau Espin Pedrol2-44/+55
Right now, according to a few measurements taken on B210, we expect the Tx Gain at UHD level to relate 1:1 with the slope in Tx output power given a specific band. If more fine-grained results are wanted or some device doesn't follow a 1:1 slope relationship, functions TxGain2TxPower and TxPower2TxGain need to be adapted/improved. Change-Id: I6f432465dce5c6ec1f1bc4653f6149efb18c3f43
2020-06-09radioInterface: Operate on real Tx power attenuation rather than on device ↵Pau Espin Pedrol7-61/+59
specific gains All the Tx gain related APIs are left out of reach from radioInterface, and in there we simply interact with radioDevice passing the attenuation received from TRXC. Prior gain logic is moved in base radiodevice class, with the idea that the setTxGain() and related functions will be dropped over time in each sublcass in favour of an specific implementation of the SetPowerAttenuation API. Change-Id: I4f8a1bcbed74aa9310306b97b0b1bfb02f7855e6
2020-06-09UHDDevice: Implement getNominalTxPower() based on TxFrequencyPau Espin Pedrol2-6/+90
The table with nominal UHD Tx Gains and real transmit power is filled with values measured experimentally. More information can be found in OS#4583. Related: OS#4583 Change-Id: If7ef5bf95ffe4afe5864c0f051853aa38b9639eb
2020-06-08Transceiver: Implement TRXC cmd NOMTXPOWERPau Espin Pedrol10-0/+50
It allows the BTS to retrieve the nominal transmit output power value of each TRX in order to compute attenuation later on and apply it through SETPOWER or ADJPOWER TRXC commands. Change-Id: I1d7efe56e008d8d60e23f9a85aa40809f7f84d9c
2020-05-29Transceiver: Fix extra space in RSP NOISELEV errorPau Espin Pedrol1-1/+1
Change-Id: I35c2f3b3b9358ddb64a53f36969621d45bb243f8
2020-05-26Transceiver: Log when sending of CLK indications beginsPhilipp Maier1-0/+2
When the logging category TRXCLK is set to info osmo-trx prints a logline that informs about the sending of clock indications. In practice this those log lines are often used to identify that osmo-trx and osmo-bts are running properly, so it would be helpful, even in productive use, if there would be an information in the log that the sending of clock indications has begun. However, the regular printing of the clock indication log line would soon flood the log. So, lets have an addional log line that logs only once when the transceiver starts and quickly informs at loglevel NOTICE that clock indications are now sent. Change-Id: I6aa88943b76c9a2bf7aed60d6a3d325c1f27820a Related: OS#2577
2020-05-09Use OSMO_FD_READ instead of deprecated BSC_FD_READPau Espin Pedrol1-1/+1
New define is available since libosmocore 1.1.0, and we already require 1.3.0, so no need to update dependenices. Let's change it to avoid people re-using old BSC_FD_READ symbol when copy-pasting somewhere else. Change-Id: I868baf575b77c448b3115701e70d439de89b0fb3
2020-04-14transceiver: get rid of the ctrl threadsEric3-75/+124
There is no need to have n threads handle n ctrl sockets, since they all will immediately respond to commands, so handle them from the existing main osmo select loop. Care must be taken to ensure that calls from within the command handler do not block, or at least don't block too long, which currently is the case. Change-Id: I642a34451e1825eafecf71a902df916ccee7944c
2020-04-14transceiver: check the right vectorEric1-2/+2
Change-Id: I03800ae094c35c306fa4ca29f84e71d958ffdbdc
2020-03-12radioDevice: Drop unused isControl param from WriteSamples APIPau Espin Pedrol7-26/+18
The out "isControl" parameter is only used by internal callers of USRPDevice, and not used at all by any user of the generic API (radioInterface*.cpp). Hence, we can get rid of it and keep it as a flag for an internal API of USRPDevice. Change-Id: I843384e24b76cdd28a95f9ee4e95e6157098e4a3
2020-03-12radioDevice: Drop unused RSSI param from readSamples APIPau Espin Pedrol7-14/+11
The out "RSSI" parameter is only filled by USRPDevice, and not used at all by any user of the API (radioInterface*.cpp). RSSI seems to be computed nowadays in the common path in Transceiver::pullRadioVector(). Change-Id: I06c2ea5a9891d170bc468f952bbf2a7e64d95784
2020-02-25cosmetic: fix several typos found by codespellPau Espin Pedrol1-2/+2
Change-Id: Id1f6766572fd313463201e6d03964965f227db25
2020-01-15lms: Initial multi-arfcn supportPau Espin Pedrol1-7/+17
With current state multi-arfcn can be used (eg. I can place a call between 2 phones using TRX1 and sustain for as long as wanted), but from time to time (around every 20seconds), a burst of Tx packed dropped events from LimeSuite appears. LimeNet-micro coefficients have yet not been tested. Related: OS#4362 Change-Id: I7e67d90a8126546eeeeba376f816ec5d158d4712
2020-01-15lms: Make ts_offset and smpl rate coefs device-specificPau Espin Pedrol1-8/+12
Right now the values are the same for all devices, but they will differ in forthcoming commits once multi-arfcn support is added. Change-Id: I262d3a71848fc3070473e29e42820848e7591d02
2020-01-15lms: Store device type specific parameters in one placePau Espin Pedrol2-25/+117
Add an enum containing each supported device type (LimeSDR-USB, LimeSDR-Mini and LimeNet-Micro) plus "unknown", to leave some room for yet-to-come devices to run with some generic parameters without rebuilding osmo-trx. Each device type is assigned a dev_desc structure, and all of them are put in HashMap, similar to what's already done in UHDDevice.cpp. Device type is infered from string provided by LMS_GetDeviceInfo(), as it was already done before in several places. From now on, we only need to parse the string once since we store the device type after first during open time. Later on, more fields will be moved to device-type specific structure, such as Tx timing offset, clock rate, etc. Change-Id: I7658615787c5bc41c365bab9c11733b701ac2ae5
2020-01-15lms: Move rx_buffers allocation to constructorPau Espin Pedrol1-4/+5
Release is done in destructor, so let's move allocation to constructor since there's really no need to have them in open() which is already quite complex and large. Change-Id: I8a4fd973590c4c165abd8f2837b2da8fc14a2066
2020-01-15lms: Make reference to std::vector unambiguousPau Espin Pedrol1-1/+1
Change-Id: Ieebdbd3d5082a02aea2441e6737783370511cbc1
2020-01-13lms: Change radioDevice constructor arg name to avoid masking instance attrPau Espin Pedrol6-9/+9
channel number mangling based on multi-arfcn feature being enabled was moved to generic radioDevice() to reuse code. Hence, the generic parent constructor sets this->chans to 1 if multi-arfcn feature is requested. However, LMSDevice constructor argument had same name as the class instance attribute, taking preference. As a result, if multi-arfcn is enabled in LMSDevice, the generic constructor first sets this->chans=1 but afterwards LMSDEvice constructor keeps calling .resize() with the argument value "chans" instead of using this->chans. Let's rename the argument in all radioDevice child class constructors to avoid potential future bugs in all of them. Change-Id: Id6c837e9133f22783dd92a81dfcc493e51bf2d21
2020-01-13lms: Improve smpl_buf error loggingPau Espin Pedrol1-2/+3
Change-Id: I511abe2c333443b978a3767bd7b7e320e07c4930
2020-01-13smpl_buf: Fix str_code() param and print unknown error valPau Espin Pedrol2-3/+5
Change-Id: I95fadac15b9ad337ebc7cfb44a20dcf803ff8a47
2020-01-07lms: Drop unused definePau Espin Pedrol1-1/+0
Change-Id: Iaf3361ed29dd552e5e52b62bc738fa20c6b583fe
2020-01-07lms: Move initialization of field started to constructorPau Espin Pedrol1-3/+1
Change-Id: I135a2ff4a419775169452be1128c7b30f7d638ad
2020-01-07radioInterfaceMulti: Fail to tune on freq not following multi-arfcn restrictionsPau Espin Pedrol2-22/+59
multi-arfcn feature uses a hardcoded disposition of logical channels on a physical channel. Logical channels in the phisical channel are separated by MCBTS_SPACING Hz, that is 4 GSM ARFCNs. As a result, multi-arfcn restricts the TRX ARFCN setup to the following: ARFCN(TRX0)=N, ARFCN(TRX1)=N+1*4, ARFCN(TRX2)=N+2*4, ... Let's make sure radioInterfaceMulti verifies the requested Rx/Tx frequencies for each logical channel over TRXC match the restriction explained above. It will check freq going to be set is indeed separated by MCBTS_SPACING from already set channels, making sure the ARFCN series is consistent. Otherwise, before this patch, one could set in osmo-bsc: ARFCN(TRX0)=N, ARFCN(TRX1)=N+2 and osmo-trx would silently ack the related Rx/TxTUNE TRXC commands, but actually still transmit on ARFCN N+4 instead. As a result, in this scenario TRX!=0 were unusable with multi-arfcn. Related: OS#4207 Change-Id: I2f3d66a611d3a489b3e4d9431994f4ec77b4460f
2020-01-07uhd: Improve some logging lines printing UHD pretty-print outputPau Espin Pedrol1-3/+6
Change-Id: If5aba28aaf8a3312d89b3e963184f9f20966d199
2020-01-07uhd: Use DEVDRV log category and support UHD >=3.11 logging frameworkPau Espin Pedrol1-12/+48
Change-Id: I36f1ff7d425a2144fb512ff393af02741eb4a3d4
2020-01-07Make logging category DLMS generic and reusable for other backendsPau Espin Pedrol2-2/+2
Make sure old configs using "logging level lms <level>" are still accepted. Initialization order of VTY componenets need to be resorted since newly introduced command requires logging VTY node to be already setup beforehand. Change-Id: Ia195a74a62a8a3dd6267fb1359acaa5628208d8e
2019-12-20Transceiver.cpp: Introduce and use new logging categoriesPau Espin Pedrol1-35/+35
Take the chance to clean up logging lines in this file: * Use LOGCHAN in more places where chan is useful * Replace inherited (old osmo-trx) categories such as WARNING with osmocom ones. Change-Id: Ic8c218f050f35d48046ccf1561fb0bfc505d4f63
2019-12-19uhd: use value already cached in tmp variablePau Espin Pedrol1-1/+1
Change-Id: I4568eaed6db3da12f83f2f503a50032f7bfb482c
2019-12-03trx: exit() on unsupported positional arguments on command lineHarald Welte1-0/+5
Change-Id: Ifeea65a359e9ca307efb2c721fd0fb6f0959e976
2019-11-27Transceiver: Fix wrong response upon CMD HANDOVER failurePau Espin Pedrol1-1/+1
Change-Id: I9d3f120b1696a9ce92c81097d04e81dbb717287d
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-22 07:01:42 +0000