Re: [Discuss-gnuradio] ASK demodulation help

[Tom Rondeau]

On Fri, Apr 11, 2014 at 1:34 PM, Nick Foster <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> wrote:

Any idea on this? Should I post the images somewhere else?

On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio