Overlapping I/O

wclark

Forgive me if these have been covered already. I tried searching this forum but found nothing relevant.

I am new to the Basic Stamp and have been reading everything I can find. The project we are working on is an automated start system for timing auto races on a road where the start and finish are a few miles apart. We use a twisted pair wire for communications and have for years simply had a person at start shout GO into a mic and worker with a headphone at finish press a button on a timer (which was stopped by an electric eye when the car crossed the finish). We want to upgrade this to to an automated start and trigger that includes a sequenced start light, a DTMF tone upon start that will be detected by the finish timing system and an electric eye sensing an early start and lighting a light.

The questions I havent been able to resolve regarding applying the Basic Stamp to this are:

Can the Stamp pull one Output line low to current sink a relay at the same time as another Output asserts a DTMFout? They may be held on for different times but need to be able to begin at nearly the same time.

While doing the countdown will it also be able to detect an input from our "electric eye" early start detector and at some point (either immediately when detected or shortly after the start) latch on another output while not changing anything about countdown or the DTMFout which still need to go on as normal?

Thanks.

Post Edited (wclark) : 10/10/2009 2:50:23 PM GMT

Marz Krishna

I would say you could easily sync the start time on the basic stamps using a cell call to a person at the finish line,(speaker phone), the easiest way to trigger the stamp at the finish line would be to use an array ping sensors hanging maybe 10 feet above the ground, since they only have a range of 3 meters. The only other way to trigger it would be to use an image sensor, but seeing that the basic stamp only has 26bytes of user ram and running and interpreter, the basic stamp is to slow to send image sensor data to a ram chip and calculate whether the blur it picks up is a car fast enough for practical use(seeing that you would need a really long signal cable that would be a whole different bag of problems). a better bet would be to use the propeller demo board with the cmu cam(image sensor/digital camera) because you would have enough ram to hold the video stream(15 frames a sec i think), and 8 other cores and 32k ram to process the video. Of course this might require some fancy coding or maybe even asm instead of the spin language depending on how much 'motion' noise is in the background that has to be filtered out(people moving etc.). It may be possible you use they hydra system with it's ethernet expansion to trigger a hydra at the finishing line to start counting the time. At the recieving end you're either going to need a Pingsensor-camera setup or a camera(image sensor)-camera setup. the hardest parts would be writing internet drivers, writing the object detection for the finishline, and writing a video recorder to record video(unless you're going to amplify the signal from the object detection and use it to trigger a regular camera from a distance). There may be better ways to do. This is just somthing to get you in a good direction.

SRLM

It depends on how accurate you want the timing. The BS2 can only do one thing at a time, but it can do them (relatively) fast. In addition, in this application you should be able to make the program deterministic (at the start) so that you can time how long the code takes to execute, and it will take the same amount of time every time (which you can then add in to the total time).

As for the early eye, it should be accurate to within a few milliseconds. Since you only need the early eye before the race begins, then you are only asking the BS2 to do one thing at a time (count down to start while watching the eye).

I don't think you need the Propeller or a camera for this application.

wclark

Thanks for the reply Marz. I guess I wasnt all that clear in a couple areas. The format for the racing is "time trial" where one car at a time proceeds up the hill so we have no need to improve on our simple "electric eye". We know who is crossing the start and finish lines. What we are doing is eliminating the potential timing inconsistency that using a human Starter, a call to the Finish to start run time and a manual start button at the timing desk (which is at the finish line). The timing system at finish is software based on a laptop, works great and all we want to do there is change the manual start button out for a DTMF decoder to start the time.

At the Start line we will be sequencing up to 3 lights a little like drag racing. After an automated countdown (flashing light) the GO light will come on to start the competitor and at the same time a DTMF tone will be sent to Finish to begin the time measurement. We will have an electric eye at start to sense anyone starting early (right now that is done by human observation and can be subjective). Any early start will light another light and may send a different DTMF tone to Finish which will inform the timing to add a 10 second penalty to the run time. The run is not disqualified just penalized.

So before we pull the trigger on the Basic Stamp (thinking BS2-IC at this point) and start developing on it I need to understand that the controller will be able to do at least 2 of these thing at a time. If I can assert one output line for a second and have another output line generate a half second long DTMF tone beginning at the same time, and if the controller will be able to accept a trigger input indicating an early start while continuing the countdown lights before it gets to the DTMS output and our GO assertion, then it is a great choice for us. If however it will only permit one output at a time to be controlled, or it will ignore an input (or abort a sequence to service it) while doing another task then it is not going to work for us.

Edit: Thanks as well SRLM. I was writing rest of this reply while you were contributing and missed it until now. I have an option for the issue of needing to do 2 things at once. I have already created a breadboard DTMF generator that will generate a fixed duration output with a ground input of any length. I was hoping not to need to use it given the DTMFout capability on the micro controller as it just adds another bit of hardware that can fail. To use this I can simply trigger the DTMF generator off the output that controls the relay for the GO light. I made this up initially before any investigation of micro controllers began here on the assumption that the controller we chose would not have a DTMF simulation. Turns out this one does but as I now understand it we may not be able to take advantage of it.

Post Edited (wclark) : 10/10/2009 7:59:58 PM GMT

Mike Green

The Stamps can only do one thing at a time as was noted. Some actions can be overlapped since the Stamp can make an I/O pin high or low and it will remain that way until changed. For controlling servos, a control pulse lasts maybe as much as 2.5ms, but the next (repeated) control pulse isn't needed for another 17.5ms and a lot can be done in that time.

In your case, you could turn on the LEDs which would take only a few milliseconds and produce the DTMF tone (using FREQOUT) for a 1/2 second, then go back to finish the LED sequence. Similarly, the Stamp could be checking the "early start" signal while it's sequencing the LEDs since most of the sequencing involves waiting until the next change should occur. What the Stamp can't do is check an input while it's actually making the DTMF tone or change an LED during the 1/2 second while the FREQOUT statement is executing.

wclark

That is terrific. Thanks Mike. Being able to leave the lights (binary outputs) in a state and do other things while the timers count to the next change makes this controller very doable for us. During the period we will be sending the DTMF tone, nothing else needs to happen as far as we know now so I can go back to planing on using that capability instead of the external DTMF generator.