USRP: High Precision Clock

From OnnoWiki
Jump to navigation Jump to search

Clock di BTS

Masalah utama yang menyebabkan handphone akan memilih sebuah BTS baik itu OpenBTS maupun "OpenBSC":http://bs11-abis.gnumonks.org/trac/wiki/OpenBSC adalah masalah keakuratan frekuensi. Untuk mengerti masalah ini, kita harus mengerti teknologi clock dan mengerti bagaimana sebuah GSM handphone memperoleh sinyal.

Mari kita lihat spesifikasi GSM 05.10 section 5.1: 

_The BTS shall use a single frequency source of absolute accuracy
better than 0.05 ppm for both RF frequency generation and clocking the timebase.
The same source shall be used for all carriers of the BTS._

_For the pico BTS class the absolute accuracy requirement is relaxed to 0.1ppm._


1: Yang Harusnya Terjadi

Kesalahan 0.05 ppm adalah 45 Hz di low band (850/900) dan 90 Hz di high band (1800/1900). Ini termasuk SANGAT akurat, akurasi seperti ini akan kita peroleh dari GPS-disciplined VCTCXO (temperature-compensated voltage-controlled crystal oscillator) atau OCXO (oven-controlled crystal oscillator, yang harganya $100-$200). Doppler shift yang akan di peroleh dari sebuah mobil yang berjalan pada kecepatan 150 km/jam atau kereta api adalah sekitar 0.15 ppm, jadi sebetulnya kebutuhan akan akurasi yang sedemikian tinggi masih di pertanyakan, tapi itu yang ada di spec. Dengan adanya effek Doppler, perbedaan frekuensi antara dua base station adalah beberapa ratus Hz, untuk kondisi yang paling parah.

Sebuah pesawat GSM biasanya menggunakan VCTCXO kualitas medium. Pada saat di start, tidak me-lock ke clock external, clock ini biasanya mempunyai keakuratan sekitar 20 ppm, atau sekitar 18 kHz low band (850/900) dan sekitar 36 kHz di high band (1800/1900). Oleh karenanya, start "cold" tanpa informasi, maka HP harus membuang waktu mencari pada frekuensi dan semua kemungkinan drift dari clock-nya sampai menemukan sinyal beacon dari BTS.

Saat HP menemukan beacon, HP akan menggunakan sinyal carrier dari BTS untuk memperbaiki clock lokal dengan cara mengatur voltage control dari VCTCXO. Sampai titik ini, VCTCXO akan se akurat clock BTS selama HP menerima sinyal dari BTS. Jika sinyal BTS hilang, maka clock HP akan drift sampai worst-case rate. Mengetahui berapa lama local clock drift, handset dapat menghitung worst-case drift dan menggunakan informasi tersebut untuk melakukan pencarian frekuensi yang lebih sempit selanjutnya.

Oleh karenanya, pada saat handset baru pertama kali dinyalakan, handset akan melakukan pencarian frekuensi yang sangat lebar sekali sampai menemukan BTS. Jika dia kehilangan sinyal BTS, dia akan mencari lagi tapi sekarang untuk lebar frekuensi yang jauh lebih sempit, karena mengetahui bahwa BTS selanjutnya akan berada dalam beberapa ratus Hz dari frekuensi yang seharusnya di samping local clock di handset belum drift terlalu banyak sejak melihat beacon terakhir. Jika handset menemukan beacon BTS yang lain saat pencarian yang sempit, handset akan "berhenti mencari* (ini sangat penting untuk diskusi kita selanjutnya). Jika handset gagal menemukan beacon BTS dalam pencarian yang sempit, handset akan memperlebar wilayah pencarian frekuensi atau jika kita menggunakan handphone multiband maka handset akan mencoba mencari di band lain.


h1. Second: What Goes Wrong When You Use an Inaccurate Clock

Jika kita menggunakan BTS yang menggunakan oscillator kristal (XO) sederhana untuk clock yang akan memberikan error beberapa kHz di RF carrier. Hal ini yang akan terjadi pada OpenBTS dengan "stock" USRP (USRP standard). Hal yang sama terjadi pada Siemens BS-11 (digunakan oleh "OpenBSC":http://bs11-abis.gnumonks.org/trac/wiki/OpenBSC) jika dia mengunci clock pada card interface ISDN-grade E1. BTS jenis ini akan gagal dengan 3 kemungkinan, tergantung seberapa jelek clock atau bagaimana sistem digunakan:


h2. Effect of Large Frequency Errors (Several kHz or More)

Tipe kegagalan yang pertama terjadi jika error dari XO BTS amat sangat besar sehingga beacon BTS berada jauh diluar kemampuan handset untuk melakukan search frekuensi yang lebar. Konsekuensi-nya handset tidak akan pernah menemukan sinyal BTS.

Error tipe ini di temukan oleh Fabian Uehlin saat dia pertama kali mencoba mengoperasikan OpenBTS pada band 1800. Error ini di perbaiki oleh Fabian Uehlin menggunakan external clock untuk memperoleh akurasi yang lebih baik.


h2. Effect of Modest Frequency Errors (500 Hz to a Few kHz)

Tipe kegagalan yang ke dua terjadi jika RF carrier BTS masih dalam cakupan pencarian yang besar tapi berbeda dari jaringan lokal yang "sebenarnya" hanya bebeImage:101 5724.JPGrapa ratus Hz. Dalam situasi ini, handset akan melihat BTS tersebut atau dia akan melihat jaringan yang "sebenarnya", akan tetapi tidak mungkin ke dua-nya sekaligus. Sistem manapun yang akan dilihat pertama kali oleh handset akan mengontrol clock-nya dan akan menyebabkan handset menjadi "buta" pada sistem yang satu lagi.

Kegagalan jenis ini di diskusikan secara detail di OpenBSC e-mail list pada musim semi 2009. Memang belum banyak di diskusikan di mailing list OpenBTS, oleh karenanya sebaiknya berasumsi bawa hal ini akan terjadi jika kita ingin mencoba menjalankan BTS pada band yang sama dengan operator lokal atau jika kita ingin mencoba untuk bekerja dengan handphone multiband. Tampaknya, teman-teman di "OpenBSC" http://bs11-abis.gnumonks.org/trac/wiki/OpenBSC telah berhasil memperbaiki masalah ini dengan cara menambahkan VCOCXO di BS-11 yang jauh lebih baik daripada XO di card E1. Di OpenBTS kita dapat menghindari masalah ini dengan cara beroperasi pada band non-lokal dan mematikan band lainnya di handset sehingga handset tidak mungkin melihat jaringan yang lain. OpenBTS memungkinkan untuk melakukan hal ini tidak seperti OpenBSC karena radio yang kita gunakan sebagian besar adalah software dan sangat flexible.

Kesalaran karena XO dari BTS dan handset akan bergantung / berbeda terhadap umur dan temperatur, oleh karenanya perilaku kegagalan akan berbeda-beda untuk setiap handset pada satu waktu dan berbeda dari jam ke jam karena handset akan memanas atau mendingin. Hal ini akan menyebabkan semua ini sangat misterius dan membuat proses diagnostik menjadi sangat sulit.


h2. Jika anda ingin mencoba beroperasi di sistem Multi-BTS

Umumnya, handset akan menerima daftar BTS tetangga dari BTS yang melayaninya dan secara terus menerus akan memonitor kekuatan sinyal dari beacon dari BTS tetangga. Fitur kunci yang digunakan untuk monitoring ini adalah Extended Training Sequence (XTS) dari burst sinkronisasi. Durasi XTS adalah 64 simbol (sekitar 0.25 mx). Jika kita cari XTS ini menggunakan matched filter, kinerja matched filter akan sangat degradasi jika offset frekuensi lebih besar dari 1/(4*0.25 ms), atau sekitar 1 kHz, karena pada frekuensi tinggi fasa relatif dari XTS dan matched filter akan drift lebih dari 90 derajat untuk perioda korelasi. Sehingga monitoring tetangga (dan juga kemampuan untuk mobile itu sendiri) akan mulai gagal jika per-BTS carrier offset lebih dari 500Hz.

Error 500 Hz adalah 0.5 ppm di low band, dan 0.25 ppm di high band. Walaupun 0.5 / 0.25 ppm lebih rendah di bandingkan dengan 0.05 ppm yang di berikan di spec GSM, kebutuhkan tersebut tetap termasuk tinggi untuk XO biasa. Keakuratan seperti ini hanya dapat diberikan oleh OCXO atau sebuah VCTCXO dengan kualitas baik dengan kalibrasi secara periodik.

h2. Solution to All Problems: Use a Good Clock

In the long-term, OpenBTS will fix both of these clock problems completely replacing the XO clock in the USRP with something much more accurate, either a true OCXO or a very high-quality VCTCXO with an automated calibration procedure.

Several OpenBTS uses have also recommended the kit "FA-SY 1" from "Funkamateur":http://www.funkamateur.de/, available for about 40€, for desktop testing.


h1. Third: When You Violate Clocking Relationships

Getting back to 05.10 Section 5.1, the GSM specifications dictate that the RF carrier and the symbol clock in the BTS be derived from a common source.

In the handset, the symbol clock is disciplined by the BTS RF carrier, just like the carrier clock. So, if your BTS RF carrier is in error by N ppm, the handset symbol clock will also be in error by N ppm. That's OK if the BTS symbol clock has exactly the same error, which it WILL if you derive everything from a common clock that way the specification tells you to.

But suppose you try to be clever. You know that once your equipment is warmed up, your BTS XO is consistently in error by +11 ppm, giving an RF carrier error of +10 kHz. So you deliberately de-tune your RF carrier by -10 kHz. That fixes the problems described in the previous section, but creates a new problem in the symbol rate clock. The standard GSM symbol clock is 270.833333 kHz. Your BTS XO is really off by +11 ppm, so your BTS symbol clock is really 270.836312 kHz. The handset locks to your BTS RF carrier, which is now spot-on its specified frequency, so the handset generates a correct internal symbol clock of 270.833333 kHz. So now the BTS and handset symbol clocks are slipping against each other at a rate of 11 ppm, or about 3 symbols per second.

Another variation on this problem is if you ignore the spec and use different clock devices for your RF carrier and your symbol clock. For example, suppose you have two 0.5 ppm OCXOs. Their relative fractional difference will be about 0.5 ppm, giving a drift of about one symbol every 7 seconds or so. (I've actually see this done before, too.)

Different handsets respond to the slipping symbol clock in different ways. In our experience, Nokia DCT3s just deal with it, apparently re-syncing on every frame, so if we only use DCT3s for testing, we may never realize that it is a serious problem. A Nokia DCT4 may camp to the beacon briefly, but will abort a transaction when the clock slips. In some handset designs, the symbol slipping interacts with the closed-loop timing advance, making that control loop unstable. Again, the error seems mysterious because different handset models respond in different ways and the effect will very with temperature as the XO in the BTS drifts around.

h1. Reclocking the USRP-1 for OpenBTS

The default clock of the USRP is 64Mhz. GSM clocks are derived from a 13 Mhz so multiples of 13 are "good clocks" for the host. Reclocking the USRP to 52 Mhz will make your host more CPU efficient.


h2. 52 MHz clock sources for OpenBTS

There are presently three choices widely used with OpenBTS:

So now you've got an external clock signal, probably a stable 52Mhz clock, and you want to run OpenBTS with it. Here are the hardware and software setup instructions.

h2. Hardware modifications to the USRP to use a external clock.

  1. Solder an SMA connector into J2001. This is the clock input. Be careful when soldering the SMA connector so you don't break the delicate trace from J2001 to C927.
  2. Move R2029 to R2030. This disables the onboard clock. R2029/R2030 is a 0-ohm resistor.
  3. Move C925 to C926.
  4. Remove C924.


h2. Software modifications to gnuradio:

For gnuradio ver. 3.1.3:

# In usrp/host/lib/legacy/usrp_basic.h, line 122 should read 

 long  fpga_master_clock_freq () const { return 52000000; }

# In usrp/host/lib/legacy/usrp_standard.cc, line 703 should be commented out 

 //assert (dac_freq () == 128000000); 
# run "make install"
# rebuild openbts
# modify OpenBTS.config (or whatever config file you are using) so that TRX.Path points to "../Transceiver52M/transceiver".

For gnuradio ver. 3.2.x:

# In usrp/host/lib/legacy/usrp_standard.cc, line 1024 should be commented out 

 // assert (dac_rate() == 128000000);

# In usrp/host/lib/legacy/db_flexrf.cc, line 179 should read 

 return 52e6/_refclk_divisor();  
# run "make install"
# rebuild openbts
# modify OpenBTS.config (or whatever config file you are using) so that TRX.Path points to "../Transceiver52M/transceiver".

For gnuradio ver. 3.3 and higher: 

* No changes to gnuradio are necessary if do not need default gnuradio applications and examples (like usrp_fft.py). If you need them, then you should apply the following patch:

 diff --git a/usrp/host/lib/usrp_basic.cc b/usrp/host/lib/usrp_basic.cc
 index 5b2f7ff..8f50ff2 100644
 --- a/usrp/host/lib/usrp_basic.cc
 +++ b/usrp/host/lib/usrp_basic.cc
 @@ -107,7 +107,7 @@ usrp_basic::usrp_basic (int which_board,
    : d_udh (0), d_ctx (0),
      d_usb_data_rate (16000000),        // SWAG, see below
      d_bytes_per_poll ((int) (POLLING_INTERVAL * d_usb_data_rate)),
 -    d_verbose (false), d_fpga_master_clock_freq(64000000), d_db(2)
 +    d_verbose (false), d_fpga_master_clock_freq(52000000), d_db(2)
  {
    /*
     * SWAG: Scientific Wild Ass Guess.
 
* modify OpenBTS.config (or whatever config file you are using) so that TRX.Path points to "../Transceiver52M/transceiver".

h2. Known Problems

As of release 2.5 "Lacassine", the 52 MHz modifications do not work with Mac OS X systems. If you use OS X, you will need to continue to use a 64 MHz clock.




Referensi

Pranala Menarik

Persiapan

OpenBTS 2.6

OpenBTS 2.8

Ettus E110

Lain Lain

Catatan Legal dan Pendukung

Catatan Sejarah

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=USRP:_High_Precision_Clock&oldid=31498"