Jugando con ODB II y el bus CAN

[Debrah] lleva su próximo proyecto al garaje. Construyó su propio lector de bus CAN con dsPIC.

Lo bueno de trabajar con una red de área de control es que es un estándar universal que se encuentra en todos los automóviles de líneas de productos modernos. Y debido a esto, el chip que necesita para comunicarse a través de ese protocolo costará un poco más de un dólar. [Debraj] eligió el MCP2551, que viene en varios paquetes diferentes de 8 pines. Incluso hay una nota de aplicación diseñada para su uso con la familia dsPIC33F.

El proyecto funciona con rieles de 5V y 3.3V. Esto complica un poco las cosas, pero un convertidor de nivel asegura que no haya problemas de comunicación entre los chips. Un letrero LCD de cuatro líneas funciona como salida durante las pruebas (puede ver esto en el clip después del descanso) pero ya tiene una segunda versión que se ve mucho mejor en el tablero.

¿Qué más se puede hacer con este truco? Bueno, hemos visto antes un método para leer los botones de control en el volante. Todo depende de los datos que transmita su vehículo y una forma de averiguarlo es crear algún hardware y comenzar a registrar los paquetes. Http://www.youtube.com/watch? V = NHou_66MbgQ

  • MGTJ91 dice:

    Bueno, podría intentar lograr esto con el OBDII de mi Acuerdo de 1999. Publique un registro de construcción!

  • Pato dice:

    ¿O tal vez paquetes de parodia? Si vas con toda la mierda del drive by wire, esa sería una forma interesante de hacer un vehículo independiente.

  • RussWill dice:

    ¿Por qué no usar tu Android?

  • Eric dice:

    Esto solo funciona en vehículos que tienen OBD-II sobre CAN. Los vehículos más antiguos utilizaron otros protocolos para implementar OBD-II. No hay seguridad en estos protocolos y puede parodiar cualquier dato que desee. Sin embargo, puede que no termine bien.

    Escribí un artículo sobre CAN en un automóvil aquí y estoy trabajando en una placa CAN para facilitar la construcción de dispositivos CAN.

  • Hattori Hanzo dice:

    Hay un error tipográfico en el título. Es un OBD, no una base de datos de documentos abierta: p

    Pero este es un proyecto interesante. Sin embargo, con el puerto OBD II no obtendrá demasiada información, porque casi todos los automóviles solo muestran la información de diagnóstico de esa manera. En el caso de Mercedes, estoy incluso bastante seguro de que la interfaz OBD está conectada a un bus CAN completamente separado de todo lo que usa el automóvil.

    El programa más interesante sería escuchar el bus CAN interno, que generalmente controla todo lo que no es absolutamente crítico para la misión y opera a una velocidad más lenta que el bus del motor.
    Para el bus de motor, debe estar absolutamente seguro de que no estropeará nada conectando un dispositivo adicional e incluso entonces solo estará inundado de mensajes, ya que todo tipo de unidades de control serán remitentes muy ocupados. Y, desafortunadamente, no hay nada realmente estandarizado fuera de la interfaz OBD y le resultará difícil averiguar qué mensajes contienen qué datos.

    El bus interno no estará tan lleno, pero aún presentará una gran cantidad de datos del motor y mucho más, que generalmente no se transmite al bus del motor. Teniendo en cuenta la naturaleza de CAN, prácticamente tampoco es un problema simplemente “parodiar” mensajes (nada realmente parodia, porque CAN no tiene direccionamiento de punto final) y, por lo tanto, controla algunas cosas con un microcontrolador. Incluso hay hardware disponible comercialmente para, por ejemplo, Transforme su automóvil en un órgano liviano después de desbloquearlo. Básicamente, esos dispositivos solo escuchan el mensaje para desbloquear una puerta y luego envían mensajes para encender y apagar todo tipo de luces.

    Incluso un proyecto cuyo nombre no recuerdo ha creado un software informático automatizado que transforma Windows XP en algo medio decente que se puede utilizar en pequeñas pantallas táctiles. Y tiene una parte bastante avanzada solo para escuchar y enviar mensajes CAN. Escuchar es, por ejemplo, Controle la computadora del automóvil con botones de control diseñados para la radio y envíe, por ejemplo, Entregue el texto que se muestra en el tablero para las canciones reproducidas, direcciones de navegación, etc.

    ¡Un coche con bus CAN y un adaptador adecuado para escucharlo y hablar es un juguete gigante!

    • melllowfelllow dice:

      De hecho, los PID estándar / vainilla contienen solo información básica y de diagnóstico. Los proveedores tienen sus propios PID que llegan al programa de control y pueden modificar casi cualquier cosa. Las modificaciones son para parámetros y matrices; no se puede cambiar la estructura del software.
      En mi opinión, mire los códigos de control individuales para comprar cualquier cosa menos dispositivos simples. Los dispositivos más complejos generan códigos de control específicos basados ​​en otros dispositivos [like speed, temp, etc] y / o estado actual en el programa de control.
      6Lz

  • charliex dice:

    He descubierto que la mayoría de los ODB II tienden a ser lentos para las actualizaciones, especialmente a medida que lo investiga. descifrar los datos restantes del bus CAN, si también es capaz, es mucho mejor. Las RPM, etc. pueden ser de 500 ms o peor.

    muchos obd-pids son específicos de OEM, pero muchas personas los han descifrado u obtenido documentos internos.

  • gregman_1 dice:

    ¿Por qué querría meterme con Old Dirty Bastard?

    • Troll_Dragon dice:

      Fo da oro en sia teef! (A $ 1654 / oz.) XD

  • glacipafo dice:

    ¿Es estrictamente necesario el traductor de niveles? Sé que en los dsPIC más grandes, los pines del modo ECAN también se colocan en pines de E / S tolerantes a 5 V que aceptarán hasta 5,5 V. Quizás el PDIP-dsPIC le permite asignar funciones a sus pines de tolerancia de 5V.

    Creo que el umbral alto de entrada en MCP2551 es similar a 2.6V o lo que sea, por lo que un máximo de la salida dsPIC aún se registraría en el transceptor.

  • Joeblo dice:

    Suena limpio.

    Estoy tratando de encontrar información / bibliotecas de comunicaciones entre la CPU y la radio para construir un “spoofer de radio” que permitirá reemplazar la radio OEM.

  • Alex dice:

    ¿Se puede usar algo como esto para limitar la velocidad informada a través del puerto OBD II? Conduzco un automóvil que tiene un dispositivo conectado al puerto OBD II que compara la velocidad informada a través del puerto con el límite de velocidad en el área. Me gustaría insertar algo entre el dispositivo y el puerto que solo informará una velocidad de más de 70 MPH al dispositivo hermano mayor insertado en el automóvil.

  • Hotjoe dice:

    Hola,

    Cualquiera aquí puede ayudarme a entender si es un protocolo común comunicarse con la ECU a través del puerto OBD II para controlar o limitar la velocidad máxima del vehículo, como el límite de velocidad publicado o la velocidad máxima segura permitida por la ley estatal.
    ¿Alguien está interesado en la piratería ética para crear un dispositivo de seguridad?

    Configurado y escuchando …

    José

Maya Lorenzo
Maya Lorenzo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *