Re: [Openbts-discuss] Device doesn't see network at all (openbts-uhd + usrp2 + wbx)

[Љубомир С. <lj...@gm...>]

Ok David I understand your concern. But here is a "kid" trying to make
OpenBTS to work, and after only few searches over the Net - the kid found
suggestion "check your clocking issues". Go see this oscilator, check out
that oscilator or whatever. I didn't say that I want to have OpenBTS running
in the same band my local operators run. I just want my OpenBTS actually
RUNNING. And after many searches and consultations, somehow I ran into
"clocking issues". There is actually a tool that ensures clock compatibility
between usrp and local base stations if I'm getting this well (kal). Please
explain that to me, I really want to know what is a purpose of that tool if
the aim is to avoid local mobile operators.

So, just to clarify: I'm trying to make OpenBTS actually running (tried with
no-roaming foreign cards, now searching for some 850M phones ....), and
somehow "clock issue" popped out. By the way, the clock as a problem is
still just a guess.

Cheers,
Ljubomir

On Mon, Jun 13, 2011 at 4:54 AM, David A. Burgess <dbu...@jc...> wrote:

>
> OK, so here's a message to everyone who is trying to run OpenBTS on a stock
> USRP and trying to get their everyday cellphone to camp to it: STOP BEING
> STUPID.  What Kurtis suggests below is a strongly recommended mode of
> operation: Do not run OpenBTS in a band that is also used by public networks
> in your area.  I say this routinely.  I put it in a wiki.  Nobody is
> listening.  At least once a week, some kid trying to run OpenBTS on a stock
> USRP in the same band as their local cellular carriers posts to the list
> saying "OpenBTS doesn't work".  It doesn't work because you didn't bother to
> read the wiki or understand the technology before turing on a radio
> transmitter in a licensed band, a band used to provide a critical public
> service, and, whether you know it or not, inviting all of your neighbors'
> phones (not just your own) to jump on to your little network.  (See my other
> recent post, "you were warned".)
>
> Besides making clocking much less of an issue, operation in a non-standard
> band also greatly decreases the likelihood that you will end up in prison or
> paying heavy fines for disrupting a public network.  This is no joke and
> your local public cellular network is not a toy.  This kind of clueless,
> careless  operation is what makes me constantly question continued support
> for the USRP in the public release: it makes the barrier to access too low
> to keep out irresponsible people.  When someone runs OpenBTS in their local
> public-carrier cellular band (usually just because they are too cheap/lazy
> to get a proper multi-band unlocked phone) they are creating a real threat
> to public safety and those of us responsible for offering this source code
> to the public do not care to be a party to that.  I have tried before to
> give friendly advice to push people in the right direction and already know
> from experience that it is a waste of time, so the next someone disregards
> this advice I will try something new: deleting threads from the archive and
> banning people from the list.
>
> To the rest of the OpenBTS community, I apologize, but we need to start
> enforcing some standards for responsible operation.
>
>
> On Jun 12, 2011, at 3:15 PM, Kurtis Heimerl wrote:
>
> > As a suggestion, if you have a phone that reads only in the non-local
> > GSM bands (900 here in the US, 850 in europe), running OpenBTS in
> > those bands would cause that handset to see ONLY your BTS, simplifying
> > the clock issue significantly. That's been my goto way to debug clock
> > issues.
> >
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Openbts-discuss mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>