Cara terbaik untuk melakukan I2C / TWI jarak jauh


9

Saya memiliki proyek yang mengharuskan untuk melakukan I²C / I2C / TWI jarak jauh (30 hingga 40 meter).

Saya telah melihat beberapa orang menyarankan menurunkan clock-rate ke suatu tempat di sekitar 500 Hz, untuk mengurangi efek kapasitansi dari garis panjang seperti itu saya kira? Komponen yang saya gunakan memerlukan setidaknya clock-rate 100 kHz standar. Saya melakukan penelitian lebih lanjut dan menemukan di antara jawaban pertanyaan lain saran untuk menggunakan level shifter P82B96. Dalam lembar data, mereka memberikan contoh penggunaannya pada garis bahkan 100 meter:

I2C_longDistance

Saya telah menemukan cara lain untuk menggeser level melalui papan breakout dari adafruit , yang hanya sebuah MOSFET (bss138) dengan dua resistor pull-up (satu untuk setiap sisi / voltase). Mereka mendapat ide daricatatan aplikasi dari NXP (AN10441) , dan dua saluran di sana dapat digunakan seperti ini:

pergeseran tingkat MOSFET

Sekarang saya bertanya-tanya: solusi mana yang terbaik? Atau ada sesuatu yang saya abaikan? Dan juga, apakah 5V cukup untuk memastikan koneksi yang baik? Apakah akan ada keuntungan menggunakan voltase yang lebih tinggi seperti 12V?


Seperti yang tertulis, pertanyaan Anda mungkin terlalu luas untuk format situs ini. Cobalah untuk mempersempit pertanyaan Anda dan membuatnya sangat spesifik.
Joe Hass

Saya menambahkan ringkasan, apakah sempit dan cukup spesifik?
DaJF

Anda juga harus menentukan panjang kabel maksimum untuk sensor dan memberikan gagasan tentang apa arti "biaya rendah" bagi Anda. Apakah Anda berharap dapat memberikan daya ke sensor melalui kabel yang sama?
Joe Hass

@ JoHass Apakah pertanyaannya sekarang cukup sempit? Jika tidak, apa lagi yang harus saya lakukan?
DaJF

Hai, saya tahu ini adalah pertanyaan lama, tetapi apa yang akhirnya Anda lakukan pada akhirnya? Saya memiliki pertanyaan yang persis sama dengan Anda, jarak yang sama terlibat dan laju clock minimum 100kHz. Saya tertarik untuk mengetahui apa yang berhasil untuk Anda, terima kasih.
pcdev

Jawaban:


1

Saya pikir Anda berada di jalur yang benar dengan sesuatu seperti NXP P82B96. Jika Anda melihat Gambar 14 dan teks terkait datasheet membahas menggunakan panjang kabel hingga 250 m dengan kecepatan data lebih dari 100 kHz.

Ada banyak sensor suhu I2C yang tersedia yang dapat memberi Anda akurasi beberapa derajat celsius tanpa kalibrasi dan tanpa tambahan sirkuit analog. Karena Anda tetap mengembalikan data untuk diproses, memfilter derau akan sangat mudah.

Jika Anda khawatir tentang kapasitansi kabel Anda mungkin lebih baik dengan twisted pair unshielded daripada kabel berpelindung.


Bisakah P82B96 digantikan oleh alternatif MOSFET? Untuk harga satu P82B96, saya benar-benar dapat membeli 100 bss138 MOSFET (saya bisa memberi Anda tautan jika Anda mau). Memang, seperti yang Anda katakan, saya telah menemukan apa yang tampak seperti sensor temp yang cocok: LM75A. Mengenai pilihan antara kabel berpelindung atau tidak berpelindung, sepertinya itu masalah yang Anda inginkan: kemungkinan interferensi (tidak bertutup) atau kapasitansi saluran (terlindung), apakah ini asumsi yang benar? Apakah yang satu lebih menonjol dari yang lain? Saya tidak tahu bagaimana menentukan ini. Terima kasih btw!
DaJF

Saya tidak berpikir Anda dapat mengganti P82B96 dengan MOSFET untuk garis panjang. Sepertinya repeater IC sebenarnya menyediakan beberapa amplifikasi, di mana MOSFET terutama menyediakan perubahan level tegangan. Saya khawatir saya tidak yakin bagaimana melakukan panggilan pada kabel ... Anda harus melihat catatan aplikasi NXP AN255. Mereka berbicara tentang menggunakan kabel twisted pair tetapi tidak menyebutkan perisai. Untuk sinyal digital noise mungkin kurang dari masalah kapasitansi.
Joe Hass

2

Anda mungkin bisa lolos dengan sensor DS18B20 dengan menggunakan CAT5 berpelindung atau kabel serupa. Ini hanya pengukuran termal, jadi jika beberapa bacaan rusak Anda dapat membuat program Anda cukup kuat untuk menghadapinya (bagaimanapun juga itu adalah praktik yang baik).

Untuk penggunaan rantai restoran, saya telah merancang apa yang disebut kontrol RTU (unit atap) yang bekerja pada beberapa sensor pasif (mereka menggunakan termistor NTC yang dapat dipertukarkan , yang tidak memerlukan kalibrasi untuk pemanasan yang nyaman). Jauh lebih mudah untuk menyaring suara dari sensor pasif. Sepasang instalasi (kompleks otomotif utama Amerika Utara) menggunakan RTD platinum dengan pengkondisi sinyal - perangkat yang sangat akurat dan stabil. Anda harus memutuskan sensor terlebih dahulu, kemudian melihat bagaimana hal itu dihubungkan - salah satu dari opsi sensor ini cocok untuk aplikasi Anda (meskipun RTD mungkin berlebihan).

Jika tidak jelas, saya menyarankan konfigurasi "bintang" sensor di sekitar prosesor Anda.

Jika Anda benar-benar ingin menggunakan "bus" (selain satu-kawat atau I2C), Anda akan membutuhkan kecerdasan di ujungnya, yang berarti prosesor dalam beberapa bentuk. Jika Anda menggunakan babi utuh, Anda mungkin ingin mempertimbangkan untuk menggunakan sensor nirkabel yang berkomunikasi melalui beberapa band ISM yang legal di wilayah Anda. Atau, Anda dapat menggunakan satu sensor per Pi dan membuatnya berbicara satu sama lain melalui intranet WiFi Anda.


Saat ini saya sedang dalam tahap "menentukan apa yang harus dibeli", sehingga bus atau sensor dapat menentukan yang lain. Satu-satunya persyaratan yang saya miliki untuk ini adalah mudah digunakan dan dapat diperpanjang. Alasan untuk memilih bus adalah karena saya lebih suka tidak menjalankan kabel ke masing-masing sensor (yang sepertinya Anda sarankan, atau apakah saya mengartikan "bintang" salah?). Apakah I²C protokol yang layak untuk digunakan pada kabel yang bisa 30M / 90FT?
DaJF

Ya, itulah yang menjadi "bintang" kabel dari controller ke masing-masing sensor. I2C pada 30m .. baik .. Saya pernah mendengar klaim itu mungkin pada kecepatan yang sangat rendah, tapi saya tidak akan berharap itu berfungsi dengan baik.
Spehro Pefhany
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.