9 Jan
2014
9 Jan
'14
9:26 p.m.
Hey OpenBSC, Tom,
I've been working on getting OsmoBTS running on the recently open-sourced
Range Networks RAD1 radio. The code is available here:
https://github.com/kheimerl/vbts-openbts/tree/osmotrx. I am stuck now and I
was hoping the mailing list might be able to provide some perspective.
With the RAD1, the system is beaconing correctly. However, phones are
unable to camp. I logged a phone trying to camp on both the RAD1 and a B100
to compare the output and see if anything jumps out. The osmoBTS/osmo-nitb
logs are seemingly identical, but the transceiver outputs are different.
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.
Does anyone have a different perspective on what might be going on in here?
Thanks!
10 Jan
10 Jan
12:39 p.m.
On Jan 9, 2014 3:26 PM, "Kurtis Heimerl" <kheimerl(a)cs.berkeley.edu>
wrote:
With the RAD1, the system is beaconing correctly.
However, phones are
unable to camp. I logged a phone trying to camp on both the RAD1
and a B100
to compare the output and see if anything jumps out. The osmoBTS/osmo-nitb
logs are seemingly identical, but the transceiver outputs are different.
By beaconing correctly, you mean the handset recognize the network?
Based on these logs, you're not receiving RACH bursts.
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.
-TT
11 Jan
11 Jan
4:27 a.m.
Thanks for the response! This level is a bit beyond where I normally work.
Followup comments in line:
On Fri, Jan 10, 2014 at 3:39 AM, Tom Tsou <tom(a)tsou.cc> wrote:
On Jan 9, 2014 3:26 PM, "Kurtis Heimerl"
<kheimerl(a)cs.berkeley.edu> wrote:
Yep. When doing a scan it correctly identifies the new network.
With the RAD1, the system is beaconing correctly.
However, phones are
unable to camp. I logged a phone trying to camp on both the
RAD1 and a B100
to compare the output and see if anything jumps out. The osmoBTS/osmo-nitb
logs are seemingly identical, but the transceiver outputs are different.
By beaconing correctly, you mean the handset recognize the 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...
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?
-TT
13 Jan
13 Jan
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?
4177
days inactive
4181
days old
3 comments
2 participants
participants (2)
-
Kurtis Heimerl -
Tom Tsou