24 Jan
2014
24 Jan
'14
10:29 a.m.
hi,
i experience problems with osmo-trx/umtrx. when i start osmo-trx, i get
the following output:
openbsc osmo-trx # /files/projects/gsm/osmo-trx/Transceiver52M/osmo-trx
linux; GNU C++ version 4.5.4; Boost_104900; UHD_003.004.000-1b07671
Config Settings
Log Level............... NOTICE
Device args.............
TRX Base Port........... 5700
TRX Address............. 127.0.0.1
Channels................ 1
Samples-per-Symbol...... 4
External Reference...... Disabled
Diversity............... Disabled
-- Opening a UmTRX device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Setting UmTRX 4 SPS
-- Transceiver active with 1 channel(s)
i use current master. (an older version with branch umtrx_dual_test
works with two TRX.) when i use RSSI test phone, i see that the RF power
is high on TS0 and TS1 only. also it takes many tries to sync to it. i
receive BCCH infos with some dropouts, but RACH is not received.
i have no slotmask define at osmo-bts. any idea what causes it?
regards,
andreas
24 Jan
24 Jan
11:58 a.m.
Hi Andreas,
We use the current master of osmo-trx in production and lab environments
without any issues, so there should be something wrong with your setup.
Could you please provide more details about your setup and experiments you
did?
E.g. what PC so you run it on, what is the CPU utilization, have you tried
to run it with real-time priority, what exactly you feed into the osmo-trx
and what do you see on your monitoring phone, how exactly long is "longer",
etc
We noticed, that Linux kernel 3.3 had issues with 1GbE chips from Intel, so
we switched to the kernel version 3.8, which works stable. We use kernels
from the stock Ubuntu Server 12.04.
24 янв. 2014 г. 13:47 пользователь "Andreas Eversberg"
<andreas(a)eversberg.eu>
написал:
hi,
i experience problems with osmo-trx/umtrx. when i start osmo-trx, i get
the following output:
openbsc osmo-trx # /files/projects/gsm/osmo-trx/Transceiver52M/osmo-trx
linux; GNU C++ version 4.5.4; Boost_104900; UHD_003.004.000-1b07671
Config Settings
Log Level............... NOTICE
Device args.............
TRX Base Port........... 5700
TRX Address............. 127.0.0.1
Channels................ 1
Samples-per-Symbol...... 4
External Reference...... Disabled
Diversity............... Disabled
-- Opening a UmTRX device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Setting UmTRX 4 SPS
-- Transceiver active with 1 channel(s)
i use current master. (an older version with branch umtrx_dual_test works
with two TRX.) when i use RSSI test phone, i see that the RF power is high
on TS0 and TS1 only. also it takes many tries to sync to it. i receive BCCH
infos with some dropouts, but RACH is not received.
i have no slotmask define at osmo-bts. any idea what causes it?
regards,
andreas
25 Jan
25 Jan
7:22 a.m.
Alexander Chemeris wrote:
Could you please provide more details about your setup and experiments
you did?
E.g. what PC so you run it on, what is the CPU utilization, have you
tried to run it with real-time priority, what exactly you feed into
the osmo-trx and what do you see on your monitoring phone, how exactly
long is "longer", etc
We noticed, that Linux kernel 3.3 had issues with 1GbE chips from
Intel, so we switched to the kernel version 3.8, which works stable.
We use kernels from the stock Ubuntu Server 12.04.
dear alexander,
sorry, but this was my fault. here is the reason why i have only RF
power on two slots:
- i configured TS 0 with CCCH and TS1..TS7 with SDCCH8
- i set bts type at osmo-nitb to "nanobts", which rejects SDCCH8 on TS2..TS7
- no "Set Chan Attr" was sent from osmo-nitb to osmo-bts for TS2..TS7,
so osmo-bts did not send SETTSC to osmo-trx.
the thing is that the transceiver will only send bursts to umtx, if
SETTSC was given. (makes sense)
i found out that sending no butsts from osmo-trx to the transceiver will
cause no RF output. this is why osmo-bts sends dummy bursts for the
first TRX, so there is RF power on all TS all the time. on other TRX,
osmo-bts send bursts, only if the logical channel (the bursts belong to)
is activated. this is the way it is done to reduce noise on the
spectrum. i can see it one the osmocombb-RSSI application. once a
channel was activeated, there will be RF power on the specific TS, even
when osmo-bts does not send bursts anymore. i guess that some filler
table of osmo-trx causes it. i think it would be nice if osmo-trx would
stop transmitting, when there are no more bursts comming from osmo-bts.
(at least after a while.)
best regards,
andreas
8:36 a.m.
On Sat, Jan 25, 2014 at 1:22 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
once a channel was activeated,
there will be RF power on the specific TS, even when osmo-bts does not send
bursts anymore. i guess that some filler table of osmo-trx causes it. i
think it would be nice if osmo-trx would stop transmitting, when there are
no more bursts comming from osmo-bts. (at least after a while.)
Yes, this is the behaviour of the filler table, which will resend the
previous frame until a new frame arrives. Sending an idle frame will
disable output, which is how the filler table is managed in OpenBTS.
You can disable the filler table with this patch.
diff --git a/Transceiver52M/Transceiver.cpp b/Transceiver52M/Transceiver.cpp
index e5ab476..9077465 100644
--- a/Transceiver52M/Transceiver.cpp
+++ b/Transceiver52M/Transceiver.cpp
@@ -197,19 +197,13 @@ void Transceiver::pushRadioVector(GSM::Time &nowTime)
TransceiverState *state;
std::vector<signalVector *> bursts(mChans);
std::vector<bool> zeros(mChans);
+ std::vector<bool> filler(mChans, true);
for (size_t i = 0; i < mChans; i ++) {
state = &mStates[i];
while ((burst = mTxPriorityQueues[i].getStaleBurst(nowTime))) {
LOG(NOTICE) << "dumping STALE burst in TRX->USRP interface";
-
- TN = burst->getTime().TN();
- modFN = burst->getTime().FN() % state->fillerModulus[TN];
-
- delete state->fillerTable[modFN][TN];
- state->fillerTable[modFN][TN] = burst->getVector();
- burst->setVector(NULL);
delete burst;
}
@@ -220,9 +214,8 @@ void Transceiver::pushRadioVector(GSM::Time &nowTime)
zeros[i] = state->chanType[TN] == NONE;
if ((burst = mTxPriorityQueues[i].getCurrentBurst(nowTime))) {
- delete state->fillerTable[modFN][TN];
- state->fillerTable[modFN][TN] = burst->getVector();
bursts[i] = burst->getVector();
+ filler[i] = false;
burst->setVector(NULL);
delete burst;
}
@@ -230,6 +223,11 @@ void Transceiver::pushRadioVector(GSM::Time &nowTime)
mRadioInterface->driveTransmitRadio(bursts, zeros);
+ for (size_t i = 0; i < mChans; i++) {
+ if (!filler[i])
+ delete bursts[i];
+ }
+
return;
}
8:57 a.m.
Tom Tsou wrote:
Sending an idle frame will
disable output, which is how the filler table is managed in OpenBTS.
hi tom,
so when i stop sending the bursts, the filler table will continue to
transmit bursts. do i understand it correctly: if i send a single idle
burst (frame??) after sending bursts, the filler table is disabled until
new bursts are sent?
what does an idle frame look like? is it a burst without bits? (only the
6 byte header?)
best regards,
andreas
3751
days inactive
3752
days old
4 comments
3 participants
participants (3)
-
Alexander Chemeris -
Andreas Eversberg -
Tom Tsou