aboutsummaryrefslogtreecommitdiffstats
path: root/Transceiver52M/device
AgeCommit message (Collapse)AuthorFilesLines
2018-12-12LMSDevice: make use of dev-args in osmo-trx.cfgOliver Smith1-2/+40
Allow selecting a specific LimeSDR device by setting dev-args in the config file. Split up the given dev-args address by comma and select the device where all substrings can be found. I could not test this with real hardware, but I have added a test case to make sure this works as expected. Related: OS#3654 Change-Id: Ib9aaa066a01bf9de3f78234d7ada884d6f28c852
2018-12-07lms: Do {under,over}run checks even if LMS_RecvStream failsPau Espin Pedrol1-1/+1
Under failure, it could still be that stream status is updated, so let's father that in all cases. Change-Id: I4e2b8be06d2993db1bab233948a8ee774b8ac4ee
2018-12-07lms: Move {under,over}run checks into separate methodPau Espin Pedrol2-11/+16
Change-Id: I7f450aa79f6285d14826c40ecfdd9490d00509ef
2018-12-05lms: Improve Set{Rx,Tx}{Gain,Freq} loggingPau Espin Pedrol1-6/+10
Change-Id: I6713a27c5f74beb7fcfdd712fcf695afccbc3d76
2018-12-05lms: Allow setting Tx/RxFreq for lchan!=0Pau Espin Pedrol1-11/+0
Related: OS#3346 Change-Id: I9dd0bb41d1863111d28947fc0d7c7e7ecfaf5fa8
2018-12-05lms: Allow setting Tx/RxGain for chan!=0Pau Espin Pedrol1-10/+0
Related: OS#3346 Change-Id: I5fae92a7ed5e2d92be12b9dfd33fc56195030c0b
2018-12-04lms: Close device on LMS_Init failurePau Espin Pedrol1-1/+1
Change-Id: I0b307452a9e122a0ea39a46f096423c9a5293d30
2018-12-04lms: Make sure LMS_Close is called when Device is torn downPau Espin Pedrol2-0/+11
This change fixes lots of memory leaks inside libLimeSuite as announced by ASan after exiting the osmo-trx process (throgh CTRL+C for instance). This way also we make sure libLimeSuite can communicate with the HW and close whatever subsystems were enabled during LMS_Open time. Change-Id: I56ffb87079e34aa2d0322fd2ca6429742f9f7640
2018-12-03lms: Destroy streams on device stopPau Espin Pedrol1-0/+4
They are recreated during start(). Actually, if they are not stopped here, during start() after stop(), LMS_SetupStream() will fail because it will detect the streams are already opened. Change-Id: I70d47c287aabdabc5dc1304a942d130aeb10bdc5
2018-12-03lms: Fix start after stop of devicePau Espin Pedrol1-0/+6
Change-Id: I56358a1d1601853bc6dd2e6bb5f80798d0ba84b2
2018-12-02UHDDevice: log exception information on device open failured0gtail1-2/+2
Change-Id: Ia84ddcf50cc83f9326b22bfdfb4f259b4e0bc5f1
2018-11-29lms: Set Rx gain to midpoint, as comment suggests.Harald Welte1-1/+1
So far, the Rx gain was set to 34 dB, wile the comment stated it would be set to half-point, which is 73/2=36dB. Let's adjust the code to match the comment. Change-Id: Idc646def53b83faf4e6c011fb595fa436e223b32
2018-11-29lms: User correct scale factor for transmit samplesHarald Welte1-1/+8
Due to (I believe) a copy+paste mistake from the USRP1 code, we were using only a scale range of up to 9830 when transmitting samples, rather than the full 16 bit signed integer range up to 32767. As a result, we were loosing almost two bits (MSBs) of resolution as well as a lot of transmit power. This changes the scale factor to 0.707 (1/sqrt(2)). Please note that the much higher DAC output level means that the analog gain should be reduced. The theoretic range of up to 73dB should not be used, but Lime Microsystems suggest a value of 61..67 dB. This can be achieved by using a "osmotrx tx-attenuation" value of 6..12 inside the osmo-bts-trx configuration file. Related: OS#3341 Related: OS#3342 Change-Id: I71702feaa11f53e7614a6938a984dd748405474a
2018-11-23lms: Apply LMS->OSMO log level conversionPau Espin Pedrol1-1/+1
Change-Id: I3a8fbcc7cacebc7038c60175a8ae43b21f713cbb
2018-11-23lms: Use LimeSuite.h log level defines instead of hardcoded valuesPau Espin Pedrol1-4/+4
Change-Id: Iee693da1a0fa1db23deafa8d3845c04171e24799
2018-11-19UHDDevice: setRxGain on chan 0 when using multi-arfcnPau Espin Pedrol1-0/+3
When using multi-arfcn feature, several logical channels (arfcn) are multiplxed into one physical transceiver, as can be seen in uhd_device::set_channels. As a result, when multi-arfcn is enabled some properties are actually shared for those logical channels, and internally mapped to the first (only existing) channel, and per-channel internal array variables are allocated accordingly (size() == 1). When setting RxGain, we need to set the correct existing physical channel. Same check is done in getRxGain, and then we apply the RxGain correctly and we avoid outputing an error "Requested non-existent channel" immediatelly after. Change-Id: I5b02bb1ef6450dc48be7b8058d96a5691847d3cc
2018-09-28Use pthread_setname_np to name threadsPau Espin Pedrol1-0/+1
osmo-trx can start a considerable amount of threads that can make debugging it challenging at least. By using phtread_setname_np, the system sets a meaningful name to the thread which can be seen while debugging with gdb or by printing /proc/$pid/task/$tid/comm. Now we also log system TID when setting the name so we can identify different tasks in /proc even if pthread_setname_np fails. Change-Id: I84711739c3e224cb383fd12b6db933785b28209e
2018-09-20device/lms/LMSDevice.cpp: fix compilation warningVadim Yanitskiy1-1/+1
The following warning was observed with GCC 4.8.5: make[4]: Entering directory `.../osmo-trx/Transceiver52M/device/lms' CXX LMSDevice.lo LMSDevice.cpp: In member function 'LMSDevice::writeSamples()': LMSDevice.cpp:582:22: warning: 'rc' may be used uninitialized in this function [-Wmaybe-uninitialized] samplesWritten += rc; Let's fix this by zero-initializing 'rc'. Change-Id: I4b4a061fc12e5fd1db8d1087d8e0c46ff1e23412
2018-09-13cosmetic: Use proper whitespace in several for loopsPau Espin Pedrol1-1/+1
Change-Id: I82bdeb8a3fa38f3d125e8cbccc3eddbf2b8d8f58
2018-09-10UHHDDevice: Replace deprecated header uhd/utils/thread_priority.hppPau Espin Pedrol1-1/+3
Fixes compilation warning: In file included from osmo-trx/Transceiver52M/device/uhd/UHDDevice.cpp:31: /usr/include/uhd/utils/thread_priority.hpp:10:17: note: #pragma message: This header is deprecated - please use <uhd/utils/thread.hpp> instead. Header was moved in uhd.git c33928d2bbdd27688c3475e77fc461e7d16eba5a. Change-Id: I6299df48a5e14c54eaa07288d166c705eb9ebdbe
2018-09-03lms: Return error on device read timeoutPau Espin Pedrol1-3/+5
If LImeSDR device is unplugged or its fw crashes during operation, reading from the device will fail and will first receive short reads and finally 0 byte reads. Let's quickly notify these events to upper layers instead of trying to process the buffer and checking timestamps for something we know it's already not useful. Related: OS#3340 Change-Id: Ib1af8cdd6cdadf581b039882add4049eea45a0f7
2018-08-17logging: Introduce new "DDEV" category for device-specific codeHarald Welte3-171/+171
The DMAIN category got too overloaded. Let's have the code in Transceive52M/device/* use the new DDEV category. Also, in some cases the log levels have been adjusted to ensure that enabling INFO level should not result in a complete overflow of messages during normal operation. Change-Id: I844fe4a75bf277cd3cc5bd8fa06e06ad97b2ea95
2018-06-20lms: Allow values diff than 34dB to be set by setRxGain()Pau Espin Pedrol1-3/+1
Until now, setRxGain in LMSDevice did not take into account the setter parameter and was always using hardcoded 34dB, which was experimentally found to be a good default value. Let's force that value during initialization, but still allow the upper layers (controlled by BTS) to set different values. osmo-bts only sends a SETRXGAIN command (which calls setRxGain in osmo-trx) if a value is explicitly set in its VTY config, so we are on the safe side if the user doesn't explicitly configure a desired dB. Change-Id: I5684e675281a3f581855dbb56d199a6fe238a712
2018-06-14usrp1: Fail in case of unsupported configurationHarald Welte1-0/+12
There might be some configuration that's not supported by osmo-bts-usrp1, and we should reject that properly. Change-Id: Ic7308ce0c57439fe97668bd31801c4bf76b797ad Closes: OS#3348
2018-06-14lms: Fail in case of unsupported configurationHarald Welte1-0/+8
There might be some configuration that's not supported by osmo-bts-lms, and we should reject that properly. Change-Id: I6f82edce589030a4407f6150fb7e8abe6417c1f2 Closes: OS#3347
2018-06-14lms: Fix coding styleHarald Welte1-10/+10
In Change-Id Ib2fca81b76d027b08e2891056fa076d071597783 we introduced some coding style violations. Let's make newly-added code follows standard Osmocom coding style. Change-Id: Ib7ddd275014f03a2eed3cddc02b1356e2b00c0bc
2018-06-14radioDevice: better encapsulation in base classHarald Welte6-34/+38
It's not good style to have the derived classes initialize members inherited from the base class using "this->foo = bar". Rather, let's make the base class have a constructor, and call that constructor to initialize the members of the base class. While doing this * rename 'offset' to 'lo_offset' to avoid confusion with timestamp offset * move 'InterfaceType' into the base class * move 'chans' into the base class * move 'rx_sps' into the base class * mark base class members as 'protected' Change-Id: Ib885675a7612a392aa7f75fca81269ddcff2f6ab
2018-06-13radioDevice: Move tx_sps from derived into base classHarald Welte6-17/+18
All three derived classes use a tx_sps member, let's move this into the base class. Change-Id: I73b4aa2705c5049561e2d7b21301a0d2b3c96ced
2018-06-13lms: Call set_antennas() during open() methodHarald Welte1-0/+5
Without this call, the antenna/path configuration is not applied. Change-Id: I0bca58266b59f1315ec72b6407fe4f4495aff678
2018-06-13lms: Fix support for rx_paths / tx_pathsHarald Welte2-3/+10
Before this patch, any configuration in osmo-trx.cfg regarding the rx and tx "antenna" (path) would have been completely ignored, as the radioDevice::make() function would simply drop those arguments to the floor. Change-Id: Ie50f854abbc9dcf351cddc052d10206382e1d5d3
2018-06-13move set_antennas() from UHD to generic radioDevice base classHarald Welte4-33/+29
Change-Id: I806143e9db21f0be4dcc6a376b3a630be7aeb3ba
2018-06-13lms: Reduce Rx gain from 47 to 34 dBZydrunas Tamosevicius1-1/+1
Initially, Rx gain was hardcoded to be 47. This was too high for our setup and we were constantly getting "clipping detected" messages. Reducing Rx gain to 34 solved the issue. However, it looks like gains should be controlled through configuration files. Change-Id: I30580f18c4ad630c09f725b1d24c125fc3119809
2018-06-13lms: fix LMS_StartStream() handling for multiple channelsZydrunas Tamosevicius1-0/+5
LMS_StartStream() (in LMSDevice::start()) was moved to separate loop. It is because LMS_SetupStream() would fail for second channel if streaming has already been started (LMS_StartStream()) for single channel configuration. Change-Id: I6704bb92864aa81417507c4ae24a22f41dc529c1
2018-06-13lms: Reduce log level of "send buffer of len ..."Zydrunas Tamosevicius1-1/+1
Log level of "send buffer of len ..." messages was changed as it was causing problems on some machines. Change-Id: I605d50e81966c7bd169b27788d62af6fb54c84e1
2018-06-13lms: Use same timestamp offset like when using LimeSDR via UHDZydrunas Tamosevicius1-5/+2
The tx timestamp offset was not set. We set it to the same value as it was in UHD interface for LimeSDR Change-Id: I78bc40cd575097f71a5f82b63467fa81c3f8d837
2018-06-13lms: Check LPBFW to set is within supported rangePau Espin Pedrol1-6/+26
As of LimeSuite 618fbb9c3188b36d75ad5785a97b8887dcc468f6, it seems 5e6 is within the returned range, but LMS_SetLPFBW fails anyway. See for more information: https://github.com/myriadrf/LimeSuite/issues/184 Change-Id: I967e7da7c0e3e8138b76733ee4a0e6311d20b62e
2018-06-13LMSDevice: Fix setup failure with LimeSuite > 18.04.1Pau Espin Pedrol1-1/+1
Fixes: https://github.com/myriadrf/LimeSuite/issues/184 Change-Id: Ia9f37995cd10d19d6820e3e12b8ee8f3efbff5d4
2018-06-13LMSDevice: Set correct values for Max{Tx,Rx}GainPau Espin Pedrol1-2/+2
Change-Id: I3b3a7080a69e15d8d6770186810d922227439099
2018-06-13LMSDevice: Reduce Rx logging verbosity: Only log unexpected timestampsHarald Welte1-1/+2
Change-Id: I06b35efb7368616b9f4d348da574cd524ffe3ea6
2018-06-13LMS_Device: Set ts_offset to 0.Harald Welte1-1/+2
I'm not quite sure what the ts_offset is for, but by using "0" we are now receiving exactly the timestamp that we're expecting: LMSDevice.cpp:486 [tid=140576250332928] chan 0 recv buffer of len 2500 expect 305ed0 got 305ed0 (305ed0) diff=0 Change-Id: I270c94945b1af9662cfc468cfda1ae3af3ac0a27
2018-06-13LMSDevice: Fix initial timestamp offset of 2500Harald Welte1-1/+1
ts_initial must not point to the timestamp of the first sample in the last "flush" sample buffer, but to the first timestamp we expect in the next buffer. Change-Id: I23af62870544d4c6cf5f6e2d6578936603bceb91
2018-06-13LMSDevice: Set low-pass filters to smallest possible optionHarald Welte1-0/+4
Rx 1.4 MHz, Tx 5MHz. Both massively too wide for GSM, but there's no smaller band-width available. Change-Id: I9723c9a2ea77f65bfa9d796d7c44adc2417e89cf
2018-06-13LMSDevice: Typo fix: s/Internal/ExternalHarald Welte1-1/+1
Change-Id: Icacfe6da90a89c7f00d62c580948fb913998eaa7
2018-06-13LMSDevice: Print sample rate range + actual sample rate after setting itHarald Welte1-0/+9
Change-Id: I19c1a5b2d2431b8d39e277244e313f6e559e4d25
2018-06-13LMSDevice: Call LMS_Init() before setting sample rateHarald Welte1-4/+6
LMS_Init() will override basically all device settings with their default value, including the sample rate. We hence have to make sure to call it before any other API function that changes the device config such as sample rate, frequency, filter bandwidth, ... Change-Id: I4cdbae8406b5e1e93da491e90f8bad41d4be748b
2018-06-13build: Add support for LimeSuite device backendPau Espin Pedrol2-0/+14
Change-Id: I239e1b37263a62b374d84974c9347e3654072e87
2018-06-13lms: Several improvements and compilation/runtime fixesPau Espin Pedrol3-124/+261
Continuation of initial work done on LimeSuite support from Harald. Change-Id: Ib2fca81b76d027b08e2891056fa076d071597783
2018-06-13Initial work towards direct LimeSuite support in OsmoTRXHarald Welte2-0/+648
This is work in progress towards a direct LimeSuite driver in OsmoTRX, bypassing the currently rather complex stack of wrappers by going through UHD, SoapyUHD, SoapySDR and LimeSuite. Change-Id: Iaef29c4c2585ef8c2f94866c9591919f538c1a2d
2018-05-08UHDDevice: Fix setup failure with LimeSuite > 18.04.1Pau Espin Pedrol1-2/+2
Fixes: https://github.com/myriadrf/LimeSuite/issues/184 Change-Id: I48ead8b8996981263297b66c0c7d3d0972261316
2018-04-24Build one osmo-trx binary for each device support enabledPau Espin Pedrol1-1/+3
Same way as we do in osmo-bts. After this commit, osmo-trx no longer exists. Instead, osmo-trx-uhd and osmo-trx-usrp1 are generated based on configure flags enabled. A new flag --with(out)-uhd has been added to enable/disable build of osmo-trx with UHD backend. It is left enabled by default to keep compatibility with older build scripts. Binary with USRP1 backend must still be manually enabled with --with-usrp1 flag. Change-Id: Iea8c0d7434762713a53440d29bf3ebd84accb262