From: Holger Hans Peter Freyther <zecke(a)selfish.org>
The iPhone5 (US) appears to have some issues with the SIs generated,
or the nanoBTS is not sending them correctly. Add a hack to put all
bands into the SI2/SI5 message.
This is a quick change without much reflection and watching for side
effects. I have verfied that a network with ARFCN 134 and neighbors
ARFCN 130 and 512 do not get generate the SI2ter and announce everything
inside the SI2.
---
openbsc/src/libbsc/system_information.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/openbsc/src/libbsc/system_information.c b/openbsc/src/libbsc/system_information.c
index c901a4a..cb67011 100644
--- a/openbsc/src/libbsc/system_information.c
+++ b/openbsc/src/libbsc/system_information.c
@@ -44,6 +44,7 @@
* array. DCS1800 and PCS1900 can not be used at the same time so conserve
* memory and do the below.
*/
+#if 0
static int band_compatible(const struct gsm_bts *bts, int arfcn)
{
enum gsm_band band = gsm_arfcn2band(arfcn);
@@ -57,6 +58,7 @@ static int band_compatible(const struct gsm_bts *bts, int arfcn)
return 0;
}
+#endif
static int is_dcs_net(const struct gsm_bts *bts)
{
@@ -70,6 +72,11 @@ static int is_dcs_net(const struct gsm_bts *bts)
static int use_arfcn(const struct gsm_bts *bts, const int bis, const int ter,
const int pgsm, const int arfcn)
{
+ if (bis || ter)
+ return 0;
+ return 1;
+#if 0
+ Correct but somehow broken with either the nanoBTS or the iPhone5
if (!bis && !ter && band_compatible(bts, arfcn))
return 1;
if (bis && pgsm && band_compatible(bts, arfcn) && (arfcn < 1 || arfcn > 124))
@@ -77,6 +84,7 @@ static int use_arfcn(const struct gsm_bts *bts, const int bis, const int ter,
if (ter && !band_compatible(bts, arfcn))
return 1;
return 0;
+#endif
}
/* Frequency Lists as per TS 04.08 10.5.2.13 */
--
1.7.9.5
Dear all,
so far the osmocom.org mailing lists have always been in a 'non-members
are manually moderated' mode. This has created a lot of work for manual
list moderation, where a lot of the messages caught are simply spam, and
only the occasional valid message is being received.
I'd like to thank the list moderators for taking care of this.
However, in more recent discussions, we were considering to move the
lists to a completely closed mode, i.e. postings would automatically be
rejected from non-members.
The automatic response would contain a description of how to subscribe
in 'nomail' mode, i.e. to subscribe in a way to be able to post to the
list, while still not receiving any incoming traffic. The latter should
be fine for occasional posters who don't want the bulk e-mail that goes
with a full/regular subscription.
Please provide feedback in case you disagree with that change. Unless
there is major opposition, we will likely transition to the 'closed'
mode within one month.
Thanks,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
The OpenBSC(a)lists.osmocom.org mailing list has 1 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: edoardo.rispoli(a)gmail.com on Mon Jan 13 23:46:56 2014
Subject: Re: [RFC] [ADMIN] Making lists subscriber-only?
Cause: Post by non-member to a members-only list
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!