PPA – Infrared Photogate Sensor (IRPS) design

An IRPS is required to provide ball position timings, so that the Arduino can precisely calculate the timing of a high power pulse to the electromagnet.

The general concept of a photogate is that infrared light shines from a LED (transmitter) to a Phototransistor (receiver) all the time, except when the ball is travelling through and blocks the path.  The output of the infrared phototransistor is analogue, so signal conditioning and digitisation is performed in the Input Board.

The electronic circuit is:

LED1 and T1 were originally a Jaycar product, but unfortunately their spacing didn't suit my tubing, so I kept having to cut them in half.  They were helpful for initial prototyping, but I moved to generic infrared LED and phototransistors.  VCC=5V

It was clear that small movements in the relative position of the two sensors leads to measurement error.  For example, for a nominal separation of 25mm, if the phototransistors have a small wobble of even 0.25mm between them, a 1% error would be introduced.  So the first design requirement was ability to lock in the distance between infrared beams.

This makeshift arrangement was useless because the distance between the infrared beams wasn't locked down

First checkpoint - how well do the sensors work ?

I needed to establish how well  the sensors were working, so I knew if they were good enough to start optimising the electromagnet timing.

The tube was positioned to include a sloped and a level section.  Two IRPS (ie. four photogates) were laid out next to eachother on the level section, with the principle being that a similar velocity would be expected as the ball rolls through.


As each electromagnet pulse will be tuned for a particular IRPS, the actual difference in ball speed is not as important as the consistency between the IRPS units.  Specifically, consistency of the ratio of one velocity to the other is the goal.  The ideal result would be a narrow distribution of a single ratio, with very little data on either side.

I started dropping the ball through the tube and recording the ratio of speeds between the two sensors... the results were terrible:


The actual distribution leaves a lot to be desired - the ratio can vary across an 8% band.  This would be a poor basis on which to optimise the electromagnet pulses.  During the experiment it was noted that movement of the tube relative to the phototransistor made triggering unreliable.  So the second design requirement is that the tube can't move relative to the sensors.

This prototype had fixed distance between infrared beams, but the tube could wobble around

I also noticed that overhead lighting was a source of output signal variation, so the third design requirement was that the sensor must be shielded from ambient light.

This prototype shielded the sensors from ambient light, but had a straight path for the tube... not great for a circular accelerator!

A usability issue with the above design is that the permanent 'roof' of the design had to be threaded over the complete tube - a real hassle if there are already other components like electromagnets in place. So the fourth requirement is a detachable roof.

Detachable roof for easy removal/installation on the tube

Second checkpoint - how well do the sensors work ?

As before, two IRPS were laid out next to eachother, for the ball to roll through.

Laying out IRPS next to eachother to check for consistency in timing

This time, the results were vastly improved (note the horizontal axis is expressed as percentage difference) :

Percentage difference between velocities as calculated from IRPS 1 and 2.   n=50

The results show that typically IRPS 1 measures 0.7% faster than IRPS 2, but what's important is that in the worst case, the IRPS 1 measures 0.4% or 1% faster than IRPS2.

I've pondered where the remaining error is coming from in the position error blog, but in the meantime, I kept improving the design:

The tube is of course laid out in a circle, so having a straight IRPS design isn't ideal…. but any particular curvature will limit the design/operation to just that curvature.  So the fifth design requirement was to allow variable curvature:

Segmented IRPS with allows variable tube curvature, with the bar on top maintaining the distance between the infrared beamsThe above design is pretty similar to the final version.  The only changes were to:

  • reshape the board to be more space efficient
  • remove the links
  • use o-rings to hold the 3d printed halves together (great idea Alister).  The o-rings can be easily rolled in from the outside thanks to the board redesign which features the 3d printed block overhanging the edge of the board.
  • make the leap to generic phototransistors and LEDs.

Finally, a spacing rod was added between the bottom of the IRPS and the Electromagnet, to ensure a consistent distance.

IRPS power usage

The downside of the IRPS design is the relatively high power consumption.  Many would consider the fact the LEDs are always on (100% duty cycle) to be wasteful.  I looked into using IR leds with built in modulation at 40kHz and similar frequencies, however this frequency has a material chance of adding delay to the recognition of the ball intercepting the beam, and was thus unacceptable.

0.025 msec      Duration of 40kHz signal

10 m/s             Assumed speed of ball

10 mm/msec   change units

0.25 mm          Distance ball travelled during 40kHz cycle duration

0.125 mm        Distance the ball could travel while during the 'off' part of the cycle

If the photogates are 25mm apart, and we permit a contribution of 0.1% error, the error distance can be up to 0.025mm.  As the distance the ball travels during the 40kHz signal is much larger than the acceptable error, the 40kHz signal is not suitable.

I considered arrangements whereby the LED’s were switched on in a ‘smart’ way, such as:

  • Only powering LED2 if phototransistor 1 had been activated.
  • Only powering on LEDs if the previous IRPS had been activated some time before.

However both options require additional circuitry and impose assumptions about where the ball is, where it is going etc.  In a very tightly controlled and well known environment such assumptions might be ok, but I was keen to avoid such assumptions to maintain flexibility for broad future use.

So what did I do to keep IRPS power usage as low as I could ?  I lowered the LED current as low as possible by experimenting with various currents, settling on the lowest one that worked reliably.

Leave a Reply

Your email address will not be published. Required fields are marked *