Searching \ for 'Software implemented phase lock loops' 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/index.htm?key=software+implemented
Search entire site for: 'Software implemented phase lock loops'.

Truncated match.
PICList Thread
'Software implemented phase lock loops'
1998\07\23@190207 by Dominic Gualtieri

flavicon
face
I was wondering If anybody on the list knows how to make a phase lock
loop using a
Pic. Thanx in advance.

Dominic

1998\07\24@084220 by Peter L. Peres

picon face
On Fri, 24 Jul 1998, Dominic Gualtieri wrote:

> I was wondering If anybody on the list knows how to make a phase lock
> loop using a
> Pic. Thanx in advance.
>
> Dominic

This issue is complex, and leads to very individual solutions.

For a starting point, think of a software loop that can vary its run time
and can check an input pin on every loop pass and measure the number of
times it sees a '1' and a '0' at this point.

Peter


'Software implemented phase lock loops'
1998\08\17@122719 by marc
flavicon
face
Hi Dominic (Dominic Gualtieri), in <spam_OUT35B82191.E2748CF3TakeThisOuTspamnetworx.on.ca> on Jul 24 y
ou wrote:

> I was wondering If anybody on the list knows how to make a phase lock
> loop using a
> Pic. Thanx in advance.

Something I've done on an AVR S1200 (I've combined it with 3-to-1 majority
receiver).  It's a simple DPLL that can be done in a _very_ few lines of
code:


Read the comparator output regularily, ie 7x per bit interval.  You then
get 7 readings per bit.

0011111 1100000
....... .......
  ^       ^

The marked location ^ is the received bit.

After determining the received bit, you scan the 7 slices for bit changes.
In the above example there are some, so you are not in sync with the
sender.

To adjust your phase, insert an 8th slice, or drop one (only 6) for the
next bit interval:

0011111 1100000 00111111 10000000 1111111 0000000
....... ....... ........ ........ ....... .......
  ^       ^        ^        ^       ^       ^- no bit changes -> 7
normal   normal  8 sl.     8 sl.  no bit change -> 7 slices

As you can easily see, at the end you're in perfect sync with the sender.

1998\08\17@161421 by Mike Keitz

picon face
On Mon, 17 Aug 1998 14:09:25 CET Marc Heuler <.....marcKILLspamspam@spam@aargh.franken.de>
writes:
>Hi Dominic (Dominic Gualtieri), in <35B82191.E2748CF3spamKILLspamnetworx.on.ca>
>on Jul 24 you wrote:
>
>> I was wondering If anybody on the list knows how to make a phase
>lock
>> loop using a
>> Pic. Thanx in advance.
>
>Something I've done on an AVR S1200 (I've combined it with 3-to-1
>majority
>receiver).  It's a simple DPLL that can be done in a _very_ few lines
>of
>code:

First realize that there is no general solution that is ideal for all
cases.  You need to consider the type of signal that the PLL will lock to
in order to optimize it.

Here's a method I've used in several projects to receive NRZ data sent
over radio.  In this case, the receiver had a good idea of the exact data
rate, since both the transmitter and receiver are using crystal clocks.
Also in this case, there is a relatively long time (100 bits or so)
alotted to acquire synchronization.   These factors allow the phase
adjustments to not be too severe in order to keep the bit timing from
being thrown way off during signal noise or fading.

The simplest implementation, which is still quite effective, takes two
samples during each bit time.  One sample is at the nominal center of the
bit, and is used for the data output.  The other sample is taken 1/2 bit
time later, at the nominal end of each bit and it is used for
synchronization.  Ordinarily the samples will be taken at a rate that
corresponds to the rate expected from the transmitter.  In other words,
no long term adjustments to the frequency are made, but the sample clock
phase may be adjusted for each bit.  One way to do that in software is
just to write a loop that always takes exactly the right number of cycles
to execute, but has a provision to add or drop a cycle or two as needed.

After taking each center sample, the PLL algorithm looks at the last 3
samples (Center of last bit, end of last bit, center of this bit).  There
are 8 possible combinations which are classified into one of the
following four cases.  By xoring a few bits together, it is possible to
determine the case simply.

Case 1: 000 or 111 -- This bit is the same as the last bit, since there
is no edge there's no information about the clock.  So continue sampling
at the nominal rate.

Case 2: 001 or 110 -- The end of bit sample was taken closer to the
center of the last bit than to this bit.  So the clock phase should be
adjusted to take the next sample later, i.e. lag the clock.  The amount
of lag determines the response time fo the PLL.  Usually about 1/32 to
1/64 bit time is good.

Case 3: 011 or 100 -- This is the opposite of case 2.  The clock needs to
lead, take the next sample sooner.

Case 4: 010 or 101 -- In normal data, this shouldn't happen.  Either the
data is noisy, or the clock is exactly 180 degrees out of phase.  I like
to handle this the same as Case 1, so if it's just that the end of bit
sample is bad, the clock won't be thrown off.  It could also be handled
as a lead or lag in order to get out of a 180 degree out of phase
situation quickly.

In operation, two bits of the same value are Case 1, where any transition
is a Case 2 or 3.  The phase adjusts until approximately half of the
transistions lead and half lag, causing the average data rate to be exact
and the end of bit sample to land between bits all of the time.  If the
two crystals do differ in frequency, somewhat more leading or lagging
will occur as needed.

Enhancements include taking several samples near the center of the bit
for majority decision.  I don't know if this is real worthwhile, but it's
easy to do.  The software can determine if a valid data signal is present
(a "carrier detect") by looking for a relative lack of Case 4 situations.
If more than a couple of percent are 010 or 101 it's probably not
receiving any data, just noise.

Since only slight phase adjustments are made each time, it can take many
bits to acquire synchronization.  This is good however in that it also
takes many bits to lose synchronization.  If there isn't much time to
synchronize, consider using another method that takes more samples to
find the bit edges quickly at first.  It is simplified because that
routine doesn't need to actually receive and process the data; it will be
garbled anyway until in sync.  Then switch to this method to actually
receive the data.


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

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