Buenas!

La idea de este topic es documentar un poco unos cambios que le hice a la inyección (y también documentar cambios que no hice, si bien hice el intento de comenzarlos, ya que quizás a alguien le sirvan a futuro, tanto sea para evitar tomar un camino, como para probar que me equivoqué y seguir desarrollando los mismos).

Quizás a alguien le interesen, a algunos otros quizás les parezcan un sacrilegio, personalmente no me gusta tener que agregar cosas al auto, pero mientras: A) no se vean. B) no afecten negativamente. No me reuso demasiado a los mismos.

Antes de seguir, dejo una advertencia, viene mucho material de lectura, con una prosa mala, ya que no me encanta escribir, y de hecho escribo similar a como hablo. No solo esto, sino que si además no les gusta la electrónica digital, dudo les interese.

Les cuento la idea y como surgió.

Primero que nada y para ponernos en contexto, me gustan los autos, me gusta la ingeniería (estudio Ingeniería en Computación), y me gusta (si bien no tengo tanta idea) la electrónica.

Todo comenzó con una motivación, esta fue ver en cada momento, que estaba haciendo la ECU del auto. Que razón hay para esto? Bueno en particular en mi auto yo estaba teniendo unos problemas eléctricos, y como resultado de estos, el motor no estaba moderando parejo, y me estaba dando menos rendimiento (tanto en performance como economía) del que debería.
Pero también me interesaba por el sencillo hecho de algún día poder tener un sistema de Logging en el auto, sea esto para mejorar la EPROM que posee la ECU, como también para diagnosticar futuros problemas que pueda tener.

Hoy día, y hace años ya, los autos poseen una interfaz “genérica” para este propósito, llamada OBD2, esta permite, según cada ECU, ciertas funciones sobre la misma, pero generalmente se permite acceder a varios valores del motor en tiempo real.

Para nuestros autos (motores M10, M20 y M30), al menos de fábrica no traían estas funcionalidades. Si bien contaban con una ECU, es decir, la ECU no tiene forma “sencilla” o “genérica” de informar hacia el exterior del estado de la misma (y por consiguiente del motor). Por lo cual mi objetivo era conseguir esta información.

Con esto, decidí hacer algo de estilo DIY para poder obtener datos de la ECU, sin modificar el sistema del auto. Es decir, sin reemplazar la ECU del auto por otra. Esto ya

A continuación y antes de entrar en detalles de los procedimientos que fui realizando introduzco algunos conceptos que voy a utilizar.

ECU: Engine Control Unit: se le llama así a la unidad encargada de tomando varias entradas de sensores usualmente conectados al motor, decidir ciertos accionares sobre el mismo, como ser ignición, inyección, control de la válvula paso a paso, etc.

EPROM: Se le llama así a una memoria programable borrable mediante luz UV, es un tipo de PROM (programable read only memory), existen otras variantes de PROM como ser EEPROM y FLASH

Pinout: Denomina los pines de un conector, en este caso se va a hablar del pinout de la ECU, es decir, de los varios conectores que posee esta.

Bueno, cuando me puse a investigar como funcionaban estas ECUs primero me tuve que familiarizar con la familia de la misma, en mi caso es la “famosa” 059, fabricada por Bosch, es la Motronic 1.0.
La Motronic 1.0 es una de las primeras inyecciones completamente electrónicas que fabricó Bosch luego de su línea Jetronic, esta inyección posee 2 salidas de inyectores (para configuraciones en 2 bancos), una sola salida de ingnición directa a bobina y controla motores paso a paso mediante 2 señales. Del lado de las entradas, la inyección toma la posición del motor mediante una rueda bi-dentada (que en el caso del M30B34 es parte del volante). Esta rueda es bi-dentada, ya que se cuenta con una rueda completa con 116 dientes, y otra rueda con un solo diente. Estos sirven para dividir las fases del motor, la rueda que tiene un solo diente indica el PMS del primer cilindro mientras que los otros dientes simplemente le dan un régimen de rpm a la ECU (no le sirve para los PMS de los otros cilindros dispares, ya que 116 no es divisible entre 3)
Las diferencias más importantes con la 1.3 (la que se encuentra usualmente en las 325 E30) es la manera que tiene de tomar las referencias en el motor, la 1.1 y 1.3 saben exactamente el estado del motor, tanto a nivel cigüeñal como árbol de levas, mientras que la 1.0 solo sabe el estado del cigüeñal. Esto le permite a la 1.3 tener ciertas optimizaciones en su programa, y de esta manera mejorar rendimiento, sobretodo a la hora del ralenti. Estas diferencias son “importantes”, si bien hasta el momento no cruciales si alguien decide hacer lo mismo en un M20.

INTENTO 1

Luego de entender las entradas y salidas relevantes que tenía la ECU, tome como objetivo encontrar una manera de obtener los datos directamente del CPU de la ECU. Este es un 8051 de Intel, usualmente fabricado por Siemens. Luego de googlear mucho, encontré que este CPU si tiene una línea de datos seriales!, por lo cual mi siguiente paso sería encontrar estas líneas dentro de la ECU.
En su momento pude conseguir, luego de buscar mucho, un diagrama de una 059, pero luego de mucho mirarla, descubrí que me sería imposible sacar los datos por esa línea de comunicación serial. Esto se debe a que los pines no se encontraban disponibles y además habría que desarmar el código en assembler que estaba en el CPU, para poder modificarlo, hacer que enviara datos por el canal serial, y luego volver a ensamblar el código; todo por supuesto sin afectar el rendimiento de la misma. Es decir, todo esto requería un trabajo, primero de ingeniería inversa, y luego, además de esa muy ardua tarea, requería que la modificación no excediera la potencia de cómputo del CPU.

INTENTO 2

Después de desanimarme al no poder conseguir los datos de esa manera, seguí investigando alguna otra manera. Ahí fue cuando se me ocurrió que la mitad del programa del CPU está almacenado en una EPROM externa al mismo. Primero vamos a introducir un poco el concepto de programa de una CPU, se puede pensar en este como un conjunto de instrucciones, algunas secuenciales, otras de tipo interrupción, junto a los datos que se utilizan para computar los resultados de estas instrucciones. Este programa, en el caso de la 059 se ubican, o bien completamente en una EPROM de 64K, o bien 32K en el CPU y 32K en una EPROM. En el caso de mi 059, al tener un zócalo para EPROM de 24 pines, poseía la segunda división de memoria.
En cualquiera de los 2 casos, habría ciertos datos relevantes en la EPROM, estos son comúnmente llamados mapas, y son matrices con valores, donde usualmente los ejes son carga y rpm. Estos valores a su vez los utiliza el programa dentro de la CPU para calcular avance, tiempo de inyección, corte de rpm, grado de apertura del paso a paso, etc.
Como segundo, tenemos otros 2 conceptos relacionados a la informática y que en particular se utilizan en el área del hacking, estos son MITM y Sniffing.
MITM es un acrónimo para Man In The Middle, que quiere decir, hombre intermediario y Sniffing quiere decir olfatear. Ambos conceptos están relacionados al hacking íntimamente. Ambos son conceptos donde se tiene un canal de comunicaciones, y se quiere infiltrar (y en el caso del MITM modificar) la información que pasa por la misma. MITM vendría a ser como ponerse en el medio del canal, es decir, si tenemos un objeto A y un objeto B que se comunican mediante un canal C, MITM “rompe” el canal C, obteniendo C1 y C2, hacia A y B respectivamente, desde MITM. MITM entonces obtiene la información de ambos y puede decidir si dejar pasar un mensaje o no, como también generar mensajes “falsos”.
Por otra parte Sniffing solo pretende “ver” la información que por el canal pasa.

Otro concepto a integrar sería como funciona una PROM. Simplificando un poco, una PROM funciona de la siguiente manera, imaginemos una matriz, donde se le llame dirección de memoria a la posición de cada celda, y una vez que tenemos una dirección de memoria se le llame dato a la información que esté en esa celda. De esta misma manera, una PROM tiene (en el caso de estas ECUs) patillas que sirven para indicar una dirección, y por otro lado tiene patillas donde queda disponible el dato, una vez se haya presentado una dirección.

Ahora vamos a hacer una supoción (probablemente cierta), y es que si la CPU de la ECU está pidiendo una dirección de memoria, donde se encuentra un mapa, por ejemplo de inyección, entonces sabemos que la ECU recolectó datos, y calculó que las RPM y la carga del motor es tal que el dato necesario está en dicha dirección de memoria.
Entonces si sabemos en que direcciones están los mapas, y más particularmente, como se organizan estos, podemos obtener, a partir de ciertas direcciones de memoria (donde estén los datos que conozcamos) el estado del motor (RPM, carga, etc).

Una idea que se me fue ocurriendo además, en simultáneo, mientras pensaba esto, era que si tomaba una estrategia de tipo MITM entre la EPROM y la CPU, podría modificar ciertos valores, según las lecturas de algunos otros sensores (como podría ser una wideband, o un mapa de “reajuste” que podría tener el dispositivo que hiciera de MITM). Por desgracia, también investigando, encontré que sería muy dificil hacer esto, ya que el tiempo que pasa, entre que la CPU pida la dirección de memoria y espere el dato, es muy pequeño, como para hacer más de un par de operaciones en quién fuese a hacer de MITM.

Por lo tanto se deshechó esa idea, y se continuó con la técnica de Sniffing, ahora bien, la idea es la misma, obteniendo una dirección de memoria, obtener datos de la ECU.
Para esto se hizo un diseño sencillo para probar el concepto. Primero se tomó un Arduino www.arduino.cc , que iba a actuar de “detector” de dirección de memoria, se hizo un programa sencillo, que simplemente leía el valor de esta dirección de memoria de los pines correspondientes a esta en el zócalo de la EPROM en la ECU y los escribía por Serial a una PC. Luego se introdujo la EPROM a la ECU normalmente.
Por desgracia debido a mi falta de conocimientos de electrónica análoga, la carga del arduino sobre la ECU en el zócalo, hacían imposible que la EPROM que estaba colocada funcionara correctamente. Probablemente hubiese un drain de voltaje en el zócalo de la EPROM, y el diferencial no fuese suficiente para que la EPROM detectara un cambio en los pines de dirección y por ende, el CPU no pudiese obtener el dato necesario. En la práctica, lo que se vió, es que si el arduino estaba apagado, el auto funcionaba correctamente, al darle corriente al arduino, cuando este comenzaba a correr el programa, el auto corcoveaba y luego se apagaba.

INTENTO 3 (la tercera es la vencida)

Como última idea, luego de esta segunda derrota, se me ocurrió pensar de manera más abstracta.
Si bien mi idea siempre fue “ver” que estaba haciendo la ECU, no era necesario que observase la ECU en sí. Con ver sus entradas y salidas, podría suponer, con un pequeño margen de error, que estaba haciendo.
Por lo cual me puse a investigar el Pinout de la ECU. La Motronic 1.0 como vimos anteriormente depende de varios sensores. Pero en particular me concentré en los que me interesaban.
Me interesaría obtener los siguientes datos de los mismos:
RPM
Avance
Tiempo de apertura de inyectores
Temperatura del Refrigerante
Temperatura del Aire que ingresa al motor
AFM (Carga del motor)
Idle o WOT switch (esta inyección y creo que la 1.3 también no poseen un TPS como tal)
Sensor O2
Voltaje del auto

Por lo cual tendría que observar los siguientes pines:

1-Coil (señal a la bobina de cuando disparar) Dispara por negativo
2-WOT (señal de Wide Open Throttle, acelerador presionado al 100%) 0v o 5v
3-Idle (señal de ralenti, acelerador completamente no presionado) 0v o 5v
5-Ground (necesario para completar los varios circuitos)
7-AFM-Input (entrada del AFM) 0v-5v gradual
8-Engine Speed Input (rueda dentada, marca velocidad de motor) AC
13-Engine Temperature (temperatura del refrigerante) 0v-5v
14-Injector Bank 1 (banco de inyectores 1) Dispara por negativo
15-Injector Bank 2 (banco de inyectores 2) Dispara por negativo
22-Air Inlet Temperature (temperatura del aire que ingresa al motor) 0v-5v
24-O2 Sensor Input (sonda Lambda narrowband) 0v-1.1v
26-Reference Sensor Input (rueda con un diente, marca posición del cigueñal) AC
33-Idle Speed Actuator Extend (paso a paso) 0v 12v
34-Idle Speed Actuator Retract (paso a paso) 0v 12v
35-Power (solo cuando se encuentra encendido el relay de alimentación de la ECU) 0v o 12v

Una vez que sabemos que pines queremos leer y procesar, debemos ver como hacer esto!

Para ello voy a utilizar una plataforma la cual me gusta, ya que simplifica la vida de la gente como yo, a quienes nos gusta la electrónica digital, pero somos medios troncos para la análoga.
Esta plataforma se llama Arduino (www.arduino.cc).
La ventaja en este caso del arduino, es el lenguaje de programación que utiliza, que es de “bastante alto nivel” para este tipo de componentes, lo cual permite conseguir resultados de desarrollo rápidos , buenos y mantenibles.
Además de la parte de software. Posee muchas bondades, como ser lectura y escritura digital en pines, como también lectura análoga y escritura en modo pwm con frecuencia ajustable.
Todo en el rango de 0-5v.
También soporta detección y ejecución de interrupciones sobre algunos pines.

Ahora, el trabajo “feo” (para mi) que tuve que hacer, fue acondicionar algunas señales. Las señales de tipo graduales, de 0-5v no hubo problemas, se conectan a un pin análogo del Arduino
Las señales de tipo binarias 5v, tampoco hubo problemas, se conectan a un digital del Arduino.
Ahora bien, las señales de tipo binarias en a nivel 12v, el arduino no puede leerlas directamente (sin quemarse), por ello fue necesario utilizar un optoacoplador 4n25 en conjunto con un par de resistencias, diodos zener y capacitores para reducir el “rebote” de la señal.

A futuro voy a tener que averiguar como hacer para leer los 2 tipos de señales que todavía no pude implementar, estas son las señales variables 0-12v y señales de tipo CA (corriente alterna) o llamadas de efecto hall también.

Como esto es un trabajo en proceso, todavía no se están leyendo todos esos pines.
Por el momento faltan leer los que hacen referencia a la velocidad y posición del motor.
También está faltando leer la información relacionada al paso a paso.
Debido a lo mencionado en el párrafo anterior

Pero concentrémonos de momento en lo que SÍ tenemos.

Con los datos que tenemos, podemos obtener varios datos:
RPM: podemos obtenerlas si contamos la cantidad de disparos de la bobina en un intervalo de tiempo determinado (también podemos obtener la cantidad de tiempo entre disparo y disparo y extrapolar una frecuencia y por ende las RPM)
Este dato aún no está funcionando correctamente, sospecho sea por ruido en el disparo de la bobina, es un aspecto a corregir, pero quizás se pueda leer de alguna de las entradas aún no procesadas.

Avance: Para este dato vamos a precisar leer la posición y la velocidad del motor, por ende, aún no es posible obtenerlo.

Tiempo de apertura de inyectores: Este dato lo tenemos, ya que podemos detectar CUANDO y por CUANTO tiempo se están disparando los bancos de inyectores. Se detectó que se disparan por negativo, quedando flotando estos pines cuando no están disparando.

Temperatura del Refrigerante: Este dato también lo tenemos, es una simple resistencia variable, donde un pin de la misma va a 5v y la otra es la que estamos leyendo. Esta resistencia disminuye el voltaje que se lee a medida que se calienta el motor, probablemente haya una resistencia pullup dentro de la ECU que cree este efecto. Uno de los pasos a futuro es conseguir un mapa, Voltaje-Temperatura, para poder leer con más facilidad el valor

Temperatura del Aire que ingresa al motor: Funciona de igual manera a la temperatura del refrigerante, de hecho parece que los valores se correspondieran a la misma temperatura.

AFM (Carga del motor): Este valor en el caso del AFM 027 (el cual es el que tengo yo) es lineal a la apertura de la misma. Si bien no quiere decir que sea lineal con respecto a la cantidad de aire que entre al motor. También se están requiriendo algunos ajustes con respecto a esto, ya que ni 0v ni 5v se corresponden con los extremos reales que estoy obteniendo a la hora de la lectura.

Idle o WOT switch: Estas 2 entradas las tenemos directamente, si bien no funcionan como uno esperaría, ya que una señal alta en Idle indica que está en ralentí, sin embargo una señal baja en WOT indica que el mismo está en aceleración máxima. De cualquier manera fue tema de ver empíricamente cuales eran estos valores.

Sensor O2: Este sensor, como el voltaje máximo que proveía era de 1.1v fue conectado directamente al Arduino, a un pin análogo, y lo que se hizo fue multiplicar la lectura por 5, para tener básicamente el mismo rango que los otros sensores análogos.

Voltaje del auto: Esto era interesante, ya que de esta manera también podemos monitorear problemas de suministro eléctrico (en mi caso, pensaba que mis problemas venían por este lado).
Para poder leer el voltaje, se utilizó un diodo zener, para evitar picos de voltaje, y se construyó un divisor de voltaje, de esa manera se puede acondicionar la señal, se supuso que la misma va a variar entre 8v como mínimo y 18v como máximo, con esos valores se creo el divisor de voltaje.

Una vez que se tiene todo conectado correctamente, subí un programa al arduino.
Este lo que hace es simplemente leer todos los valores que puede, codificarlos, y pasarlos mediante Serial.
Con esto ya tenemos más de la mitad del trabajo realizado.

En este momento podemos ver en la PC, utilizando un monitor serial todos estos datos.

Luego de esto y para facilidad de uso, dado que me he dedicado últimamente a realizar aplicaciones en Android, aproveché este know-how y cree una app que sea capaz de leer, interpretar y presentar estos datos de manera gráfica.

El resultado final es el siguiente:

https://www.youtube.com/watch?v=c_UQWqbNXgM

Con algunos arreglos extra y más frecuencia de actualización:

https://www.youtube.com/watch?v=6oaGc43DLSc

Como se puede observar en el video, se sigue con unos problemas con la lectura de RPM.
La velocidad se está obteniendo de un Shield GPS de Arduino

Más adelante (y si hay interés) puedo dejar los diagramas eléctricos de los divisores de voltaje y optoacopladores, como también el código que está cargado en el Arduino y la App Android

A futuro, además de leer los pines que estarían faltando para tener acceso a más información, me gustaría agregar una sonda lambda wideband, y de esta manera poder logguear con más exactitud, la mezcla, a distintas cargas y rpm, y de esta manera poder grabar nuevas PROMs y poder extraer más rendimiento del motor.

Y aún más adelante, se podría crear un sistema similar a los piggyback, pero adaptable, de esa manera se podría mantener toda la instalación original del vehículo, pero teniendo la mayoría de las bondades de una inyección programable.

Espero que haya sido interesante.

Saludos