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-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio