Searching \ for 'Fr. Tom: PICs and High Speed' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Fr. Tom: PICs and High Speed'.

Truncated match.
PICList Thread
'Fr. Tom: PICs and High Speed'
1998\06\19@013749 by Thomas McGahee

flavicon
face
----------
> From: Dominic Gualtieri <spam_OUTdgualtieriTakeThisOuTspamNETWORX.ON.CA>
> To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Subject: Re: Beginners question on increasing pic internal clock spee
> Date: Thursday, June 18, 1998 12:23 PM
>
Big SNIP
>
>   Okay here is why I am looking to get a 1nanosecond clock pulse. My
application
> is to measure the distance between 2 unknown points ( at most being 500-600
yards
> apart) using a two-way (round trip) ranging principle based on point source
radio
> systems. This is basically how I want it to work. Transceiver 1 transmits a
> signal(pulses), the signal is received at transceiver 2, and after a fixed
known
> delay , it is re-transmitted back to transceiver 1, is received by
transceiver
> 1`s receiver and input to a ranging circuit. The ranging circuit measures the
time
> difference between the original transmission time and the time of reception
(less
> the known fixed delay) , which would be a direct measure of the two-way
distance
> when multiplied by the speed of light.This is the problem, the speed of light
> travels at 186,000 miles per second.That translates into roughly 98,208,000
feet
> per second. For an accurate measurement I would need an oscillator( I guess
out of
> the question with a pic) that would supply my ranging circuit with a time
period
> that would translate into approximately 1nanosecond per foot. I would like to
use
> a PIC to do all the conversions( time to feet and/or yards) and drive an LCD
> display. Any help will be greatly appreciated.
>
> Dominic

OK, now we have enough facts that we can begin addressing the issues at hand!
First, the PIC can drive the LCD display and handle the input buttons and all
that foolishness quite readily. As to doing the actual conversions, well, that
depends in what is entailed with the conversions. Often times it is actually
much easier to handle the conversions with a dumb old stupid EPROM. Yep, a
stinky old EPROM can do the conversion in the time it takes to give it a stable
input code in the form of an address.

Take as an example a circuit that I built that determines how fast a person
can throw a baseball:

I had a woolen winter glove with a metal braid pad sewed on to the inner
part of the glove's thumb. The other fingers also had metal braid, and the
finger pads were all connected together. I used a baseball covered with
aluminum foil. When a person put on the glove and held the ball, the
combination
of the thumb and the foil covered ball and the fingers formed a closed
circuit. This acted as my "normally closed" START switch. When the person had
the
ball firmly in hand, I would hit a reset button. This cleared the counter and
the
display. When the ball was released an RS flip flop was activated and the
output
of a crystal oscillator was gated through and drove a 12 digit binary counter.
This counter continued to count until the ball hit the target, which was a
piece of cloth with heavy duty aluminum foil glued on. About 1/4" behind the
target's aluminum foil was a flat metal plate. When the ball hit it would
connect the aluminum foil to the metal plate and cause the RS FF mentioned
earlier to turn the gate signal OFF. The distance from where the ball was
thrown a known, fixed distance. The gated counter had accumulated a count
that increased with the amount of time it took for the ball to turn the
gated oscillator off. I had written a simple program in FoxPro that took the
info about clock rate, distance, mph conversions and all that stuff and then
prepared a binary file that contained the decoded info for each tick of the
clock. (I could have made this even smaller than I did, but the EPROMs were
dirt cheap, so I just coded them out for every possible time all the way down
to a single clock tick). I used FoxPro because I like it. I could have
used C or even Basic to prepare the EPROM binary files, but I guess that
each of us uses what they feel most comfortable with. And for me, its Foxpro.

I coded the EPROM into 4 banks. That allowed me to
handle 4 digits and a floating decimal point. I directly coded the 7 segment
plus decimal point info into the 8 output bits at each address. Bank 0
contained the LSB, and the other banks contained the other corresponding
digit info. For example, if a given address corresponded to 54.78 MPH, then
Bank 0 had the code for 8, bank 1 the code for 7, bank 3 the code for 4 AND
the right hand decimal point, and bank 4 had the code for 5. The two high
order bits of the EPROM was used to select which bank was being accessed. A
simple 2 bit binary counter driven by a signal from a lowly 555 timer set
the rate at wich the banks were changed. Transistors drove the digit selects
(from these same 2 bit counters). The 555 allowed control over the refresh
rate of the four 7 segment readouts.

This was an extremely simple circuit, and it did what it had to do quite
elegantly. If I had wanted to, I could have used a larger size EPROM and
used a switch to master bank select either a MPH or KPH readout.

Now, what YOU have to do is really quite similar. You want to send out a signal
and at that instant gate a crystal oscillator ON. You want the fastest
oscillator that your Logic circuits can handle. Now, the PIC can trigger this
circuit, or it can have it's own autonomous control. In any case, once the
circuit sends out the signal, it waits for reception of the return signal.
That reception triggers the end of the clock being gated on. It is now OFF.
The binary counter now has a static number and the EPROM sees this as its
address.
You can do like I did and have the EPROM decode the segments for you, or
you can just do away with the EPROM and somehow get the PIC to read the
binary address info and decode using al agorithm. Have fun! I find the EPROM
approach much better for most applications. If you want the output display to
be
LCD instead of LED, then consider having the PIC control the BANK addressing,
and store the digit codes in BCD. The PIC could then get the digits one at
a time by addressing the appropriate banks, convert the BCD to ASCII by ORing
0x30 with it, and then the PIC could send that to the LCD along with stuff
like whether that is in feet or meters, etc.

Don't expect the poor little PIC to do everything all by itself. Use high speed
counters and logic for the high speed part. Use any old EPROM for the
decoder part (I used a 128K part in my particular application). If you need
more digits of accuracy, then either use a larger EPROM or use two or more
EPROMS being fed with the same address. Each one's outputs would represent
different digits of the answer.

A PIC would work wonderfully as the central controller for such a system,
coordinating the user input and shuffling the data out to the LCD in a nicer
presentation than you could get with just plain 7 segment readouts.

Your biggest headache is going to be the high speed part. Use as high a
frequency
oscillator as you can get. If you are trying to measure 1 ns time intervals,
then at least a 1 GHz clock would be required. The first few stages of the
binary counter would have to be VERY high speed parts, but once you have
the signal past a few stages it will be within the range of fast TTL devices
to handle. So only a SMALL section of the counter chain has to be somewhat
esoteric and expensive. Buy only as much really high speed stuff as you
absolutely need.

The EPROMS need to be programmed to reflect the 'turn-around' time of the
returning signal. Because you are dealing with ns here, the turn-around
receiver/transmitter needs to be as high speed as possible. Strive for
something as simple as a detector and output amplifier. The main unit should
be capable of sending and receiving simultaneously. The first received pulse
should turn the counter off. Do not purposefully add any extra delay to the
remote receiver/transmitter. Strive for as instantaneous a resonse as you
can get.

I would begin by programming the decoder to assume NO delay at all from the
remote, other than that caused by separation distance. Then you implement
the machine, determine the error, and re-program the EPROM(s) with the
correction factor built in based on actual verified tests. This is the sanest
approach, as at first there will be too many unknown sources of signal
delay.

Also, don't attempt to send a code of some sort. It is enough to get an
'echo'. Many individual echos can help you get a more accurate result over
a period of time.

The PIC or other microcontroller might be able to take a series of readings
and average them after throwing away ones that are far different from the
others. This Olympic scoring approach of throwing out the high and low
readings and averaging the rest goes a long way towards removing certain
kinds of 'noise' from the system.

I hope that you have found this information useful in some way.
Fr. Tom McGahee

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...