Calculating the speed of an object

Anything easy is probably going to include two photo sensors. Whether feeding them into a PLC is the best answer is debatable, but there are certainly worse ways (I'm sure there are folks here who could do it with a big analog meter and a few 12AX7's).

This is an obvious subject for a home-built thingie. I would assume that any dad who's remotely interested in electronics would have considered this, which means that it should be well-covered in hobbiest magazines. There should be designs from the '50s (with that meter and those 12AX7's) through today, with only the technology changing.

Do a web search on "pinewood derby timer" and see what you get:

I'm not that old, though -- Heathkit died one or two years after I got a checking account (but not before I got a full house radio control set from them), and tubes were out of fashion long before I reached an age to be a professional.

Got $60, a juice can, and a soldering iron? How about radar, from my favorite kit company since Heathkit died.

Se I'm old too,Tim. 12AX7's, Heathkit....

Hello Tom,

There is (was?) a way to do with with stuff you have at home, I just don't remember where the software came from: A good USB camera and an image processor software that can recognize patterns, find where the pattern moved to on consecutive scans and calculate the distance. Then you'd just have to convert that to speed based on the number of milliseconds there are between takes.

Of course, then there is good old Doppler but that would require some electronics on the car.

I never built one, but I did design and build an order-of-finish detector. There were red/yellow/green lights above each of three tracks. (Model railroad stuff). The winner lit up green; second place, yellow; third place, red.

My first gizmo with an LCD readout timed rifle bullets by noting the the interval between shadows cast on a pair of photocells six inches apart. No processor, but plenty of hardwired logic. The readout was in feet per second and no, I didn't use a hardware divider. Can anyone guess what I did instead?

Jerry

Joerg wrote in news:nLiQg.3500$ snipped-for-privacy@newssvr11.news.prodigy.com:

You could just put a 3-D accelerometer on the car, filter a bit, and sample fast. Micromachining techniques bring us very small and inexpensive accelerometer packages with a fine response down to DC

Hello Jerry,

Since you mentioned logic, maybe an ECL counter running full throttle? I'd probably have done it in analog fashion with a ramp followed by a gate and then a cheap meter like the $2.99 digital multi-meters from Harborfreight.

It was all digital. A 10 MHz crystal running a counter gave all the precision one could want. Consider: the sensors were nearly 6" apart. (As far as practical in a 6" construction box.) At the outlandish bullet speed of 5,000 feet/sec, that's 100 microseconds from sensor to sensor. At 10 MHz, that's 1000 counts. We used LS-TTL and CMOS for everything but the analog photocell circuits.

All right: now we know the time for the fixed distance. My question was, how did we convert that to speed (= distance/time) without doing arithmetic? Any takers?

Jerry

P.S. I did this at the request of my technician, who was an avid hunter and reloader. His title had been wireman before he became my technician.

I laid out the functions that the gizmo needed to do -- a block diagram with brief text descriptions of each block's function -- and he did the circuit details with little help. Then he built it. It worked.

Hello Jerry,

I am afraid you are going label this a sledge hammer method:

Since 1000 counts are 10 bits I'd probably have taken an EPROM from a discarded computer and poured a LUT into it. Pretty much any old EPROM of 8k or more could be used here. If you need more than 256 speed levels it'll take two EPROMs, or one EPROM plus a little "poor man's logic".

...

When this was built, the biggest available and reasonably priced PROM was 512 bytes. 1000 counts was the approximate accumulation for 5000 feet per second. Typical bullets are about a fifth if that at the muzzle and slower yet at 100 Yards, information that the gizmo was intended to collect. (There was a plate of 7/16" steel in front of it in case the shooter missed.) The main counter was long enough to measure down to 200 ft/sec, but the analog differentiator needed a longer time constant for such low speeds. The counts to be converted ranged from about 1000 to

25 times that; too many for brute force even today. Finesse was needed.

Jerry

Having counted n counts during the passage of the bullet, you latch this and feed it to the preload inputs of a down counter (could even be the same counter). Set this running at the original clock speed, reloading with n every time it hits zero, and you have a divide by n counter. Clock (or clock enable) another counter with this divided signal for a fixed period of time and this count will give you the frequency (1/n). Select a suitable time for the run of this counter and you can scale the count value read out to be fps (0.5s for 6" between measurement points).

Andy McC

Exactly so.

There's another cute trick for converting a binary number to BCD for display. Can you get that one also?

If you don't already know it, you might be delighted to learn about a BRM; binary rate multiplier. (There also BCDRMs, but they have more jitter.) When a number N is loaded into an n-bit BRM, it's output frequency is the input frequency times N/2^n. Each transition occurs on an input clock, so there is some jitter. By running the system with a

1024x clock and dividing the output by 1024, the jitter can be made insignificant. You can play a lot of tricks with them, including guiding 2-axis tables along arbitrary straight lines. (A better tool for that is a DDA; digital differential analyzer. It consists of two registers and an adder. With DDAs, one can also guide the table along circles.)

Jerry