Tốc độ khung hình (tin nhắn) bus tối đa là 125 kbit / s là bao nhiêu?

Xe buýt CAN của tôi đang chạy ở tốc độ 125 kbit / s và chỉ sử dụng định dạng khung mở rộng. Tôi muốn biết tốc độ tối đa của khung CAN tôi có thể gửi là bao nhiêu. Giả sử chiều dài dữ liệu luôn là tám byte.

Theo trang Wikipedia này , mỗi khung hình có độ dài khung (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bit tối đa :

Có tính đến khoảng cách giữa các khung hình tối thiểu ba bit , tốc độ gói tối đa dưới 125 kbit / s phải là: 125000 / ( 128 + 3) = 954khung hình mỗi giây.

Nhưng trong thử nghiệm của tôi, tôi không thể đạt được điều đó. Tốc độ khung hình tối đa tôi có thể đạt được (với tất cả tám dữ liệu byte) là khoảng 850 khung hình mỗi giây.

Có gì sai ở đây - tính toán của tôi, hoặc phương pháp thử nghiệm của tôi?

Theo đề xuất của Olin Lathrop, tôi sẽ mở rộng về nhồi bit.

CÓ THỂ sử dụng mã hóa NRZ và không hài lòng với các bước chạy dài hoặc số 0 (Nó mất dấu vết của các cạnh đồng hồ nên có). Nó giải quyết vấn đề tiềm năng này bằng cách nhồi bit. Khi truyền, nếu nó gặp phải một chuỗi 5 số 0 hoặc 0 liên tiếp, nó sẽ chèn một chút của cực khác và khi nhận được, nếu nó gặp 5 hoặc số 0 liên tiếp, nó sẽ bỏ qua bit tiếp theo (trừ khi bit đó giống như trước đó bit, trong trường hợp nó phát hành một cờ lỗi).

Nếu bạn đang gửi tất cả các số 0 hoặc tất cả các số cho dữ liệu thử nghiệm của mình, một chuỗi gồm 64 bit giống nhau sẽ dẫn đến việc chèn 12 bit nhồi. Điều này sẽ tăng tổng chiều dài khung hình lên 140 bit, với tốc độ khung hình tốt nhất là 874 khung hình / giây. Nếu các bit dữ liệu giống như MSB của CRC, bạn sẽ nhận được một bit nhồi khác ở đó và tốc độ khung hình giảm xuống còn 868 khung hình / giây. Nếu CRC có các bước chạy dài hoặc số 0, điều đó sẽ làm giảm tốc độ khung hình hơn nữa. Việc xem xét tương tự áp dụng cho định danh của bạn.

Tổng cộng có 16 bit nhồi sẽ tạo ra tốc độ khung hình lý tưởng là 850,3 khung hình / giây, vì vậy bạn nên xem xét nó. Một thử nghiệm nhanh sẽ là sử dụng dữ liệu thử nghiệm với các bit xen kẽ và xem điều gì xảy ra với tốc độ khung hình của bạn.

Olin đã đúng với mô tả của mình về việc nhồi bit và làm thế nào điều đó có thể ảnh hưởng xấu đến thông lượng CAN lý thuyết. Một điều khác có thể làm giảm thêm thông lượng thực tế từ lý thuyết là độ trễ. Ngay cả khi bộ điều khiển CAN của bạn có thể đạt được mức sử dụng bus 100%, bộ xử lý máy chủ có thể không thể xử lý Tx và / hoặc Rx ở tốc độ đó. Đây có thể là kết quả của bộ xử lý chậm và / hoặc phần sụn không hiệu quả thực hiện ngăn xếp CAN.

Khung 2.0a (tiêu chuẩn) nhỏ nhất bạn có thể xây dựng là 47 bit ... Khung 2.0b (mở rộng) nhỏ nhất bạn có thể xây dựng là 67 bit ... Điều đó bao gồm 3 bit khoảng cách giữa các khung và loại trừ nhồi bit ... Về lý thuyết chúng ta có thể xây dựng một khung mà sẽ không bao giờ thứ; Trong thực tế, nhồi bit sẽ xảy ra khá nhiều!

Tốc độ tối đa cho CANBus 2.0a / b là 1Mbit.
Ở tốc độ 1Mb / S, một bit đơn (trội / lặn) dài 1uS, tức là. 0,000'001 S
Vì vậy, khung 67 bit [khung lý thuyết 2.0b nhỏ nhất ] sẽ mất 67uS để truyền - trước khi khung khác (67 bit) có thể được truyền.
1'000'000 / 67 cung cấp 14.925 khung hình hoàn chỉnh (+ 25 bit của khung hình tiếp theo)

Khi bạn đang chạy ở tốc độ 1/8 của tốc độ đó, bạn có thể nhận được tối đa 1/8 của các gói
14'925 / 8 = 1'865 khung hình / giây @ 125Kb

Vào thời điểm bạn đang sử dụng tất cả 64 bit (8byte) dữ liệu và ĐÁNH GIÁ bạn đã không kích hoạt "lỗi" nhồi bit bằng cách có các chuỗi liên tiếp 1 hoặc
0'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

Và đó cũng là giả định hệ thống dây điện của bạn là hoàn hảo. Xe buýt của bạn có thể được làm từ cáp UTP 120ohm và được tách rời điện dung ở cả hai đầu không? Hoặc một số dây ngẫu nhiên với điện trở 120ohm trên một đầu?

Nhìn chung, tôi muốn nói rằng bạn đang làm khá tốt để có được 90% thông lượng tối đa theo lý thuyết.