Hola, Pongo aquí unas observaciones: 1) Un error de 5ms es muchísimo para un microcontrolador. La chronopic puede ejecutar en ese tiempo unas 5.000 instrucciones (Todo el firmware completo no tiene más de 200 y muchas se ejecutan sólo en la inicialización). 2) El firmware es el mismo para la chronopic 1.0, 2.0 y 3.0. Y puesto que el microcontrolador es el mismo (no se ha modificado) el software se ejecuta en el mismo tiempo para todos los prototipos. No va a hacer cosas diferentes en chronopic 1.0 que en la 3.0. Es el mismo firmware corriendo en el mismo microcontrolador con el mismo reloj. 3) Podría haber un bug en el firmware de manera que no cronometrase bien. Por eso se hizo una primera validación conectando un generador de ondas cuadradas a la skypic y comprobando que el tiempo calculado por el firmware fuese correcto. Los resultados obtenidos fueron los que os adjunto en la hoja de cálculo (que se hizo con openoffice 1.0 por eso está en formato .sxc). El resultado fue que el firmware tiene un error máximo de 0.5ms. Y para tiempos de vuelo del orden de 500ms es de 0.04ms. Es decir, errores casi despreciables. Esto es lo normal al usar microcontroladores. CONCLUSIONES ------------ A partir de estos hechos medidos: 1) El firmware tiene un error casi despreciable, muy por debajo de los 5ms detectados. 2) Se ha detectado un error de unos 5ms en las pruebas de validación --> Conclusión: el error NO está en el firmware, sino en otra parte del hardware. POSIBLE CAUSA DEL PROBLEMA -------------------------- Revisando el esquema del hardware he visto que puse un condensador de 1uF en paralelo con la plataforma para eliminar los rebotes (por hardware. Además se eliminan los rebotes por software). Creo que el retraso lo puede estar provocando ese condensador. Al realizarse el salto, el condensador tarda un tiempo en cargarse. Hasta que no se carga no le llegan los 5v al PIC. Este tiempo de carga depende del valor de la resistencia de pull-up interna del PIC (tengo que mirar cuanto es). Un valor típico de pullup es 4K7 lo que daría un tiempo de carga del condensador de 4.7ms . Este dato cuadra bastante bien con el retraso encontrado de 5ms. PRUEBAS A REALIZAR ------------------- Sugiero repetir las pruebas pero quitando el condensador electrolítico C4 (desoldándolo). Saludos, Juan El lun, 28-01-2008 a las 18:05 +0100, Xavi de Blas escribió: > Después de diversas pruebas de validación, se han encontrado dos > errores en la medición. Ambos errores ya existían en Chronopic 1.0 y > aunque son muy pequeños, existen y hay que corregirlos. > > 1) En comparación con un osciloscopio (Biopac), el Tiempo de Contacto > de Chronopic es usualmente 5 ms menor y el Tiempo de vuelo 5 ms mayor. > Siendo 5 ms el valor escrito en el firmware como tiempo antirrebotes, > tal vez este valor se use erróneamente en el programa: > > TIEMPO_ANTIRREBOTES EQU 0x05 > > Estos 5ms oscilan entre (4,5 y 6,9) de hecho la media encontrada ha > sido de 5,7ms > > Para saltos, repercute en una diferencia en el vuelo de menos de 1cm, > así que es poco, pero sin duda es un error > > 2) Cuando los contactos son inferiores al tiempo de rebotes, las > diferencias con Biopac son mayores. Esto no es problema en saltos, > pero sí puede serlo en skipping, tiempos de reacción cortos, ... > Habría que poder ajustar desde el software este TIEMPO_ANTIRREBOTES > tal y como ya se ha hablado alguna vez. > > Si podemos modificarlo deprisa, el nuevo chronopic 3.0 saldrá con el > firmware corregido, y si no es así, entonces la siguiente versión de > Chronojump debería actualizar el firmware. > > Se apunta la posibilidad de que cuando se realice la corrección, se > ofrezca al usuario la posibilidad de corregir automáticamente todos > los datos captados previamente. > > Recuerdo que para saltos la desviación es muy ligera. > > Por otro lado, los datos concuerdan ligeramente con lo que se obtuvo > en comparación con Ergojump: > http://mail.gnome.org/archives/chronojump-list/2005-July/msg00002.html > > "Se advierte que en general los tiempos de contacto en Chronopic aparecen > ligeramente inferiores y los de vuelo ligeramente superiores. Por otro > lado, son datos que no difieren de más de 1 cm. de elevación del CdG, y > por tanto son poco relevantes." > > Aunque revisando la hoja de cálculo que se obtuvo de dicha > comparación, la variabilidad era mucho mayor, hecho que lleva a pensar > que dicho dispositivo quizás tenía menos precisión o arrastraba algún > otro error. > > Voy a estudiar el código del firmware. Para los interesados: > http://www.iearobotics.com/personal/juan/proyectos/chronopic/1.0/ > > Ahora es cuando nos acordamos de que el firmware está en ensamblador y no en C. > > > Saludos > _______________________________________________ > Chronojump-devel-list mailing list > Chronojump-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/chronojump-devel-list -- Juan Gonzalez Gomez juan iearobotics com www.iearobotics.com
Attachment:
medidas.sxc
Description: OpenOffice Calc spreadsheet