That's very likely it. It's effectively starting with a random guess as to the bit timing, and it locks exponentially faster the closer it is to correct. So for a worst-case guess, it'll take significantly longer to lock.
--n On Fri, Apr 11, 2014 at 10:33 AM, Francois Gervais < francoisgerv...@gmail.com> wrote: > That could explain it. However most of the time it locks just fine even > for the preamble with the same block parameters. I'm not sure what causes > this variability and if I have control over it of not. > > Might be related to when the MM clock recovery starts sampling the signal. > Sometimes it's lucky and start sampling the bit close to a bit frontier and > sometimes not so it needs to adjust on the next bit. Could that make sense? > > > On Fri, Apr 11, 2014 at 1:19 PM, Nick Foster <bistrom...@gmail.com> wrote: > >> To me it looks like it's taking some time to acquire, which is normal for >> a closed-loop timing recovery algorithm. This is one reason packets have >> preambles. If you need it to lock faster and don't mind some self-noise, >> and if the SNR is high enough, you can turn up the gain of the M&M block >> (change 0.175 in both gain mu and gain omega to a larger number) to allow >> it to lock faster. >> >> --n >> >> >> On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais < >> francoisgerv...@gmail.com> wrote: >> >>> Any idea on this? Should I post the images somewhere else? >>> >>> >>> On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais < >>> francoisgerv...@gmail.com> wrote: >>> >>>> I tried using the M&M clock recovery block as suggested and I have a >>>> little fidelity problem. I added two screenshot links below which show the >>>> problem. I would say 70% of the time the recovered data is fine but for >>>> some reason it's sometimes badly distorted. By looking at it, the input >>>> signal looks always about the same. Is there something obviously wrong in >>>> what I'm doing? >>>> >>>> ASK demodulation GRC >>>> >>>> https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing >>>> >>>> Signal in and out of Clock recovery block >>>> >>>> https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing >>>> >>>> >>>> On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury >>>> <john.malsb...@ettus.com>wrote: >>>> >>>>> I don't know if I would call it overkill. It is just one of several >>>>> methods you can use to achieve synchronization. Other options for >>>>> synchronization include correlate and sync (probably needs modification), >>>>> or possible the polyphase resync. Others on the list would have more >>>>> expertise on these blocks. >>>>> >>>>> In my experience 10 samples per symbol seems to work well with M&M. >>>>> I've heard very high samp/sym (ie. >20) can cause problems, but I haven't >>>>> seen this myself. >>>>> >>>>> The amplitude going into M&M should be as close as possible to +/- >>>>> 1.0, which is why you want the scaling functions before this block. The >>>>> AGC block assures you're working with something constant amplitude for >>>>> demodulation. >>>>> >>>>> -John >>>>> >>>>> >>>>> On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais < >>>>> francoisgerv...@gmail.com> wrote: >>>>> >>>>>> Thanks guys for the information, >>>>>> >>>>>> I looked a little about the M&M recovery block but it seemed to me >>>>>> like and advance algorithm, overkill for what I'm trying to achieve. I'm >>>>>> I >>>>>> mistaken? >>>>>> >>>>>> If I'm using the M&M clock recovery block what is the quality of >>>>>> input signal I should aim to avoid translation errors? Should my signal >>>>>> be >>>>>> filtered with a really narrow band and should I allow more harmonics in >>>>>> to >>>>>> the signal is more square? Can the input signal have too much sample per >>>>>> bit? Right now I'm at 16. Is more better? Is it better to have more >>>>>> amplitude? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury < >>>>>> john.malsb...@ettus.com> wrote: >>>>>> >>>>>>> Depending on various factors the implementation may vary, but you >>>>>>> could probably start with a chain that looks something like this: >>>>>>> >>>>>>> I/q source -> filter -> AGC -> AM demod (complex to mag) -> scaling >>>>>>> for am depth -> m&m clock recovery -> slicer -> do something with the >>>>>>> data >>>>>>> >>>>>>> Other, more advanced implementations might use correlation for >>>>>>> synchronization. >>>>>>> >>>>>>> -John >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais < >>>>>>> francoisgerv...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK >>>>>>>> signal from a device I have, as a first project. I'm using RTL-SDR as >>>>>>>> the >>>>>>>> input device. >>>>>>>> >>>>>>>> I'm slowly getting there. I receive the signal, at 2Msample/s, I >>>>>>>> low-pass filter it to 300khz, I send it through the AM demodulation >>>>>>>> block >>>>>>>> and then through the DC blocker. >>>>>>>> >>>>>>>> From there I have my signal and it looks fine i.e I could retrieve >>>>>>>> the information manually by looking at it. >>>>>>>> >>>>>>>> Now I think the goal is to somehow synchronize with the bits and >>>>>>>> re-sample to get 1 sample per bit. This could then be sent to a file. >>>>>>>> Is >>>>>>>> that it? >>>>>>>> >>>>>>>> At first glance I'm thinking I should have a PLL which ouputs a >>>>>>>> clock at about 250khz (twice the bit rate) and synchronize the rising >>>>>>>> edge >>>>>>>> with every bit transitioning from 0 to 1 so unless I receive only ones >>>>>>>> ou >>>>>>>> zeros I should be quite in sync. Then I could toggle a sample every >>>>>>>> falling >>>>>>>> edge of the clock which should be at about the middle of the bit. >>>>>>>> >>>>>>>> Is this a viable solution? Can it be done with gnuradio? Other >>>>>>>> alternatives? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Discuss-gnuradio mailing list >>>>>>>> Discuss-gnuradio@gnu.org >>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> Discuss-gnuradio@gnu.org >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
