It isn't necessarily something that consistent, but when I put something through sensors that is clearly faster, the time may indicate otherwise. I will give that program a go, and will get back to you.
Alright, I gave that program a try, and I believe that I am getting a bit more what I should be for times, but I keep running into the problem where the pulsin pin is high, and not ready to accept the input. I am simply using a pole that I am swiping through the sensors, which, I know is not very scientific, but it is what I have to work with right now. Anyhow, is there any way I can keep that pulsin pin ready to accept the input?
The solution·will cost you another I/O pin·and a couple of diodes to "clear" the RS latch to a known state.
If the the PULSIN pin is not low when it gets checked then (instead of DEBUG)take an output pin·(Set_Arm)·HI then LO.· With the attached circuit,·the START_221 output·gets diode-OR'd with the·new output·pin = "S"_input.· So, one or the other can set it to the desired state as part of initialization.
Here is a twist on the project.· You might want to consider.......
If i wanted to know the speed of a vehicle I would hide one of these http://www.radarguns.com/·in a tree and send the read data from its lcd to my computer in the house.
I might even use certain read data to trigger a camara.
Sorry, my trigger is with NAND gates. Sorry I wasn't more clear. I suppose that changes things a little...
Anyhow, so this set_arm out goes into the SR latch, between the 221 one shot and the NAND gate SR latch? I know that the pulsout pin is low
before I run something through the sensors because I have an LED hooked up to the output of the latch in parallel with the input of the PULSIN pin. The
LED is off before I run something through the sensors, yet I am still getting the message that the pulsin pin is not ready.
Yes, that's not per plan.· I drew that with NOR gates way back when.
If it is with NAND gates then the R and S should be pulled up (so that they're guaranteed HI in their Remain-the-same state, the Not-Allowed state is 0 and 0.)
I've shown pretty clearly how the set-arm/clear should be implemented last reply.
I just started reading this and have a question
are all the cars going to be going in the same direction?
looking over the software it can only start with In1,
on which side of In1 is the pulsin pin 0 located
is this for a track ?
Ok I have another Question
with the circuit as is, he gets a Pos/Neg pulse, it holds this state until the second sensor is broken, then pulses back to the starting state?
Both sensors are high until tripped. When the first timer sensor is tripped, it places a pin high through a triggering circuit. When the second timing sensor is tripped, the pin is put back low.
Ok guys, I tried many options and really don't know where to go from here. I'm thinking I may go to IR for the sensors. In which case, I will need to create a separate circuit to modulate an emitter at a set frequency. Somthing like a crystal oscillator or a 555 timer. Also, I just keep getting erratic time readings. I was also thinking about not using the pulsin command, but using the count command and an oscillator circuit instead to calculate the speed. I could just buy some ready made sensors, but I really don't want to spend a lot of money on this. Any ideas?
Im trying to follow what your doing, I ran a quick test in spice and attached it. I overlapped one set of pulses to see what happened when they were both on and as long as the first one turned off first all worked well. there are two pages, attached together. does this look like what your trying to do?·
Post Edited (L_Gaminde) : 2/19/2009 6:16:22 PM GMT
rifleman4040 said...
Ok guys, I tried many options and really don't know where to go from here. I'm thinking I may go to IR for the sensors. In which case, I will need to create a separate circuit to modulate an emitter at a set frequency. Somthing like a crystal oscillator or a 555 timer. Also, I just keep getting erratic time readings. I was also thinking about not using the pulsin command, but using the count command and an oscillator circuit instead to calculate the speed. I could just buy some ready made sensors, but I really don't want to spend a lot of money on this. Any ideas?
Here is what I did to test my first speed trap years ago.
1 started by using IR led's and the IR receivers in the tin can both set at 40 khz ·· got it all working.
2 needed more distance tried lenses with LED's got it to work wanted more distance
3 switched to visable laser (levels) (cheep laser leval came with a little trypod) ·· installed a IR phototransistor ( that had visible light ability) in place of the modulated one in the 40khz tin can receiver it was no longer modulated.
4 all worked well, installed lenses so I could be·off by an Inch or so in pointing.·It is very hard to align IR·lasers· and receivers.
5 I ended up using a PIC chip with built in timer·that was set up to give me the resolution· I wanted ( or needed ) ·
What kind of lenses did you end up using? I am running into that problem as well. It is quite the pain to get everything lined up properly. I really like the distance that I can get out of the visable red laser, but I think I am running into to much ambient light "noise". I picked up some ir emitters/phototransistors, but they don't seem like they are going to give me near the range of the visable units.
1st off get yourself some 1 1/2" or 2" ABS tubing (black drain pipe) use about 6" lenth at your receiver, then mount the tin can module in a cap ( but don't glue it on) this will block lots of ambient light. The lenses I picked up at one of the surplus dealers, right now I see that WWW>Allelectronics.com has lenses. now if you use IR laser you will get the same distance as visable but again very hard to set up. I can get good results 100 feet plus. The lenses I used were arround 2" dia so using a rubber drain coupling ( the ones with the S Steel band arround them 2 x 1 1/2 is what I used to clamp the lense on the pipe.
Ok, here's another question for you guys. I tried the device in pretty much complete darkness, and still have the same results. Shouldn't the ambient light problem be solved by the dark room?
It is in the previous posts of this thread. I am getting erratic readings on the pulsout pin. If i run something that is clearly slower through the sensors, I may get a faster time, and visa versa.
are you getting readings when nothing goes through the sensors (this would be more like ambient noise)
your using the debug command does that mean there is a monitor running?
also rewrite your program to just sit and look at your input pin and make it loop and debug 0's if in a stable state and 1's if there is a change watch this program for a few minutes if you get a lot of random 0's and 1's then you have a noise problem
I don't know, I have an led hooked up on the output pin, and it seems to be operating normally then, but perhaps I should try it with the debug to see at actual logic levels. Thanks.
remember an led can be dimmed using pulses and it just looks dim. it will not look like on and off unless there is a off period that your eyes can preceive or brain or whatever.
Alright guys, I think I'm getting some consistency, but I had a bit of a time getting things to this point.
I set the laser/detector pairs up vertically so I could drop an object from the same height, and use that as a consistent trial for for the pulsin times. (The whole acceleration due to gravity thing). I was getting about 1% variance , so I figure that is pretty decent.
Now, I just need to figure out the math part of it. I have the equation to figure out the miles per hour from the pulsin times, but I really don't know how to put that into the
stamp. I tried the equation that was posted on the first page of this thread, but that doesn't seem to be right, as the figures are not very believable.
Is there also a way I could put in different numbers for the number of feet so that I could set up the sensors at different distances apart, to suit the needs. (IE, closer together for slow speeds, people, etc. and farther apart for vehicles at greater speeds). Something like a constant for the number of feet that I could change without changing all of the math coding. I just really don't know how to do the order of operations in stamp math, as was said in an earlier post that it just ignores the parenthesis and such. Would I just put each separate quantity for an order of operations in as a variable, and do things that way?
Comments
I've attached a slightly modified version of your program.· Tell me how it works out.
What are you using to simulate the vehicle, what's breaking the beams, something consistent?
The solution·will cost you another I/O pin·and a couple of diodes to "clear" the RS latch to a known state.
If the the PULSIN pin is not low when it gets checked then (instead of DEBUG)take an output pin·(Set_Arm)·HI then LO.· With the attached circuit,·the START_221 output·gets diode-OR'd with the·new output·pin = "S"_input.· So, one or the other can set it to the desired state as part of initialization.
Post Edit -- Since drawing the schematic with NAND gates, I've got that stuck on my brain.· (Why'd I do that?)
Post Edited (PJ Allen) : 2/11/2009 2:31:08 AM GMT
Here is a twist on the project.· You might want to consider.......
If i wanted to know the speed of a vehicle I would hide one of these http://www.radarguns.com/·in a tree and send the read data from its lcd to my computer in the house.
I might even use certain read data to trigger a camara.
hmmm
I might build it....
Randy C
Post Edit -- If you don't have any diodes, you could use the two remaining NOR gates.
Post Edited (PJ Allen) : 2/11/2009 3:51:57 AM GMT
Anyhow, so this set_arm out goes into the SR latch, between the 221 one shot and the NAND gate SR latch? I know that the pulsout pin is low
before I run something through the sensors because I have an LED hooked up to the output of the latch in parallel with the input of the PULSIN pin. The
LED is off before I run something through the sensors, yet I am still getting the message that the pulsin pin is not ready.
So, my conflicted state is actually 0 and 0.
If it is with NAND gates then the R and S should be pulled up (so that they're guaranteed HI in their Remain-the-same state, the Not-Allowed state is 0 and 0.)
I've shown pretty clearly how the set-arm/clear should be implemented last reply.
·
are all the cars going to be going in the same direction?
looking over the software it can only start with In1,
on which side of In1 is the pulsin pin 0 located
is this for a track ?
Ok I have another Question
with the circuit as is, he gets a Pos/Neg pulse, it holds this state until the second sensor is broken, then pulses back to the starting state?
Both sensors are high until tripped. When the first timer sensor is tripped, it places a pin high through a triggering circuit. When the second timing sensor is tripped, the pin is put back low.
Post Edited (L_Gaminde) : 2/19/2009 6:16:22 PM GMT
1 started by using IR led's and the IR receivers in the tin can both set at 40 khz
·· got it all working.
2 needed more distance tried lenses with LED's got it to work wanted more distance
3 switched to visable laser (levels) (cheep laser leval came with a little trypod)
·· installed a IR phototransistor ( that had visible light ability) in place of the modulated one in the 40khz tin can receiver it was no longer modulated.
4 all worked well, installed lenses so I could be·off by an Inch or so in pointing.·It is very hard to align IR·lasers· and receivers.
5 I ended up using a PIC chip with built in timer·that was set up to give me the
resolution· I wanted ( or needed )
·
Hope this helps
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=FB121-ND
I am hitting them with 650nm red lasers.
But I did pick up some of these to try.
emitter
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=LED55C-ND
And here are the phototransisors.
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=L14G1-ND
I got a few of each of these listed on the datasheet.
what made you come to this conclusion ?
we have no Idea what results your getting
your using the debug command does that mean there is a monitor running?
also rewrite your program to just sit and look at your input pin and make it loop and debug 0's if in a stable state and 1's if there is a change watch this program for a few minutes if you get a lot of random 0's and 1's then you have a noise problem
I don't know, I have an led hooked up on the output pin, and it seems to be operating normally then, but perhaps I should try it with the debug to see at actual logic levels. Thanks.
I set the laser/detector pairs up vertically so I could drop an object from the same height, and use that as a consistent trial for for the pulsin times. (The whole acceleration due to gravity thing). I was getting about 1% variance , so I figure that is pretty decent.
Now, I just need to figure out the math part of it. I have the equation to figure out the miles per hour from the pulsin times, but I really don't know how to put that into the
stamp. I tried the equation that was posted on the first page of this thread, but that doesn't seem to be right, as the figures are not very believable.
Is there also a way I could put in different numbers for the number of feet so that I could set up the sensors at different distances apart, to suit the needs. (IE, closer together for slow speeds, people, etc. and farther apart for vehicles at greater speeds). Something like a constant for the number of feet that I could change without changing all of the math coding. I just really don't know how to do the order of operations in stamp math, as was said in an earlier post that it just ignores the parenthesis and such. Would I just put each separate quantity for an order of operations in as a variable, and do things that way?