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
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@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
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
On Sat, Jan 25, 2014 at 1:22 AM, Andreas Eversberg andreas@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; }
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
-
Alexander Chemeris -
Andreas Eversberg -
Tom Tsou