Get Started with Altium Upverter, Sign Up Now.
We’re back to building our airsoft tracer unit which we started in Part 1. If you’ve forgotten what happened in part one and don’t want to re-read the whole article, we were building a fancy array of UV LEDs that are activated by an airsoft BB traveling past a light gate, and are switched off when the BB reaches the other light gate. On this project, we’re going with the attitude that ‘if it’s worth doing, it’s worth overdoing’. So while most commercial tracer units use under 2 watts of UV emitters, and the most expensive are about 6 watts, we’re throwing over 170 watts of UV emitters into the tracer unit. This massive amount of UV light will make airsoft tracer BBs glow, as they have the same chemicals as ‘glow in the dark’ powder and paints. This makes the BB easier to track in low light or dark conditions, such as inside a building or after dark. In Part 1, we defined our project parameters and requirements, then selected the high level components we thought might work well for the project.
Now that you’re all caught up on the project, welcome to Part 2. In this article, we are going to prototype the project on breadboards to ensure all our component choices are valid, and determine/tune the values of several resistors and capacitors that are going to be critical to detecting the fast moving BB traveling past our light gate. I was hoping to also make a start on the software to see if we can exclude some of the components we chose in Part 1, and get the rudiments of the system functioning. However, I’m having a hiccup with one portion of the design which we will discover as we go through it in this article, so that will be covered in Part 3.
As I mentioned in Part 1, I’m building this project article by article—by taking the approach of having you follow along with me as I design the tracer unit from start to finish, as that allows more learning opportunities as we discard components, discover that parts are not optimal, and make mistakes along the way. This is not a writeup of a completed project, but a writeup of the journey to get there.
Since we cannot control the LEDs without the photogate, it is probably the most critical portion of the project. Therefore, I’m going to start by building the amplifier for the PIN diode, which we are using to detect infrared light at the photogate. The PD15-22B/TR8, which is the PIN diode we selected for the surface mount PCB, isn’t available in a through-hole package, nor is the OSRAM SFH 4641-Z IR emitter. To be able to prototype, I’ve chosen parts with comparable specifications to work with instead.
Testing the Diode
My first step is to check that the PIN diode is going to respond nicely to the 950nm IR emitter. To do this, I set my lab power supply to limit the current to the emitter to 20mA, and then connected the PIN diode directly to the oscilloscope probe. Operating in the photovoltaic mode, the diode acts a bit like a really bad solar cell, generating a small amount of voltage as it is exposed to light that it is sensitive to.
Waving the IR LED back and forth over the photodiode showed the response on the oscilloscope, so all looking good so far! You’ll notice the amplitude of the voltage is low, with 5mv/division on the oscilloscope.
Next, I wanted to see how fast the photodiode could respond in photovoltaic mode. For many applications, the photovoltaic mode is going to be sufficient, however, it’s relatively slow due to the capacitance of the diode junction. The voltage created by the light needs to charge the junction as if it were a capacitor, so the voltage has a rise time that is far less than instantaneous. To test this, instead of powering the IR emitter all the time and breaking the beam as we would in the final product, I added an N-Channel MOSFET to the breadboard. The MOSFET will control the IR LED with my function generator, thus enabling me to dial up any frequency I want and see what the response is. Channel 1 (below) on the oscilloscope is connected to the LED leg, and channel 2 (blue) is connected to the photodiode.
With a simple 60Hz signal, we can confirm everything is working before continuing on to more applicable frequencies.
Switching the IR emitter with just a 1kHz signal, we can already see significant effects of the junction capacitance. The rise time is around 212us, which for many applications might be fine, but is inapplicable in ours as we need to capture a much shorter signal.
In the UK, we have joule limits for the energy of the BB as it exits the replica firearm. The highest joule limit is allowed for bolt action rifles, and equates to 500 feet per second with the lightest commonly used BB (0.2g). At 500 fps, we can expect the BB to occlude the light beam for about 20-40us. The actual period of time will depend somewhat on the exact implementation, but this ballpark figure should give us an idea what rise time to aim for. With a rise time an order of magnitude higher than this, photovoltage mode will not work for this application.
In part 1, this was already expected, so we designed a circuit to use the photodiode in photoconductive mode. As the junction is exposed to light, it is able to conduct current in the reverse-biased direction. As the junction conductance is directly correlated with the amount of light hitting it, the junction capacitance has no bearing on the rise time. We can use this conducted current to determine how much light is hitting the sensor instead of using the induced voltage. To do this, we need a transimpedance amplifier to convert the current into a voltage.
Soldering Op Amps to Breakout Boards
The op amps were also only available in surface mount, however, as they are in the common SOT-23-5 package, I have used breakout boards for them. If you’ve never tried soldering a relatively small and fine pitched component to a breakout board, it’s quite simple, even with thick solder and a wide chisel tip on your soldering iron. I use a 2.4mm wide chisel on my soldering iron for soldering even 0.4mm pitch and 0201 size components, so don’t feel as though you need anything more than a temperature regulated soldering iron to work with small surface mount parts.
You’ll only need a soldering iron, a flux pen and a set of tweezers. You can read more about my suggestions for these over on the Altium blog in my Kitting Out an Electronics Lab article. The breakout boards I have are from Sparkfun, and the pads look a little tarnished, so the flux is just going to make soldering to the pads much faster and easier.
First, I will wipe some flux across all the pads on the board, then tack down one pin in the corner, ensuring that all the other pins are well aligned on their pads. To do this, I hold the component with curved tweezers onto the board, and bring in the freshly cleaned and tinned soldering iron tip. The solder on the tip will transfer onto the pad and lead, with the flux you already added to the board ensuring that the solder on the iron tip flows well.
At this point, you can add a little more flux to all the pins if you want. Continue soldering each pin with a one second long tap from the corner of the soldering iron tip so just the pad and leg of the part make contact. If you have a small bit of solder on the tip, it will transfer over to the pin and pad nicely, without shorting any of the pins. If you do short adjacent pins, you can add a little more flux and then use the soldering iron to wipe it away. The surface tension of the solder will cause some of it to pull away on a clean iron tip, and the flux will ensure it doesn’t oxidise and flows well.
To ensure the breakaway headers get soldered on straight, and you don’t melt the plastic if you take too long, you can mount the pins into the breadboard and drop your breakout board on top. Then, just solder as normal. If you are worried that the pins of your breakaway header are tarnished, or that the breakout board is, you can add a little bit of flux here too. Make sure you’re using no-clean flux though, as you don’t want a sticky, mildly corrosive flux stuck between your header and the board.
Building the Circuit
I then built the circuit on the breadboard using the schematic the Analog Devices website calculated for us. However, to make prototyping easier, I’m using multi-turn pots, which I pre-set using a multimeter for the resistance in the schematic, instead of using exact fixed value resistors. I’m using an LM317 to create my 2.75V positive rail from a 5V supply generated by my lab power supply. I wanted a higher voltage coming into the breadboard for the IR emitter to run off, so I could use a larger resistor than if I powered the board with 2.75V. I didn’t have a close match to the correct current limiting resistor for the IR LED with 150mA at 2.75V.
I’m using a Texas Instruments TPS60403 inverting charge pump to create the -2.75V supply for the op-amps. You can read more about negative voltage in my article on the Octopart website. The op-amps need very little current, so the 60mA charge pump is more than sufficient.
To test the PIN diode, I’m using the MOSFET set up for the function generator and IR LED that I mentioned earlier. This will give me a continuous pulse of light that I can watch with my oscilloscope along with the amplifier output to see the response of the amplification circuit.
For the first test, I tried it out at 10kHz just to see if it would be better than the 1kHz signal we had previously. Clearly, the signal is looking much more square, but is looking pretty wavy! After a bit of poking around with the oscilloscope probe, I found that the noise was coming from the inverting charge pump, the output of which looked exactly like the flats of the blue waveform. Clearly, it needs a lot more capacitance than the datasheet suggests, needing around 40uF before the signal looked better.
As a note on the oscilloscope probes, this is a brand new oscilloscope for me, and I found out much later on in testing that the attenuation switch moves rather easily. It was set to 1x initially, but by the point of this screenshot, it had moved to 10x attenuation, so the voltage levels are all 1/10th of what they should be. This caused much confusion as to why the amplifier circuit just wouldn’t go above about 370mV no matter what I did! So lesson learned, check the test equipment settings before blaming the circuit, especially if it’s not test equipment you’re familiar with. You’ll see the attenuated voltages from here until almost the end. I wanted to keep the oscilloscope screenshots as they were taken rather than go back to replicate them with the probe set correctly, as I did say I would show all the goofs in this series!
Now that we verified that the circuit is amplifying the signal, it’s time to clean it up. I’m moving the oscilloscope probe between the two amplifier stage outputs to see the response. It’s an iterative process of first looking at the output of the first amplifier stage and turning the multi-turn pot’s adjustment until the output is looking as square as possible, then going to the second stage and turning the resistor between the stages until the signal looks as good as possible, and finally turning the feedback resistor for the second stage. This is repeated many times and at several frequencies well beyond what we expect the circuit to see in order to get the best tuned values we can.
Now, at 25kHz, the response curve is looking about as good as it can. The small spikes on the trace are caused by some interference from the LED magnifying lamp I’m using as a light source on my workbench. I’m not sure if it is conducted through the power lines, is radiated electromagnetically, or if the LEDs are emitting some infrared light which is influencing the photodiode, either way, it doesn’t have any bearing on the actual circuit’s functionality.
Running my function generator with a 35% duty cycle, 5kHz square wave gives a 39.36us pulse for me to work with. This closely replicates the time of the BB traveling through the light gate, and should give a good indication of the signal edges the microcontroller will have to work with.
It looks pretty good, and it was right about this point that I realized the attenuation switch on the probe had shifted earlier on during testing! This looks exception, and we have a 2.7-3.3v signal depending on how much light is hitting the sensor, and if I cover the sensor + led with a white box or not (amplifying the light).
Once the resistor values were well tuned, I switched out one of the capacitors as well, so I need to measure the multi-turn pot resistance and then re-draw the schematic for later reference. The schematic doesn’t need to be a perfect drawing, mine is just on a post-it sticky note giving me something to refer back to later.
While writing this, I’ve realised that since the LED will always be on and the BB will block the light, the signal here is the inverse of what we will expect in the actual tracer unit. This doesn’t really matter, however, as our edges look good on both sides.
This could be a good stopping point for tuning the circuit, however, these resistor values don’t represent real-world sourceable values. I also need to build a second amplifier circuit so I can test fire a BB between two sets of gates, so I’ll build a second circuit with the values of resistor I have on hand.
Here’s a slightly lower duty cycle 5kHz signal with the circuit implemented using commercially available resistor values. I’ve also dropped the capacitance of the inverting charge pump which is also noticeable.
The commercially available resistor values give us a good leading edge, but a poorer trailing edge. This will still be more than acceptable for triggering a microcontroller interrupt as far as I’m concerned. However, it will be interesting to see what it looks like when a BB travels past, as we may need to change resistor values to sharpen up the trailing edge.
The final circuit boards of this project will be integrated into a mock suppressor attached to the replica firearm. For now, I need a way to mount the IR emitter and photodiode to the rifle to see what it looks like on the scope when a BB passes through. I designed a quick attachment for the end of a rifle barrel to hold the IR emitters and photodiodes a known distance apart. We said in the last article that the battery would determine the minimum length of the suppressor at 80mm, so I used that length with the photogates 6mm in from either end.
I wasn’t sure how straight I’d be able to get the part pressed onto the end of the rifle, so I made the bore through 12mm in diameter, as I didn’t want one of my very limited IR emitters or photodiodes to be damaged by a BB impact if I didn’t get the unit on straight.
There’s nowhere to mount any UV LEDs, nor is there any intention to. This is just to test the photogates we are building against real-world conditions to ensure the amplifiers are going to be able to catch the passage of the BB.
I printed the mock suppressor in PET-G with 0.3mm layers to reduce the print time. This gives a bit of an ugly print but it’s only the function we care about at this point of the project. I used hot glue to attach the IR emitter and photogate into the 3D printed adapter, then wired them up to the breadboard so we can start testing. I tried to keep the wires short enough to not allow much noise to be picked up, or have any odd effects on such a small signal from the photodiode, while still being long enough to manipulate the rifle attached to it without constantly disconnecting the cables that are just pushed into the breadboard.
My first test is with a 0.45 gram BB, which is the heaviest I have and therefore will travel the slowest. It’s worth noting I’m running the IR emitters at only about 40mA current, rather than the 150mA they are rated for, and that the emitter and photodiode are about 18mm apart. In the final board, the emitter and diode will be much closer, and I will most likely drive the emitter at a higher current. This will give a larger voltage range, allowing for clearer readings. As channel 1 (yellow) is looking a bit low voltage in my current temporary setup, there may also be some hot glue over the photodiode! Those are things that can be optimized and tuned on the final board, but at this point, I’m most interested in the response curve looking like something a microcontroller will trigger on.
My next heaviest BB is a 0.32g, and that is definitely traveling faster.
Finally, we have the 0.2g BB, which is traveling quite fast. How fast?
If I add cursors to the oscilloscope display we can see the travel time is 444 μs to cover the 68mm distance between gates. That’s () 153.2 m/s or 502 feet/second. It sounds like it’s in the right ballpark area for a 0.2g BB, but to make sure, we can check with a 0.45g BB.
The 0.45g BB covers the 68mm in 695us, which means it’s traveling at 97.84m/s or 321fps. This is the rifle I regularly play with, and I know I shoot at 320 fps ± 3 fps, as we must perform a chronograph test prior to playing to ensure our guns are safe and legal.
When testing the 0.2g BB, I accidentally double fed the gun, putting two BBs down the barrel at once. I thought this was actually pretty interesting to see, as having two BBs come down the barrel could definitely cause some issues in software if we get a second pulse on the first photogate before the second photogate has been triggered. I would have thought the two BBs would travel with the rear BB pushing the first one out, however, it looks like they were separated by at least the gate distance as they went down the barrel. This is definitely an edge case which we will need to account for in the firmware. We will need to ensure that a second pulse coming through the first gate before the second is triggered will not cause a race condition or leave the code in a bad state. This is the sort of event that real world testing highlights well, as using a function generator to provide the pulses will never cause these events to happen.
At this point, I’m happy with the performance of the photogate and know that it will perform well on a circuit board with perhaps some minor tuning of the feedback resistor values.
LED Power Supply
In part 1, I was very unsure of the LED power supply. I chose the TPS92691 LED driver as it has good performance characteristics for driving an LED, but with the soft start, it looked questionable whether or not it would be able to be switched on and off fast enough for the purposes of this application. I bought the TPS92691 evaluation module to give me a chance to try it out before committing to the design. If the part doesn’t work the way we want it to, and we commit to a PCB using that part, it will mean a revision of the PCB at the least.
As the UV emitters we’re going to use in the project are not particularly cheap, wouldn’t be easy to use in a breadboard or solder wires to, and emit light of a frequency that is rather harmful, I bought a pack of cheap white LEDs from an online marketplace that have similar current draw and forward voltage. They will make great stand-ins for the UV emitters.
My first test was to connect the eval module up to the LEDs and just switch the power supply on and off. The LEDs lit up very bright and current regulation was good. Once I knew the board was functional, I added an N-Channel MOSFET to a breadboard to allow my function generator to bring the shutdown pin to ground, disabling the driver. This will make it possible to rapidly turn the driver on and off by connecting a function generator to the gate of the MOSFET.
At 5Hz, also known as ‘Disco Mode’, everything was working great. How about a higher frequency?
At just 100Hz, far below the speed we will need, the driver failed to either switch fully on or fully off. It was stuck in a limbo state of soft start and capacitor drain.
I had suspected this would be the case, so I shifted the MOSFET from pulling the shutdown pin to ground to instead pull the LED string to ground.
That did not go as I had hoped. The driver is very confused by the lack of load with a sudden appearance of load. It gets itself into a state of doing a massive voltage spike to its maximum output voltage around once per second. It has no real correlation between the function generator’s signal and the LED power, and the ramp time is so long (almost 20ms) that it rules the TPS92691 out as an option for powering our LEDs.
The development kit for the TPS92691 was not cheap, but it was well worth the cost as a fully populated and useless circuit board would have been substantially more expensive.
I suspected the TPS92691 might not do what we needed when I was purchasing components. I had hoped it would but planned for it not to. I also picked up an STMicroelectronics STEVAL-ILL063V1 evaluation board, which was relatively cheap. I don’t know that it will do any better than the Texas Instruments part did, but it’s worth a try. This is a much simpler driver and evaluation kit, so I speculate that perhaps being less feature-rich it might cope with my less mainstream usage a little better.
The evaluation kit has VIN, GND, DIM and the LED positive and negative terminals. Given the simplicity of the terminals I’m going to jump straight to testing the board with the LEDs connected to the dev board and FET.
I powered up the evaluation board with the LEDs connected, and they are shining nice and bright. Now that the kit is proven to be functional, it’s time to try toggling the MOSFET from the function generator.
Before we get to that though, I just wanted to share the scope screenshot with no power connected to the evaluation kit. You’ll see why in the next screenshot.
Not only does the evaluation kit not react well to even 20Hz of control, but it’s also generating a significant quantity of electrical noise. The noise could potentially be dealt with in-circuit, however, it’s well beyond what I’d want to try to deal with on a very compact circuit board next to extremely sensitive signals (such as those from our photodiode). The fact that the driver doesn’t work as we wanted is slightly irrelevant at this point.
We’re now two dev kits down, and I don’t hold a lot of hope that a traditional LED driver will be able to react to the rapidly changing loads as we need. At this point, I have to ask myself, do we even need current regulation? With a maximum pulse time of around 640us, the LEDs should not be getting to the point of overheating. Essentially, we will be running pulse width modulation on the LEDs, with a pulse of the BB travel time, and a period equal to the time between shots leaving the gun.
Obviously, we could easily add some crude current limiting with an LM317 or an LM334, or even more efficient current limiting with some op-amps and transistors, however, those solutions all add thermal loads and board space requirements I’m not sure we require to the project. I typically chase an ideal solution and use more components than are strictly required to make a functioning circuit, so I’m curious to try the other approach of issuing the bare minimum possible.
Current limiting has always been so critical in running powerful LEDs in products I’ve worked on that it’s very hard for me to consider running these LEDs without some form of current limiting. Therefore, I’ve set up an experiment with my cheap LEDs to run overnight: for 10 hours, I’m going to pulse the LED on for 640us, and off for the rest of a 20ms period, which should give me 1.8 million LED flashes. If the cheap LEDs survive 1.8 million unregulated flashes, I feel as though I can safely run the UV emitters without any current regulation. While the forward voltage of these LEDs is the same as that of the UV emitters, the current is about only one third of the UV LEDs’. The higher power UV LEDs, however, will have a PCB to sink heat into. To be safe, I’ve set the LEDs on a ceramic dish and left them run unattended. The LEDs definitely need to run unattended as the pulse intensity and rate are headache-inducing after just a couple of minutes.
The Next Day
Exactly 10 hours later, the LEDs are still fully functional and only slightly above the ambient temperature. These are very cheap LEDs and I’m not sure if that makes them more or less robust than a relatively expensive UV LED. I’m going to take the gamble and skip the constant current supply, keeping in mind that if things don’t go well then we will need to revise the design after the first prototype circuit boards have been assembled.
I ended up spending a couple of days reading technical journal publications and white papers trying to find what actually causes LEDs to fail, specifically UV emitters, and the research was fairly frustrating. The vast majority of literature on failure modes of LEDs and non-visible light emitters (IR and UV) are more focused on the entire lifecycle and degradation over tens of thousands of hours of usage. I’m more interested in the effects of doing bad things to the LED, like giving it too much current. It appears that LEDs are not particularly fussed about overvoltage, where most can handle significant ESD events in the forward direction but fail almost instantly if reverse biased. There are some mentions of overcurrent damaging the silicon through electromigration which is broadly classed under electrical overstress. I feel as though the short pulse duration and the extremely long period between pulses are going to be fine for this application. Even if my friend shoots 3000 BBs a day, which is a lot, we’re looking at around 2.04 seconds of total LED on time if his gun is slightly broken and the BB takes 680us to travel past the LEDs (I expect it will be under half this time). If he played one day per weekend, it’s just 106 seconds per year, or a bit under 18 minutes per decade of LED on time.
So this has quickly become an interesting engineering trade-off, for me at least. By not utilizing current limiting, we could be drastically reducing the expected lifetime of the UV emitters, but at the same time, a decade of use is only going to be 18 minutes of total on time for emitters rated for tens of thousands of hours of use. Furthermore, as the battery depletes and its voltage exponentially gets closer to the emitters’ forward voltage, the current draw of the LEDs will also drop off exponentially.
The next article should be a lot shorter as we look at the firmware for the project. We’ll be trying to capture the photogate response with a microcontroller interrupt. I’ve had some issues in the past with platform-specific bugs using the MBED online compiler platform that could affect this, if I run into any issues I’ll switch compiler as it’s not worth the development time on a one-off project to fight bugs in platform libraries.
Once we have the very basics of the firmware designed, we’ll be getting into capturing the schematic, PCB layout, and finally building and using the project!
There’s still lots of interesting decisions to be made, and the fun of the hardware design and testing to come. I hope you’ll continue following along as we continue the project build.