13 Jun
2016
13 Jun
'16
5:15 p.m.
Hi.
While running osmo-trx with B200 I've noticed following log messages
repeated multiple times:
1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector:
Clipping detected on received RACH or Normal Burst
2) ERR 3011304256 16:58:12.9 UHDDevice.cpp:1512:write: Skipping buffer
data: timestamp=210353475 time_end=202360063
How bad is that: are those break everything completely or can be
sometimes ignored? What could be causing it and what can be done to try
to fix it (hw/sw)?
Note, I run it as follows:
sudo chrt 20 ./Transceiver52M/osmo-trx
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
13 Jun
13 Jun
6:58 p.m.
Hi Max,
On Mon, Jun 13, 2016 at 6:15 PM, Max <msuraev(a)sysmocom.de> wrote:
While running osmo-trx with B200 I've noticed
following log messages
repeated multiple times:
1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector:
Clipping detected on received RACH or Normal Burst
This means that your phone transmit at a level which saturates BTS's
receive chain. Osmo-trx can't demodulate the signal and prints this
message.
I don't have much experience with USRPs, but general way to avoid this is:
1) Decrease "ms max power", so that phone starts with lower power,
2) Reduce "rxgain" in osmo-bts config
3) Add an attenuator to your Tx/Rx chains.
2) ERR 3011304256 16:58:12.9 UHDDevice.cpp:1512:write:
Skipping buffer
data: timestamp=210353475 time_end=202360063
This means that you're loosing samples between the device and UHD.
Can't help you much here, because it's device specific. May be Thomas
can suggest something.
This is not the end of the world, but it may lead to all kinds of
unstable behavior similar to when you have really bad radio link and
bursts are dropped randomly.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
14 Jun
14 Jun
2:55 p.m.
Thanks, setting in
open-bsc.cfg:
...
bts 0
...
ms max power 16
and in osmo-bts.cfg:
...
phy 0
instance 0
osmotrx rx-gain 1
...
fixed it for me on B200. It still doesn't work due to abis issues with
osmo-bts-trx so I don't know if those values are optimal but it removes
the warning.
On 06/13/2016 06:58 PM, Alexander Chemeris wrote:
Hi Max,
On Mon, Jun 13, 2016 at 6:15 PM, Max <msuraev(a)sysmocom.de> wrote:
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
While running osmo-trx with B200 I've noticed
following log messages
repeated multiple times:
1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector:
Clipping detected on received RACH or Normal Burst
This means that your phone
transmit at a level which saturates BTS's
receive chain. Osmo-trx can't demodulate the signal and prints this
message.
I don't have much experience with USRPs, but general way to avoid this is:
1) Decrease "ms max power", so that phone starts with lower power,
2) Reduce "rxgain" in osmo-bts config
3) Add an attenuator to your Tx/Rx chains.
2) ERR 3011304256 16:58:12.9
UHDDevice.cpp:1512:write: Skipping buffer
data: timestamp=210353475 time_end=202360063
This means that you're loosing
samples between the device and UHD.
Can't help you much here, because it's device specific. May be Thomas
can suggest something.
This is not the end of the world, but it may lead to all kinds of
unstable behavior similar to when you have really bad radio link and
bursts are dropped randomly.
16 Jun
16 Jun
10:55 a.m.
Hi.
A little follow-up.
When testing calls after manual poweron using clkind branch of osmo-trx
I've noticed following:
WARNING 3077733184 10:50:06.4 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 1 subslot 0
WARNING 3077733184 10:50:08.2 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 1 subslot 0
WARNING 3077733184 10:50:08.2 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 1 subslot 0
WARNING 3077733184 10:50:12.0 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 2 subslot 0
WARNING 3077733184 10:50:13.0 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 2 subslot 0
WARNING 3077733184 10:50:32.2 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 2 subslot 0
WARNING 3077733184 10:50:32.5 Transceiver.cpp:749:driveControl:
NOHANDOVER at timeslot 2 subslot 0
Looking at the code which produced it does not reveal much - just a
debug print upon reception of some command. Why is it a warning? What's
bad about it?
On 06/13/2016 06:58 PM, Alexander Chemeris wrote:
Hi Max,
On Mon, Jun 13, 2016 at 6:15 PM, Max <msuraev(a)sysmocom.de> wrote:
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
While running osmo-trx with B200 I've noticed
following log messages
repeated multiple times:
1) WARNING 3011271488 16:59:00.1 Transceiver.cpp:674:pullRadioVector:
Clipping detected on received RACH or Normal Burst
This means that your phone
transmit at a level which saturates BTS's
receive chain. Osmo-trx can't demodulate the signal and prints this
message.
I don't have much experience with USRPs, but general way to avoid this is:
1) Decrease "ms max power", so that phone starts with lower power,
2) Reduce "rxgain" in osmo-bts config
3) Add an attenuator to your Tx/Rx chains.
2) ERR 3011304256 16:58:12.9
UHDDevice.cpp:1512:write: Skipping buffer
data: timestamp=210353475 time_end=202360063
This means that you're loosing
samples between the device and UHD.
Can't help you much here, because it's device specific. May be Thomas
can suggest something.
This is not the end of the world, but it may lead to all kinds of
unstable behavior similar to when you have really bad radio link and
bursts are dropped randomly.
2892
days inactive
2895
days old
3 comments
2 participants
participants (2)
-
Alexander Chemeris -
Max