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

[Milos P. <mil...@gm...>]

I haven't started openBTS till now, and I have no experience, but for those
who want to get experience without a trouble I would suggest:
http://en.wikipedia.org/wiki/Faraday_cage

Make sure that the cage hole is appropriate for the purpose.

Cage hole diameter frequency attenuation calculation:
http://www.eetasia.com/ARTICLES/2000DEC/2000DEC01_RFD_ID_TA.PDF?SOURCES=DOWNLOAD

One could even offer relatively cheap Faraday cage/bag as a accompanying
product for USRP, and suggest the usage of Faraday cage for openBTS test
purpose
once someone post 'it doesn't work' - if it works in the cage, then it
works. (ie. if it doesn't work out of cage, get a license and clock)

For usage of some other band that it's not used locally you'll need a
license too, so suggesting usage of other band is not great idea, and can be
legal offence too.

With appropriate cage it should work even if you are on the same band with
public network, and there is no disrupting, nor interference, and it's in
your private space.

One can always command caged ME with AT commands via serial/usb cable, and
get headset for voice quality testing.


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
>