¿Cuál es la velocidad máxima de trama (mensaje) del bus CAN a 125 kbit / s?

Mi bus CAN funciona a 125 kbit / sy utiliza exclusivamente el formato de trama extendida. Me gustaría saber cuál es la velocidad máxima de trama CAN que puedo enviar. Suponga que la longitud de los datos es siempre de ocho bytes.

Según esta página de Wikipedia , cada cuadro tiene una longitud máxima de (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128bits de cuadro :

Teniendo en cuenta un espacio mínimo entre125000 / ( 128 + 3) = 954 cuadros de tres bits , la velocidad máxima de paquetes por debajo de 125 kbit / s debe ser: cuadros por segundo.

Pero en mi prueba, no pude llegar tan alto. La velocidad de fotogramas máxima que puedo lograr (con los datos de ocho bytes) es de alrededor de 850 fotogramas por segundo.

¿Qué hay de malo aquí: mi cálculo o mi método de prueba?

Según la sugerencia de Olin Lathrop, ampliaré el relleno de bits.

CAN utiliza la codificación NRZ y, por lo tanto, no está contento con largas series de unos o ceros (pierde la noción de dónde deberían estar los bordes del reloj). Resuelve este problema potencial rellenando bit. Cuando transmite, si encuentra una serie de 5 ceros o sucesivos, inserta un poco de la otra polaridad, y cuando recibe, si encuentra 5 ceros o sucesivos ignora el bit subsiguiente (a menos que el bit sea el mismo que el anterior bits, en cuyo caso emite un indicador de error).

Si envía todos los ceros o todos los datos de prueba, una cadena de 64 bits idénticos dará como resultado la inserción de 12 bits rellenos. Esto aumentará la longitud total de cuadros a 140 bits, con una tasa de cuadros de 874 cuadros / seg. Si los bits de datos son los mismos que los del MSB del CRC, obtendrá otro bit relleno allí, y la velocidad de cuadros baja a 868 cuadros / seg. Si el CRC tiene tiradas largas de unos o ceros, eso reducirá aún más la velocidad de cuadros. La misma consideración se aplica a sus identificadores.

Un total de 16 bits rellenos producirá una velocidad de cuadro ideal de 850.3 cuadros / segundo, por lo que debe considerarlo. Una prueba rápida sería usar datos de prueba con bits alternos y ver qué sucede con su velocidad de cuadros.

Olin tiene razón con su descripción del relleno de bits y cómo eso puede afectar negativamente el rendimiento teórico de CAN. Otra cosa que puede degradar aún más el rendimiento real del teórico es la latencia. Incluso si su controlador CAN es capaz de lograr una utilización del bus del 100%, es posible que el procesador host no pueda manejar Tx y / o Rx a esa velocidad. Esto podría ser el resultado de un procesador lento y / o un firmware ineficiente que implementa la pila CAN.

El marco más pequeño de 2.0a (estándar) que puede construir es de 47 bits ... El marco más pequeño de 2.0b (extendido) que puede construir es de 67 bits ... Eso INCLUYE 3 bits de espacio entre cuadros, y excluye relleno de bits ... En teoría podemos construir un marco que nunca se rellene; En realidad, ¡un poco de relleno va a suceder mucho!

El baudio máximo para CANBus 2.0a / b es 1Mbit.
A 1Mb / S, un solo bit (dominante / recesivo) tiene una longitud de 1uS, es decir. 0.000'001 S
Por lo tanto, una trama de 67 bits [la trama teórica más pequeña de 2.0b] tomará 67 uS para transmitir, antes de que se pueda transmitir otra trama (67 bits).
1'000'000 / 67 da 14,925 cuadros completos (+ 25bits del cuadro siguiente)

Como está corriendo a
1/8 de esa velocidad, puede obtener a lo sumo 1/8 de los paquetes 14'925 / 8 = 1'865 cuadros / segundo a 125Kb

En el momento en que está utilizando todos los 64 bits (8 bytes) de datos, y ASUMIENDO que no ha activado "errores" de relleno de bits al tener cadenas de 1 o 0 consecutivos
1'000'000 / (67 + 64) = 7'633
7 ' 633/8 = 954

Y eso también supone que su cableado es perfecto. ¿Su bus de lata está hecho de cable UTP de 120 ohmios y está desacoplado capacitivamente en ambos extremos? ¿O algún cable aleatorio con una resistencia de 120ohm en un extremo?

En general, diría que lo estás haciendo bastante bien para obtener el 90% del rendimiento máximo teórico.