Estoy escribiendo un software para hacer una aplicación de telemetría para mi 2001 VW Golf mk4 leyendo parámetros de OBD2 usando un cable compatible con ELM327.
Lo logré hasta ahora. El problema que tengo ahora es que el software es demasiado lento (3 - 4 valores por segundo). Algunos de los problemas pueden estar en mi software, algunos pueden ser la limitación del protocolo OBD2 en mi automóvil, pero supongamos que todo proviene de mi software y lo mejoraré hasta el punto en que pueda leer como lo más rápido posible.
Leí en la documentación del cable que está prohibido, para un automóvil que usa estándares OBD2 anteriores a 2002, leer valores más rápido que 100 milisegundos de diferencia. Dice que pueden ocurrir problemas, pero no entran en detalles.
Mi pregunta es: ¿alguien tiene alguna idea de qué tipo de problema puede ocurrir al leer la información demasiado rápido del OBD2, y si esos problemas, si ocurren, pueden solucionarse simplemente quitando y volviendo a conectar los terminales de la batería al automóvil?
La documentación de ELM indica que no se trata de un problema exclusivo de consultas. Veo en la página 31 de ese documento que el problema era el de la velocidad a la que llegan las solicitudes J1850 al sistema OBD (esto es consecuencia de la actualización de abril de 2002 del estándar J1979 ). Específicamente, le advierten que no realice consultas a velocidades superiores a 100 milisegundos (también conocidas como 10 por segundo), pero no brindan detalles.
Es importante comprender que no solo está leyendo datos pasivamente. Se está produciendo un bucle asincrónico de consulta-respuesta. Por lo que puedo decir, demasiadas consultas demasiado rápido podrían desbordar la cola de mensajes salientes en el sistema OBD. Dado que esa situación se parece mucho a un problema de desbordamiento de búfer , no es imposible que pueda causar daños fatales a su sistema OBD, si no a toda la computadora del motor.
Ese soy yo siendo asustadizo: es tu vehículo, por supuesto.
Ahora, dicho todo: parece que las herramientas de monitoreo OBD están disponibles gratuitamente para Ubuntu. La página del manual de obdgpslogger muestra dos opciones de interés:
-a|--samplerate <samples-per-second>
Sample at most this many times a second. The software will sleep
temporarily at the end of each loop if appropriate. Keep in mind
there is an upper limit to samplerate, typically capped by I/O
on your serial port. Set this to zero to sample as fast as
possible. BE WARNED. Values greater than ten here are forbidden
for cars predating April 2002. If you think your car postdates
early 2002, and you'd like to sample as fast as possible, the -o
option may help
-o|--enable-optimisations
Enable certain elm327 optimisations. This will [usually] make
sampling faster [not a noticeable amount if you're only sampling
once a second], but makes it much easier to accidentally disobey
the standard if you're sampling as fast as possible.
A partir de esa página, parece que la mejor tarifa real que es probable que logre será el resultado de:
obdgpslogger --samplerate 10 --enable-optimisations
Notará que la mayoría de las herramientas de software OBD rara vez muestran más de 4 o cinco salidas por vista. También me he encontrado con problemas al intentar leer demasiados valores a la vez.
Hablando por experiencia, sugeriría elaborar una estrategia para sondear diferentes valores. Por ejemplo, realmente solo necesita sondear
El truco consiste en sondear las cosas que cambian más a menudo, más a menudo.
La próxima vez que esté en un automóvil con una computadora a bordo, cambie a la vista de consumo instantáneo y vea con qué frecuencia cambia el valor. Para mi coche, es cada segundo. Diría que un segundo es una excelente línea de base porque en realidad le permite leer 9 PID a 100 ms cada segundo sin problemas.
Nicu Surdu
Nicu Surdu
bob cruz