aboutsummaryrefslogtreecommitdiffstats
path: root/Transceiver52M/radioInterface.h
AgeCommit message (Collapse)AuthorFilesLines
2023-08-25transceiver: add experimental viterbi equalizer supportEric1-3/+3
The VA is already being used by the ms side and is part of the original gsm design. It only works for gmsk, 4sps, and needs a bit of rx burst scaling and burst shifting. Change-Id: I9d7a4ff72e323832a94d885d5714fcde01ceeb3d
2022-12-23clean up mutex, scopedlock, and signal classesEric1-4/+3
This also uncovers very interesting design decisions like the copying of mutexes and condition vars depending on recursive locks that were previously hidden by shady c function calls.. We have perfectly good c++11 versions for all of that. While we're at it, also use the initialization list for the other (still copy constructable) vectors, which cleans up the radio interfaces. Change-Id: Idc9e3b1144c5b93f5dad2f8e0e30f1058477aa52
2020-10-14Calculate RSSI offset based on RxGain configurationPau Espin Pedrol1-0/+4
Prior to this patch, osmo-trx relied totally on proper VTY configuration being set in "rssi-offset" together with the RxGain set through TRXC in order to provide correct Uplink RSSI measurements to bts-trx. With this patch, RSSI is now by default calculated (in LMS and UHD backends) based on the currently set RxGain, by providing empirically discovered values. Still, for backward compatibility, the old "rssi-offset" command will overwrite completely the per-default calculated rssi offset. A new optional parameter "relative" is added at the end of the "rssi-offset" VTY command to flag the value as relative to the newly per-default calculated value. This way specific setups (like adding a LNA / RF fronted) can still be expressed while still keeping the automatic per-default offset. Related: OS#4468 Change-Id: I8ef78fd20c22c60d61bfb18d80a4a36df4fd6c20
2020-06-09radioInterface: Operate on real Tx power attenuation rather than on device ↵Pau Espin Pedrol1-5/+3
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-08Transceiver: Implement TRXC cmd NOMTXPOWERPau Espin Pedrol1-0/+1
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-01-07radioInterfaceMulti: Fail to tune on freq not following multi-arfcn restrictionsPau Espin Pedrol1-0/+8
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
2019-10-17Fix common misspellings and typosMartin Hauke1-2/+2
Change-Id: I4ec7accb1912c052b446be7c399bed32a8c62253
2019-09-20radioInterface: Atomically fetch and change underrun variablePau Espin Pedrol1-1/+1
Otherwise, it could happen that underrun events are lost: TxLower (isUnderrun): RxLower (pullBuffer): read(underrun) read(underrun) write(underrun, |val) [maybe underrun becomes TRUE] write(underrun, false) Similary, it could happen the other direction if atomic was only applied to isUnderrun: TxLower (isUnderrun): RxLower (pullBuffer): read(underrun) -> true read(underrun)-> true write(underrun, false) write(underrun, true|val) where val=false So in here isUnderrun would return true twice while it should only return one. Change-Id: I684e0a5d2a9583a161d5a6593559b3a9e7cd57e3
2019-09-20radioInterface: Mark setRxGain as virtualPau Espin Pedrol1-2/+2
Otherwise the parent function is always called even if the iface is radioInterfaceMult. Change-Id: Ie41efab1e60b88677bbd1ec333ea656794503a5a
2019-09-13radioInterfaceMulti: Override setTxGain() to avoid chan!=0 callsPau Espin Pedrol1-0/+4
Change-Id: I7e67f660c3b0b009db59b405de603f6058021802
2019-09-13radioInterface: Remove unusued getRxGain()Pau Espin Pedrol1-3/+0
Only the radioDevice->getRxGain() is called from inside radioInterfaceMulti, so the API in radioInterface is not used at all. Change-Id: Icc4e9a7ebfdafe7c72c535752a5e379d12592c9a
2019-09-13radioInterface: Rename mRadio to mDevicePau Espin Pedrol1-5/+5
Previous naming is ready confusing, because "Radio" is actually the common term between radioInterface and radioDevice, and it looks like it's referring to radioInterface rather than radioDevice. On the other hand, mDevice cleary states it refers to the radioDevice item. Change-Id: I708bb1992a156fb63334f5590f2c6648ca27495e
2019-08-21Drop old setPriority related codePau Espin Pedrol1-3/+0
This code is not needed anymore since we are setting SCHED_RR scheduler with a real time priority in main thread during startup, so all threads will inherit same rt priority, which should be enough to keep the process working reliably even on high system loads (from non rt processes). osmo-trx was tested to be reliable during test with stress-ng as explained in related ticket below. Related: OS#2344 Change-Id: I3a88946dd71e9aeeaac9d19d396e2236c302b608
2018-09-03radioInterface: forward errors from RadioDevice to Transceiver in recv pathPau Espin Pedrol1-5/+5
Change-Id: Id7b08b19d6575c79b4d57db656a17ff05bb61ee9
2018-09-03cosmetic: Fix trailing whitespacePau Espin Pedrol1-2/+2
Change-Id: Ia647cfed0acb35adeb9b3b7824170d06c0369ef7
2018-04-24Transceiver: Move device specific code to radioDevice classPau Espin Pedrol1-0/+3
Change-Id: Ibcf258d8bf8595e286682e0bc59391b239ea7642
2018-04-24Move device specific code out of radioInterfacePau Espin Pedrol1-8/+0
This way code of radioInterface is independent of the device and doesn't need to be rebuild for each device. Change-Id: Id104e1edef02f863b6465ced5b4241050dc188f9
2018-04-24Change configure define USRP1 to DEVICE_USRP1Pau Espin Pedrol1-2/+2
Similar as we do for ARCH_*, it's easier to find those are related to device support features. Change-Id: Iba238bff689b8f944af76120402c0fa2e29a70de
2017-05-19radioInterface: Remove UmTRX 'diversity' optionTom Tsou1-25/+2
The 'diversity' option was an experimental 2 antenna receiver implementation for UmTRX. The implementation has not been maintained and current working status is unknown. In addition to code rot, Coverity is triggering errors in the associated code sections. Removal of code cleans up many cases of special handling that were necessary to accommodate the implementation. Change-Id: I46752ccf5dbcffbec806081dec03e69a0fbdcdb7
2016-07-20uhd: Update USRP2/N200/N210 for 4 SPS RxTom Tsou1-5/+3
Requires changing the radioInterface API to pass in Rx side SPS value. Update the (deprecated) diversity configuration to match as well. Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
2016-07-01mcbts: Add multi-ARFCN radio supportTom Tsou1-1/+31
Add new radio interface "radioInterfaceMulti" for multi-carrier support. Only USRP B200/B210 devices are supported because of sample rate requirements (3.2 Msps). Only 4 SPS operation Tx/RX is supported. 8-PSK is supported. Other options may be added at a later time Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
2016-07-01iface: Add inner ring-buffer implementationTom Tsou1-17/+9
Two buffers, inner and outer, are used in the transceiver implementation. The outer buffer interfaces with the device receive interface to guarantee timestamp aligned and contiguously allocated sample buffers. The inner buffer absorbs vector size differences between GSM bursts (156 or 157 samples) and the resampler interface (typically fixed multiples of 65). Reimplement the inner buffer with a ring buffer that allows fixed size segments on the outer (resampler) portion and variable lengths (GSM side) on the inner side. Compared to the previous stack-like version, this implementation removes unnecessary copying of buffer contents. Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
2016-03-06EDGE: Setup variable sampling on receive pathTom Tsou1-1/+2
Allow setting the device to non single SPS sample rates - mainly running at 4 SPS as the signal processing library does not support other rates. Wider bandwith support is required on the receive path to avoid 8-PSK bandlimiting distortion for EDGE. Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
2014-12-15Transceiver52M: Implement POWEROFF commandTom Tsou1-1/+2
Add stop and restart capability through the POWEROFF and POWERON commands. Calling stop causes receive streaming to cease, and I/O threads to shutdown leaving only the control handling thread running. Upon receiving a POWERON command, I/O threads and device streaming are restarted. Proper shutdown of the transceiver is now initiated by the destructor, which calls the stop command internally to wind down and deallocate threads. Signed-off-by: Tom Tsou <tom@tsou.cc>
2014-12-15Transceiver52M: Allow setting gain before POWERONTom Tsou1-1/+1
There is no reason gain settings should not be modifiable when the radio is running or not. Signed-off-by: Tom Tsou <tom@tsou.cc>
2013-11-15Transceiver52M: Remove unused codeThomas Tsou1-4/+0
This includes unknown and unused variables, functions, and non-relevant documentation. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-11-15Transceiver52M: Use independent power scaling varables for each channelThomas Tsou1-3/+1
Simply vectorize the existing power state variable. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-11-15Transceiver52M: Add dual channel diversity receiver optionThomas Tsou1-8/+30
This patch add support for dual channel diversity on the receive path. This allows two antennas two shared antennas to be used for each ARFCN handling channel in the receiver. This configuration may improvde performance in multi-path fading environments, however, noise andpotential interference levels are increased due to the higher bandwidth used. The receive path is oversampled by a factor of four for a rate of 1.083333 Msps. If the receive paths are tuned within a maximum channel spacing (currently set at 600 kHz), then both ARFCN frequencies are processed by each channel of the receiver. Otherwise, the frequency shifted diversity path is disabled and standard non-diversity operation takes place. Diversity processing is handled by selecting the path with the higheset energy level and discarding the burst on the second path. Selection occurs on a burst-by-burst basis. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-11-15Transceiver52M: Set variable thread priority levelsThomas Tsou1-1/+1
The transceiver and underlying device drivers are threaded. use the following priority levels. 0.50 - UHD driver internal threads 0.45 - Receive device drive thread 0.44 - Transmit device drive thread 0.43 - UHD asynchronous update thread (error reporting) 0.42 - Receive burst processing thread(s) Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-11-15Transceiver52M: Add multi channel transceiver supportThomas Tsou1-21/+20
This patch primarily addresses devices with multiple RF front end support. Currently device support is limited to UmTRX. Vectorize transceiver variables to allow multiple asynchronous threads on the upper layer with single downlink and uplink threads driving the UHD I/O interface synchronously. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Add 64 MHz resampling option with B100Thomas Tsou1-7/+4
Move B100 to the resampling interface with default clocking. This temporarily resolves undetermined FPGA clocking issues. This also provides extensible support for multiple clocking rates and resampling ratios. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Setup dual sample rate transceiverThomas Tsou1-4/+3
This patch applies oversampling, when selected with 4 sps, to the downlink only, while running the receiver with minimal sampling at 1 sps. These split sample rates allow us to run a highly accurate downlink signal with minimal distortion, while keeping receive path channel filtering on the FPGA. Without this patch, we oversample the receive path and require a steep receive filter to get similar adjacent channel suppression as the FPGA halfband / CIC filter combination, which comes with a high computational cost. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Setup dual Laurent pulse shaping filterThomas Tsou1-1/+1
Provides substantially improved transmit phase error performance when enabled. Requires use of 4 samples per symbol, and is enabled by default when set. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Add SSE floating point / integer conversionThomas Tsou1-1/+0
Convertions are performed in multiples of 4 or 8. All loads are considered unaligned. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Replace resampler with SSE enabled implementationThomas Tsou1-5/+20
Replace the polyphase filter and resampler with a separate implementation using SSE enabled convolution. The USRP2 (including derived devices N200, N210) are the only supported devices that require sample rate conversion, so set the default resampling parameters for the 100 MHz FPGA clock. This changes the previous resampling ratios. 270.833 kHz -> 400 kHz (65 / 96) 270.833 kHz -> 390.625 kHz (52 / 75) The new resampling factor uses a USRP resampling factor of 256 instead of 250. On the device, this allows two halfband filters to be used rather than one. The end result is reduced distortial and aliasing effecits from CIC filter rolloff. B100 and USRP1 will no be supported at 400 ksps with these changes. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Rename samples-per-symbol variable namesThomas Tsou1-5/+1
Because repeatedly typing mSamplesPerSymbol is giving me carpal tunnel syndrome. Replace with the much shorter, easier to type, and just as clear name of 'sps'. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Set resampling option automatically based on deviceThomas Tsou1-3/+20
Remove the built time resampling selection and link both options. Move the normal push/pullBuffer() calls back to the base class and overload them in the inherited resampling class. USRP2/N2xx devices are the only devices that require resampling so return that resampling is necessary on the device open(), which is the point at which the device type will be known. The GSM transceiver only operates at a whole number multiple of the GSM rate and doesn't care about the actual device rate and if resampling is used. Therefore GSM specific portion of the transceiver should only need to submit the samples-per-symbol value to the device interface. Then, the device should be able to determine the appropriate sample rate (400 ksps or 270.833 ksps) and if resampling is appropriate. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Remove and rename oversampling variablesThomas Tsou1-4/+1
The transceiver only uses a single integer oversampling value, which is more simply referred to as samples-per-symbol. mRadioOversampling --> mSPS mTransceiverOversampling (removed) Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Remove periodic alignment update from UHD buildThomas Tsou1-4/+4
Periodic timing alignment should never be required for UHD devices, though the mechanism was used as a fallback mechanism should UHD not properly recover after an underrun - as may occur in old 003.003.000 based revisions. This issue is not a concern in more recent UHD releases and deprecates this code for legacy USRP1 use only. Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-10-18Transceiver52M: Add UHD device type checkingThomas Tsou1-2/+2
UHD device type was previously detected, but only categorized in terms of bus type, USB or Ethernet, and sample rate capability. With the number of supported device increasing, we can no longer easily group devices since we need to handle more and more device-specific peculiarities. Some of these factors are managed internally by the UHD driver, but other factors (e.g. timing offsets) are specific to a single device. Start by maintaining an enumerated list of relevant device types that we can use for applying device specific operations. Also rename the USB/Ethernet grouping to transmit window type because that's what it is. enum uhd_dev_type { USRP1, USRP2, B100, NUM_USRP_TYPES, }; Signed-off-by: Thomas Tsou <tom@tsou.cc>
2013-06-16Fix build of the Transceiver.Alexander Chemeris1-0/+2
2011-11-26transceiver: make the transmit drive loop bus dependentkurtis.heimerl1-0/+3
With the introduction of the B100, there is USB support using UHD devices. The characteristics of the trasmit side burst submissions are more reflective of the bus type than the device or driver. Use a fixed latency interval for network devices and the adaptive underrun approach for USB devices - regardless of driver or device type. The GPMC based transport on the E100 appears unaffected by either latency scheme, which defaults to network. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2677 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-11-26transceiver: move various radio interface definitionskurtis.heimerl1-9/+8
Move them out of the interface file - primarily for readability. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2674 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-11-26transceiver: separate I/O portion of radio interface implementationkurtis.heimerl1-7/+7
Move push and pull of buffers into a dedicated file. This will allow us to swap out resampling, non-resampling, and possibly floating point device interfaces while presenting a single floating point abstration in the interface itself. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2670 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-11-26transceiver: separate radio clock and vector interfaceskurtis.heimerl1-95/+2
Remove radio clock and vector interfaces into their own files. This clears up and simplifies the radio interface and, additionaly, prepares for a further split of the I/O portion for optional resampler use. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2669 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-11-26transceiver: reinsert digital gain scalingkurtis.heimerl1-1/+4
Commit e161523c (transceiver: simplify transmit power control) changed transmit gain control to RF setting only. This was appropriate for a WBX board with 25 dB of gain control, but inappropriate for an RFX with fixed transmit gain. RFX boards will regain the ability to set transmit attenuation. Since gain is set on the RF side first, reintroducing digital gain settings should have limited overall effect on non-RFX daughterboards. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2660 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-11-26transceiver: simplify transmit power controlkurtis.heimerl1-1/+1
UHD will internally accept floats with a range of +/-1.0, which corresponds to a 16-bit signed integer range of apporximately +/- 32000. Set the default amplitude to .3, which is a safe value agaist saturation elsewhere in the transmit chain. The non-UHD maximum amplitude is unchanged at 13500. Remove digital gain control because it's unnecessary and causes extra load on enbedded systems. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2654 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-11-26uhd: inline thread priority settingkurtis.heimerl1-0/+2
Push the ability to set thread priority out to the 52M Transceiver interface, because that's where the thread control exists. Signed-off-by: Thomas Tsou <ttsou@vt.edu> git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2644 19bc5d8c-e614-43d4-8b26-e1612bc8e597
2011-10-12Adding in the missing Transceiver52M directorydburgess1-0/+243
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2307 19bc5d8c-e614-43d4-8b26-e1612bc8e597
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 06:25:57 +0000