Hola Juan Acabo de realizar una comparación entre Chronopic3 y Chronopic1 a partir de una plataforma de contactos que disponía de salida de cables duplicada. Las dos Chronopic estaban conectadas a mi maquina /dev/ttyUSB0, /dev/ttyUSB1 y eran gestionadas por chronojump_mini. Como veréis en el archivo adjunto (OpenOffice), existen diferencias entre el TC y el TF (tiempo de vuelo o Time of Flight) en ambos dispositivos, pero siempre (excepto en el caso comentado en el siguiente párrafo) inferiores a 1ms, por tanto respetando la frecuencia de muestreo estimada en 1000Hz. Como se ve también en la hoja de cálculo, los tiempos entre las Chronopics difieren en mayor medida cuando el tiempo a medir es mayor. Esto no supone un problema para los saltos, pero sí para cuando se use chronopic para otras aplicaciones de tiempo más elevado. Además, la aparición de las diferencias, refleja en mi opinión, que efectivamente existe algún error en la medición/tratamiento de los datos que se arrastra en cada bucle de tiempo. Así, se cree que Chronopic3 difiere en la medición por alguna diferencia en el hardware, que esta diferencia no es significativa en los saltos (objetivo inicial y principal del proyecto), pero que conviene ser analizada y corregida cuanto antes para que Chronopic sea funcional en tests de más duración entre eventos. Que la medición realizada entre Biopac y Chronopic3 (similar a la incluída en este correo), pero con diferencias de un orden de magnitud superior, puede que se explique por haber usado un a conexión de cables distinta, en que ambos dispositivos no se encontraban en paralelo. Puede que un dispositivo estuviera afectando al otro. Se espera mañana poder probar con la misma disposición usada en la prueba entre Chronopic3 y 1. En el caso de que mañana la diferencia continue existiendo, se probará sin el condensador C4. Saludos 2008/1/28, juan <juan iearobotics com>: > 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 > > _______________________________________________ > Chronojump-devel-list mailing list > Chronojump-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/chronojump-devel-list > > >
Attachment:
chronopic1-chronopic3.ods
Description: application/vnd.oasis.opendocument.spreadsheet