Re: [bluetooth] Re: Clock Recovery in BT

[Jyoti Wagholikar <jyoti_wagholikar@yahoo.com>]

Hi Robert,
     Thanks for your information. Can you give me the
solution for synch word? Actually I have written C
program to calculate the synch word. I am not sure
whether I have implemented it correctly or not. I'll
go through it and will check whther my understanding
is correct or not.
 I have taken Pseudo random noise sequence that is
given in the specification. Is it correct? Do I need
to generate the sequence everytime?

thanks,
-Jyoti
--- Robert Openshaw <robertopenshaw@yahoo.com> wrote:
> I am not currently coding a correlator block, but I
> have coded one in
> Verilog in the past.
> 
> Basically the access code is used to find the start
> of the packet, and
> also to identify which pico net that packet is
> associated to. (A sort
> of address) I strongly recoomend reading over the
> access code section
> of the bluetooth 1.1 spec. You can find an
> 'introduction' to the access
> code and it's function starting on page 48. But I
> would recommend
> reading the entire section about the bluetooth
> packet construction. You
> can download the spec from http://www.bluetooth.com
> 
> You would have to have a talk with Jamil on how he
> intends to architect
> this bluetooth core. On the solution I have worked
> on in the past the
> sync word portion of the access code is calculated
> in software within
> the main controller. But this is an architecture
> issue. I could give
> you a solution that works great! (in verilog) But
> would not meet the
> requirements of this project due to different
> architectures.
> 
> The most basic of correlators is:
> A 64 bit shift register (the access code is 72 bits
> max, that includes
> a pre-amble and a trailer pattern of 4 bits each the
> remaining 64 bits
> is called the sync word)
> A 64-bit comparater that cominatorialy compares the
> 64 bits in your
> shift register with a target 64-bit pattern
> (basically 64 xor gates),
> that COULD be parallel loaded into another 64-bit
> register from say a
> host processor for example.
> 
> The output of this comparater is a 64-bit pattern
> consisting of 1's
> where there was a bit miscompare and a 0 for a bit
> compare. We then
> need to combinatorially add all the bits together to
> find otu the total
> number of 1's, this gives us an error value. Say 4
> int his example.
> 
> To provide a bit more flexability you can then
> compare this error value
> with a programmable threshold, which is merely a
> value written itno
> another register. If the total number of errors is
> <= our threshold
> give a correlate signal, otherwise don't.
> 
> If this is done combinatorially you will probably
> find it can run at a
> reasonable speed, I did however create an adder tree
> that could be
> pipelined if required. That is pretty simple really
> and wasn't
> necessary as this block, as described above and only
> if encoded as
> described above, would only need to run at the
> incomming data
> bit-rate....
> 
> Cheers
> Rob
> 
>  --- Jyoti Wagholikar <jyoti_wagholikar@yahoo.com>
> wrote: > 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
> 
=== message truncated ===


=====
**************************************************************
Jyoti Wagholikar
Graduate Student
State University Of New York at Stony Brook
***************************************************************

__________________________________________________
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