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
Timo Jacobus