Searching \ for '[PIC] PIC18F-timing using lasers' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'PIC18F-timing using lasers'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC18F-timing using lasers'
2007\05\26@173932 by Rikard Bosnjakovic

picon face
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.

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.

- Rikard -

2007\05\26@184617 by Jinx

face picon face
> 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

picon face
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
- 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)


Rikard Bosnjakovic wrote:
{Quote hidden}

2007\05\27@055500 by Jinx

face picon face
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

picon face

Hi Jinx
See comments below

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

face picon face
> [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...