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

[Kurtis H. <khe...@cs...>]

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.

2011/6/12 Љубомир Самарџић <lj...@gm...>:
> Just for the record, device is actually transmitting.
>
> I'm reading everything I can find regarding clocking issues, but I still
> cannot be sure that it's the only problem I have.
>
> Also, it would be nice if someone can clarify this: usrp2 cannot have
> external clock, but can "tune up" internal clock based on some external
> reference? Basicaly (if I get it right) I have to tune external reference
> based on measured offset and internal clock should be (based on that) in
> corelation with regular cell network clock (and OpenBTS should become
> visible)?
>
> Sorry for bothering, thanx for help ;)
>
> Ljubomir
>
> 2011/6/11 Љубомир Самарџић <lj...@gm...>
>>
>> News from me :) When I start kal with 95% gain I get something like this:
>>
>> ./kal -f 940.01e6 -v -g 95
>> linux; GNU C++ version 4.3.4; Boost_104200; UHD_003.001.001-09cf8eb
>>
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- mboard0 is MIMO master
>>
>> UHD Warning:
>>     The hardware does not support the requested RX sample rate:
>>     Target sample rate: 0.270833 MSps
>>     Actual sample rate: 0.271739 MSps
>> kal: Calculating clock frequency offset.
>> Using GSM-900 channel 25 (940.0MHz)
>>         offset   1: -7661.58
>>         offset   2: -24499.12
>>         offset   3: -24431.74
>>         offset   4: -7659.51
>>         offset   5: 39077.79
>>         offset   6: -7624.26
>>         offset   7: -7647.07
>>         offset   8: 37708.44
>>         offset   9: -7662.61
>>         offset  10: -7681.27
>>         offset  11: 37858.75
>>         offset  12: -7635.67
>>         offset  13: 37938.57
>>         offset  14: 37830.76
>>         offset  15: 39156.57
>>         offset  16: -7651.21
>>         offset  17: 37794.48
>>         offset  18: 37984.18
>>         offset  19: 36736.11
>>         offset  20: -7546.52
>>         offset  21: -7521.64
>>         offset  22: 37936.50
>>         offset  23: 37790.33
>>         offset  24: -7606.64
>>         offset  25: -24500.15
>>         offset  26: -7573.47
>>         offset  27: 39492.43
>>         offset  28: -7551.70
>>         offset  29: -7491.58
>>         offset  30: -24460.76
>>         offset  31: -24429.66
>>         offset  32: -7535.11
>>         offset  33: 37981.07
>>         offset  34: -7605.60
>>         offset  35: 38243.32
>>
>> So, how should I interpret this? usrp's internal clock is definitely too
>> much shifted but in which direction?
>>
>> And one more thing I'm not sure about: after I know the clock offset, how
>> can I use it? Is there a way to permanently "tune up" usrp's internal clock?
>> Or to use this value within OpenBTS itself?
>>
>> Cheers once again :)
>> Ljubomir
>>
>>
>> 2011/6/11 Љубомир Самарџић <lj...@gm...>
>>>
>>> While I'm searching for another gigabit ethernet card (or switch) ... :)
>>>
>>> Antennas are VERT900, both. So, I'm still not sure whether usrp device is
>>> really transmitting anything (as I said A and C leds are on).
>>>
>>> I have read Open BTS / clocks article
>>> (https://sourceforge.net/apps/trac/openbts/wiki/OpenBTS/Clocks), so it
>>> literaly says: "Whatever system the handset sees first will control its
>>> clock and make it blind to the other."
>>>
>>> I'm still stuck with kal (kal-uhd), here is what I tried:
>>> (local bs is transmitting on 940M)
>>>
>>> src/kal -f 940.01e6 -v -D
>>>
>>> and I'm getting:
>>> linux; GNU C++ version 4.3.4; Boost_104200; UHD_003.001.001-09cf8eb
>>>
>>> debug: FPGA Master Clock Freq:  100000000
>>> debug: External Reference    :  No
>>> debug: RX Subdev Spec        :  B
>>> debug: Antenna               :  RX2
>>> debug: Gain                  :  0.450000
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>> -- mboard0 is MIMO master
>>>
>>> UHD Warning:
>>>     The hardware does not support the requested RX sample rate:
>>>     Target sample rate: 0.270833 MSps
>>>     Actual sample rate: 0.271739 MSps
>>> kal: Calculating clock frequency offset.
>>> Using GSM-900 channel 25 (940.0MHz)
>>> debug: error limit: inf
>>> debug: error limit: inf
>>> debug: error limit: inf
>>> debug: error limit: inf
>>> ........
>>>
>>> Cheers,
>>> Ljubomir
>>>
>>> On Sat, Jun 11, 2011 at 5:33 AM, abhinav anand <a.a...@gm...>
>>> wrote:
>>>>
>>>> I have also tested Kal on USRP2 for the non 52Mhz transceiver.
>>>> It gave pretty accurate results !!!
>>>>
>>>> On Fri, Jun 10, 2011 at 2:36 PM, Thomas Tsou <tt...@vt...> wrote:
>>>>>
>>>>> 2011/6/10 Alexander Chemeris <ale...@gm...>:
>>>>> > I think Kal is not ported to non 52 MHz configuration and doesn't
>>>>> > work
>>>>> > with USRP2 - that's why you see this error about incorrect frequency.
>>>>> > Correct me if I'm wrong.
>>>>>
>>>>> I did a quick port to UHD - the necessary changes were minimal - when
>>>>> working with the usrp2 about nine months ago. The usrp2 doesn't have a
>>>>> reconfigurable clock rate and the sample rate for UHD devices can be
>>>>> set without specifying decimation. 52MHz is the default so that's what
>>>>> the usrp2 tries to use.
>>>>>
>>>>> http://ttsou.github.com/kalibrate-uhd/
>>>>>
>>>>> I can still detect signals, though I'm not entirely sure if and to
>>>>> what degree the sample rate offset has on accuracy.
>>>>>
>>>>>  Thomas
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>