Difference between revisions of "USRP: High Precision Clock"

From OnnoWiki
Jump to navigation Jump to search
Line 70: Line 70:
 
Handset yang berbeda akan merespond berbeda untuk slipping symbol clock. Pengalaman dengan Nokia DCT3 akan berusaha mengatasinya dengan cara re-sinkronisasi setiap frame, sehingga jika kita menggunakan DCT3 untuk percobaan, kita tidak melihat hal ini sebagai hal yang serius. Sementara, Nokia DCT4 akan lock ke beacon sebentar, akan tetapi akan putus jika clock slip. Beberapa desain handset, slip symbol akan berinteraksi dengan closed-loop timing advance, akibatnya control loop menjadi tidak stabil. Oleh karenanya, error ini tampaknya seperti misterious karena handset yang berbeda akan bereaksi berbeda dan effek-nya akan berbeda untuk beda temperatur karena XO di BTS akan drift.
 
Handset yang berbeda akan merespond berbeda untuk slipping symbol clock. Pengalaman dengan Nokia DCT3 akan berusaha mengatasinya dengan cara re-sinkronisasi setiap frame, sehingga jika kita menggunakan DCT3 untuk percobaan, kita tidak melihat hal ini sebagai hal yang serius. Sementara, Nokia DCT4 akan lock ke beacon sebentar, akan tetapi akan putus jika clock slip. Beberapa desain handset, slip symbol akan berinteraksi dengan closed-loop timing advance, akibatnya control loop menjadi tidak stabil. Oleh karenanya, error ini tampaknya seperti misterious karena handset yang berbeda akan bereaksi berbeda dan effek-nya akan berbeda untuk beda temperatur karena XO di BTS akan drift.
  
−
==h1. Reclocking the USRP-1 for [[OpenBTS]]==
+
==h1. Reclocking USRP-1 untuk [[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.
 
  
 +
Default clock USRP adalah 64Mhz. GSM clock diturunkan dari 13 Mhz oleh karena itu kelipatan dari 13 adalah "clock yang baik" untuk host.  Reclocking USRP ke 52 Mhz akan menyebabkan host lebih effisien dalam penggunaan CPU.
  
 
==h2. 52 MHz clock sources for OpenBTS==
 
==h2. 52 MHz clock sources for OpenBTS==

Revision as of 07:22, 6 April 2012

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. Solusi untuk Semua Masalah: Gunakan Clock yang baik

Untuk jangka panjang, OpenBTS akan memperbaiki masalah clock ini dengan mengganti XO yang ada di USRP dengan sesuatu yang lebih akurat, bisa OCXO atau VCTCXO yang berkualitas baik dengan prosedur kalibrasi automatis.

Beberapa pengguna OpenBTS menggunakan & merekomendasikan "FA-SY 1" dari "Funkamateur":http://www.funkamateur.de/, tersedia seharga 40€, untuk ujicoba desktop.

h1. Third: Ketika Kita Melanggar Hubungan Clocking

Kembali spesifikasi GSM 05.10 Section 5.1 yang menyebutkan bahwa RF carrier dan symbol clock di BTS harus di turunkan dari sumber yang sama.

Di handset, symbol clock di kontrol oleh RF carrier BTS, seperti carrier untuk clock. Oleh karenanya, jika RF carrier BTS kita mempunyai error N ppm, maka handset symbol clock juga akan mempunyai error N ppm. Hal ini tidak masalah jika BTS symbol clock mempunyai ke salahan yang persis sama, yang tentunya terjadi jika kita menurunkan semuanya dari sumber clock yang sama seperti di sebutkan oleh spesifikasi GSM.

Tapi jika kita ingin mengakali. Kita tahu bahwa saat peralatan mulai menyala, BTS XO akan secara konsisten mempunyai error +11 ppm, hal ini akan menyebabkan RF carrier error +10 KHz. Sehingga kita sengaja me de-tune RF carrier dengan -10 KHz. hal ini tampaknya memperbaiki masalah yang disebutkan di bagian sebelumnya, akan tetapi menimbulkan masalah baru di symbol rate clock. Standard GSM symbol clock adalah 270.833333 kHz. Jika BTS XO anda off +11 ppm, maka BTS symbol clock sebetulnya adalah 270.836312 kHz. Handset akan lock ke RF carroer BTS, yang sekarang bekerja pada frekuensi yang benar, sehingga menyebabkan handset membangkitkan simbol clock internal 270.833333 kHz. Akibatnya sekarang BTS dan handset symbol clock tidak cocok satu sama lain dengan rate 11 ppm, atau sekitar symbol per detik.

Variasi dari masalah ini adalah ketika kita mengacuhkan spesifikasi dangn menggunakan clock yang berbeda untuk RF carrier dan symbol clock. Sebagai contoh, misalkan kita mempunyai dua OCXO 0.5 ppm. Sehingga perbedaan relatif-nya adalah sekitar 0.5 ppm, hal ini akan menyebabkan drift satu symbol setiap 7 detik.

Handset yang berbeda akan merespond berbeda untuk slipping symbol clock. Pengalaman dengan Nokia DCT3 akan berusaha mengatasinya dengan cara re-sinkronisasi setiap frame, sehingga jika kita menggunakan DCT3 untuk percobaan, kita tidak melihat hal ini sebagai hal yang serius. Sementara, Nokia DCT4 akan lock ke beacon sebentar, akan tetapi akan putus jika clock slip. Beberapa desain handset, slip symbol akan berinteraksi dengan closed-loop timing advance, akibatnya control loop menjadi tidak stabil. Oleh karenanya, error ini tampaknya seperti misterious karena handset yang berbeda akan bereaksi berbeda dan effek-nya akan berbeda untuk beda temperatur karena XO di BTS akan drift.

h1. Reclocking USRP-1 untuk OpenBTS

Default clock USRP adalah 64Mhz. GSM clock diturunkan dari 13 Mhz oleh karena itu kelipatan dari 13 adalah "clock yang baik" untuk host. Reclocking USRP ke 52 Mhz akan menyebabkan host lebih effisien dalam penggunaan CPU.

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=31503"