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
Look at the clock_recovery_mm_ff block. It does exactly what you want.
–n
On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais
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
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
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
Any idea on this? Should I post the images somewhere else?
On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
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
Signal in and out of Clock recovery block
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
<[email protected]
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?
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 <
On Fri, Apr 11, 2014 at 1:34 PM, Nick F. [email protected]
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