Monitorear motor a explosión con 16F877A

Necesito si alguien me pudiera confirmar una idea para desarrollar en un proyecto de adquisicion de datos de motores a explosion.
Mi pregunta no es sencilla, por lo tanto intentare detallar lo mejor posible cual es el problema.
Cualquier acotacion q ayude, ademas de lo que voy a explicar, y sin ningun tipo de compromiso, sera bienvenida.
Basicamente usando un 16f877A y con un programa en Pic basic pro se leen los datos de presion y temperatura en admision, cilindro y escape,
en motores de dos y cuatro tiempos, por cada grado de giro. Por lo tanto se toman 360 muestras en 2T o 720 en 4T
Para la referencia se usa un encoder acoplado al cigüeñal del motor.
Es decir: cuando el encoder pasa por el Punto Muerto Inferior (PMI) envia la señal de inicio al micro, y se toma la primera muestra, que debe realizarse
en un tiempo "X" que tarda el cigueñal en girar un grado. Segun las RPM "utiles" del motor, variables a voluntad, este tiempo "X"puede variar entre 10 a 90 microsegundos. Luego se toma la segunda muestra, en la siguiente vuelta, pero esta vez se "demora" el tiempo "X", desde que el encoder da el inicio, ya que la primera muestra ya se tomo, y luego se realiza la lectura. Y asi sucesivamente se va sumando tiempos "X" de demora antes de leer el canal de la señal para entrar en fase con la correspondiente presion y/o temperatura por cada grado, hasta completar las 360 o 720 muestras.
Ya conozco las configuraciones de reloj para la conversion, pero al programar en PBP me surge un duda con la siguiente instruccion:
ADC_SAMPLEUS 50
Se que este es el tiempo total de conversion, entre que setea el canal y realiza la conversion. Es decir que comprende los 12 Tad necesarios.
Por lo tanto tendriamos 4,16 microsegundos (50/12) por cada Tad, que esta ok segun el minimo por Tad de 1,6 uS.
Suponiendo que lo bajo a 24 uS al ADC_SAMPLEUS serian 2 uS por Tad, y sabiendo que cuando se realiza la conversion solo se involucra al canal de la señal los primeros Tad para tomar la señal en el capacitor de carga y los demas Tad son de conversion por bit, mi pregunta es la siguiente:
¿puedo subir las RPM del motor tanto como para que el tiempo "X" de giro por grado se haga muy chico (minimo 3 uS), teniendo en cuenta que solo utilizo los primeros Tad`s de la conversion para "leer" la señal???
Ejemplo: Tengo el motor girando a 15000 RPM, por lo tanto el tiempo "X" por grado de giro seria de 11 uS. ¿¿¿Puede el ADC del micro en ese tiempo y configurado con ADC_SAMPLEUS=24 realizar una buena medida por cada grado de giro???

desde ya muchas gracias
 
Reglas generales de uso del foro (Extended Version)

01) No escribir todo en Mayúsculas (Título). Las mayúsculas equivalen a elevar la voz.

02) Utiliza siempre títulos descriptivos. Evita usar "Hola", "Ayuda por favor", "Urgente", "Auxilio". etc.
 
Pues lee a ver que dice el datasheet, el que yo usaba el ADC tardaba 14 ciclos de máquina. (no era un pic)
Para tiempos críticos yo me plantearía hacer el programa en ensamblador o como mucho en C, el basic aunque compilado nunca tuvo fama de eficiente.
 
El ADC del pic 16f877 no es el mas rapido, recuerda que le toma 11TAD para convertir el dato y un tiempo similar para adquirirlo, por lo que el tiempo de conversion seria muy lento para la aplicacion que quieres.

Necesitas buscar un pic con un ADC mas rapido, la serie 18 me parece que cuenta con micros con adc de hasta 400msps y en el caso de los dsPICs y los pic24 cuentan con ADCs de hasta 2msps.

Saludos!
 
Otra cosa que tienes que pensar es que vas a hacer con el "chorro" de datos que te entren; o tener suficiente memoria para almacenarlos o un canal de comunicación rápido para transmitirlos.

Si piensas en ADCs externos maxim tenía un de 8 con conversión simultanea, en lugar de un conversor y un multiplexor. Igual lo necesitas para tomar datos simultáneamente en varias partes del motor.
 
Generalizando un poco sobre fisica...

El sensor de temperatura es lo suficientemente rapido... lo dudo, debes tener encuenta la enorme inercia que tiene la temperatura comparado con el micro.
Sem e ocurre como sensor de baja inercia la utilizacion de hilo caliente o un termopar de baja inercia, aunque seguira siendo lento, del orden de decimas de segundo.

Aunque si te conformas con temperaturas relativas, puedes utilizar un sistema de muestreo y retencion (sample & hold) diferencial. Tomas una muestra y la restas de la siguiente, filtra y amplificas esa minuscula señal.


El sensor de presion es algo mas bondadoso y suelen llegar a unos pocos kilohercios.

Es inutil tomar miles de muestas de una tension que apenas varia, ocupando al micro para obtener la misma informacion con un muestreo a menor sampleo.

Para mejorar la captura a alta velocidad lo mejor es atacar al adc con un operacional en configuracion unidad (el tipico que tiene la salida unida a la entrada +), se suele insertar una resistencia en la salida del opam de unos 22ohms para evitar oscilaciones entre el opam y el ADC


Conclusion,
Debes reducir al maximo la toma de datos para que el micro pueda filtrar, transmitir y mostrar los datos.
Si la temperatura varia apox. al cabo de 2 segundo, es inutil muestrear a 75k, tienes 75000 muestras con el mismo valor y el micro completamente sobrecargado.

Busca el datasheet del sensor de presion y anota la frecuencia maxima.
Busca el datasheet del sensor de temperatura y anota el tiempo minimo de inercia.


Para el tema de temporizaciones debes utilizar el modo especial del timer1 que genera la conversion del adc automaticamente en un tiempo determinado.
 
Muchas gracias a los que respondieron.

En cuanto al tema de medir la temparatura, debido justamente a lo que conto tiopepe, solo seria para tener una idea global de como responde el sistema.
Lo que realmente nos interesa es conocer las presiones del motor, sobre todo en motores de dos tiempos en los que la puesta a punto se basa en conocer las presiones existentes en cierres y aperturas de lumbreras, para modificarlas luego y ajustar el sistema completo.
Las muestra de presion se realizaria por cada vuelta (empezando de grado 0 al 1, del 1 al 2 y asi hasta 360 obviamente), por lo que el tiempo minimo para tomar cada muestra por vuelta se corresponde con las maximas RPM en que manejariamos estos motores 2T. Por lo tanto a 15000 RPM tenemos un tiempo minimo para tomar datos por vuelta de 0.00396 segundos (4 mS), y por grado de avance de 11 uS. Aunque no creo que lleguemos a tan altas RPM, y nos quedariamos en el orden de las 4000 - 8000 RPM (42 - 20 uS por grado de avance).
En cuanto a lo de los sensores hay otro equipo encargado de esa primera parte del sistema, y creeria que no habria problema con las frecuencias.
Por lo de filtrado hay una etapa antes de ingresar al ADC del micro que consiste en filtros antialiasing de 4 orden para cada uno de las lineas de sensores.
Y los datos ya convertidos a digitales no se guardan en memoria porque seria un derroche de tiempo increible, por lo que se mandan via serial a la pc a 9600 de velocidad.
La frecuencia de trabajo es de 20 Mhz.
Voy a ver como setear lo que remarco tiopepe sobre el timer1 ya que no lo habia tenido en cuenta.
 
Última edición:
A 9600bps no se envía mucho, la verdad, son unos 960 bytes por segundo.
11uS por dato son unos 100.000 por segundo, si son datos de 10 bits o llevan algún identificador o algo necesitarías como 3bytes por dato no llegas ni por asomo.
Lo digo porque yo hice un sistema de adquisición a 115kbps y se quedaba muy corto, era por no liarme con el USB.
 
En realidad serian solo 360 datos, cada uno de un byte, ya que por ahora trabajariamos a 8 bits, que se toman de a un dato por vuelta, es decir que en cada vuelta se muestrea, convierte y envia el dato.
Y para ello hay un tiempo de entre 15 y 7,2 mS por vuelta, dependiendo de las RPM, para realizarlo.
Desde ese punto a mi me parece factible, aunque la cuestion sigue en torno al ADC y los tiempos para realizar las mejores medidas posibles, ya que hablamos de grados de avance por vuelta.
 
Atrás
Arriba