Bagaimana cara menyinkronkan dua mikrokontroler ke akurasi mikro-detik?

Saya perlu menyinkronkan dua pengontrol mikro sehingga mereka dapat mengukur kecepatan gelombang propagasi. Pengukuran waktu tunda perlu memiliki akurasi mikrodetik (kesalahan kurang dari 1/2 mikrodetik).

Saya memiliki dua pengendali mikro ( ATmega328 ) yang menggunakan kristal 12MHz.

Keduanya dilengkapi dengan transceiver Bluetooth. Transceiver Bluetooth mengirim dan menerima paket dengan jitter ~ 15 milidetik.

Saya berharap untuk menyinkronkan pengendali mikro menggunakan transceiver Bluetooth, atau beberapa metode kreatif lainnya.

Saya telah mencoba menyinkronkan mereka dengan menyentuhnya bersama, tetapi saya ingin mereka tetap disinkronkan selama sekitar 10 menit, dan jam mereka melayang terlalu cepat. Mungkin jika memungkinkan untuk memprediksi penyimpangan jam secara akurat, metode ini akan berhasil.

Bagaimana cara saya mencapai sinkronisasi ini?

Saya tidak bermaksud melakukan hujan di parade nirkabel Anda. Anda telah mengalami persyaratan yang sulit namun tidak terduga. Sesuatu seperti itu memerlukan evaluasi ulang dari keseluruhan desain sistem.

Hal pertama yang terlintas dalam pikiran adalah untuk mematikan kedua unit dari satu osilator. Anda memiliki komunikasi Bluetooth, yang mengisyaratkan bahwa kisaran berada di urutan 10m. Anda dapat menghubungkan unit Anda dengan kabel coax RG174 atau serat optik, yang akan membawa jam.

2 , ada osilator presisi. Dalam rangka meningkatkan presisi dan biaya.

• TCXO (osilator kristal kompensasi suhu). 1 hingga 3 ppm melayang, biasanya.
• OCXO (osilator kristal yang dikendalikan oven). Melayang di urutan 0,02ppm. Beberapa OCXO telah melayang hingga 0,0001 ppm.
• Jam atom ( standar Rubidium , misalnya). Saya menyebutkan jam atom sebagian besar untuk memberikan kerangka referensi. Lebih lanjut tentang itu di sini .

Ketiga , osilator presisi yang dilatih dengan GPS. Setiap satelit GPS memiliki beberapa jam atom di dalamnya. Biasanya, ada banyak satelit GPS yang terlihat. GPS banyak digunakan untuk ketepatan waktu (penggunaan yang kurang dikenal dibandingkan dengan sat nav). Sebagian besar penerima GPS memiliki output 1PPS (satu pulsa per detik), yang menyediakan waktu yang akurat untuk 50ns.
Untuk memiliki drift 0,5μs lebih dari 600s (10 menit), jam Anda (clock 12MHz dalam desain Anda saat ini) harus memiliki drift kurang dari 0,0008ppm. Tetapi jika Anda dapat memperbaiki kesalahan waktu sesekali dari sumber eksternal drift rendah, persyaratan untuk drift di jam bisa lebih santai. Jika Anda dapat mengoreksi setiap detik, maka jam Anda dapat memiliki penyimpangan 0,5 ppm.

Modul GPS dengan output 1pps sudah tersedia dan murah.

Tidak perlu mendisiplinkan osilator CPU ke GPS (mis. Dengan PLL). Selama Anda dapat "cap waktu" peristiwa eksternal relatif terhadap jam CPU, itu relatif mudah untuk menginterpolasi waktu pengiriman gelombang Anda dan menerima peristiwa antara dua peristiwa PPS.

Anda sering dapat menggunakan kombinasi pengatur waktu perangkat keras pada mikrokontroler, bersama dengan penghitung perangkat lunak untuk acara overflow, untuk membuat penghitung siklus CPU dengan lebar sewenang-wenang. Mungkin sulit untuk menangani peristiwa rollover dengan benar, baik penghitung perangkat keras maupun penghitung perangkat lunak, tetapi pada akhirnya, Anda dapat memiliki, katakanlah, penghitung 32-bit yang dihitung dengan kecepatan jam CPU (memberikan resolusi tinggi ) dan berguling dengan periode yang lebih lama dari interval yang Anda coba ukur (misalnya, 429 detik @ 10 MHz).

Anda dapat menggunakan penghitung ini untuk mencatat waktu berbagai peristiwa eksternal. Jika salah satu dari peristiwa tersebut adalah pulsa 1-pps dari penerima GPS, maka keakuratan dasar jangka panjang dari jam CPU menjadi tidak peduli. Satu-satunya hal yang penting adalah stabilitas jangka pendeknya. Anda dapat menyimpan cap waktu GPS dalam buffer FIFO, dan membandingkan cap waktu acara lain dengan nilai-nilai dalam buffer itu. Karena Anda tahu pulsa GPS terpisah tepat satu detik, Anda dapat menemukan waktu yang tepat untuk kejadian lain dengan menginterpolasi.

$GPS_n$$GPS_{n+1}$$Time_n$$Time_{n+1}$$Ext$$GPS_n$$GPS_{n+1}$

Akhirnya, jika Anda memiliki pengaturan ini berjalan pada dua sistem yang terpisah, masing-masing dengan penerima GPS sendiri, Anda dapat membandingkan waktu yang dihitung untuk berbagai acara pada dua sistem dengan presisi tinggi (biasanya pada urutan ± 100 ns), bahkan jika Jam CPU dari kedua sistem tidak disinkronkan.

Saya telah menerapkan sinkronisasi jam nirkabel untuk mikrokontroler sebelumnya, tetapi hanya dengan akurasi milidetik, yang cukup baik untuk aplikasi. Dari bacaan saya, makalah ini menjelaskan sinkronisasi mikrodetik dengan cukup baik: http://www.math.u-szeged.hu/tagok/mmaroti/okt/2010t/ftsp.pdf

Pada dasarnya, jika Anda memiliki pengetahuan tentang acara transmisi dan acara kedatangan paket radio masing-masing pada pemancar dan penerima, Anda memiliki acara yang dapat diamati (dengan asumsi Anda mengabaikan waktu propagasi gelombang radio) antara 2 sistem yang dapat digunakan sebagai referensi. Fitur rapi lainnya yang disebutkan dalam makalah ini adalah estimasi kemiringan jam menggunakan regresi linier.

Periksa Bluetooth Clock Synchronization Protocol (CSP) yang merupakan bagian opsional dari Health Device Profile (HDP) Bagian dalam dokumen yang relevan dengan CSP adalah 2.1 & 8.

Saya belum memiliki kesempatan untuk mencobanya sendiri, tetapi sejauh yang saya tahu, BlueZ (stack protokol Bluetooth Linux resmi) baru saja menambahkan dukungan untuk HDP , termasuk dukungan untuk CSP. Jadi meskipun itu tidak terdengar seperti Anda akan berjalan pada platform yang mendukung tumpukan BlueZ, tapi mungkin kode setidaknya akan memberikan implementasi referensi yang baik.