Advanced time reading precision with mainstream IR hardware

Other Hardware Science and Measurement
1

Hi everyone !
I'm working on a project of an advanced ballistic chronograph.
My goal is to acquire the speed of bullets from a range of 300 to 1200m/s with a read error of less than 1/1000 (ideally 1/10000).
For the hardware side, it's a classical pair of IR break beam sensors spaced apart from a known value (100mm or 200mm), they trigger a micros() timer by interrupt pins, and the readed time value gives us the speed, display it on a screen and log to sd card.
Problem is the non-consistency of the measurements compared to lidar based chronograph that a friend have.

I think it's possible to get better measurement resolution by modulating the signal of the IR LED. We could send time based frames and search wich "frame" is not read by photodiode.

Thing is : How far can we push the frequency of an ir led / photodiode combo, or else what's the best type of sensor we can use for this application

2

It seems to me like you have a latency involved in the sensor and adding "frames" would only add uncertainty to the mix. My guess is that you need to quantify the latency of the sensors and adjust your program accordingly. The offset isn't necessarily the issue, but the difference between them will add or subtract from your total. Inconsistent latency will add to your window of real time measurement as well. I'd start by fully qualifying the sensor you're using in its current state.

3

I agree with your reflexion and have thought about it but ended up saying to me :
If the latency is constant and the same on the 2 sensors, we don't care,
and if constant but not the same on the 2 sensors, it's just an offset thing.
I can't really qualify them because I don't get an oscillo :frowning:
So maybe I should try other sensors.
My only method since now was trial and error but for such precision i'm stuck

PS: The difference of flight time between 1000 and 1001m/s for 100mm spacing is 100ns, not 100µs, 100ns !

4

0.1m/1200m/s = 83.3us Measuring that with a 4us accuracy micros() clock will only get you 5% accuracy.

Maybe doing it with a freerunning Timer1 and ICP1 would work. You could hardwire OR the two detectors, feed it into ICP1 on an Uno and record the time:

Take a look at adapting:

https://www.gammon.com.au/forum/?id=11504&reply=12#reply12

ETA:

Taking the 62.5ns resolution of the free-running Timer1, you could approach 62.5e-9/84e-6=0.0007440476 or 1/1344 resolution with an Uno. (Or 1/2688 resolution with the 200mm separation.)

5

Ok I see ! I only tried with +/-300 m/s projectiles, so my 5 to 10 m/s error is only related to the micros() timer resolution !! Thought it was 1ms not 4ms :exploding_head:

I will give a try to ICP1 and if i'm not satisfied i will search on that way to get 6.25ns res :

6

micros() reports at 1us resolution/precision, but it takes a few instructions and conditionals to calculate the result, and has opportunity for interrupts (TIMER0_OVF_vect is the main culprit) to delay the parts, which all add up to some possible jitter degrading the accuracy a couple us:

And yes, faster processors can do higher precision timing.

I see that the ESP32 has a 80MHz (or 160MHz) clock capture system:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/mcpwm.html#capture

ETA:
The code in the instructable PNG will have 6.25ns resolution, but will have similar accuracy problems because it isn't using the capture functionality -- After an edge trigger, it calls an ISR to copy the clock to a variable. The nice thing about the capture is that it copies the clock value to a register in hardware, and then calls a routine to deal with the copied value.

7

You also can use visible light LED or laser diodes for minimal environmental effects.

8

The sensors are in a "close" 3d printed petg-cf tube so external light variation is not such a concern in my case
Also i chosed IR most because of availability and I already got it.

9

Am I doing things good with that code and the 2 sensors wired in parallel configuration ?

#define triggerPin 8
#define ledPin 13
 
int countCycle = 0;
float flightTime = 0;
const int SensorSpace = 100;
float speed = 0.0;
volatile unsigned long timeCap;
float timeA = 0.0;
float timeB = 0.0;
bool timeAok = 0;
bool timeBok = 0;

void setup() {
  pinMode (ledPin, OUTPUT);
  pinMode (triggerPin, INPUT_PULLUP);
  Serial.begin(9600);
  noInterrupts();
  TCCR1A = 0;
  TCCR1B = 0b00000101;
  TIMSK1 = 0b00100001;
  TCNT1 = 0; 
  ICR1 = 0; 
  interrupts();
}
 
ISR(TIMER1_OVF_vect)
{
  digitalWrite (ledPin, !digitalRead (ledPin)); // To monitor cycles works great
  countCycle++;
}
 
ISR(TIMER1_CAPT_vect)
{
  timeCap = ICR1;
  if (!timeAok)
  {
    timeA = countCycle * 4194.304 + timeCap * 0.064; // eventA in miliseconds
    timeAok = 1;
  }
  else
  {
    timeB = countCycle * 4194.304 + timeCap * 0.064; // eventB in miliseconds
    timeBok = 1;
  } 
}
 
void loop() {
  if (timeAok & timeBok)
  {
    flightTime = timeB - timeA;
    Serial.println(flightTime);
    speed = SensorSpace/flightTime
    Serial.println(speed);
    timeAok = 0; timeBok = 0;
  }

}
10

Schematic?

Does it work?

I'd move the calculations out of the ISRs and into loop, change the bitwise '&' to a logical '&&', and maybe add decimal points on the floating point time difference:

Serial.println(flightTime,3); Serial.print(" mSec, ");

It is also good to copy from the ISR-modified variables into local copies.

Another point of concern is that as time progresses past 10 or 100 sec, the difference between floats won't be able to resolve intervals like 84us. I'd clear countCycle in the first half of ISR(TIMER1_CAPT_vect) or complete the differencing in ticks before the conversion into milliseconds.

1 Like
11

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.