Margin of Victory camera

Status
Not open for further replies.

Magnethead494

Well-known member
For a multimedia project, I want to build a simple MOV camera to take to the track. I want to make a laser tripwire using a standard laser pointer and an LDR inside a tube. This tripwire is read by an mcu, which then puts a 5V circuit to the camera as the remote trigger by toggling a 2N2222 on the ground side of the trigger circuit. The camera is prefocused and pre-zoomed, so it shoots on the rising edge.

http://chdk.wikia.com/wiki/USB_Remote

The plan was to use an uno that I already have, and run it on 3 D cells, or a lantern battery with a 5V LDR. But I was told that there's a good chance that the 16MHz CPU speed would not catch a car breaking the beam at 160+MPH (I'm doing ideal calculations at 300MPH and realistic at 160MPH) on a reliable basis, and told that The Due would be better, but that the T3 might be able to do what I want.

By my figure, 1/16M is 6.25 x 10^(-8) and 1/48M is 2.083 x 10^(-8) of a second.

If the sensor is 3mm across, at 300 MPH (way over ballpark here) then that is 2.23 x 10^(-5) of a second ( 3 / 134,112 ). That's 1,073 cycles at 48MHz and 358 cycles at 16MHz.

Is that enough cycles to register the breaking of the beam?


I need to get the LDR, the hard part will be setting up the voltage divider to simulate a digital IO to activate an ISR. From what I've read, a sample unit can be anything from 2M to 200K unlit by laser, and 100-200 with the laser on it. So I just have to make a voltage divider to make a 0.7 (low) and 3.0 (high) volt output on the actual numbers.

My camera's Field of View is about 60 degrees at 5mm/28mm/f2.8 so I have a slightly narrow window to work with. My next battle is where to place the laser tripwire.

If I place the tripwire 30 feet before the camera, and assume the total reaction time from beam break to shutter is 1/10 of a second,

60 MPH: 88 ft/s = (30 - 8.8 ft ) / 88 = 0.24 s
90 MPH: 132 ft/s = (30 - 13.2 ft ) / 132 = 0.13 s
120 MPH: 176 ft/s = (30 - 17.6 ft ) / 176 = 0.07 s
160 MPH: 234 ft/s = (30 - 23.4 ft ) / 234 = 0.03 s
200 MPH: 293 ft/s = (30 - 29.3 ft ) / 293 = 0.002 s

that's the amount of offset delay required for a constant trigger position. In other words, 30 feet away would be perfect for pro-mods and fuel altereds, but the closer the car, the closer I need the tripwire to the camera. What I want to do is find a happy medium so that I get a shot somewhere near the finish line, before/after is fine for the most part (I'm going for close, not exact).

Each lane is 25 feet wide or so, so figure a 60 degree FOV, focused on the midstripe plus a 5 foot back-distance, makes a 30/60/90 triangle with a 30 foot long leg, and by trig, the short leg is 15 feet. So I have a 30 foot total viewing window to get within, 15 feet before the finish line and 15 feet after.

Based on that table above, I am going to want to bias the laser closer to the camera.

60 MPH: 88 ft/s = (18 - 8.8 ft ) / 88 = 0.10 s
90 MPH: 132 ft/s = (18 - 13.2 ft ) / 132 = 0.036 s
120 MPH: 176 ft/s = (18 - 17.6 ft ) / 176 = 0.002 s
160 MPH: 234 ft/s = (18 - 23.4 ft ) / 234 = - 0.023 s
200 MPH: 293 ft/s = (18 - 29.3 ft ) / 293 = - 0.038 s

So around 18 feet is a good starting point. Lots of trial and error will be involved.

But the big thing- is 48MHz enough? Or do I really need to go to a Due to capture a reliable beam-break?
 
Well, if you use attachInterrupt() on AVR or ARM, the change in voltage from low to high, or high to low, is captured by digital circuitry. Then the interrupt response begins several cycles later. I believe the hardware in either chip requires a pulse at least a couple cycles long, so in theory a 48 MHz chip can capture a shorter pulse than a 16 MHz.

On AVR, everything in the chip (except USB) generally runs from the same 16 MHz clock. On ARM, typically the peripherals run from different clocks than the CPU core. On Teensy 3.0, most peripherals run from the bus clock, which is 48 MHz when the core runs at either 96 or 48 MHz. I don't know exactly how the SAM3X chip on Due is configured, but it's probably something similar.

In terms of the application, I must confess I don't fully understand what you're trying to do, even after reading your message a few times. It seems like you're detecting the passage of a car and triggering the shutter of a camera. If there's only 1 sensor, why use a microcontroller at all? (as someone who sells microcontroller boards, perhaps I shouldn't ask that.....) Does the microcontroller actually DO anything, besides just detect the signal change and transmit a pulse to the camera? Does it do anything more than basically act as a piece of wire?

Or if the only need for a microcontroller is a delay from the sensor pulse to the camera trigger pulse, yes a microcontroller is easier to program to specific delays than tuning the resistor on a 555-based timer circuit. But really, my question is what function does the microcontroller actually do? It is just a fixed delay from detecting a sensor pulse to sending a camera shutter pulse? If there's something more to this application, I've not understood what it could be?

I must confess, I also don't quite understand the need for extremely fast response speed. At 293 feet/sec (200 MPH), an 8 foot long car will interrupt the beam for 27.3 ms. That's milliseconds, not microseconds or nanoseconds. I suppose this goes back to the fact I don't really know what you're actually doing.... but if the only function is a fixed delay before you send a shutter pulse to a camera, why does it matter if you can respond in 62 ns or 21 ns. Even if your response time on the microcontroller is 1 us, if all you're doing is adding extra delay before sending a pulse, why not just subtract 1 us from the delay?

These extremely brief times, in the dozens of nanoseconds, are incredibly short. They're far less than the mechanical accuracy of camera shutter. In fact, the speed of light (in a vacuum) is just under 1 foot per nanosecond. Just to put the difference between 62 and 21 ns into perspective, the infra light doesn't even travel across the 25 foot wide track during 1 cycle on Teensy 3.0.

Something else I noticed is you mentioned using an LDR sensor, which I'm guessing is Cadmium Sulfide photocell? Have you checked its response time? CdS photocells are usually very slow. In fact, they're so slow that I suspect you'll need to find a better sensor to even detect a 200 MPH car going by. Phototransistors are usually better, but still not anywhere near the incredibly fast response times you've mentioned. I'm not an expert in optical sensors, but my brief experience is you generally need a PIN photodiode for higher bandwidth detection. PIN photodiodes can be tricky to use they're sensitive to electromagnetic interference, but they are very common in sensor modules like IR remote receivers (where the 38 kHz filter is integrated into the package) and IR data interfaces like IRDA. I'm not sure if even PIN diodes can achieve the incredibly fast detection times you've mentioned? Does any optical sensor that has response times in the 25 to 100 ns range?

Maybe if you explain this project a bit more, and in particular what functionality the microcontroller actually implements, I might be able to respond better?

Perhaps others here will recognize what you're attempting and have useful advice?

Oh, and of course, yes, you should definitely buy a Teensy board..... ;) Seriously though, some conversation about the project is probably best.
 
Last edited:
Your assumptions are close.

1. I'm assuming worst case, IE, something very small triggering the beam. Realistically, it will be at least a 2" OD roll bar, at most, it will be the body of a car. But I'm working with a worst-case scenario.

2. The camera auto-shutters when 5 volts is supplied to the USB port, on the rising edge.

3. the Mcu is to convert the change of voltage due to the LDR into a transistor trigger to complete the 5 volt circuit to fire the shutter. [I suppose I could also put the LDR on the base lead of the transistor, technically, and forget the mcu]

4. I'm blind in this sector, I just know that laser-LDR trip wires are easiest to setup and debug.

5. If I use a photodiode, how can I use it without using an mcu? By just putting it between the 5 volt supply and base of the transistor, with a pulldown resistor?

By my figure, 1/16M is 6.25 x 10^(-8) and 1/48M is 2.083 x 10^(-8) of a second.

If the sensor is 3mm across, and a 2" OD roll bar breaks the beam at 300 MPH (way over ballpark here) then that is 3.78 x 10^(-4) of a second ( 2 inches / 5280 inches per second ). That's 18,181 cycles at 48MHz and 6060 cycles at 16MHz.
 
Last edited:
Here's what I came up based on this -> http://www.absorblearning.com/media/attachment.action?quick=14u&att=2929

Except that this will enable the transistor when the sensor is lit, and I need the opposite, to trigger then it goes dark (laser beam is blocked). So would I want to use a PNP transistor on the positive line instead?

Screenshot2012-12-29at22601AM.png
 
Last edited:
Either Teensy 2.0 or 3.0 is plenty fast enough to detect the pulse.

The big challenge is making a sensor fast enough to detect such a quick beam interruption. I have not personally designed a PIN diode sector circuit, so I can't help much more than merely pointing you towards the type of sensors that might be fast enough. At least you can avoid the pain of building it with a CdS photocell that's much too slow.
 
This is the only 'red' photodiode that I see in stock- http://www.mouser.com/ProductDetail...=sGAEpiMZZMtWNtIk7yMEsUiFQt45oKERrPXUCpv3W/Q=

Figure 5 of the datasheet shows how to use it in a 3 wire interface. But google doesn't return much for the part number, and I don't know enough about op-amps or anything to know how to put it into a switch circuit...

The output is high when lit and low when unlit [triggered], so I should be able to put it to the base of PNP triggering the hot side of the USB remote lead, and not need an mcu at all?

Screenshot2012-12-29at81515PM.png


Screenshot2012-12-29at81524PM.png
 
Last edited:
Look at the frequency response specs on page 2 of the datasheet.

http://www.ti.com/litv/sbbs002a

Rise time 28 us, overload recovery 50 us... probably fast enough for this application, but in the context of response speed of even 16 MHz AVR, fairly slow.

I noticed that, but I dont know what to really compare it to.

the 2" OD roll bar at 300MPH was 0.000378 of a second actuation time, 50us response time is 0.000050, a 7.5:1 ratio. Slow relative to the task, but I think it would work? I figure I can put a capacitor in the circuit to keep the USB high long enough for the camera to detect the rising edge, if I have issues with it tripping faster than the camera can detect.
 
Yes, flipping the whole thing and using a PNP would make one line 'NEG' and the other line will go low when the light turns off. However you will need another pulldown resistor on the output to GND -- basically when the PNP turns off, it will stop pulling the line high, but won't actively pull it low. The resistance you need depends on the load the camera presents -- but without knowing more about your system, I'd start with something between 1k an 10k. Any general purpose PNP would work -- e.g. 2N3906. If you aren't careful, a short circuit on the output when the laser is on may damage (overheat) the transistor. You might want to put 100 ohm in series with it.

-- edit -- reading your needs, it seems you need a rising edge (0 to ~ 5 V) when the light turns off -- so, you can still use an NPN like you have -- just add a ~ 1kohm pullup R in series with your POS output and join it to your NEG output. Now that junction will be low whenever the laser is on, and high (i.e. ~ battery level) whenever the laser is off.

I agree with Paul -- a CdS photoresistor will have delays in the millisecond range (although it's better under high light than low levels) -- more than anything else here. What delays does the camera shutter have ? milliseconds also ?
 
Like this?

The 3 pin header represents the output of the TI photodiode as shown. (Second drawing is for a raw-part reference. The TI chip is a little more complicated than a simple photodiode)

I don't have a way to measure how quick the camera's reaction time is, I figure I'll set the jig up and test it, adjust, test, adjust, test...and when it's where I want it, measure the distance and call that the general calibration setting. Figure I'll start around 18 feet and see what that gets me.

Screenshot2012-12-29at81524PM.png


Screenshot2012-12-30at125736AM.png


Screenshot2012-12-30at125859AM.png
 
Last edited:
Status
Not open for further replies.
Back
Top