OsmoBTS on RAD1

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/.

Kurtis Heimerl kheimerl at cs.berkeley.edu
Sat Jan 11 03:27:17 UTC 2014


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 at tsou.cc> wrote:

> On Jan 9, 2014 3:26 PM, "Kurtis Heimerl" <kheimerl at 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?
>

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...


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140110/67144c55/attachment.htm>


More information about the OpenBSC mailing list