Eliminating Input Hysteresis?

I'm working on a project, a ballistics chronograph. Basically a light sensor which will send a certain voltage to the Arduino until it is tripped by a bullet. Then the voltage will change very briefly while the bullet is between the light sensor and the light source. The ADC is far too slow, so I am trying to use the digital pins.

Using direct bit reads, I can sample the pin plenty fast enough to detect the bullet. However, due to the pin hysteresis, the ATMEGA's digital pins can't actually read the small change in voltage very well. Is there some way to eliminate the input hysteresis so that it always trips at a certain voltage? Or do I have to move to a different controller (like a Teensy)?


The hysteresis has nothing to do with your problem, as you present it as accuracy. The hysteresis is a constant, no matter what it is. So it does trip at a certain voltage.

Not only can you not eliminate it, you are barking up the wrong tree. If your problem is that the voltage change is too small, you have to amplify it.

What happens is that I adjust the sensor circuit so that the Arduino almost 'trips' (in this case, the pin almost reads low). Then the voltage will decrease by ~.05V and the pin will go low. But when the voltage increases, the pin will continue reading low.

So if it cannot be eliminated, I wonder how to easily amplify the signal... Basically any deviation from the expected voltage will send a good signal to the microconroller, and it needs to happen within just a few microseconds? I've read a bit about amplifiers, comparators, and using simple transistors as amplifiers... Still very confused about what to look for specifically!

...the ATMEGA's digital pins can't actually read the small change in voltage very well.

Yeah... Digital inputs are not designed to measure a voltage change.

According to the ATmega datasheet an input less than 1V (0.2Vcc) is low. An input greater than 3V (0.6Vcc) is high. Anything in-between is undefined (it may read high or low).

You could make a [u]comparator[/u] with an op-amp if you want to change those thresholds. And, your undefined range can be much tighter depending on the precision of your resistors and voltage reference.

I'm not sure what your timing requirements are, but the input has to be a "stable" (valid high or low) for some (short) period of time before and during the time that the pin is read. You'd have to check the datasheet for that.

And unless you're using an edge-triggered interrupt, your software has to be reading that input at the time when the needs to be read, and it's only gets read when your program reads it (usually when your program loops-around to the read instruction). I've never used interrupts on the Arduino, but this might be a situation where an interrupt is the best approach.

It's better to use a comparator IC for a comparator, than an op amp as a comparator, as the devices are optimized for use as such.

You don't say what sensor you are using, but a bullet is typically moving pretty fast. Your sensor may just be too slow to give you what you want to do - even BEFORE you get to the Arduino. An Arduino sampling a sensor in a loop probably is not going to give you the resolution you want either, but first, you need to get a sensor that gives a reliable signal for something moving that fast. Do you have a second sensor or how are you measuring distance/time?

FWIW it's faster to poll a pin than use interrupts. But it sounds like some amplification is required as stated.

What sort of bullets. They usually have a speed of between 500 and 3000 feet per second, if the sensors are 1 foot apart that gives you between 2mS and 300uS to take the reading.

The input capture registers in the AVRs are designed for this kind of timing job.

aarg: The input capture registers in the AVRs are designed for this kind of timing job.

Awesome, wasn't aware of the input capture registers. Will be looking into this.

The sensor is an infrared light sensor. There will be a series of emitters, so when the bullet passes between the emitters and the sensor there will be a slight change in the sensor's resistance. There will be two or three of these gates, so we just calculate distance/time=speed. Here's an example of another ballistics chronograph.

I want it to handle up to 3000 fps. The bullet will take about 3 microseconds minimum to go from tip to tail. The sensor's response time is sub-millisecond, which is sufficient.

It looks like a comparator would be the best component for the job. I see the CD4585BE looks like a good choice... Thanks everybody!

Hi, It sounds like you are using one sensor, and trying to measure the resultant pulse width..

Why don't you use two sensors that are spaced apart and measure the time between change of state, say LOW to HIGH of the first to LOW to HIGH of the second?

That way you will illuminate the hysteresis.

I haven't seen any high speed devices use only one sensor.

Thanks.. Tom.. :)

The digital Arduino inputs have two pitfalls, the hysteresis (usually fine), and the synchronization with the processor clock.

The hysteresis (Schmitt trigger) requires a signal to exceed the threshold voltages, before the input pin changes its state. A voltage between both thresholds will preserve the preceding logic pin state.

The synchronization takes some time and can make very short spikes (<1 clock cycle) ignored by the input logic.

The analog comparator can be used to detect arbitrary voltage level crossings, at 500-750ns speed, without further external components.

The use of a single sensor (light barrier…) will suffer from the effective bullet length, which may tumble while passing the barrier, and from different on and off delays of a sensor. Two sensors will always sense the same (leading) edge of the bullet, at the same sensor delay.

Sorry, I worded that poorly. There will be two sensors, so minimum a few hundred microseconds between the first gate trigger and the second gate trigger. I mentioned the bullet length as there was some question as to whether the sensor could actually react quickly enough when the bullet was passing through the light.

Diettrich, you mention there’s issues with processor clock synchronization… I will have to look into this as well.

A few hundred µs are slow enough for the hardware. So most probably your code spends too much time after detecting the first trigger, before it starts waiting for the second trigger.

The bullet will take about 3 microseconds minimum to go from tip to tail.

You'd better have some pretty tight code (that's only 60 instructions), or use two capture inputs, which I think needs two TCs, but maybe not.

Another option is to use the comparators to set/reset a flip flop and have the Q output gate a CPU timer/counter.