Shop OBEX P1 Docs P2 Docs Learn Events
Basic Stamp Speed Trap — Parallax Forums

Basic Stamp Speed Trap

rifleman4040rifleman4040 Posts: 28
edited 2009-03-11 03:48 in BASIC Stamp
Hello everyone. I was thinking about constructing a speed trap with the basic stamp to check the speed of motor vehicles. It would be constructed along the lines of using 2 laser modules paired with photo detectors(would this be the right component?). The laser/photo detector pairs would be placed an exact measured distance apart. From the time the vehicle broke the first beam to when the time the vehicle broke the second beam could then be measured, and then the exact speed could be calculated. Now, I have a few questions if I may.

Would the PULSIN command be the direction I should go with this?

What sensor should I use for the laser? I was thinking about using a visible light red laser for aiming purposes.

The BSII can power a laser module, because the laser is nothing more than a diode, right (5mW laser) ?

Any help/suggestions/advice would be greatly appreciated.

Thanks a lot.

·
«1

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-06-20 04:38
    See this thread for hardware suggestions.

    -Phil
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-21 05:52
    Ok, I have the hardware portion, I think. Anyone give me an idea about the programming side of the house? I know I could do a counter with a 1ms pause, and have that loop between the two sensor activations, but I think I can be more accurate than that using something like the PULSIN command, but I don't know how to use it with two different sensors. Anyone point me in the right direction?
  • kelvin jameskelvin james Posts: 531
    edited 2008-06-21 16:49
    A 555 timer ic would work as a fairly accurate stopwatch. The first laser would activate the 555 set at say 10khz (1/10 sec) and the stamp would count the pulses until the second laser turns it off. Lots of info and circuits on the web.
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-22 03:01
    Hey, thanks for the help guys. That is a good idea, but I can use a loop with the basic stamp as follows:

    DO
    LOOP UNTIL IN3 = 0

    DO
    PAUSE 1
    LOOP UNTIL IN4 = 0

    LOOP


    With this I can be accurate to the millisecond, right? So, it would be more accurate than with the 555 timer setup. With the PULSIN command, I should be able to get down to 2us increments I thought, so could be even more accurate.·Thanks again for your help guys, but still lookin for info on the PULSIN command being used to tell me the time between pulses between two sensors.


    ·
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-06-22 03:23
    rifleman4040 said...
    With this I can be accurate to the millisecond, right?
    No. The looping mechanism itself takes time, which gets added to the 1ms PAUSE. Moreover, the initial DO:LOOP has overhead as well, which adds to the uncertainty of the start time. Plus, you will need some sort of counter incrementing in the second loop to track how much time has passed.

    Now, all of that said, the second loop is deterministic and can be calibrated, leaving only the indeterminacy of the first loop to deal with. The farther apart you place your two lasers, the less of an effect this will have on the accuracy of your system.

    You are right about being more accurate than a 555 timer, though. The Stamp timing is controlled by a resonator, which is far more accurate — and less temperature-sensitive — than the RC timing of a 555. This is especially critical when you're working outdoors.

    -Phil
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-22 08:09
    OK.

    So, you told me why it won't work, and that was my best shot at it. So, what would be the most accurate way to make it work?

    I need that initial do loop to continually monitor the first sensor to start the time, don't I? If not, how can I work around this?

    I would like to know if and how I can use the PULSIN command can be used to measure the time between the high to low change of state between two separate pins.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2008-06-22 13:09
    Asssuming the detectors go HI when activated --

    speed_counts  var  word
     
    Trigger:
      IF IN0 = 0 THEN Trigger
     
    Estimate:
      IF IN1 = 1 THEN Done
     
      speed_counts = speed_counts + 1
      ' PAUSE __ ?
      GOTO Estimate
     
    Done:
      DEBUG DEC speed_counts
    

    You haven't noted·the distance between·these detectors nor the range of speeds involved.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2008-06-22 13:27
    Since you're buying some "detectors", you might as well add a quad NOR I.C. to the Bill of Materials.· The output of this circuit would be the pulse to be measured with PULSIN:

    start_stop_speed.jpg

    Post Edit -- sp.

    Post Edited (PJ Allen) : 6/22/2008 4:35:39 PM GMT
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-22 16:07
    The speeds involved would be probably 50 - 200 MPH. I think placing the detectors about 10 feet apart would be sufficient. Why the blank after the pause, wouldn't it just be 1 to give the most precise results? Would that program be any better as far as the "lag" is concerned than what I have? I already have the detectors which are fiber optic visible laser detectors and I'm using a pair of visible red laser modules (the setup seems to be up and running as I want it to). Just need to get the program down. You guys are great, and thanks a lot for the diagram PJ, I just might do that when I can get the NOR gate. That I image would be THE way to do it. Thanks again guys.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2008-06-22 16:47
    If you're trying to go with some internal counting scheme, you'll have to come up with a way to figure counts/increments vs. execution speed.· That's not going to yield the accuracy you seem to be striving for.· Better get the NOR gate I.C. (they're less than $1.)

    Post Edit --
    In PBASIC Help we read:
    Quick Facts
    attachment.php?attachmentid=73641

    PULSIN will wait for the desired pulse, for up to the maximum pulse width it can measure, shown in the table above. If it sees the desired pulse it measures the time until the end of the pulse and stores the result in Variable. If it never sees the start of the pulse, or the pulse is too long (greater than the Maximum Pulse Width shown above), PULSIN "times out" and store 0 in Variable. This operation keeps your program from locking-up should the desired pulse never occur.

    __________________

    It won't wait indefinitely for a PULSIN cycle to occur.· So, I would have a leading trigger (another detector), IF·trigger_pin = 1 THEN GOTO PULSIN routine.

    Post Post Edit -- I think that you will have to·situate your detectors closer together, given the 131.07ms max pulse time limitation.· (A car travelling at 50mph·will transit 10 ft. in ____ sec.)

    Post Edited (PJ Allen) : 6/22/2008 5:24:19 PM GMT
    549 x 133 - 7K
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-23 05:59
    So you are saying a THIRD detector laser pair, or just use the first detector to start the PULSIN routine as you listed in your previous post.

    Another thing that gets me, is if that the detectors are much closer together, they may both be activated at the same time depending on the length of the vehicle. You see, both detectors are HIGH when the beams are on, when the speed trap is set. When the beams are broken, the detectors give a low to the pins. So, will that "restricted combination" cause problems for the setup? Or, would the STAMP mind having two lows for the pulsin command (KEEP STATE) until the HIGH LOW combination could be given?

    Isn't there a way to extend the time the PULSOUT can measure by increasing the timeout time?
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2008-06-23 12:17
    *** You might want to investigate the increment accumulation method; set that up with a one-shot pulse generator and see how that goes, accumulator counts vs. time (35msec gives me __ counts, 50msec gives me __, and so on).· Maybe it's fairly linear and you can "back-calculate" (interpret) those results.· I cannot predict those results, but that's·how I'd find out. ***

    It seems to me that since the PULSIN event/cycle·has to begin within 130msec of the command then you need a detector ahead of the timing pair to tell the Stamp, "Hey, get ready, here it comes!"

    The "time-out" time is fixed, there's no programming it differently.

    A·possible "restricted state" conflict.· True.· The solution would be to run each detector output into a non-retriggerable one-shot, and then to the SR Latch (the circuit diagram.) When the detector becomes active, it would trigger the one-shot, which would emit a pulse (very brief, a tick, 1usec) which would·"tap" the latch and would be unable to do so again till the detector went inactive.

    50 mph, 10 ft. transit = 137msec (out of range)
    200 mph, 10ft. transit = 34msec

    Post Edit -- I didn't know what your detector inactive state was/is.· I showed an SR Latch with NOR gates and·its restricted state is 1 & 1.· An SR Latch can also be made with NAND gates and·its restricted state is·0 & 0.· "Wiki" that.· [noparse][[/noparse]RS, SR, 6 of the one, a half dozen of the other.]

    Here's an excellent (dual)·non-retriggerable one-shot -- http://media.digikey.com/pdf/Data%20Sheets/Fairchild%20PDFs/MM74HC221A.pdf·
    It has Q and /Q outputs (for a HI-going pulse or a LO-going pulse, respectively.)

    Post Edited (PJ Allen) : 6/23/2008 1:29:35 PM GMT
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-24 15:10
    Great, I'm moving forward with this, and I got the latch to work, and the PULSIN command to work with it as well. Thanks a lot for all the help. It is greatly appreciated. I'll try to keep you guys posted with the results, if interested.
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-25 03:45
    Okay, any Basic Stamp math wiz's out there? This is the equation to compute MPH from the count from the PULSIN command. Now, the equation is this

    15
    __________

    t (.000002)
    _____________________ = MPH

    11

    Where "t" equals the PULSIN count. Is there any reasonable way to program this into the stamp,
    or where would it just be better to do the calculations myself after the time is recorded by the device?

    Post Edited (rifleman4040) : 6/25/2008 5:01:18 AM GMT
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-06-25 04:26
    Could you put that equation on one line, please (using * and /)? I can't make heads or tails of it in that form.

    Thanks,
    Phil
  • rifleman4040rifleman4040 Posts: 28
    edited 2008-06-25 04:58
    15 / ( t * .000002) / 11 = MPH

    So, it is 15 divided by the quantity t * .000002 , and then all of that divided by 11 to equal miles per hour. Someone can check my math if they like. Basically, I'm placing the detectors 2 feet apart, as this will be more than enough space between them with 2us intervals. So, I took 2ft / t(.000002) * 3600 / 5280, and simplified it as much as I could. Again, "t" is my PULSIN count, and MPH is miles per hour. Basically, I want the program to put my PULSIN count into that equation to display MPH. You think you can actually put that into the BS II and get accurate results?
  • Tracy AllenTracy Allen Posts: 6,662
    edited 2008-06-25 15:54
    Yes, the conversion from feet per second to mph is
    mph = fps * 0.6818

    And since the detectors are 2 feet apart and the count is in units of 2 microseconds, that becomes,
    mph = 68180 / t ' t from BS2 COUNT command

    You said you expect a speed range of 50 to 200 mph, so t will range from 1363*2 uS down to 340*2 uS.

    But 68180 is too large a number for the Stamp. Here are a couple of formulae that adjust the magnitude so it will fit:
    mph = (6818 / t  * 10) + (6818 // t * 10 + (t/2) / t)
      DEBUG ? mph   ' in units of whole mph
    



    or
    mph = (34090 / t * 10) + (34090 // t * 10 + (t/2) / t) * 2
      DEBUG DEC mph/10, ".", DEC1 mph    ' units of 0.2 mph
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-08 00:14
    Ok, it's been a long while, and now I've picked up this project again. You guys all know how you get busy with other things, and this stuff gets pushed aside. Anyhow, i have the three detectors set up with a one shot running into an SR latch, but I'm getting weird readings for pulsin times. I've put pull down/up resistors in on the inputs to try to get more precise readings, but no dice. Anyone have any ideas?
  • MrBi11MrBi11 Posts: 117
    edited 2009-02-08 00:52
    I know it's a different approach than the start/stop beams but maybe looking into interfacing with something like this.

    If you could tap into it, get the distance change in a preset time you could effectively create a 'handheld' unit to do the same thing.

    It would be really cool to build it into it's existing housing, maybe put new electronics in battery compartment, and power it externally.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Smile ... It increases your face value!

    Post Edited (MrBi11) : 2/8/2009 12:59:13 AM GMT
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2009-02-08 01:54
    rifleman,

    Weird readings...?

    Sketch out a schematic and post that and upload your program as an attachment and we can talk.
    ·
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-08 02:25
    Ok, thanks. I know I need to provide much more information. By weird, i mean that they are erratic. When I put an object through the sensors at roughly the same speed, i get large difference in values of the pulsin variable. I can try to post a schematic. What would be the easiest and quickest way to create and post a schematic? If this is any help, I will provide part numbers to the digital IC's that I am using for the trigger circuit.



    http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-9187-5-ND Monostable Multivibrator

    http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=MM74HC00N-ND Quad 2-input NAND Gate, used for SR latch to use one pin for pulsin



    The one shot is placed on each input of the SR latch.

    Here is the basic program.

    ' {$STAMP BS2}
    ' {$PBASIC 2.0}

    t VAR Word
    mph VAR Word

    SPEED_TRAP:

    Trigger:
    IF IN1 = 0 THEN Main
    GOTO Trigger

    Main :
    PULSIN 0, 1, t

    IF t = 0 THEN Trigger

    mph = (34090 / t * 10) + (34090 // t * 10 + (t/2) / t) * 2
    DEBUG CR, DEC mph/10, ".", DEC1 mph, " MPH" ' units of 0.2 mph

    GOTO Trigger
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2009-02-08 02:42
    With regard to schematics, the easiest means for me is to draw it out on a sheet of paper then run that through·my flatbed scanner.
    Otherwise, get busy with good ol' MS Paint (which can take a while.)

    For the time being, I'd just DEBUG the PULSIN time results and worry about the mph calc later.

    N.B. -- You are aware that PBASIC doesn't·process parentheses, order of·operations,·etc. like in algebra class, right?··It just processes in order, left to right,·without regard to bracketing.· It lets you place them, alright, but it ignores them just the same.·
    So, writing
    mph = (34090 / t * 10) + (34090 // t * 10 + (t/2) / t) * 2
    works out as:
    mph = 34090 / t * 10 + 34090 // t * 10 + t / 2 / t * 2

    Post Edit -- The BS2 does, in fact, handle parentheses, but the BS1 does not.


    Post Edited (PJ Allen) : 3/11/2009 1:51:20 PM GMT
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-08 02:47
    Alright, thanks a lot info, I'm not very good at Stamp math. Anyhow, when I was running it, I did have the calculations commented out and was just debugging the pulsin times, but was just getting irregular results. I was getting large discrepancies in time with approximately the same speed through the sensors.
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-10 17:48
    Here is the diagram.
  • Carl HayesCarl Hayes Posts: 841
    edited 2009-02-10 21:27
    kelvin james said...
    A 555 timer ic would work as a fairly accurate stopwatch. The first laser would activate the 555 set at say 10khz (1/10 sec) and the stamp would count the pulses until the second laser turns it off. Lots of info and circuits on the web.
    Why not let the 555 run all the time.· Start counting when the first beam is interrupted, and stop when the second beam is interrupted.· No need for additional hardware/software for stopping and starting the 555.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · -- Carl, nn5i@arrl.net
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-10 21:47
    Isn't 10khz 10,000 cycles per second, thus 1/10000 of a second? Anyhow, that is an interesting way to do it, but how accurate can a 555 timer be? I figured that the pulsin· method may be the most accurate, but maybe that route won't work and I may have to pursue different options such as this.
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2009-02-10 23:45
    What is the value of the caps used as "C_ext" with the 221s?· That should be a very brief pulse.

    Reading back, there was also the matter of the extra (3rd) sensor which would prompt the Stamp·for an imminent·"pulsin event" (remember the "130msec rule").
    634 x 420 - 97K
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-10 23:53
    Yep, I just run that third "here it comes" sensor right into a pin and use that to start the trigger program. The triggering circuit is working, as I have an LED hooked up to the output of the SR latch to ensure it is functioning. Don't remember off hand what the value of the caps is, I can check that tonight. Anyhow, I believe that part of the circuit is working. That timing diagram looks about what I should have, or at least what I am after. Oh, and I did not mention, forgive the rought diagram. Anything else?
  • PJAllenPJAllen Banned Posts: 5,065
    edited 2009-02-11 00:11
    You could put in a DEBUG to print the state of "Q", that is, to know that it is·LO/0·("ready") to begin with.· Please·upload, as an attachment,·the program that you are using.
    780 x 712 - 148K
  • rifleman4040rifleman4040 Posts: 28
    edited 2009-02-11 00:13
    The caps are .001uF, which should give me about a 1.5us output pulse from the 221. I wanted the smallest pulse that would reliably trigger the SR latch and not possibly result in a conflicted state if both timing sensors are tripped overlapping low.

    Here is the basic program for the trigger circuit.

    And I was getting pulsin times, they were just erratic.

    Post Edited (rifleman4040) : 2/11/2009 12:21:54 AM GMT
Sign In or Register to comment.