[USRP-users] Simple correlator to detect synchronization timing.

Marcus Müller marcus.mueller at ettus.com
Thu Jul 2 11:45:42 EDT 2015


Hi Jeon,

is this the mail you were referring to on discuss-gnuradio? I'm
including it in my reply, because that seems sensible.

What you're looking at looks very much like a synchronization problem.
Manchester tells me we have a reliable rate of transitions, so that's
handy :)
I'd go for oversampling (if that's possible) by a factor of let's say 4
or 5 of your symbol rate, and implementing a sensible filter for the
signal; then, throw the Mueller & Müller clock sync (Look into the
[Synchronizers] categorie in GRC) at the problem :)

Best regards,
Marcus

On 02/20/2015 03:02 PM, Jeon via USRP-users wrote:
> I am trying to make something which:
>
> * finds some synchronization timing position
> * throws away what comes before sync code
> * passes what comes after sync code
>
> a sync code is '010110' (FYI, It is encoded with Manchester code, so
> the decoded code is 001)
>
> I have tried:
>
> * digital_correlate_access_code_bb with access code 010110
> * fir_filter_xxx with taps of [0,1,0,1,1,0]
> * interp_fir_filter_xxx with taps of [0,1,0,1,1,0],
> where values of threshold, decimation and interpolation I cannot assure
>
> But, I cannot see value 3 which is expected
> if there is perfect timing synchronization for a given sample stream
> ......0101011001......
>
> Am I using wrong blocks, or somewhat misconfigured threshodl,
> decimation and interpolation values?
>
> If you have an idea for it, please give me some advice.
>
> Regards,
> Jeon.
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150702/19653fcb/attachment-0002.html>


More information about the USRP-users mailing list