Cronografo argentino?

[kv29]

Buenos días, amigos del foro.
Hace un par de días tomé contacto con este tema y me entusiasmó mucho (la inactividad por el aislamiento social me tiene loco), al punto de que ayer me propuse conseguir algunas cosas de electrónica, y con las ideas tiradas por ustedes y otras sacadas de la red, construir mi cronógrafo. Y bueno, desde que tomé la decisión de hacerlo y espero la encomienda de M.L., se me cruzaron algunas ideas que quiero compartir y creo que pueden mejorar el área de sensado, o dicho en otras palabras: aumentar el diámetro del caño.
1) En lugar de enfrentar emisor y sensor, colocar el emisor unos milímetros antes del sensor en la misma línea, pero no dentro del caño, sino en una ranura por la cual proyectar la luz I.F. en la pared posterior del tubo y que el sensor "vea" la sombra del proyectil y no al proyectil mismo. (siempre la sombra va a ser de mayor tamaño, y más fácil de detectar).
2) Regular la intensidad del led emisor de manera que sea apenas suficiente para excitar al sensor.
Cuando digo algunas cosas de electrónica me refiero a todo. Ademas de electrónica y de programación no sé un joraca.
Saludos!

Hola hrplvr. Esta bueno que se animen con el asunto. Te hago un par de observaciones sobre lo que opinaste

1) Es correcto el razonamiento. Lo que me llama la atención del chrono chino que compró kurupi (en otro posteo), es que esta armado al revés (de tal manera que el balín pase lo más próximo posible al led sensor y tiene arriba una fila de leds IR).
2) Si el punto 1 se cumple razonablemente bien, no sería tan necesario llevar la intensidad del LED casi al umbral de detección, aunque también se lo podria dejar lo más finito posible y ver si esto contribuye con la detección y los cálculos posteriores. Hay que probar.

Es un gusto leerlos. Si me llega el chino se lo presto para averiguar lo que puedan de el

Gracias Kuru, unas fotos siempre van a venir bien.

No era fácil la cosa .. por algo valen caros los buenos

Caro para nosotros, afuera sale barato y viendo fotos del interior, son 2 guitas de componentes. Igual que la cosa sea difícil, no asusta. Ya lo tengo casi resuelto (no tan versátil como el Chrony aún, pero funciona). Lo que más me cuesta es darle una FORMA decente al conjunto sin recurrir a algún servicio que haga gabinetes termoformados, que es caro y te piden cantidad para justificar el diseño.

La caja me quedó impecable, el problema es darle salida al tubo y reemplazarlo por algo más práctico. Hablando del tema, es muy probable que un segundo diseño le dé salida al LCD y solamente deje la electrónica en una minicaja, dejando todos los datos en el celular.

[hrplvr]

Hola, buenos días.
La idea de emisor y sensor en la misma linea, independiente de la dificultad de implementarla, surgió del recuerdo del último eclipse de sol ocurrido el año pasado (el cual tuve la oportunidad de ver desde un lugar de privilegio). Las únicas manera de observar fueron: mediante la proyección de la imagen sobre una pantalla en cámara obscura y la otra, mediante máscara de soldar para evitar el deslumbramiento, aparte del daño en las retinas. . Aclaro que sin duras la mejor es la primera, proyección en pantalla y observación a través de pequeña abertura en el caño, desde afuera.
Para evitar deslumbramiento, (mascara de soldar) regular intensidad del emisor y proyectar la luz en forma de banda transversal, para esto: emisor desde fuera del caño a través de fina ranura. Por supuesto que para implementar esta idea se debe usar un solo emisor para definir mejor la sombra del proyectil.

Sin dudas, la dificultad de implementar estas ideas radica en el diseño. 1) Receptáculo para el detector, se debe calcular el diámetro de la apertura y la distancia a ella según el ángulo útil del sensor para que cubra el área de pared opuesta del caño donde se proyectará la imagen del proyectil. y 2) lo mismo para el emisor. Creo que lo ideal seria en una sola pieza emisor y detector separados por un tabique y colocar en el caño mediante una sola abertura para cada una de las dos estaciones. Tengo conocido con impresora 3D. veré que puede diseñar cuando tenga los elementos y pueda comenzar las pruebas y observaciones-
Los tendré al tanto de lo que logre-
Saludos!

[kv29]

Me doy cuenta ahora que malinterpreté tu observación. El sensor necesita que el led lo apunte de forma directa, o no tendrá la sensibilidad necesaria para provocar la interrupción.
No puede detectar la luz IR reflejada porque el rebote es muy débil y más aún si aumentas la distancia al sensor (estamos hablando de unos pocos cms). Si comenzamos a achicar las distancias, volvemos al problema inicial de tener un tubo pequeño (que es lo que tratamos de evitar).

Sería conveniente si pudieras subir algún esquema para ver alternativas.

[hrplvr]

Me doy cuenta ahora que malinterpreté tu observación. El sensor necesita que el led lo apunte de forma directa, o no tendrá la sensibilidad necesaria para provocar la interrupción.
No puede detectar la luz IR reflejada porque el rebote es muy débil y más aún si aumentas la distancia al sensor (estamos hablando de unos pocos cms). Si comenzamos a achicar las distancias, volvemos al problema inicial de tener un tubo pequeño (que es lo que tratamos de evitar).

Sería conveniente si pudieras subir algún esquema para ver alternativas.

Si el reflejo de la luz del led en la pared del caño no es suficiente para excitar al sensor, debo tirar todas mis ideas a la "m%#$·%$#. .
Empezar con otra cosa.
Saludos.
Héctor

[kv29]

Me doy cuenta ahora que malinterpreté tu observación. El sensor necesita que el led lo apunte de forma directa, o no tendrá la sensibilidad necesaria para provocar la interrupción.
No puede detectar la luz IR reflejada porque el rebote es muy débil y más aún si aumentas la distancia al sensor (estamos hablando de unos pocos cms). Si comenzamos a achicar las distancias, volvemos al problema inicial de tener un tubo pequeño (que es lo que tratamos de evitar).

Sería conveniente si pudieras subir algún esquema para ver alternativas.

Si el reflejo de la luz del led en la pared del caño no es suficiente para excitar al sensor, debo tirar todas mis ideas a la "m%#$·%$#. .
Empezar con otra cosa.
Saludos.
Héctor

JAJA, no te desanimes Hector. Yo te aconsejo arrancar con lo que ya se sabe que funciona, y una vez que comprendas las posibilidades (e imposibilidades) de los componentes a través de la práctica, seguramente vas a podes encontrar formas alternativas y creativas también. Vi por internet un tipo que hizo un crono usando una barrera con laser, bastante económico y creativo el asunto aunque hay que darse maña con la construcción

Igualmente, la forma más sencilla de no "entubar" los sensores, es la del crono que compró kurupi. Fijate la mini plataforma que hay por delante, que ayuda a centrar la boca del cañón para que el disparo pase por los sensores. El primero sensor lo agarra seguro, solo hay que lograr tener el rifle bien centrado para que el balin también pase por el segundo sensor. Se me ocurre que para los rifles de quiebre puede ser un incordio porque hay que moverlo constantemente para recargar, mientras que para un pcp es fácil mantenerlo así.

[gabrielnn77]

disculpa, podes pasar el esquema general del codigo que usas para tomar las lecturas de los tiempos? para ver como lograste capturar los dos eventos
en un proyecto vi que usaban una estrategia como sugeria caarlo cre, de meter la lectura de los sensores directamente en el bucle principal
porque para mi que las interrupciones no estan funcionando, no es suficiente el tiempo de exitacion del sensor para que dispare la interrupcion (supongo que es eso, en realidad no se por que a alta velocidad no dispara la interrupcion)

[kv29]

Hola Gabriel, estas son las interrupciones tal como las uso. NO las puse en el loop, ni es necesario porque las interrupciones se ejecutan independientemente de lo que sea que el arduino esté haciendo en el momento que ocurren.

Estas 4 definiciones van antes que todo,
const int sensor1=2;
const int sensor2=3;
unsigned long time1;
unsigned long time2;

Luego en el Void Setup, pone las interrupciones,
attachInterrupt(digitalPinToInterrupt(2), paso1, FALLING);
attachInterrupt(digitalPinToInterrupt(3), paso2, FALLING);

Y finalmente, creá un par de voids con las ISR que se mencionan arriba,
void paso1() {
time1 = micros();
}
void paso2() {
time2 = micros();
}

Otra posibilidad (en vez de utilizar interrupciones) es meter 2 WHILE en el loop para que detecten los cambios de estado de ambos pines, pero no lo probe. Tengo entendido que las interrupciones son más rápidas que esto (no lo confirmé).

En los "pasos" podes hacer que te muestre mediante serial si detecta algo (o no) al momento de hacer las pruebas.

[gabrielnn77]

con esa misma idea lo hice yo, pero con el rifle no me detecta nada, y si lo tiro a mano, si

por las dudas, time1 y time2, las definiste como volatile ?

[gabrielnn77]

gente, buenas
hay algun avance con esto? yo tengo que reconocer que no toque mas nada, estoy en duda de gastar en fotodiodos de mejor calidad porque, como comente mas arriba, probe implementarlo con las interrupciones en arduino, y a alta velocidad, no me detecta nada (no dispara ninguna interrupcion), y no se si el tema esta en el tiempo que necesita el fotodiodo o en la velocidad del arduino

[kv29]

Buenas. Estoy a full con el laburo y la familia, todo en el mismo ámbito, y no pude continuar.
Me frene con el asunto de la aplicación en android por un lado, y terminar de definir el tubo o tunel con los sensores por el otro, de la forma más prolija posible. Vamos a ver si puedo retomar dentro de poco.

[alex2040br]

Buenas, tema programación paso, es algo que tengo pendiente,
he comprado una copia china de arduino y ni siquiera lo he probado
Lo mío es la electrónica, amo montar circuitos.

Creo que lo mejor sería saber cuál es el croni más sencillo y efectivo,
copiarlo y de última mejorarlo, es lo ideal para saber que va a funcionar.

Leds IR creo que deben andar bien los que se usan en tv y control remoto.
Cajas se puede reciclar para quién no quiera o pueda comprar, yo he reciclado varias
de gabinetes de fuentes de notebooks quemados, u otras cosas que la gente tira al no tener arreglo.

He visto varios modelos que tienen sobre esas 2 antenitas un arco de varios sensores,
eso garantiza una un rango amplio de detección.

Voy a husmear si encuentro algo, si lo logro se los comparto por aquí
Recuerdo cuando tenía la locura de buscar en páginas rusas diagramas
de pedales de efectos para guitarras y fabricar clones

Los sigo leyendo, saludos

[gabrielnn77]

ahi al final me decidi y compre unos fotodiodos de mejor calidad, y ahora si pude tomar el disparo
como los sensores son infrarojos, el esquema es el de un cronografo de tubo
si bien estoy en fase de pruebas, tire dos tiros y me midio los dos sin problemas
la idea es imprimir en 3d un soporte para los sensores y pantalla, para agarrarlo al caño
algo que esta en la linea de estos dos:
https://ar.pinterest.com/pin/473792823271073610/
https://www.air-chrony.com/ru/khronogra ... y-mk1.html

pero mas simple
alguien sabe donde puedo imprimir en 3d y que costo tendria? yo hice los modelos, pero no tengo ni idea si hay que tener en cuenta algo en el diseño para poder imprimirlo despues
por ejemplo, desde el vamos lo hice de 22 cm de largo, y ahora veo que muchos imprimen maximo 20 cm

[gabrielnn77]

ahi mande a imprimir un montaje para armarlo
cuando llegue, muestro que tal funciona
dejo enlace del modelo del montaje
https://youtu.be/3Tz094T5HoM

[kv29]

Muy bueno Gabriel. Yo no estoy seguro de poder retomar lo mío, si bien funciona tal como esta, no tengo tiempo para terminar de pulir el asunto del entubado y resolver la programación de la app para el celu, por lo cual probablemente lo deje asi como está para uso personal.

[Aled86]

Felicitaciones a todos los que encaran este proyecto!!
Sigo el posteo para ver como avanzan. Saludos!

[tornetto]

Buenas gente. Yo a principio de año tenía casi cocinado el tema del Cronógrafo (no se por que se llama grafo si no dibuja nada xD) pero tuve que abandonar porque me tuve que mudar por la cuarentena. Estoy a pocas materias de recibirme de Ing. en Computación, y nuestra especialidad es esto (electrónica + programación).
Tengo muchas herramientas, así que las pruebas las pude hacer lo mejor que me dio con mis conocimientos.
Hay muchos puntos donde quizás les sea útil mi opinión.
1.- Ojo cuando van a la casa de electrónica a comprar "fotodiodos". Los "fotodiodos" que al menos me vendieron a mí, son fototransistores, y eso tiene sus pro y sus contras. El pro es que la sensibilidad es alta, debido a que es un transistor. La contra, es que el tiempo de respuesta también es demasiado alto para esta aplicación.
2.- El proyecto que pasaron de td0g está bueno. En parte me basé en ese para el diseño del mío. TD0G usa fotodiodos de los posta, polarizados en inversa, con una tensión alta (yo uso 28v). Ahora les tiro el mejor descubrimiento que hice. Se puede usar un LED como fotodiodo. Sólo hay que polarizarlo en reversa, con la suficiente tensión para detectar el cambio de tensión cuando sucede el evento, cuando el proyectil corta el haz de luz.
3.- Tema de programación de Arduino. La función millis() no es muy precisa. Yo no la uso para cuando tengo que hacer mediciones de tiempo sensibles (leer https://www.instructables.com/How-to-ge ... h-05us-pr/). Lo ideal es usar el timer de 16 bits que tiene el arduino, y una interrupción que se genera cuando hace el overflow del registro contador del timer para llevar la cuenta más precisamente, y usar los puertos GPIO de manera nativa, sin usar la librería de las funciones digitalRead(), pues consumen mucho tiempo. Si les interesa el código del timer, me avisan y se los subo.
Espero que les haya sido de utilidad. Si les interesa, les paso el circuito que voy haciendo, y el código, no tendría problema en compartirlo. Sólo quiero ver como se hace para licenciar con alguna licencia para que se pueda usar, pero nadie salga a vender mi diseño.

[gabrielnn77]

no se como se me paso el ultimo comentario, me habría ahorrado tiempo

bueno, comento mis avances: como bien dicen ahi, use fotodiodos de calidad, y puede tomar bien el paso del balin sin errores
en el codigo de arduino use interrupciones para capturar el paso del balin
para contar el tiempo, como bien explican ahi, no se puede usar la funcion micros() porque tiene unra resolucion de 4 [us], lo que genera un error de mas o menos 9 FPS (para una lectura de 900 FPS, y con una separacion de sensores de 10 cm)
esto lo comprobé midiendo al mismo tiempo con un chrony
ahora estoy probando usando timer2 como contador de tiempo (no puedo usar timer1 porque entra en conflicto con el shield LCD)
uso una estrategia de iniciar el timer2 cuando pasa el primer sensor y calcular el tiempo cuando pasa el segundo
habia puesto el prescaler del reloj en 1, pero me dio alguna lecturas un poco inconsistentes (aunque justo tambien se me quedo sin pilas el chrony, asi que no se cual es el verdadero error)
ahora compre pila nueva, y por las dudas puse el prescaler en 8, lo que da una frecuencia de 2MHz, que seria una resolucion de 0.5 [us]

no se si la estrategia es la correcta, mañana con sol probare de nuevo al lado del chrony

basicamente en la rutina de la interrupcion del sensor 1, lanzo el timer2, y en la rutina del sensor 2, me fijo cuanto tiempo paso

pedazo de codigo del sensor 1:
void sensor1(){
cli(); //stop interrupts
//TCCR2B = (1 << CS20); // prescaler : 1
TCCR2B |= (1 << CS21); // prescaler : 8
sei(); //allow interrupts
running = ! running;
}

no estoy seguro que esas ordenes sean lo suficientemente rapidas para no afectar la medicion

[tornetto]

Bueno, te comparto mi código.

Código: Seleccionar todo

volatile byte ovf = 0;
byte ovf_aux;
unsigned int tcnt_time;
float calculated_time;
unsigned long calculated_time_shift;


void setup() {
  // put your setup code here, to run once:

  
  Serial.begin(9600);
  
  TCCR1A = 0;
  TCCR1B = 0;
  TCCR1B |= (1<<CS10);
  //TCCR1B |= (1<<CS12);
  TIMSK1=0;
  TIMSK1 |= (1<<TOIE1);

  DDRC &= B11111110;
  pinMode(ledPin, OUTPUT);
  pinMode(A0, INPUT);

  
  
  //interrupts();

}



void loop() {
  // put your main code here, to run repeatedly:


  noInterrupts();
  
  while(PINC && B00000001){};
  digitalWrite(ledPin,HIGH);
  
  TCNT1=0;
  
  ovf = 0;
  
  interrupts();
  
  while(!PINC && B00000001){}
 

  tcnt_time = TCNT1;
  ovf_aux = ovf-1;

  
  
  
  calculated_time = ((ovf_aux*65536)+tcnt_time)/16.0; //tiempo en milisegundos
  
  Serial.println("OVF es");
  Serial.println(ovf_aux);
  Serial.println(tcnt_time);
  Serial.println(calculated_time);
  

  delay(1000);

}

ISR(TIMER1_OVF_vect){
  ovf++;
  
}

Está cero comentado porque es un prototipo desechable jaja. Decime si te sirvió.

[gabrielnn77]

Bueno, te comparto mi código.

Código: Seleccionar todo

volatile byte ovf = 0;
byte ovf_aux;
unsigned int tcnt_time;
float calculated_time;
unsigned long calculated_time_shift;


void setup() {
  // put your setup code here, to run once:

  
  Serial.begin(9600);
  
  TCCR1A = 0;
  TCCR1B = 0;
  TCCR1B |= (1<<CS10);
  //TCCR1B |= (1<<CS12);
  TIMSK1=0;
  TIMSK1 |= (1<<TOIE1);

  DDRC &= B11111110;
  pinMode(ledPin, OUTPUT);
  pinMode(A0, INPUT);

  
  
  //interrupts();

}



void loop() {
  // put your main code here, to run repeatedly:


  noInterrupts();
  
  while(PINC && B00000001){};
  digitalWrite(ledPin,HIGH);
  
  TCNT1=0;
  
  ovf = 0;
  
  interrupts();
  
  while(!PINC && B00000001){}
 

  tcnt_time = TCNT1;
  ovf_aux = ovf-1;

  
  
  
  calculated_time = ((ovf_aux*65536)+tcnt_time)/16.0; //tiempo en milisegundos
  
  Serial.println("OVF es");
  Serial.println(ovf_aux);
  Serial.println(tcnt_time);
  Serial.println(calculated_time);
  

  delay(1000);

}

ISR(TIMER1_OVF_vect){
  ovf++;
  
}

Está cero comentado porque es un prototipo desechable jaja. Decime si te sirvió.

no entendi una goma, jajaja
calculo que estas lellendo la direccion de memoria del pin para detectar la señal, yo en lugar de eso, uso una interrupcion, no se si es mucha sobrecarga hacerlo asi
lo otro que veo, es que configuras timer1, no se bien que quieren decir esos valores, pero de todas formas yo tengo que usar timer2 porque el 1 lo usa la libreria del cheapLCD
de todas formas calculo el tiempo de la misma forma

no se para que desabilitas las interrupciones, no se que efecto tiene si no estas usandolas
la verdad que me vendria bien algo de documentacion jajajaj

una observacion, que es algo que vi en la lib que vos recomendaste antes
puede ser que justo entre que lees TCNT1 y lees ovf, justo entre esas dos sentencias, se provoque el desborde, y estes considerando un desborde que es una unidad mayor al real

en la libreria usa tambien timer2, por eso es mas probable que haya un desborde y se de ese error

[MauroSeba]

Bueno, te comparto mi código.

Código: Seleccionar todo

volatile byte ovf = 0;
byte ovf_aux;
unsigned int tcnt_time;
float calculated_time;
unsigned long calculated_time_shift;


void setup() {
  // put your setup code here, to run once:

  
  Serial.begin(9600);
  
  TCCR1A = 0;
  TCCR1B = 0;
  TCCR1B |= (1<<CS10);
  //TCCR1B |= (1<<CS12);
  TIMSK1=0;
  TIMSK1 |= (1<<TOIE1);

  DDRC &= B11111110;
  pinMode(ledPin, OUTPUT);
  pinMode(A0, INPUT);

  
  
  //interrupts();

}



void loop() {
  // put your main code here, to run repeatedly:


  noInterrupts();
  
  while(PINC && B00000001){};
  digitalWrite(ledPin,HIGH);
  
  TCNT1=0;
  
  ovf = 0;
  
  interrupts();
  
  while(!PINC && B00000001){}
 

  tcnt_time = TCNT1;
  ovf_aux = ovf-1;

  
  
  
  calculated_time = ((ovf_aux*65536)+tcnt_time)/16.0; //tiempo en milisegundos
  
  Serial.println("OVF es");
  Serial.println(ovf_aux);
  Serial.println(tcnt_time);
  Serial.println(calculated_time);
  

  delay(1000);

}

ISR(TIMER1_OVF_vect){
  ovf++;
  
}

Está cero comentado porque es un prototipo desechable jaja. Decime si te sirvió.

no entendi una goma, jajaja
calculo que estas lellendo la direccion de memoria del pin para detectar la señal, yo en lugar de eso, uso una interrupcion, no se si es mucha sobrecarga hacerlo asi
lo otro que veo, es que configuras timer1, no se bien que quieren decir esos valores, pero de todas formas yo tengo que usar timer2 porque el 1 lo usa la libreria del cheapLCD
de todas formas calculo el tiempo de la misma forma

no se para que desabilitas las interrupciones, no se que efecto tiene si no estas usandolas
la verdad que me vendria bien algo de documentacion jajajaj

una observacion, que es algo que vi en la lib que vos recomendaste antes
puede ser que justo entre que lees TCNT1 y lees ovf, justo entre esas dos sentencias, se provoque el desborde, y estes considerando un desborde que es una unidad mayor al real

en la libreria usa tambien timer2, por eso es mas probable que haya un desborde y se de ese error

Ahora entiendo porque estas faltando los sabados

[gabrielnn77]

ehh, falte el sabado pasado nomas, estaba con fiebre
y hoy, porque ahora confirmado estoy aislado
volviendo al tema, con las correcciones correspondientes, midiendo a la par de un chrony, da una diferencia de 1 a 2 FPS
creo que las pruebas son mas que satisfactorias
el unico tema que tengo que revisar, es puntualmente el caso donde se produce el desborde justo en el momento que estoy leyendo el contador de timer2 y el contador de desbordes
porque me paso que en un par de mediciones me dio valores inusuales bajos de velocidad o demasiado alto
saque la cuenta, y es justamente el valor que arroja sumarle o restarle 128 [us] a la medicion del tiempo, es decir que a veces, estoy tomando un desborde de mas o de menos, y me da ese error de 128 [us]
voy a pegarle una mirada a la libreria esta https://github.com/ElectricRCAircraftGu ... merCounter a ver si entiendo la idea de como evita ese error, y listo
si a alguien le sirve, puedo pasar video, codigo, y especificaciones de los componentes, sobre todo el critico creo que es no errarle al fotodiodo

el dispositivo en cuestion, calcula la velocidad en FPS, m/s, energia en joules, vel min, max, promedio y spread
lee hasta 50 disparos, aunque es trivial ponerle que lea 100 o 150

[gabrielnn77]

https://www.youtube.com/watch?v=s2DOzHH34lQ
prueba del ultimo prototipo

[Danielboom]

https://www.youtube.com/watch?v=s2DOzHH34lQ
prueba del ultimo prototipo

Lindo !!!!

Slds

[kv29]

https://www.youtube.com/watch?v=s2DOzHH34lQ
prueba del ultimo prototipo

Muy bueno Gabriel, te felicito. Ahora, a pulirlo. Haberlo conseguido uno mismo no tiene precio.

[pecos pest]

les tiro algo.
hace mas de 30 anios construi uno , basado en el principio de un par de pantallas hechas con alambre finito de bobinar en zig zag. cada vez que tiraba habia que volver a alambrarlas. primitivo pero andaba ,sobre todo con calibres gordos. ( debuto con un 43 Spanish )
En Usa habia unos con pantallas conductoras impresas.
la electronica muy simple , un contador 74C926 y un cristal de 100khz como reloj. Media el tiempo de vuelo. El calculo de la velocidad a calculadora o tabla impresa.

los Chrony y competition electronics ( tengo de los dos ) detectan la pasada con un fotodiodo pero enfocan con una lente cilindrica , de forma que el sensor puntual ve una linea como un puntoy al pasar el proyectil se produce un pequenio pulsito por la parte de la raya obstruida. Es muy chiquito. Detectarlo no es changa.
si examinan una pantalla , van a ver que lleva bastante electronica analogica asociada , basicamente lo que hace es tomar el nivel de luz existente , y con eso establecer la referencia para polarizar un comparador de forma que el sistema se adapta a condiciones variables de iluminacion.
Tratar de hacer reverse engineering del circuito de una pantalla es garantia de terrible dolor de cabeza, mas vale diseniar uno propio.
Con el Arduino le pueden agregar los chiches que quieran , pero hace falta una parte de disenio analogico que se esta volviendo un arte olvidado.

Please no me manden al residencial geriatrico.

[Caaarlo]

pero hace falta una parte de disenio analogico que se esta volviendo un arte olvidado.

Tal cual, es lo que inicialmente sugerí para asegurar una detección consistente.

[Caaarlo]

volviendo al tema, con las correcciones correspondientes, midiendo a la par de un chrony, da una diferencia de 1 a 2 FPS

Bien, ahora deberías probar con proyectiles a diferente velocidad y ver si la precision se mantiene, porque podes estar incurriendo en un error muy comun que es ajustar la función para que coincida a esa velocidad solamente, y en este caso si lo sacas de esa velocidad, pierde precision. Me refiero a medir por ejemplo un proyectil a 1200 pies, y otro a 600 pies.

[tornetto]

Si, yo hice eso en mi diseño. Un comparador con bias y en la entrada de referencia un capacitor para marcar la tensión de referencia en base a las condiciones de luz de ese momento, pero no me funcionó jaja. Así que seteo la referencia a mano, que igual no es tan cambiante porque los fotodiodos tienen una sensibilidad a un espectro muy angosto, entonces las condiciones de luz ambiente no influyen casi en absoluto, al menos en el ambiente donde yo lo probé.
Lo de usar un lente lo considere, pero dado a que no tengo mucha idea de óptica, no conozco alguien que la tenga, ni tampoco que pueda fabricar esos lentes, desistí por ese lado.

[gabrielnn77]

bueno, ultima comparación de mediciones, creo que llegue al límite de lo que puede hacer el arduino, en lo que respecta a reducir el jitter en las mediciones

Código: Seleccionar todo

resorte	chrony	chrotex	delta
1	803	620	183     <----------- primer lectura
1	846	840	6
1	848	846	2
1	851	852	-1
1	844	633	211    <---------- primer lectura
1	856	860	-4
max	899	904	-5
max	900	903	-3
5	899	901	-2
4	902	906	-4
3	888	892	-4
2	874	877	-3
min	857	861	-4
min	845	847	-2

para el cálculo de la velocidad, simplemente hice distancia/tiempo, como el resultado difiere del chrony en valores mayores y menores, no usé ninguna constante para compensar ni nada
la primer lectura siempre me da cualquier cosa, calculo que hay que hacer algo para inicializar mejor las variables/ registros del arduino, estoy probando como resolverlo
con respecto a las variaciones que había detectado antes (de hasta +- 8FPS) lo pude achicar a esto: +-6 (me desconcierta un poco, creí que tendría que der un poco menos, pero igual se puede ver que es bastante constante)
asumo que esta relacionado a que el loop principal esta haciendo una lectura analógica (para tomar si presiona algún botón)
pude reducir el jitter deshabilitando timer0 y timer1 entre las interrupciones que toman sensor 1 y 2 (para contar el tiempo uso timer2)
deshabilitar timer0 y 1 es muy recomendable porque es usado (timer0) por algunas funciones de arduino y genera interrupciones adicionales que interfieren con la medición del tiempo (tenerlo en cuenta para cualquier implementación)
probablemente una implementación mas simple, sin botones para navegar los datos, sea mas constante todavía, aunque a mi humilde entender, los errores están en un rango aceptable (asumiendo que la lectura del chrony es perfecta)
con el tema de la lectura a diferentes velocidades, eso es lo que pude variar sin tocar demasiado
pongo a disposición de quien lo pida el código del arduino y la lista de materiales usados
no se donde subir todo para que quede accesible, capas a github
costo final del proyecto: algo de $5000, comprando por ML con envío, y haciendo imprimir la cajita y soporte de los sensores

[gabrielnn77]

ahi dejo el codigo arduino, y los archivos de freecad para imprimir los soportes
https://github.com/gabrielnn77/cronografo