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
