On Fri, Apr 11, 2014 at 1:34 PM, Nick Foster 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 woul
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 <
francoisgerv...@g
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 a
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
(chang
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
>
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 look
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
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
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 i
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
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
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 an
11 matches
Mail list logo
