[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth] Re: Clock Recovery in BT
Hi Robert,
Even I am trying to implement the correlator.
I took threshold as 60. I am not sure what is the
exact value of the threshold should be. Are you
writing a code in C or VHDL/Verilog?
Can you please clear my concepts regarding access
code/correlator?
What I think is:
Correlator is required to find the starting of the
packet right? How does correlator give signalling on
the receiver side?
While transmitting the packets the access codes are
derived according to different modes like inquiry,
device access code, channel access code etc.
Is the mode information passed from bolck to block in
data path block modules?
thanks,
-Jyoti
--- Robert Openshaw <robertopenshaw@yahoo.com> 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!
>
> 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
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
To unsubscribe from bluetooth mailing list please visit http://www.opencores.org/mailinglists.shtml