Re: [bluetooth] Re: Clock Recovery in BT

[Jamil Khatib <j-khatib@palnet.com>]

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