This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Max msuraev at sysmocom.deHi. 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 at 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. > > -- Max Suraev <msuraev at 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