13 Jan
2014
13 Jan
'14
6:39 p.m.
On Fri, Jan 10, 2014 at 10:27 PM, Kurtis Heimerl
<kheimerl(a)cs.berkeley.edu> wrote:
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
Yep. When doing a scan it correctly identifies the new
network.
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.
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... 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?