On Fri, Apr 11, 2014 at 1:34 PM, Nick Foster <bistrom...@gmail.com> wrote:
> 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 > I would suggest downsampling before the clock sync block, too. IIRC, you're using 16 samples per symbol, which is way higher than you need. Go through a 4x down sampler to get 4 sps. That could help with this issue. Note that you'll probably have to change your gains for the new sps value. Tom > 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
