Hiểu tốc độ truyền dữ liệu qua dây đồng


11

Tôi đã nghiên cứu các cách khác nhau để kết nối các cảm biến với Arduino và i2c dường như là một phương pháp phổ biến. Tôi đã đọc rằng nó chỉ đáng tin cậy ở khoảng cách ngắn (tối đa vài mét), với tốc độ dữ liệu 400 hoặc 100kbps. Tôi đang gặp khó khăn để hiểu tại sao các giới hạn của giao thức này quá thấp so với các truyền dữ liệu khác qua đồng, chẳng hạn như Ethernet gigabit. Tôi đã thấy các lý do như điện dung, sụt áp và điện trở được đưa ra, nhưng Ethernet không phải là cat5 / 6 có phải chịu tất cả các vấn đề tương tự không? Về cơ bản, tôi muốn biết tại sao việc giảm một số điện áp xuống một số dây đồng không mang lại kết quả nhất quán hơn (băng thông, khoảng cách) khi so sánh các phương pháp khác nhau này.


Có rất nhiều giao thức chính với những hạn chế đã nêu thường bị bỏ qua. Ethernet chỉ đáng tin cậy đến 30ft mà không có bộ lặp. USB dưới 10 feet. Điều đó không có nghĩa là mọi người không đẩy các giới hạn. Đó là những quyết định triển khai dựa trên mức độ nhanh chóng / đáng tin cậy mà bạn cần dữ liệu và liệu bạn có đủ khả năng chi trả dữ liệu cho việc kiểm tra crc hay không.
mreff555

Tôi chỉ muốn chỉ ra rằng mặc dù I2C không có ý định sử dụng theo cách này, nhưng chắc chắn có thể sử dụng nó trên 100m. (Nó có cùng khoảng cách tối đa theo lý thuyết như ethernet). Tuy nhiên, bạn sẽ có tốc độ baud rất thấp, HOẶC dòng điện kéo lên của bạn sẽ lố bịch.
Opifex

@Opifex Tốc độ khủng khiếp!
DKNguyen

1
Đây không phải là một câu trả lời, và có lẽ tôi nói rõ, nhưng các giới hạn trong I2C (hoặc bất kỳ giao thức nào khác) về cơ bản là do vật liệu dây giao thức. Mấu chốt của câu hỏi của bạn dường như là "nếu phương pháp X đưa tôi A lên đồng, thì Y và Z cũng không nên lấy tôi A?" Điều đó vốn không đúng.
dwizum

6
Trong 30ft, bạn có nghĩa là 328ft / 100m @ mreff555? Đó là thông số kỹ thuật cho ethernet cặp xoắn, ethernet đồng trục cũ thậm chí còn dài hơn (200m cho 10base2, 500m cho 10base5).
Đánh dấu gian hàng

Câu trả lời:


14

Định lý của Shannon đặt giới hạn cuối cùng của băng thông thông tin trên cáp. Dưới đây là một số thông tin thêm về điều đó: https://www.gaussianwaves.com/2008/04/channel-capacity/

tl; phiên bản dr: Phương trình Shannon-Hartley:

  • C= =Btôiog2(1+SN)(1)

Trong đó B là băng thông tính bằng Hz, SN là tỷ số tín hiệu trên tạp âm.

I2C rõ ràng không phải là bất cứ nơi nào gần giới hạn Shannon cho cáp. Thay vào đó, nó là một giao thức nhẹ với thời gian chậm có chủ ý (100/400 kbit / s) sử dụng bus thu gom mở để dễ dàng thực hiện cho một mạng các thiết bị nhỏ có nhu cầu I / O khiêm tốn và kiểm soát. Hoạt động chậm được chỉ định bởi I2C tránh hầu hết các vấn đề toàn vẹn tín hiệu.

Có các biến thể I2C nhanh hơn sử dụng tốc độ 1 Mbit và 3,2 Mbit / s. Những điều này đòi hỏi sự chú ý nhiều hơn đến bố cục và kết thúc so với I2C bình thường và tất nhiên có thời gian chặt chẽ hơn, đòi hỏi khắt khe hơn.

Di chuyển lên chuỗi thức ăn Shannon-khôn ngoan, Gbit Ethernet sử dụng nhiều kỹ thuật để đạt được thông lượng của nó:

  • Tín hiệu vi sai
  • Nhiều cặp (4)
  • Tín hiệu đa cấp, được gọi là PAM-5
  • Preemphocation / Deemphocation
  • Cân bằng thích ứng

Những kỹ thuật này cần rất nhiều silicon, bao gồm một khối ADC / DAC tín hiệu hỗn hợp nhanh, lớn để nói chuyện với cáp và một số xử lý tín hiệu khá nặng để quản lý nó. Thêm vào đó, ngăn xếp phần mềm phức tạp hơn nhiều để điều khiển nó. Điều này làm cho Ethernet như một khối trên chip hơi nhiều cho một bộ vi điều khiển cấp thấp (một số trong đó chọn sử dụng PHY bên ngoài thay thế). Tuy nhiên, sự trưởng thành của nó đặt nó trong tầm với của Hệ thống trên Chip lớn hơn.

Dù sao chúng ta cũng đến gần giới hạn Shannon? Xem thêm tại đây: https://pdfs.semanticscholar.org/482f/5afbf88a06d192f7cb052f543625c4b66290.pdf


Hah, có voodoo: nhấn mạnh trước và nhấn mạnh. Vì vậy, ethernet không chỉ gửi các xung vuông hoặc thậm chí sóng hình sin xuống dòng và cầu nguyện rằng nó sẽ không bị biến dạng quá nhiều vào thời điểm nó đến đích. Nó định hình một dạng sóng tương tự và gửi nó xuống dòng.
DKNguyen

3
@DKNguyen Voodoo thực sự cho Ethernet 100 megabit hoặc nhanh hơn là trong máy thu. Các thuật toán cân bằng thích ứng được sử dụng, ngày nay thường được thực hiện bằng kỹ thuật số; tín hiệu nhận được cung cấp cho ADC theo sau bởi một số phần cứng DSP (tất cả bên trong thiết bị PHY $ 0,5 của bạn). Công nghệ trong một giao thức tốc độ cao gần đây lại tinh vi hơn một lần nữa.
đáng sợ_jeff

Thx @scary_jeff về eq thích ứng. nhắc nhở. Đã thêm nó vào câu trả lời của tôi.
hacktastical

6

Có nhiều thứ để truyền hơn là chỉ cáp đồng. Bạn đã thấy phần cứng đằng sau ethernet? Có lẽ là không, bởi vì rất khó để tìm thấy bất kỳ mạch cấp cơ sở nào cho những gì đang thực sự xảy ra vì ruột luôn bị ẩn trong một IC. Gần nhất tôi từng tìm thấy là từ tính cần thiết cho ethernet, dường như không phải là tùy chọn. Đó chỉ là một gợi ý về những gì đang diễn ra với phần cứng ethernet.

Hãy nghĩ về nó theo cách này: Không khí là một phương tiện. Tại sao loại thông tin có thể được truyền đạt khi chó nói chuyện với nhau ít hơn nhiều so với khi con người nói chuyện với nhau? Tại sao việc gửi một số sóng áp lực trong không khí không mang lại kết quả phù hợp hơn trong giao tiếp giữa hai loại động vật này?

Chỉ một số yếu tố giới hạn cho I2C (và nhiều giao thức khác) là:

  1. ổ đĩa mở
  2. không có trở kháng phù hợp
  3. không truyền cân bằng
  4. không kiểm tra lỗi
  5. sơ đồ mã hóa đơn giản
  6. Các mức điện áp tương đối cao (nếu bước điện áp của bạn không phải lớn như vậy, bạn có thể truyền nhanh hơn vì dV / dT của bạn không phải cao như vậy đối với tốc độ cao hơn)
  7. không cách ly
  8. điện áp đơn cực (ethernet truyền ở +/- 2.5V có thể giúp bằng cách nào đó)
  9. Truyền của nô lệ được đồng hồ bấm giờ bởi vì vậy về cơ bản đồng hồ phải thực hiện một chuyến đi vòng nhanh hơn tín hiệu dữ liệu

Tất cả những điều này là tốt để làm cho mọi thứ đơn giản. Không tốt cho tốc độ dữ liệu cao hoặc truyền đường dài.

Có lẽ cũng có một số voodoo khác đang diễn ra trong phần cứng mà tôi không biết.


6

Một vài quy tắc đơn giản: Không có thứ gọi là mặt đất. Tất cả các dây là ăng ten. Tất cả các dây là đường truyền. Luôn có tiếng ồn.

Nếu một dây ngắn so với thời gian tăng tín hiệu, thì bạn có thể bỏ qua sự không phù hợp và phản xạ trở kháng đường truyền (không giống như Ethernet, đòi hỏi phải kết thúc phức tạp và định hình xung). Nếu dây dài, thì điện áp cảm ứng trên dây và chênh lệch mặt đất có nhiều khả năng làm cho mức tín hiệu số của bạn ở đầu xa không xác định hoặc không chính xác. Nhưng Ethernet sử dụng tín hiệu vi sai xoắn đôi, giúp giảm đáng kể các vấn đề tham chiếu mặt đất và nhiễu gây ra. Bộ thu Ethernet cũng sử dụng các đầu vào tương tự nhạy hơn là các đầu vào kỹ thuật số thông thường, do đó cho phép mất nhiều đường truyền hơn. Thêm vào đó là mã hóa và sửa lỗi của Ethernet để khắc phục các số liệu thống kê về tiếng ồn và bạn có thể đi nhanh hơn và xa hơn một cách đáng tin cậy.


5

I2C là một bus thoát nước mở , nó được kéo xuống thấp, nhưng kéo lên (ít nhất là đối với các biến thể 100kHz, 400kHz thông thường) là các điện trở thụ động.

Do đó, có một giới hạn về việc vật có thể hoạt động nhanh như thế nào dựa trên tốc độ điện trở kéo lên có thể sạc điện dung của xe buýt nhanh như thế nào, đôi khi bạn có thể tăng thêm tốc độ bằng cách hạ thấp giá trị kéo lên nhưng điều đó có nghĩa là các nút cần chìm nhiều dòng điện hơn để có mức logic thấp .... Hoặc bạn có thể đi theo một cách khác, làm chậm xe buýt để cho phép sử dụng các điện trở kéo lên có giá trị cao hơn để tiêu tán năng lượng thấp hơn (ví dụ như bus PM).

Đó là hướng dẫn để kích hoạt một phạm vi và lưu ý rằng cạnh rơi trên I2C là sắc nét hơn sau đó tăng lên.

Đối với mục đích sử dụng, về cơ bản, cảm biến nhiệt độ và các thiết bị cấu hình nhỏ trong một bo mạch đơn (hoặc nhiều nhất là một khung gầm), điều này hóa ra khá nhiều điểm hay giữa độ phức tạp khi thực hiện, số lượng pin thấp và phần cứng đơn giản. Mục đích thiết kế không phải là "Liên kết dữ liệu đường dài, nhanh" và đối với tất cả những gì tôi thấy SPI thường dễ xử lý hơn, I2C phù hợp với trường hợp sử dụng dự định của nó thực sự khá tốt.

Khi khoảng cách tăng thì một thứ khác sẽ trở nên phù hợp hơn, nhưng trên một bảng với giao diện cấu hình thiết bị điện tử / nhiệt độ / thiết bị khiêm tốn, điều đó rất hợp lý (Đáng chú ý là giao diện quản lý PHY trông RẤT NHIỀU như I2C).


2

Các kết quả khác nhau là do mạch điều khiển là khác nhau cho mỗi công nghệ.

I2C 100kHz thường sử dụng điện trở pullup để đặt tín hiệu ở mức cao và trình điều khiển cống mở để đặt tín hiệu ở mức thấp.

Các điện trở pullup thường là vài kilo-ohms. Cáp càng dài thì càng có nhiều điện dung. Thời gian để đường dây chuyển từ 0 sang 1 sẽ tỷ lệ thuận với tổng điện dung trên đường dây và giá trị điện trở pullup. Ở đâu đó trong phạm vi khoảng T = 2 * R * C sẽ đúng.

Ví dụ: nếu bạn có cáp 10 feet có điện dung 20pF mỗi foot và bạn đã sử dụng điện trở pullup 10K thì sẽ mất T = 2 * 20pF / ft * 10 ft * 10K = 3.6us để chuyển từ thấp lên cao.

Trong trường hợp này, rõ ràng là bạn không thể có bất kỳ một bit nào sau một bit 0 nhỏ hơn 3,6us, do đó tốc độ truyền của bạn sẽ bị giới hạn ở mức 277kHz.

Trong một hệ thống I2C thực, đặc tả I2C bắt buộc thêm thiết lập và giữ thời gian xung quanh dữ liệu và chuyển đổi đồng hồ. Thời gian đó là hàng trăm nano giây hoặc micro giây. Thời gian được thực hiện rất chậm nhằm mục đích để các thiết bị có thể được thực hiện với giá rẻ (đồng xu) và tiêu thụ rất ít năng lượng (milliwatts).

Mặt khác, Ethernet có thể chạy nhanh hơn mặc dù điện dung của cáp vì nó không sử dụng điện trở pullup. Nó chủ động lái cao hoặc thấp vào cáp. Trình điều khiển có trở kháng thấp và nó có thể sạc bất kỳ điện dung dòng nào rất nhanh. Tất nhiên là tất cả đều có giá. Ethernet thường tiêu thụ hàng trăm mW điện năng và chi phí ít nhất vài đô la cho mỗi cổng để thực hiện.

Có thể một thiết lập tương tự I2C chạy nhanh hơn, chắc chắn, chỉ cần thay đổi pullup 10K thành 100 ohms và bây giờ thời gian tăng của bạn thành 10ft cáp giảm từ 3,6us xuống 36ns. Sau đó, bạn có thể có thể chạy ở mức khoảng 10 MHz mà không gặp quá nhiều vấn đề (ngoài thực tế là các chip I2C thông thường không thể nói nhanh như vậy).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.