Mengapa panjang maksimum kabel USB lebih pendek daripada di RS232?
9
Mengapa kita perlu buffer sinyal USB jika kabel lebih panjang dari 5m?
Apakah itu karena tegangan sinyal turun?
Apakah itu karena ia menggerakkan arus?
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.
topi adalah salah satu yang membuat kabel USB 20m. apa yang akan terjadi? Anda mengatakan tegangan tidak berubah dan masalah kecepatan. jadi apa yang terjadi pada case kabel 20m dan USB tidak berfungsi?
user16307
2
Tuan rumah mengirimkan permintaan, tidak mendapatkan balasan tepat waktu, dan gagal menghitung perangkat di ujung lainnya.
pjc50
4
Apa kau yakin tentang ini? Sesuai spesifikasi USB , keterlambatan propagasi sinyal di sepanjang kabel harus <26ns (tabel 7-9), sehingga sinyal membutuhkan waktu kurang dari 5,2 ns / m pada kabel 5m standar. Batas keterlambatan pulang pergi sekitar 1,5 μs. Pada kecepatan itu, ada banyak waktu bagi sinyal untuk bepergian dan mundur melalui kabel> 100m. USB Implementers Forum memberikan alasan berbeda untuk batasan 5m.
psmears
Apakah ada alasan untuk USB 1.0-2.0 sebagai half-duplex daripada full duplex sejak hari pertama (seperti USB 3.0)? Dengan kata lain, adakah manfaat praktis dari dupleks setengah penuh?
tigrou
1
@tigrou lebih luas USB1 merangkul opsi-opsi sederhana di mana pun itu bisa karena perlu cukup murah untuk diterapkan sehingga bisa bersaing dengan port RS232 / PS2 / LPT / Game. Silikon telah menjadi jauh lebih murah selama bertahun-tahun; tetapi memiliki harga yang lebih tinggi dari minimum yang diperlukan untuk menjadi 'cukup baik' untuk aplikasi yang ditargetkan mengakibatkan USB2 membunuh FireWire; dan Thunderbolt semakin tampak lahir mati.
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.
Mungkin berkabut bagi Anda, tetapi tidak ada cara mudah untuk menjelaskan teori sinyal di ruangan yang memungkinkan format ini.
Wouter van Ooijen
5
Saya pikir jawaban ini menunjukkan alasan tertentu mengapa batasannya ada. Cukup mudah untuk menjelajahi lebih jauh area-area ini dengan melakukan pencarian web. Misalnya pada teori jalur transmisi. Itu sebabnya saya memposting jawaban ini.
Mattias Johansson
1
Saya jarang mengundurkan diri, jadi saya merasa harus membenarkannya sekarang. Berlawanan dengan komentar Wouter van Ooijen, saya benar-benar tidak merasa bahwa jawaban ini memberikan sesuatu yang lebih konkret daripada saran yang mungkin untuk mencari pada "batasan panjang kabel USB". Selain itu, jawaban yang Anda rujuk berisi tautan mati sehingga sarannya untuk membaca lebih lanjut bahkan tidak berguna. Jika Anda telah menemukan sumber asli yang benar dan mengutipnya, seperti yang dilakukan psmears dan pjc50, itu akan menjadi masalah yang berbeda - karena itu sebenarnya memberikan rincian mengapa batasan ini ada.
Oleksandr R.
5
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.
Tidak bisakah hub pengganti berpura-pura bertenaga bus? Saya pikir hub yang bertenaga bus dapat memberi daya pada hub yang berdaya sendiri, bukan?
supercat
Tidak ada hubungannya dengan bus-powered - ini adalah keterlambatan total dalam menanggapi ACK.
pjc50
@supercat Ya, mungkin ada hub berpura-pura alternatif. Tidak masalah bagaimana Anda melakukannya, selama pohon perangkat pura-pura muncul sesuai dengan tuan rumah.
Pasang kembali Monica
@ pjc50 sesuai dengan spesifikasi USB, penundaan ACK maksimum adalah sekitar 400ns. Sinyal waktu dapat menempuh jarak 40 meter dari tembaga di kedua arah. Ini bukan faktor pembatas di sini.
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).
RS232 mungkin memiliki "topped out" pada 115K, tapi saya ingat ketika itu adalah tautan 110 atau 300 bit per detik antara teleprinter dan modem. Sinyal tidak seimbang, tegangan berayun dari -12V ke + 12V, dan tidak ada twisted pair atau terminasi atau perisai. Pada kecepatan itu, dan jarak yang begitu pendek, karakteristik kawat tidak berarti apa-apa. Kemudian, ketika orang ingin mengirim dengan kecepatan lebih tinggi lebih dari ratusan meter, kami mendapat RS422 dan RS485 yang mengatakan lebih banyak tentang saluran transmisi kawat.
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
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.
sumber
Lihat halaman ini, /superuser/64744/maximum-length-of-a-usb-cable .
sumber
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.
sumber
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).
sumber