Re: [Openbts-discuss] Errors of OpenBTS with WBX

[David D. (IP6net) <d...@ip...>]

David,
Perhaps Hanwen was off the mark, but he was trying to help all be it he was misinformed.
The trouble is brand new users like myself are overwhelmed with sources of information, and frustrated when things dont work, believing we have check all the correct sources we turn to the mailing list or irc.
What with the gnuradio site wiki, the sourceforge site differing branches offered by contributors citing patches needed for the wbx, having to dive into archived patches on the mailing list to support the wbx etc.
Its difficult to ensure your getting the correct info and all we want is to use your fantastic software.

Having read your response to Harwen you included a link to OpenBTSClocks I am now somewhat relieved to discover the behaviour exhibited by my own tests is documented on that page, had I known to look there I would be ordering a 52Mhz clock before posting.

As an outsider/newbie I would value your feedback on the following:

Would it be a good idea or even possible to include the patched USRPDevice.ccp and .h files for use with a WBX in the main distribution and include a configure flag of --enable-wbx
As new users of both the hardware and software we want to help and I personally want to contribute and it might cut down list irritant for the more established users.
Looking over the wbx patches it looks like you can define the antenna, but I see that only in one location, am I missing something, do I need to define the antenna as tx/rx, the code has comments but it isnt clear, im not a great coder so comments are my friend.
I certainly think a 52Mhz clock will help my own tests.

Thanks
David





On 15 Aug 2010, at 16:12, David A. Burgess wrote:

Hanwen -

On Aug 15, 2010, at 3:04 AM, hanwen wrote:

MHi David,

I think the question why phone differ relates with how they are implemented. My guess is that as the OpenBTS network appears like a test network without effective authentication and encryption, some phones just ignore and don't display it.

That has nothing to do with whether or not a phone camps or attempts to register to a network.  Read the spec.  Authentication and encryption are optional features.  Many of the worlds large carriers don't even use encryption.  In fact, encryption is outlawed in many countries, yet their networks still function.  So your guess is wrong and the huge volume of uninformed speculation on the topic in the public mailing list, besides wasting a lot of time and energy, creates a false impression that there is something fundamentally flawed in our software, which is simply not the case.  (And yes, I say *our* software because the huge majority of this software was written by a very small group of people.)

To address another topic in this mailing thread, though not in your most recent message: OpenBTS will work with any SIM if it is properly provisioned in the associated VoIP PBX (Asterisk in most cases and if you don't understand what that statement means, you have no business running the software).  If putting a particular SIM in a particular phone causes it to not register with OpenBTS, that means that the phone is finding service from the other network somewhere, probably the *real* network. When that happens, IT REFLECTS A FAILURE IN YOUR TESTING PROCEDURES, NOT A FAILURE OF OPENBTS.  Again, if you take the time to understand the MS idle mode procedures, or even take the time to read the wiki page on camping, you will understand this and save yourself and everyone else on the list a lot of time and bandwidth.

http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSMS_Camping


Clocking is another important factor for search/register failure:http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClocks
Simply speaking, 52MHz can be easily decimated to multiple of GSM baud rate 13/48MHz(http://en.wikipedia.org/wiki/Um_Interface#Radiomodem) by hardware while the stocking 64MHz will require some software decimation on computer costing more CPU power. More importantly, the stock 64MHz clock is not accurate enough and can bring some significant carrier frequency offset and sampling offset. If such offset exceed the limits which the synchronization algorithms in OpenBTS or your cellphone can handle. Searching and register will fail.

The wiki page on clocks give a clear explanation of what happens when you use a clock with a large frequency offset.  It's all about clock accuracy. If you had an accurate 64 MHz clock, things would work fine.  But if you are going to change the clock anyway, you might as well change it to a more convenient frequency.  My preferred frequency would be 13 MHz, but the USRP firmware breaks if you clock it below about 48 MHz.

Also, it has *nothing* to do with "synchronization algorithms in OpenBTS".  There are no such algorithms inside the BTS.  All of the synchronization happens in the handset.  And if your clock error exceeds the design limits of the handset, you will not get reliable detection of the BTS signal.