[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth] Re: Clock Recovery in BT
Why not seperate out the function of locking onto the incomming data
stream and looking for an access code match? In my experience these
are two very very different tasks. Also the preamble can't be relied on
to provide the 1010 pattern. I have personally seen these preambles
missing, and in fact even sometimes some missing access code, in some
packets on a particular radio chip!
The first problem you have about the incoming data stream may be that
it's coming from a totally different clock, even if it is 1Mhz it does have
a certain accuracy and our clock also must be within this accuracy. But
you can no garuntee the relasionship between them! Correct? I beleive
the 1Mhz clock accuracy requirement is spec'ed in the bluetooth 1.1
spec. This accuracy ensures that over the time taken for 1 maximum
sized bluetooth data packet, that any two 1Mhz clocks will not drift far
enough appart as to cause setup/hold violations. But that is assuming
your clocks are aligned at the start of the packet!
So somehow you need to prevent this drifting of clocks resulting in us
either dropping a bit, where our clock is slightly slower, or gaining an
extra bit, where our clock is slightly faster.
So how are you going to lock onto an asynchronouse data stream?
Perhaps have a small block running much quicker that 'oversamples' the
incomming data stream? We can then track when the transitions in the
incomming data stream occurs in relation to our clock. So we can
predict if we are going to drop or gain a bit. If we then run our design at
say 2Mhz with the logic enabled every other cycle then we are
effectively running at 1Mhz. But now we can recover this 'dropped bit'
by leaving the enable high for 2 2Mhz cycles, and we can make up for
this gained, or phantom bit, by leaving the enable low for an extra clock
cycle! I feel this can then result in a reasonably safe tracking of the
incomming data stream.
Now the detection of the correct transition in the incomming data
stream is a different matter. I have seen a 1Mhz data stream from a
particular manufacturers bluetooth radio chip that has noise at a higher
frequency overlaid on the data. Especially near the beginning of the
packet when it is trying to lock onto the incomming data stream. I have
seen a radio chip, from an alternative manufacturer, that prevents this
happeneing and has a nice clean 1Mhz signal. So now we need to filter
out spuriouse transitions. This all gets pretty messy but I have an idea
for a solution.
Now onto the correlator. You are not looking for the preamble anymore!
Shift the incomming data into a 68 bit shift register, compare on every
clock cycle the contets of this shift register with our access code. As
soon as they match we have a correlation! If the correlator is run at the
incoming data stream speed we can provide a correlate signal
combinatorially in time for the next clock cycle.
A quick question. Why are you passing the incoming data stream
THROUGH the correlator to the FEC? Why not bypass the correlator, this
will reduce latency (68 clock cycles) on the incoming data path! If the
correlator merely monitors the incommind data and provides a correlate
signal (combinatorially) then the next clock cycle will be the first data
bit after the access code! (Most probably the first bit of the trailer,
depending on the packet type!) So we could pass the data straight from
the 're-sync' block mentioned above to the FEC which merely ignores all
data until the correlate signal goes high.
Could this 68 clock cycle latency could be an issue in us hitting our next
transmit time slot? It is easliy avoided using the method mentioned
above! Also the correlator can be run slow, so as to reduce power
consumtion..... (At the speed of the incomming data stream!)
I feel that a programmable threshold is important. I have seen
successfull corellations with 0 errors, I have also seen access codes
with 3 errors in it! We really still want to detect these packets with say
3 errors! Say make the threshold programmable from 0 to say 15 errors
(just picking numbers from thin air!) I can see situations where we could
have bit errors in the access code! (noisey enviroment! While popping
pop corn in the microwave????) But we want to reduce the chances of
correlating on incorrect access codes! Now I know this is unlikely. The
access codes are calculated in such a way as to ensure a high hamming
distance between any two valid access codes! But It's better to be safe
than sorry. The software could 'tune' this threshold accordign tot he
signal quality if an error count is fed abck from the correlator. This could
tell the software how many errors are actually occuring in the access
codes!!!
Thats about it for my first installment... I could knock up a spec for a
correlator explaining the reasoning behind features if you woudl like...
Not necessarily as a part of your bluetooth spec, but merely to try and
explain my thoughts......
Cheers
Rob
Robert Openshaw
----- Original Message -----
From: Jamil Khatib <khatib@i... >
To: bluetooth@o...
Date: Thu, 26 Jul 2001 23:34:12 +0200
Subject: Re: [bluetooth] Re: Clock Recovery in BT
>
>
> Hi,
> Try to look at the access code correlator I designed (you can find
> it in the bluetooth project pages).
> the correlator keeps comparing hte inputs till both the input and
> the expected value are matched within
> certain threshold. Till now I do not know how to select this
> threshold.
> regarding the preamble ( and since the correlator does not look
> for the exact pattern) I think we can
> ignore them
>
> Note: the correlator is too slow and it needs lot of modifications
> to get faster
>
> Any comments
> Jamil Khatib
>
> > Hello Mr. Khatib
> >
> > Yes that symbol recovery is what I am talking about.
> > There is a preamble of 1010 or 0101 before 68-bit
> > access code which helps in determining the symbol
> > rate. In inquiry and other packets which have no
> > header or payload, access code is only 68 bits,
> > without any preamble. also due to settling time of
> > radio, it is less likely that we can receive all the 4
> > bits of preamble at receiver. In all these cases (that
> > is no preamble and unknown number of preamble bits)
> > how symbol recovery can be done? I will be thankful to
> > you if you can guide me on this.
> >
> > regards
> > Faisal
> > --- Ling Su <lingsu@p... > wrote:
> > > I guess it would't be access code correlator, it
> > > means the symbol recovery
> > > before you feed the data into your logic. Bluetooth
> > > need pretty fast
> > > recovery, since it only has 4 sync symbol.
> > >
> > > -Ling
> > >
> > > ----- Original Message -----
> > > From: "Jamil Khatib" <jamilkhatib75@y... >
> > > To: <bluetooth@o... >
> > > Cc: <faisalmaalik@y... >
> > > Sent: Wednesday, July 25, 2001 1:39 PM
> > > Subject: Re: [bluetooth] Clock Recovery in BT
> > >
> > >
> > > > Hi,
> > > > sorry for the delay.
> > > > do you mean the access code correlator?
> > > >
> > > > if not can you explain it to me because it seems
> > > the I
> > > > am missing something.
> > > >
> > > > regards,
> > > > Jamil
> > > >
> > > > --- Faisal <faisalmaalik@y... > wrote:
> > > > >
> > > > > Hello
> > > > >
> > > > > can any one help me in designing of the clock
> > > and
> > > > > data recovery sub-block of bluetooth baseband
> > > > > receiver. Any suggestions, ideas or relevant
> > > > > information would be welcome.
> > > > >
> > > > > Faisal
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------
> > > > > Do You Yahoo!?
> > > > > Make international calls for as low as
> > > $.04/minute
> > > > > with Yahoo! Messenger
> > > > > http://phonecard.yahoo.com/
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Make international calls for as low as $.04/minute
> > > with Yahoo! Messenger
> > > > http://phonecard.yahoo.com/
> > > > --
> > > > To unsubscribe from bluetooth mailing list please
> > > visit
> > > http://www.opencores.org/mailinglists.shtml
> > > >
> > >
> > >
> >
> >
>
> --
> Jamil Khatib
> OpenCores Organization
> http://www.opencores.org
>
--
To unsubscribe from bluetooth mailing list please visit http://www.opencores.org/mailinglists.shtml