The leak was reported by ASan.
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7fd9c9c29f41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x55bd63ae2364 in RadioInterfaceMulti::init(int) /git/osmo-trx/Transceiver52M/radioInterfaceMulti.cpp:209
#2 0x55bd63a9c6d2 in makeRadioInterface(trx_ctx*, RadioDevice*, int) /git/osmo-trx/Transceiver52M/osmo-trx.cpp:115
#3 0x55bd63a9f663 in trx_start /git/osmo-trx/Transceiver52M/osmo-trx.cpp:600
#4 0x55bd63a9fd6f in main /git/osmo-trx/Transceiver52M/osmo-trx.cpp:695
#5 0x7fd9c7910151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
Change-Id: Ia4f9d4e47caa86ada98054763573e652d281992c
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
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
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
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
In multi arfcn mode, osmo-trx would drop some bursts because it couldn't detect it
and would emit idle burst instead. Specificaly detection of peak in correlation
vector failed. Correcting copying of history in pullBuffer method fixes this issue.
[Re-worked by Pau Espin Pedrol <pespin@sysmocom.de>]
Fixes: 57df2362f0eca0a330aad3e18906046dfadb9c8b
Change-Id: I93e43f6868cd67e69fc59d2980a03550d2505bf8
The only who should be setting class instance value "underrun" to false
is isUnderrun().
Similar fixes were already applied lately to radioInterface.cpp.
Change-Id: I3239b1df4536c080365106b3e4daa523b57f5dff
It's not a pointer check or a boolean expression, in here we really
check chan index is 0, so it's more clear doing so this way like it's
done in all other places.
Change-Id: I83b14487d14ba8272f58796f640f58a88891e532
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
Fixes this type of compilation warning:
‘void* memcpy(void*, const void*, size_t)’ writing to an object of non-trivially copyable type ‘class Complex<float>’; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]
Change-Id: Ibb2380a0a335ce798fe87221519fbbebade53054
Previous checks on multi-channel TSC and ARFCN settings would fail
if channels were initialized out of order. Namely, if channel 0
was not configured first, osmo-trx would error on the control
interface leading osmo-bts to fail.
Allow global TSC setting on all channels with added logging notice.
Notify if channel frequency is unexpected - which may happen if
channels are setup out of order - but do no report as error.
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
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>
Pau Espin
Harald Welte
Timo Jacobus