Re: [bluetooth] Re: Clock Recovery in BT

[Robert Openshaw <robertopenshaw@yahoo.com>]

Hi,

Yes I can draw a specification for the correlator block and clock
recovery block.. What I can do is try and get these spec.'ed for you
and I can e-mail them to yourself for review, then you can make any
suggestions or comments to me if you like... I have had a brief look
throught your bluetooth spec, but I will want to have a more in-depth
look through it before I write up these specs just to make sure I don't
make any stupid mistakes. :-)

I will most probably be away over the next week, but I will be taking
my laptop with me, so I will be able to work on them then.

Regards
Rob

 --- Jamil Khatib <j-khatib@palnet.com> wrote: > 
> Hi,
> Thanks for your information.
> Please check my answers and comments below within your email
> 
> robertopenshaw@hotmail.com_NO_SPAM wrote:
> 
> > 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!
> 
> 
> I agree with you I should update this to the next release of the
> design document.
> 
> > 
> > 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.
> 
> 
> In fact I had a suggestion about such block in hte design document in
> the past but I dropped it but I think I should consider it again.
> 
> > 
> > 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.
> 
> 
> I thought I put it in the design document but it seems I forgot it.
> Anyhow all datapath blocks (including the correlator) should have
> pass signal to by pass the block 
> 
> 
> > 
> > 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!!!
> 
> 
> Programable threshold is on my todo list.
> 
> 
> > 
> > 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......
> 
> 
> 
> If you would like try to make the proposal for both the clock
> recovery and correlator blocks that can fit in the whole opencores
> bluetooth design and I will added there.
> Do you agree to take the reponsibility of these blocks? it seems you
> will be very help full to our project.
> 
> 
> Regards,
> Jamil Khatib
> 
> > 
> > 
> > Cheers
> > Rob
> > 
> > Robert Openshaw
> > 
> 
> 
> 
> 
> --
> To unsubscribe from bluetooth mailing list please visit
http://www.opencores.org/mailinglists.shtml 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe from bluetooth mailing list please visit http://www.opencores.org/mailinglists.shtml