Hardware de escáner OBD II de código abierto sin ELM o STN

Hemos construido una herramienta de escaneo OBD-II usando un microcontrolador STM32 y funciona para la mayoría de los vehículos. Pero ocasionalmente nuestro dispositivo falla al detectar el protocolo OBD, mientras que el escáner OBD (ELM) lo detectará. Estamos siguiendo la documentación estándar internacional proporcionada por ISO y, por lo tanto, la lógica es teóricamente correcta, también esta configuración funciona para la mayoría de los vehículos.

¿Hay alguna implementación de código abierto de un escáner OBD que use un microcontrolador en lugar de circuitos integrados/firmware como ELM327? Básicamente, necesito saber cómo un escáner OBD II envía sus tramas al bus CAN/K-Line.

¿Sabe que hay vehículos que tienen ECU en L-Line (Audi fue un ejemplo destacado) o en un CAN secundario? Entonces puede ser solo una cuestión de cableado.
Su mejor apuesta puede ser aplicar ingeniería inversa a lo que tiene. Sondee las líneas y registre lo que sucede durante el proceso de detección. Luego compare esto con una grabación de cómo su escáner hace la detección.
¿Qué transceptores y otro hardware está utilizando? ¿Son solo vehículos específicos que no detecta o hay un problema intermitente?
@Janka, sí, lo sé. Pero si el escáner puede detectarlo, entonces mi hardware también debe detectarlo. A menos que el escáner cambie su configuración de pines. El conector OBD, que yo sepa, es un estándar. Así que no estoy seguro de por qué falla mi configuración aunque el escáner lo detecte.
@vini_i Gracias, actualmente estoy haciendo eso. Es un poco difícil ya que no tengo un osciloscopio, por lo que actualmente uso un LabJack U3.
@Terry Gould, estoy usando un STM32F103, MSP2515 para CAN y SN65HVDA100 para KWP. La detección de CAN y la solicitud de PID son fluidas para la mayoría de los automóviles (excepto que tuvimos una falla de transmisión de CAN para un Audi Q5) e ISO9141 e ISO 14230 lento también son buenos. Excepto ISO 14230-rápido (KWP FAST). Lo cual está fallando para la mayoría de los autos rápidos de kwp.
Un rastreador de bus CAN puede hacerle más justicia que un osciloscopio o LabJack. También está seguro de que los automóviles a los que no se puede conectar tienen CAN. En los EE. UU., CAN no fue obligatorio hasta 2008. Esto deja una brecha de 12 años de vehículos que posiblemente podrían usar algo diferente a CAN (Clase 2 o LIN, por ejemplo).
Entonces, ¿el problema es solo con KWP rápido? - Es posible que desee pasar la pregunta a EE.SE.
@JimmyB, sí, solo tengo un problema con KWP rápido. He resuelto el problema. Gracias chicos

Respuestas (1)

No pude encontrar un firmware de escáner de código abierto, pero hemos resuelto el problema de KWP al que nos enfrentábamos. Todavía abierto para cualquier mención sobre los escáneres OBD II de código abierto.

Uso el mismo pin GPIO que GPIO y UART TX, que es lo que debemos hacer. Pero al cambiar entre esos dos modos, el pin entra en modo de alta impedancia y, por lo tanto, hubo una caída en el voltaje que la ECU KWP verá/leerá. Por lo tanto, hubo un bit defectuoso en el bus, y obviamente el "apretón de manos" falló. Hemos solucionado esto con una resistencia pull-up.

Hardware de escáner OBD II de código abierto sin ELM o STN
RespuestasAquíPolítica de privacidad1y, 0v