Page 2 of 2

Re: Current methods for using computer to detect events?

Posted: Sat Jan 22, 2011 10:27 am
by John Shreffler
Interesting experiment. I once made a simple model to demo a principle using reflective IR from ink patterns on a spinning white paper disc, so it is certainly possible to pick up the motion by light without disturbing the spin. However, since the final object is to translate your calculations into various points on a track, it would seem to me that directly measuring the ET to each of these points is simpler and more direct. Using the Judge chip with IR sensing 8 points along the track would certainly do this. But perhaps I don't understand completely.

Re: Current methods for using computer to detect events?

Posted: Sat Jan 22, 2011 10:45 am
by Stan Pope
John Shreffler wrote:However, since the final object is to translate your calculations into various points on a track, it would seem to me that directly measuring the ET to each of these points is simpler and more direct. Using the Judge chip with IR sensing 8 points along the track would certainly do this. But perhaps I don't understand completely.
There are several reasons for the direction chosen.

One reason "noise" in the data. On-track testing has too many uncontrolled variables. The process described removes a lot of those variables, and should eliminate almost all of the noise.

Another reason is to minimize the preparation of test cases. At its simplest, one wheel/axle per treatment. If redundancy is needed, then two or three per treatment.

Yet another is to avoid waiting for track abailability to perform the measurements. The gear goes "from closet to running" by opening the closet door!

A lesser concern (but a concern none-the-less) is retrieval of the test materials. I don't have any rug rats left at home to bring the cars back. With the apparatus, I can sit on my shop stool and let 'em rip!

I think that I was waiting for something like the arduino with its comprehensive software support to come along. It has the PIC, the communications hardware, USB drivers, a C-like compiler for the PIC program, Integrated Development Environment (IDE), that allows guys like me to do meaningful stuff with the electronics. The hardware is arriving and the programming is underway.

Re: Current methods for using computer to detect events?

Posted: Sat Jan 22, 2011 3:34 pm
by Stan Pope
The rest of the Arduino "stuff" arrived in today's post. I got the IDE installed on two machines and the driver installed on the laptop. The Arduino passes the initial tests, so at least I know it isn't DOA.

By 9pm the circuitry attached to Arduino is responding to changes in light intensity and reporting the time of the change up to the laptop!

Next is to get it programmed to run the planned experiments, to select a photodiode / LED sensitivity to work in the experimental environment, to construct a housing and hardwire the few components, and to fix a start switch for the ring.

The data collection will not be an issue ... the IDE includes a nice data collection function that i can copy/paste the series of data for each case into a spreadsheet or text file!

Less work than I expected!

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 7:46 am
by Duane
John Shreffler wrote:How many events are you looking at? If it is not over 8, you could use The Judge processor, and put the results into Excel, where you could compute deltas automatically. If interested, I could send you a chip.
I'm also very interested in getting or building a high-res timer for 3-4 sensors at low cost. I want to build or buy a timing track, but have limited room. With 3 sensors along the flat section of track, I think I could extrapolate the rate of slowing to predict the virtual total time for a full-length track. And understand more about air drag versus other effects. The ramp section of track may perhaps also be steeper or less high than in a standard full size track.

Do the connections between the IR receivers and the timer gadget (arduino, or Judge, or ...) have limits on how far apart they can be? I expect 20-30 feet separations between the 1st and last sensor.

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 8:36 am
by John Shreffler
The impedance is a bit on the high side for sending things that far. I would certainly suggest twisting the wires, or perhaps going to a thin coax like RG174.

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 9:03 am
by Stan Pope
John Shreffler wrote:The impedance is a bit on the high side for sending things that far. I would certainly suggest twisting the wires, or perhaps going to a thin coax like RG174.
Is this a good application for CAT-5 Ethernet cable? It already contains four twisted pairs of wires, all neatly color coded, and stock crimp-on connector for the "business end" of the cable. The sensors could either be "daisy chained" with connectors and off-the-shelf patch cables, or a single length of cable coud be carefully opened to expose just the needed pair at each sensor station.

For one willing to "really get into it", an IR transmitter from each sensor down to the recording point is feasible, though power to the sensor stations still needs to be provided.

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 9:16 am
by John Shreffler
That is worth a try. I will always remember one customer setting up his track for testing in his barn. We spent days trying to figure out why nothing was working. Then finally, he said it all worked when he turned off his heater. It was some kind of propane burner that was continually ignited by a clicking spark plug. Marconi would have loved it. :mrgreen:

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 12:16 pm
by dna1990
Stan Pope wrote:I think that I was waiting for something like the arduino with its comprehensive software support to come along. It has the PIC, the communications hardware, USB drivers, a C-like compiler for the PIC program, Integrated Development Environment (IDE), that allows guys like me to do meaningful stuff with the electronics. The hardware is arriving and the programming is underway.
Yes, I believe Arduino was made for you Stan. It is now a whole host of physical experiments waiting to be re-performed and compared to theory calcs, all with new precision and repeatability. Well hopefully :unsure: .

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 1:11 pm
by Duane
Stan Pope wrote:
John Shreffler wrote:The impedance is a bit on the high side for sending things that far. I would certainly suggest twisting the wires, or perhaps going to a thin coax like RG174.
Is this a good application for CAT-5 Ethernet cable? It already contains four twisted pairs of wires, all neatly color coded, and stock crimp-on connector for the "business end" of the cable. The sensors could either be "daisy chained" with connectors and off-the-shelf patch cables, or a single length of cable coud be carefully opened to expose just the needed pair at each sensor station.
How about the telephone home wiring stuff with multiple twisted pairs inside? Would that have a better or worse match (than CAT-5) with the needs of a timer chip talking to its IR receivers? Are the IR parts sending continuous light via DC levels, or 30Khz blinks like is common with household remotes?

Another alternative to sending LED and IR detector currents many feet away, is to give each sensor station its own cheap Arduino board, and use a USB hub to connect them all to the laptop in a star config. Or one board per pair of sensor stations.

Before discovering about arduinos etc last night, I was looking at USB interface gadgets that turn 8 or so independent direct I/O pins into packets on the USB bus. But to get the IR sensor sampled at Khz rates, the USB has to be running in its fastest modes and the laptop & Windows would be quite busy responding to interrupts badly. Having a smart chip at the sensor which sends a packet only when a light<-->dark transition has happened is clearly better.

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 10:30 pm
by Duane
Duane wrote:Are the IR parts sending continuous light via DC levels, or 30Khz blinks like is common with household remotes?
In Scholten's schematic, the sensor LEDs are unswitched, running on DC, and so their light is continuous, without a "carrier wave" pulse train. Very simple! The firmware is listening for a single high-->low transition on the input pin wired to the sensor's photo transistor. The passage of a car gives a shadow lasting about a 12th of a second. So the wiring between controller and sensors is basically DC. Using twisted pairs (of any kind) between controller and distant photo transistors is likely all that is needed to reject minor EMI. Adding de-bounce logic to the firmware could help reject some noise, but I won't bother for my needs. I think putting a single controller near the midpoint of the chain of sensors will be fine. Then the laptop can be close enough to that single controller to use a single usb cable without extension.

The rate of polling the sensor input pins could be improved by running a smaller inner loop with minimal I/O steps (for max inner repeats of say 100 times each) when waiting for cars to arrive.

Re: Current methods for using computer to detect events?

Posted: Wed Jan 26, 2011 11:20 pm
by Stan Pope
Duane wrote:How about the telephone home wiring stuff with multiple twisted pairs inside? Would that have a better or worse match (than CAT-5) with the needs of a timer chip.
CAT-5 (about $20/100 ft, with end connectors) handles gigabit/second ethernet at 100 ft separation so it is certainly possible to transfer our slower data on it successfully. I think that exceeds the capabilities of the phone systems "twisted pairs."

I tossed out the IR just to tease the techies in the forum ... Since we need to run power to the several sensor locations, we may as well run signal wires, too. However ... I'm sure that a dedicated techie can find a reason why only IR (or something even "techier") will do!