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/.
Tom Tsou tom at tsou.ccOn Fri, Jan 10, 2014 at 10:27 PM, Kurtis Heimerl <kheimerl at cs.berkeley.edu> wrote: > Yep. When doing a scan it correctly identifies the new network. > >> Based on these logs, you're not receiving RACH bursts. > > What makes you say that? I don't see RACHs in either log, but the phone > camps in the 52M trace so it must have received a RACH. I do see attempts to > decode a RACH in the RAD1 trace though... The logged RACH burst are below the detection threshold and subsequently dropped - most likely just noise. I assume you're lab testing, so signal strength should not be an issue. If you have logged SDCCH traffic (e.g. L3 registration), then the RACH got through at some point. You may be receiving RACH bursts, but there are no such transactions in the particular posted logs. >> Both of the transceiver outputs are attached. The only big difference I >> see is in the "underflows" on the RAD1, which in my experience is a >> deal-breaker; that's not usually an easy fix. >> >> This is unrelated to osmo-bts. The effect on performance will depend on >> the frequency of occurrence. > > My thought was that osmo-bts may not be producing enough packets (or > something) causing it to underflow. Am I off base there? The sample stream going to the device is continuous in all transceiver cases regardless of what comes down from the upper layers. If osmo-bts or openbts submits less bursts than the other, filler bursts will be added. In other words, from the device I/O standpoint, there should be no difference between osmo-bts and openbts. What happens if you start the transceiver and then shut down core while leaving the transceiver running? Underruns still present? -TT