Any idea on this? Should I post the images somewhere else?
On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais < [email protected]> 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 <[email protected]>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 < >> [email protected]> 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 >>> <[email protected]>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 < >>>> [email protected]> 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 >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
