---------- > From: Dominic Gualtieri > To: PICLIST@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