Large LED speed display & beam speed-traps

[Quantum]

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.

[Adrenalynn]

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.

[McGuireV10]

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.

[devilDroid]

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...

[Adrenalynn]

Oops, one little mistake: ops:

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.

[McGuireV10]

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...

[Adrenalynn]

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.

[McGuireV10]

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.