[Engineering] – Bullet Flight Sensor, Design Validation Testing
Successful night at Tam Labs tonight!
Tonight, the goal was to test the breadboarded prototype of the bullet flight sensor’s electronics. Remember – I am a mechanical engineer; this is a completely new foray into the world of electronics for me, aside from some simple “hook a solid state relay to a microprocessor and bit bang some code to turn on the rice cooker” projects. So even though this may seem like kindergarden EE stuff, it’s a fairly big leap for me, design wise; I’m no longer relying on the ability to clobber code and instead using discrete logic ICs and doing actual calculations and setting RC time constants, etc.
We begin with the breadboarded model:
And our setup in the lab:
On the bench is a trusty oscilloscope to look at the signals at different lines, a DC power supply set to 5V, 100mA current limit, and a signal generator. The signal generator won’t be used for this project here.
First, I verified that the *new* sensor is working – the last one had a round put through it by accident:
Next, I verified that the 555IC is getting the power that it needs. Turns out that the power rails aren’t fully connected all the way. A bit of poking with an ohm-meter fixed that. Now I am ready to insert my test points:
And trip the break-beam sensor, with my gimpy fingers:
Orange line, or Ch1, is my sensor’s output. It goes from High to Low when the beam is broken. The turquoise line, or Ch2, is my 555’s trigger output. It goes from low to high when the input pulse is received. That’s a VERY promising sign.
My fat butter fingers can only move so fast through a 10mm opening, so the event scrolls off the oscilloscope’s screen. I tried dropping a small machine screw through the opening, but that actually prove to be much harder than expected (don’t laugh!). Frustrated, I finally came up with the following idea:
By flexing the rubber ducky antenna on one of my pocket wizards and getting it to spring through the break-beam sensor gap, I can generate a quick enough blip from the sensor:
Each major division is 5 milli-second on this setting, so the rubber ducky antenna is only in the beam’s path for about 10mS. My fingers can’t move *that* fast, for sure
Repeating the test again a few times, got me the same result:
Note that irregardless of the pulse length from the sensor, the 555’s output always sits at about 35ms. This is a litte bit off from the design goal of 40ms (1/250 second shutter speed, or sync speed on a 1.6x crop camera), but close enough for government work. I attribute the difference in component value tolerances on setting the RC constant.
Now the final test – does the output from the 555 trip the SCR to fire the strobe and pocket wizard?
(I selected an SCR instead of a cheaper / more common transistor. The SCR is rated to 400V, so even an older, high voltage “digital camera killer” flash will work on this sensor. )
*drum roll please*
Turns out the same bug that bit me on the 555 timer bit me again. The top and bottom half of the power bus on this breadboard is not connected, and the SCR wasn’t grounded properly because of that. Now, plugging in a pocket wizard, this is what I get (with Ch2 now monitoring the anode of the SCR):
Interesting, it seems to add a bit of noise to the sensor output line. But the characteristic beep of the PW firing can be heard as the beam is broken. (Note that the sync voltage of the pocket wizard is only 3V or so).
Plugging in the 580EXii:
Again, some electronic noise on the sensor line, but we got what we need out of it – the clean voltage drop that triggers the monostable multivibrator.
And here’s the happy camera dork with his new toy (click link for video:)
Now that the circuit is verified working, I am okay with releasing the resources to order the acrylic for laser cutting to form the chassis, as well as starting PCB layout. Stay tuned…