View Full Version : [Project] Large LED speed display & beam speed-traps

05-20-2009, 04:55 PM
My wife (who is into robotics and frequents this forum) suggested I post a request here. My company is organizing a motorsports event and we need someone to design and build some fairly basic custom speed-trap and display equipment. I know a little about this stuff (e.g. I have a pretty good idea about what the hardware cost looks like), but I lack the time, patience and experience to put together a working project in a reasonable amount of time.

For the display portion, we'll need a very large, bright-white 4-digit (XXX.X) display which can wirelessly receive the speed to display at a distance of about 1 mile (give or take a little, but some vehicles may exceed 200 MPH so they need plenty of time to see and recognize the display). Each digit needs to be around 36" tall. I'm assuming this will rely upon a bunch of those bright-white LED-cluster 12V bulbs (and I know they're not cheap). We also need to be able to physically remove (preferable), or at least disable (unplug or throw a switch) the last after-the-decimal digit (it's used during practice for calibration, but isn't needed during the actual event). The display should show dashes when no speed is being shown (to avoid startling somebody driving along at 200 MPH with a bright flash out of the corner of their eye...) and the dash-or-no-display mode should be controllable (a switch would be fine).

The beam portion should have a single pole-mounted emitter/receiver unit, and on the other side of the roadway will be a simple pole-mounted box-mirror reflector. I imagine the receiver would have some kind of LED to indicate alignment. A laser emitter is preferred. Two of these will be placed a short distance from each other on the route: the vehicle breaks the first beam, and then the time over the known distance between the beams determines the speed once the vehicle breaks the second beam.

I imagine the beams will simply transmit a make/break signal to some kind of controller on the display board, which would work out the speed and display it. I know that sort of thing should be trivial with a PIC or Parallax type of controller. However, we also either need something that can receive the signal on a PC and store the speed, or the controller itself needs to store up to 250 speeds an have some facility for dumping those values to PC over RS232 or USB. The distance between the beams needs to be programmable (inches, feet, centimeters, whatever). It would be nice if the controller could be powered down without losing memory.

One of my business partners is an accomplished welder and can fabricate some kind of stand for the numeric display, that's no problem.

All three parts need to run off 12V so we can power them with a car battery and some clips, as it will be installed at a remote location with no AC power available.

It seems like a pretty straightforward project to me, and maybe interesting and fun from the electronics side (I'm a programmer In Real Life, so I know how that goes). We're willing to pay somebody a fee for their time if the price is right. I'm in North Florida, so if you're in Florida, that makes things a lot easier. :)

Shoot me a PM if you're interested in talking about this more. Thanks!

05-20-2009, 07:13 PM
Hmm, I've built a drag system with a light tree from some high precision light sensors and lasers. Mine is for tuning 4-wheelers on the sand dunes on a 300' stretch so the top speed never gets above 90mph. I use a Windows application, record the reaction, 60 and 300 foot time and final MPH to a SQL database and graph the results. Despite all that the light tree itself is the best part. Funny that a bunch of flashlights connected to a Phidgets input board is the coolest part. :rolleyes:

Drag / light tree systems normally cost $10,000 (at least) and they are usually 1/4 mile long. I could see accomplishing it if the display was PC controlled with a connection to the internet, assuming the speed monitoring portion was connected as well. I dunno man. You're asking a community of guys that plug servo's together to help you set up what sounds like a pretty big affair. I'll PM you to talk about it a bit more.

05-20-2009, 07:30 PM
I sent you a message but I thought I'd post something I thought about. The Phidgets high precision light sensor has a poll rate (might actually be the controller board). Every X number of milliseconds it checks the status of the analog input to see what the value is. In my setup I mounted the sensors to a PVC pipe about 12 inches long to reduce any ambient light input. I then setup a laser 25-30 feet from it and aimed it at the sensor. When something interupted the beam I detected the voltage drop in my software and record the time.

The problem is I could actually move my hand fast enough to break the beam and miss the poll rate so the voltage would never drop on the sensor, at least not that could be detected using the .Net library. My hand is roughly 4 inches across and based on my meager pitching skill I estimated my hand moving at about 40 miles per hour. In my scenario a 4wheeler front tire is 21 inches in diameter, approximatley 5 times the size of my hand. If the 4wheeler were moving at (5 times the speed) 200 MPH I might see the same results from the sensor. About every other pass was missed. Since the fastest we'll get to on a 4wheeler in 300 feet is 90 MPH, our margin of error is decent and we seem to always fall within the poll rate. The beam is interupted long enough to detect it.

Yep, it's a drag bike so the best runs are around 92-ish, most are anywhere between 72 and 86 within 300 feet. A bit faster than your off the show room floor model for sure.

What I was thinking is hooking up a UV detector LED to the analog input on the Phidget board and see if the poll rate is from the board or from the sensor. Maybe someone at Trossen can answer that, or direct me to someone at Phidgets who can.

It's also not out of the question to use some other board and sensor setup, same principles but maybe another manufacturer can support better precision. 200 MPH is tough man. Any comments from other members?

05-20-2009, 07:52 PM
Saw your PM and replied. Accurate response is absolutely critical as there will be around 200 participants on-course and we won't have any opportunities to redo any given run. As I noted in the PM, I sort of vaguely imagined some analog process would respond to the beam receiver tripping, and that would wait around for the digital/transmission portion to actually do the polling (and a subsequent reset for the next trip).

But you're right, tires at the large end might be 20" in diameter, and at 200 MPH that'll clear the beam in something like 5ms if I'm doing the math correctly.

05-21-2009, 12:48 AM
This is directly related to my [somewhat unpopular] contention that Phidgets are too slow for some applications. Fortunately the OP hasn't limited this to Phidgets. Or to polling. :) With an AVR, running the numbers, 200khz on the interrupt should be pretty easy, and you only need the rising or falling edge of the interrupt.

200MPH ~= 90m/s (rounding up deliberately)

At 90m/s, I'd expect you would see at least 2000 interrupts per meter. So the vehicle MIGHT travel 1/2000th of a meter, a couple hundreths of an inch, before you got the signal. The code would need to be carefully realtime. If you did nothing but used an instruction to set a flag for later calculation by another controller, you might get as fast as 1/350,000th or 1/375,000th, but that's really just gettin' silly, IMHO.

Another design possibility would be the Propeller. It averages around 20MIPS without interrupts (80Mhz, 4 cycle instructions), "hard realtime". The cool thing there is that you have 8 cores ("cogs"), so you could offload time keeping to one core, dedicate another core for the make/break, another core for the display driving, etc. I'm not all that up on the architecture, but I suspect you could easily just burn through your instructions on one core looking at the the digital input pin continuously. 20 million times per second? [shrug] I'd have to read up more on the internal architecture, but if you could really get 20Mhz sampling from it, then we start running in to a speed of light limitation on the gun being the limiting factor, and worrying about the length of the wire feeding the system and about stray noise.

Anywho - the takeaway here is to avoid Phidgets in this instance - they're not the best tool for this job.

05-21-2009, 08:47 AM
Ooo Propeller...

05-21-2009, 10:32 AM
Adrenalynn, although your later observations make it an irrelevant point, Wolfram Alpha's calculations agree that 20 inches at 200 MPH will take just 5.6 ms:


In more detailed discussions with people working up estimates for us, since some competitors have been clocked at 225 MPH, we've been arbitrarily naming 250 MPH as our upper design limit. 20 inches at 250 MPH pushes it down to 4.5 ms... And in reality, I chose 20" as the best-case. Most vehicles we'll see have wheels in the 16 to 18 inch range... 16 inches at 250 MPH yields about 3.6 ms in the beam.

However, this all amounts to navel-gazing since we could easily just mount the beam higher and catch the whole body of the car. The cars will be widely separated (for the purposes of these calculations), so all we really need is to know the beam was broken.

Good point about the multicore Propeller... devilDroid, don't you have one of those upstairs? :)

To add something useful: given the simplicity of the signaling from the beam sensors, we've also kicked around eliminating the radio portion and just signaling the beam make/break over really, really long runs of CAT5, which we can get for about 10 cents a foot.

I should emphasize that competitors only get one run at this, so accuracy is critical. We can't have any missed reads...

05-21-2009, 02:59 PM
You're going to need to do the resistance calculations for signal loss on those "really long runs" - I suspect you'll find that voltage drop is unacceptable...

Just to be pedantic - I never trust conversion tools for important questions:

200MPH/60 = 3.333... MPM / 60 = .0555... MPS*5280 = 293.333... Feet/Sec
293.333 * 12 = 3520 inches/sec
39.3700787 inches / meter
3520 / 39.3700787 = 90.23920065 m/s

200MPH ~= 90.23920065m/s. See, I used Google to do my conversion above, and it had even more rounding errors than I do here. :tongue: (actually, I did this math using a 14 digit mantissa, I just was too lazy to type it all out. ;) ) So we're going to be precise here to a good 8 decimal places or so.

Ok, since my math seems to prove out pretty well, we have a place to start.

In one millisecond at 90.23920065m/s we'll travel:

1sec = 1000millisecond

90.23920065 / 1000 = 0.090238201 meters = 0.90238201cm = 9.0238201mm (about 0.3552685in) per millisecond

A 1 inch grate would break the beam almost 3x per millisecond, unless someone spots a hole in the math...

1/.3552685 = 2.814772489 times per millisecond, in fact. ;)

Reading the technical docs, we can sample the digital line in about 4 clocks at 80Mhz on a Parallax Propeller. (I understand it can be overclocked too, but we really don't need to...), so we can read the line at 80/4 = 20Mhz, or 20 million times per second, or 20,000,000/1000 = 20,000 times per millisecond. 20,000 * 2.814772489 = 56,295.44978

So ultimately, if we had a one inch target grate moving across the beam, we'd catch it 56,000 times in 1 second. Or, more practically, we could expect it to get detected in some margin of 1/56,000th of a second at 200MPH.

QED. Now someone check my math. :)

I think with any margin of error, 20Mhz is gonna get the job done, and for maximum accuracy we'd need to worry about the wavelength of the light we were using, and the length of the wire... Even if I'm off by a factor of ten, even 100, it still gets it done here...

05-21-2009, 05:31 PM
Excellent details Adrenalynn! I agree about the Phidgets being slow.

McGuireV10, if you're going with CAT5 take care in what you use to connect them up. I used solid core unshielded twisted pair and got some chatter from the RJ45 jacks. You were talking a mile to the display too, that'll be the tricky bit. Making it is easy, just drill some holes and mount some flashlights (albeit powerful flashlights) and wire the bulbs up to a digital out board. The big question is, how are you going to get the info down to the board from the track? RF? Anyone?

I think considering the stakes involved and our disparate locations (I'm in Oregon) I'll gracefully bow out of the offer McGuireV10. Good luck with the project. Sounds like fun!

05-21-2009, 07:07 PM
Like yourself, nb - I'm too far removed and have too many things to take an active role - just offering some advice.

High-power XBee, at the Datarates required, could reach out 25km or farther - it's probably an ideal choice.

Consider again the Prop, which I own one of but haven't written much code for:

Core 1: (I refuse to call them "cogs" - get over it... :tongue:) Timer
Core 2: Digital Writer/Reader [shared memory between Core 1 and Core 2]
Core 3: Output to LED Mux
Core 4: Pretty formater and serial communication to XBee.

I'm not sure what we'll do with the other half the chip. Time two lanes? :)

05-21-2009, 11:25 PM
If you need it faster remember the prop can be written in assembly. This will take some time off as well.

Lynn you got to call them cogs if anything the hub would be the core. Allot of the communication is already written in parallax's object exchange you just need to paste it all together. But some of these objects use more than one cog. I think the serial communication takes more than one. I'm not checking this but just saying. You think that 8 is enough but some applications need more. But you can always use two of the suckers.

I used their servo controller objected and made a walking engine based with video. I'm held up on the remote controller part and put it on the back burner.

The other thing is you can use cogs for different snippets of code. You stop them and run another piece of code on the cog. When thats done stop that and run another and so on so on.

05-22-2009, 01:20 AM
No - it's still a multicore MCU, "cogs" is marketing-speak... Each core has access to shared memory. Each is a full core, complete as far as "completion" of a limited function MCU goes. Yes, some possibilities require multiple cores to get the job done because of their complexity. 20MIPS is MORE than fast enough to bitbash serial if nothing else. If someone's crappy code doesn't do what you want to do, the beauty of being a programmer is: ya don't have to use it. ;)

05-22-2009, 07:34 AM
Sorry, but Adrenalynn, you're calculating meters per second, not milliseconds! (And for what it's worth I only used Alpha after the fact to see whether or not I needed to hang up my programmer hat.) Hit Google with "200 mph in meters per second" and you'll get back 89.9 or thereabouts. Metric conversion isn't really relevant here. We're talking about a point source... how long one point will be intersected by something 18" wide moving at 200 MPH, which is about 5.6 ms.

Yesterday I managed to get in touch with the guy who designed the system I saw out west. It was interesting to learn how this guy solved a vast array of real-world problems. Unfortunately he's reluctant to build another rig, or sell of those he has now (although he agreed to consider it).

His setup spaces the trap beams 132 feet apart because that's how they do timing at the Bonneville salt flats. The good part is this greatly relaxes the sensitivity to spacing between the traps, but the bad part is that a vehicle can vary speed by quite a bit over that distance.

Both traps are connected to a laptop via RS-485 serial. The PC stores the values, then performs and stores the speed calc, then uses a 900MHz transceiver to send the display value to the Parallax-based display controller.

Interestingly, since the sign board is always within line-of-sight, he has also used a cheap LED laser to transmit the speed to the display (he says at 1 mile the beam is roughly 5 feet wide so maintaining alignment is no problem). However, one event wanted to show the speeds at a spectator area in addition to the track-side display, so radio made that much easier.

I appreciate the input, everyone. I've contacted about six companies and individuals asking for quotes, and they're starting to roll in. Hopefully we'll find someone who can do this within our budget.

05-22-2009, 07:54 AM
Good point about the multicore Propeller... devilDroid, don't you have one of those upstairs? :)

You can't take Byte ME's (Byte Mech Electronix) brains! Besides, they haven't been purchased yet. I would have brought a request for it to the Budget Review Board, but I've been obsessed by sending b1tch3s airborne while skating in little circles...

05-22-2009, 11:34 AM
Oops, one little mistake: :oops:

90.23920065 / 1000 = 0.090238201 meters = 0.90238201cm = 9.0238201mm (about 0.3552685in) per millisecond
Should be 90.23920065 * 1000 = 90,239.20065m/ms = 902,392.0065cm/ms = 9,023,920.065mm/ms

That's why we shouldn't convert to something like mm/ms until the very bitter end. That's why it's so important to stick with standard units of measurement like m/sec, so we don't break anything like I stupidly did.

So - that said - we still get 20 million cycles/sec. Which means that a point source would still get detected two times per millimeter, or detected generally in 0.5mm, give or take whether it enters on the rising or falling edge of the clock.

05-23-2009, 08:58 AM
This project shall henceforth express units as angstroms per fortnight.

Connecting the traps to a PC makes a lot of sense for a lot of reasons. The PC can power the traps over the serial connection, and of course, recording the values is trivial. Required processing power on the signboard is significantly minimized to a receive-and-display function. In fact, we don't really need RF communication... an 8-wire CAT5 could be used to just signal an 8-bit number (0-255) to the controller. Since CAT5 is officially good for 10Mbps data to 3000 feet, a simple hi/lo 8-line signal should be able to run 4000+ feet with no significant problems. Although I suppose that overlooks the XXX.X format... go old-school and use wire A to indicate MSB/LSB and use an implied decimal, and that problem goes away...

The trick with the sensor hardware would be detecting the signal-break, noting the time-tick, then ignoring subsequent sensor trips until the PC got around to polling. Even RS-485's 10Mbps rate (at 4000') is still quite a bit slower than the sensor polling rate, so I suppose the PC would have to pull the signal-break time-tick and the current tick to eliminate the communications delay, and then you'd have to compensate for signal propagation delay between the sensor and PC, too. Hmm. Realtime is so much fun.

This is why we wanted to just pay somebody else to handle it. We have an event to organize... :happy:

05-23-2009, 10:41 AM
I think you're going the wrong way there, so I'll wish you luck with it and check back in regularly to see how it's going.

05-23-2009, 02:26 PM
I was (mostly) just mentioning what the existing system does. So far, excluding posting here, I've floated the project to three individual engineering types and four companies, and three have replied so far -- and all three of them are working along completely different lines. Then we have your thoughts and the existing system itself... and up to four more weighing in next week. It's certainly interesting to see such a variety of solutions, although it'll complicate the decision about which approach to use.