Re: Estudiando firmware pues hay un ligero error de medición

["Xavi de Blas" <xaviblas gmail com>]

Ahora iniciaremos más pruebas, pero estoy dudando del uso del Biopac.

Juan, ¿tienes acceso al generador de ondas cuadradas que usaste la
otra vez? ¿tienes acceso a un osciloscopio?

El miércoles nos darán el presupuesto de fabricación, sería importante
saber si hay problema con el condesador antes de tirarlo a fábrica.

Por cierto, gracias por el medidadas.sxc, creo que no lo habías
enviado anteriormente

Saludos


2008/1/28, Xavi de Blas <xaviblas gmail com>:
> 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
> >
> >
> >
>
>