Mengapa kita perlu buffer sinyal USB jika kabel lebih panjang dari 5m?
Apakah itu karena tegangan sinyal turun?
Apakah itu karena ia menggerakkan arus?
Mengapa kita perlu buffer sinyal USB jika kabel lebih panjang dari 5m?
Apakah itu karena tegangan sinyal turun?
Apakah itu karena ia menggerakkan arus?
Jawaban:
Kecepatan transmisi penting karena USB setengah dupleks: untuk mengirimkan respons, bus harus diputar dan data ditransmisikan ke arah lain. Jadi tuan rumah mengirimkan data dan menunggu pengakuan atau tanggapan. Semua transfer dikendalikan oleh tuan rumah. Perangkat kemudian memiliki waktu tertentu (yang cukup singkat) untuk merespons. Waktu ini kira-kira waktu yang diperlukan untuk dua perjalanan sinyal sepanjang kabel 5m.
(Saya tidak dapat menemukan referensi saat ini, tetapi dokumen spesifikasi yang relevan bersifat publik)
Sunting: terima kasih kepada psmears untuk menemukan bagian ini
Kabel dan Solusi Jarak Jauh
- Mengapa ada batas panjang kabel, dan apa itu?
A: Panjang kabel dibatasi oleh spesifikasi penundaan kabel 26ns untuk memungkinkan refleksi menetap di pemancar sebelum bit berikutnya dikirim. Karena USB menggunakan sumber penghentian dan driver mode tegangan, ini harus menjadi kasus, jika tidak, refleksi dapat menumpuk dan meledakkan driver. Ini tidak berarti tegangan saluran telah sepenuhnya selesai pada akhir bit; dengan underterminasi terburuk. Namun, sudah cukup redaman pada akhir bit sehingga amplitudo refleksi telah dikurangi ke tingkat yang dapat dikelola. Panjang kabel kecepatan rendah terbatas pada 18ns untuk menjaga agar efek saluran transmisi tidak memengaruhi sinyal kecepatan rendah.
- Saya ingin membangun kabel lebih dari 5 meter, mengapa ini tidak berhasil?
A: Bahkan jika Anda melanggar spec, itu benar-benar tidak akan membuat Anda jauh. Dengan asumsi waktu tunda terburuk, perangkat kecepatan penuh di bagian bawah 5 hub dan kabel memiliki batas waktu 280ps. Mengurangi margin ini menjadi 0ps hanya akan memberi Anda tambahan 5cm, yang tidak sebanding dengan masalahnya.
Jadi jawaban saya hanya setengah benar: batas perjalanan bolak-balik adalah untuk rantai hub dan kabel terburuk, untuk kedalaman total 25m.
Dan Neely juga benar bahwa USB selalu dianggap sebagai solusi berbiaya rendah untuk periferal "lambat" seperti keyboard, mouse, printer, dll. Jika Anda menginginkan dupleks penuh untuk kecepatan lebih dan jarak yang lebih jauh, ethernet 100baseT adalah pilihan alami.
Lihat halaman ini, /superuser/64744/maximum-length-of-a-usb-cable .
T1: Berapa lama kabel yang bisa saya gunakan untuk menghubungkan perangkat saya? A1: Dalam praktiknya, spesifikasi USB membatasi panjang kabel antara perangkat kecepatan penuh hingga 5 meter (sedikit di bawah 16 kaki 5 inci). Untuk perangkat kecepatan rendah, batasnya adalah 3 meter (9 kaki 10 inci).
T2: Mengapa saya tidak bisa menggunakan kabel lebih dari 3 atau 5m? A2: Desain listrik USB tidak memungkinkannya. Ketika USB dirancang, keputusan dibuat untuk menangani perambatan medan elektromagnetik pada jalur data USB dengan cara yang membatasi panjang maksimum kabel USB untuk sesuatu dalam kisaran 4m. Metode ini memiliki sejumlah keunggulan dan, karena USB ditujukan untuk lingkungan desktop, batasan jangkauan dianggap dapat diterima. Jika Anda terbiasa dengan teori jalur transmisi dan ingin detail lebih lanjut tentang topik ini, lihat bagian sinyal USB pada FAQ pengembang.
Sangat tidak mungkin untuk "buffer" USB, setidaknya tidak dalam arti kata yang biasa. Biasanya, buffering berarti penguatan listrik dan mungkin regenerasi sinyal.
Dengan USB, host menggerakkan keseluruhan bus. Host mengirimkan permintaan, dan perangkat harus mengeluarkan respons ke host. Permulaan respons harus tiba di host pada waktu tertentu setelah permintaan selesai dikirim. Dengan kabel yang terlalu panjang, keterlambatan propagasi terlalu lama bagi respons untuk mencapai host tepat waktu.
Jadi ada solusi, dan tidak ada yang melibatkan "buffering" sederhana karena buffering menambahkan penundaan tambahan, dan kita perlu membuat host lebih toleran terhadap penundaan yang lebih lama.
Ada dua kelas pemecahan masalah:
Penanganan masalah yang memasukkan hub fisik atau virtual. Jika host menyebutkan hub di bus, hub itu sendiri menambahkan penundaan tambahan, dan ada kabel lain yang berpotensi panjang penuh antara hub dan host. Segala permintaan untuk perangkat yang memasang hilir dari hub dijadwalkan dengan penundaan tambahan.
Anda dapat memasukkan hub port tunggal setiap 4 m kabel, dengan hingga 7 hub secara seri. Batasannya adalah 7 level hub dari host ke perangkat pamungkas, jadi jika ada hub di hulu alat Anda, Anda perlu mengurangi jumlah hub sesuai kebutuhan. Banyak host USB menyertakan hub internal satu tingkat, jadi batas realistisnya adalah 28m kabel, dengan 6 hub seri. Semua hub kecuali yang pertama harus berpura-pura menjadi mandiri.
Anda dapat menambahkan hub virtual, dengan transceiver yang lebih besar dengan preemphasis, tepat di colokan yang masuk ke host, kemudian mengirimkan lalu lintas USB melalui kabel yang lebih panjang. Selama sinyal yang diterima oleh perangkat di ujung kabel yang diperluas tersebut masih dalam spesifikasi, dan selama receiver Anda dapat memulihkan data yang dikirim oleh perangkat standar melalui kabel yang panjang, Anda akan baik-baik saja. Hub virtual ditambahkan sehingga tuan rumah memungkinkan penundaan yang lama - tetapi tentu saja tidak ada hub fisik, hanya tiruan dari mereka.
Penanganan masalah yang meniru perangkat yang muncul "lambat" pada tingkat protokol yang lebih tinggi. Begitulah cara kerja beberapa "ekstender" Cat-5 USB. Ada lima mitra di sini: host nyata (rHost), perangkat yang ditiru melihatnya (eDev), kabel panjang, host yang ditiru (eHost), dan perangkat yang melihatnya di ujung kabel (rDev) .
Awalnya, eDev pura-pura tidak ada di sana. Pada suatu waktu eHost melihat bahwa rDev dicolokkan. Ia menyebutkannya, dan meneruskan data ke eDev. EDev kemudian mengemulasi acara plug-in, dan rHost menyebutkannya. RHost percaya bahwa ia melihat rDev, tetapi hanya eDev yang ada di sana, berpura-pura. Demikian pula, rDev berpikir bahwa melihat rHost, tetapi hanya eHost yang berada di sana, berpura-pura.
Akhirnya, rHost ingin mengeluarkan beberapa transfer ke rDev yang diyakini ada, untuk memanfaatkannya. Untuk transfer IN, eDev berpura-pura tidak memiliki data (balasan dengan NAK). Permintaan transfer diteruskan ke eHost, yang mengeksekusinya kembali dengan rDev. Hasil ini diteruskan kembali ke eDev, yang menggunakan hasil saat host mencoba transfer berikutnya.
Untuk transfer OUT, eDev harus menebak seperti apa perilaku rDev nantinya. Ada berbagai heuristik dan perilaku yang dapat dicoba di sini. Salah satu caranya adalah agar eDev selalu menerima data dan membalas dengan ACK. Transfer diteruskan ke eHost, yang kemudian memutar ulang transfer ke rDev. Idealnya, rDev pada akhirnya akan mengkonsumsi data dan ACK itu. Jika ini tidak berhasil, atau jika rDev membalas dengan STALL, yang terbaik yang bisa dilakukan eDev adalah bertindak seperti ini pada transfer berikutnya dari host. Atau, eDev selalu dapat NAK transfer, dengan asumsi yang biasanya benar bahwa tuan rumah hanya akan mencoba kembali transfer identik nanti. Meskipun transfer asli adalah NAK-ed, itu diteruskan ke eHost, yang kemudian mengeksekusi transfer dengan rDev. Apa pun balasan rDev, jadilah balasan eDev segera setelah diketahui.
Implementasi realistis akan dimulai dengan heuristik konservatif yang melibatkan perjalanan penuh ke rDev untuk semua transfer yang dapat ditunda oleh NAK. Seiring transfer berjalan, perilaku rDev yang diharapkan dapat dipelajari, dan eDev dapat menjadi kurang konservatif. "Extender" dapat menggunakan pengetahuan tentang kelas USB standar, dan beberapa kelas / pengetahuan perangkat / daftar hitam / daftar putih vendor tertentu untuk menawarkan kinerja yang lebih baik juga.
Sebagian besar skema transmisi-data-melalui-kabel memiliki standar yang diakui secara internasional yang menggambarkan bagaimana menerapkannya, termasuk spesifikasi untuk "impedansi karakteristik" kabel (anggap ini sebagai hambatan, tetapi berlaku untuk AC), impedansi terminasi ( 'resistansi' pada akhir koneksi yang diperlukan untuk menghindari pantulan sinyal Anda memantul kembali kabel ke arah pengirim), sering kali 'laju perubahan tegangan' yang ditentukan (waktu yang diperlukan untuk sinyal untuk transisi dari 0-state ke 1-state atau sebaliknya), dan karenanya jumlah transisi maksimum antara 0/1 per detik (yaitu kbps / Mbps / Gbps), dan karenanya berapa lama kabel dapat sebelum integritas sinyal menurun & hal-hal berhenti bekerja dengan benar.
Dibandingkan dengan USB, RS232 memiliki bugger semua spesifikasi pada jenis kabel, impedansi karakteristik, laju perubahan tegangan, panjang kabel, jenis konektor. Tentu saja, konektor 'D' 25-pin & 9-pin adalah umum, tetapi pada kenyataannya RS232 dirancang untuk semua jenis penghubung & kabel & produk tanpa spesifikasi nyata untuk mengatakan sebaliknya. Dalam praktiknya, dengan RS232 Anda biasanya dapat menempuh jarak yang lebih jauh dengan menjatuhkan bit bit per detik yang lebih rendah (alias 'baud'). Jarak maksimum yang dapat Anda capai juga akan ditentukan secara signifikan pada impedansi kabel Anda, terlepas atau tidaknya kabel itu, terminasi di ujungnya, dan seterusnya.
dan dalam membandingkan RS232 dengan USB, Anda membandingkan 'standar' dari tahun 1960-an yang cukup banyak berada di 115k2 (dengan pengecualian langka), dengan satu dari tahun 1990-an & 2000-an yang dimulai pada 1,5Mbps, urutan besarnya lebih cepat, lalu 12Mbps (hampir 100x lebih cepat), kemudian 480Mbps (hampir 5000x lebih cepat), tetapi yang berarti bahwa parameter kabel dan panjang kabel memainkan peran penting dalam membuatnya bekerja dengan andal . Itu dirancang sebagai standar koneksi perangkat desktop, sehingga 5m dianggap dapat diterima, dan kemudian semua parameter kabel & konektor & kecepatan diletakkan dari titik itu. Jika ada cara untuk membuat USB menjadi lebih lambat, Anda mungkin bisa membuatnya berjalan pada kabel yang lebih panjang (tanpa repeater).