¿Cómo funciona OBD2 con CAN?

Entiendo cómo funciona CAN (creo). Buena información aquí si desea ver: Diferencia entre OBDII y CAN

Muy brevemente, hay varios módulos y cada módulo publica datos interesantes en los cables. Cada módulo obtiene los datos, luego decide si los datos son interesantes para ese módulo, si los guarda, si no los ignora. (Me doy cuenta de que esto es muy breve y no entra en prioridades si se publican varias publicaciones a la vez, etc., pero no tenemos que preocuparnos por eso aquí)

He estado usando un escáner bluetooth ELM327 OBD2 y un Arduino/ESP32 para leer datos de mi automóvil.

Leí que en algunos autos no se puede sondear más rápido que 10 Hz, ya que esto puede causar problemas internos. Aquí es donde me confundí.

Entonces, digamos que todo lo que quiero obtener son las RPM del ELM327.

Desde mi comprensión de CAN, no sondea los datos, simplemente los guarda cada vez que se publican si son interesantes para usted.

Seguramente, con mi comprensión de CAN, el ELM327 sería un módulo y cada vez que se publicaran los datos de RPM, guardaría los datos. Entonces simplemente me devolvería los datos de RPM guardados cuando los pida con el Arduino. Aunque esto tal vez no se sostenga, ya que los dispositivos OBD2 pueden obtener códigos de falla que se almacenan en los distintos módulos y no se publican.

¿O hay un "módulo OBD2" en el automóvil al que se conecta el ELM327 y el ELM327 lo sondea? Si este fuera el caso, no veo la necesidad de que los cables CAN estén presentes en el enchufe OBD2 que son.

Soy consciente de que OBD2 tiene PID, no estoy seguro de cómo funcionan. Al sondear esos, ¿qué sucede? ¿Simplemente busca publicaciones previamente almacenadas en el "módulo OBD" usando el PID como algún tipo de clave o realmente lo convierte a CAN y sondea en can, lo que va en contra de cómo creo que CAN funciona?

¿Estoy completamente equivocado sobre cómo OBD2 interactúa con CAN? ¿O tal vez no entiendo CAN correctamente?

Me gustaría obtener los datos de RPM más rápido que 10 Hz, pero no quiero destruir nada. Mi auto es un Renault 2006 si eso ayuda.

gracias de antemano

¡Bienvenido a Mantenimiento y Reparación de Vehículos Motorizados!
Tienes muchas preguntas aquí, no todas relacionadas. Por favor, reduzca su pregunta a una pregunta clave. Además, lea preguntas similares: creo que tenemos publicaciones que responden a la mayoría de sus preguntas.
@RoryAlsop No siento que esté haciendo varias preguntas, quería entender cómo OBD2 obtiene datos CAN (en este caso, datos RPM), por ejemplo, sondeando o esperando las publicaciones y guardándolas. Puse la información adicional en la pregunta para que todos supieran mis suposiciones (lo que creo que sé) en caso de que eso sea incorrecto y me lleve por mal camino. De la respuesta a continuación, en realidad no usa CAN para RPM, sabiendo que esto realmente hace que la respuesta en el enlace de arriba sea más comprensible para mí

Respuestas (2)

Su pregunta es un poco amplia, pero intentaré responder el punto más crucial.

Dijiste "Desde mi comprensión de CAN, no sondeas los datos, solo los guardas cada vez que se publican si te interesan", pero no es así como funciona.

OBD2 se basa en un esquema de solicitud/respuesta. El adaptador OBD2 traduce entre UART y el protocolo real del vehículo (en su caso, CAN) y envía los dígitos por el bus. Luego espera cualquier respuesta. Si obtiene respuestas, las recopila, las traduce a dígitos y las informa a través de la UART.

Si no obtiene ninguna respuesta dentro del tiempo de espera (valor predeterminado de 200 ms), responde con "SIN DATOS" a través del UART.

Si no me equivoco, OBDII y CAN son dos protocolos de comunicación separados en cables separados. OBDII utiliza comunicaciones en serie (más antiguas y lentas) en dos cables. Canbus usa dos cables separados de OBDII y los protocolos de comunicación no son en serie sino que se transmiten en cables paralelos a diferencia del cableado en serie que básicamente envía datos en un tren. Canbus se creó a medida que la electrónica de nuestros automóviles se volvía más sofisticada y no podía manejarse en comunicaciones en serie que sobrecargarían efectivamente las comunicaciones en serie con exceso de trabajo. Los distribuidores con sus herramientas de escaneo dedicadas tienen acceso a todo, a diferencia de los lectores genéricos que solo tienen acceso a los códigos OBDII. Los lectores más nuevos leerán códigos abs para tener más acceso a los datos. Rpm se lee en las líneas de comunicación serie OBDII, no en canbus. Si bien son más lentas, las comunicaciones en serie son buenas y casi imperceptibles para la mayoría de las personas interesadas en datos en vivo. Los distribuidores usan canbus para probar sensores y programación. Las comunicaciones seriales no pueden probar los sensores ni programar los distintos módulos. Tengo un lector de precio moderado pero no puede ver los datos de canbus y se limita a decodificar errores genéricos. Mi escáner clon del mercado de accesorios de GM hace (creo, pero no he probado todo) prácticamente todo lo que hace el escáner de un distribuidor, pero a un costo mucho menor, accediendo a datos OBDII y canbus. Mi scantool se usó para programar controles remotos de reemplazo para el módulo de control de la carrocería (BCM), encendió todos los medidores e indicadores para una prueba de pantalla que incluyera el cableado y el módulo, y extrajo varios errores como el historial de desconexión de la batería o errores relacionados con las desconexiones de la batería. Mi lector genérico no puede profundizar en cada módulo como lo hace el scantool. Si pago por el acceso en línea al sitio web de GM,

No estoy seguro de que se haya usado para dividirlo en párrafos o no se pueda hacer aquí. Sí, tiendo a ser extenso, pero trato de proporcionar información pertinente que puede no ser más fácil de entender si se acorta, así que agrego ejemplos.
Tu premisa básica es incorrecta. CAN es Controller Area Network, que es la columna vertebral de toda la red de comunicaciones en todo el automóvil. Fue diseñado para permitir la comunicación de nodos separados en todo el vehículo sin la necesidad de una computadora central, así como para reducir el cableado de cobre. OBD2 viaja en el bus CAN. Es la capacidad de autodiagnóstico y generación de informes del vehículo. Lo que quiero decir aquí es que su respuesta está completamente fuera de lugar y es incorrecta. Un "poco" de información correcta con muchas cosas malas encima.
Bueno, entonces explique por qué hay dos pares de cables, uno para los pines 2 y 5 en serie, el otro par en los pines 6 y 14.
Que yo sepa, Canbus y las comunicaciones en serie no usan los mismos cables, por lo que se crean dos pares de líneas de comunicación para protocolos de comunicación separados.
Me pregunto cómo eso hace que tu respuesta sea más correcta. Aquí, ¿quizás esto te ayude?
Conozco la tecnología canbus, pero no se usó en los sistemas OBDI, por lo que su punto es discutible. Se agregó Canbus, sin aprovechar las líneas seriales cuando OBDII mejoró en más datos a medida que se agregaron más módulos. Las comunicaciones en serie se utilizaron mucho antes que el canbus. Todas las impresoras desde el primer año utilizaron comunicaciones en serie durante décadas. La distribución de pines para los conectores seriales de 9 pines usaba dos pines. Mantener las configuraciones en serie tal como se adoptaron para las comunicaciones de los vehículos significaba usar los mismos pinouts. Canbus no comparte las mismas líneas con las comunicaciones en serie.
Quizás alguna información de fondo para OBDI y OBDII pueda aclarar la información errónea al describir el OBDI original usando los protocolos de comunicación RS232, la comunicación en serie antes de que se adoptara canbus más tarde cuando OBDII reemplazó a OBDI; geotab.com/blog/obd-ii
Esto me ayudó a comprender que OBD2 no usa CAN como pensaba. Otras cosas que leí como el enlace en mi pregunta sugieren que CAN es como los datos debajo y OBD2 el lenguaje "agradable" en la parte superior