Exact match. Not showing close matches.
PICList
Thread
'[PIC] PIC18F-timing using lasers'
2007\05\26@173932
by
Rikard Bosnjakovic
|
A friend of mine sent me an inquiry about something that's a bit over
my head (at the moment), so I'm forwarding his mail to this list to
see if anyone here has any pointers where I could start dig and help
him out.
-------[cut]----------
Let me tell you what i am trying to do:
The idea is that we have 2 laser beams that will form together a radar
system that will calculate a car's speed.
A car will be travelling down a road and 2 laser beams will be in
front of the car. The PIC should start counting when the car passes
through the first laser and should stop counting at the time the car
passes through the 2nd one. We will do the circuits with the lasers,
so for the programming issue we can assume that we have 2 pins (2
inputs) that will have the 2 laser beams connected. So when PORTA goes
to 1 logic we should start counting and when PORTB goes to 1 we should
stop couting the time.
Then , knowing the time and the distance between the 2 lasers, we can
calculate the car's speed.
In theory it is just a clock but it needs to be able to count time
very accurately. We were thinking to add an external clock to make it
more sensitive. We need to be able to count down to 0.0001 sec.
The speed should be multiplexed and diplay on an LCD display with 1 or
2 decimals - 52.3(2) km/h
This is all :)
We don't really need to use an 18FXXX but someone suggested that those
have USB ports (?!?) and we can then connect it to a laptop and
enhance the app with a Visual Basic interface.
However, the main goal for me at this point is to learn to do a
project or two with those so that i can get started... So i am
interested in someone that can make this project and explain it to me.
It doesn't really matter how it is done, but i would like to be able
to see it working in some simulations or to be able to have some
schematics for it. This is why i tried using MPLAB because it seems to
be the most complex app out there.
-------[cut]----------
--
- Rikard - http://bos.hack.org/cv/
2007\05\26@184617
by
Jinx
> In theory it is just a clock but it needs to be able to count time
> very accurately. We were thinking to add an external clock to
> make it more sensitive. We need to be able to count down to
> 0.0001 sec
Example :
100.0kph => 27.7778 m/s => 2.7778mm per 0.0001s (100us)
100.1kph => 27.8055 m/s => 2.7805mm per 0.0001s
If the timing lasers were 10m apart, using 0.0001s resolution
10m @ 100.0kph = 0.3599s
10m @ 100.1kph = 0.3596s
0.0003s difference => 3 * 100us
So you'd be able to differentiate between 100.0 and 100.1, but
it's very close at 10m and 100us slice
Using a 40MHz 18F you've got a 250ns time slice, or 400 times
finer than 100us. An external clock will not be necessary. CCP
module would be the way to go
If all went well, using 250ns (0.00000025s) resolution
10m @ 100.0kph = 0.36000000s
10m @ 100.1kph = 0.35964035s
0.00035965s difference => 1439 * 250ns
Putting the lasers further apart would help, however, finer resolution
and longer connections brings its own problems
Propagation (wire time, sensors reaction time etc) of signals from lasers
to the PIC for example, but they can be calculated and factored out.
Micro-fluctuations in speed, maybe not so important or even avoidable
With a good set-up under controlled conditions, you should be able
to do speed measurement quite well. At 100m you could add another
kph decimal place with some confidence
2007\05\27@051954
by
Nicola Perotto
|
Hi rikard,
you can use any pic with at least 2 ccp, in capture mode:
- start Timer1 (without prescaler)
- setup CCP modules in Capture mode
- setup interrupt enabled for CCP events
wait
- when the first laser got interrupted you have an interrupt and you
must save the "captured" timer1
- wait the second laser...
now the difference from the two captured values is the time the car
needed to pass the lasers.
Be aware that timer can overflow! (problem only for slow speeds)
The resolution of timer1 is 1/4 of main clock (es: 8MHz -> 500ns), using
the capture mode you minimize the counting error...
Note also that some photodetector are quite slow (rise time in order of
500 ns)
Nic
Rikard Bosnjakovic wrote:
{Quote hidden}> A friend of mine sent me an inquiry about something that's a bit over
> my head (at the moment), so I'm forwarding his mail to this list to
> see if anyone here has any pointers where I could start dig and help
> him out.
>
>
> -------[cut]----------
> Let me tell you what i am trying to do:
>
> The idea is that we have 2 laser beams that will form together a radar
> system that will calculate a car's speed.
>
> A car will be travelling down a road and 2 laser beams will be in
> front of the car. The PIC should start counting when the car passes
> through the first laser and should stop counting at the time the car
> passes through the 2nd one. We will do the circuits with the lasers,
> so for the programming issue we can assume that we have 2 pins (2
> inputs) that will have the 2 laser beams connected. So when PORTA goes
> to 1 logic we should start counting and when PORTB goes to 1 we should
> stop couting the time.
>
> Then , knowing the time and the distance between the 2 lasers, we can
> calculate the car's speed.
>
> In theory it is just a clock but it needs to be able to count time
> very accurately. We were thinking to add an external clock to make it
> more sensitive. We need to be able to count down to 0.0001 sec.
>
> The speed should be multiplexed and diplay on an LCD display with 1 or
> 2 decimals - 52.3(2) km/h
>
> This is all :)
>
> We don't really need to use an 18FXXX but someone suggested that those
> have USB ports (?!?) and we can then connect it to a laptop and
> enhance the app with a Visual Basic interface.
>
> However, the main goal for me at this point is to learn to do a
> project or two with those so that i can get started... So i am
> interested in someone that can make this project and explain it to me.
> It doesn't really matter how it is done, but i would like to be able
> to see it working in some simulations or to be able to have some
> schematics for it. This is why i tried using MPLAB because it seems to
> be the most complex app out there.
> -------[cut]----------
>
>
>
2007\05\27@055500
by
Jinx
I wrote,
> Using a 40MHz 18F you've got a 250ns time slice
Think I left my brains in bed. 100ns. Which is even better, eh
2007\05\29@131750
by
Phillip Coiner
Hi Jinx
See comments below
Phillip
Things should be as simple as possible but no simpler
Phillip Coiner
CTO, GPS Source, Inc.
Your source for quality GNSS Networking Solutions and Design Services, Now!
{Original Message removed}
2007\05\29@184630
by
Jinx
> [Phillip says] Seems to me that if the propagation time for each sensor
> was the same/equal i.e. the sensors were made with the same type
> devices and you used the same amount of wire etc. the propagation
> time would not matter because you only care about the difference
That's quite true. As you say though, the trick will be to balance the
whole thing. For example, if one wire is passing over damp or wet
grass and one is over asphalt. It would be fairly easy to match a pair
of sensors with a 'scope or logic analyser, or at least characterise them
Have fun. I'm thinking of a little project myself to add a digital readout
for the speedo in an older car, but I'll be doing that on a wheel or the
transmission, not carring a laser jig around
More... (looser matching)
- Last day of these posts
- In 2007
, 2008 only
- Today
- New search...