Hi Marcus,
A it's the Polyphase Clock Sync, I didn't think about it ... :-D
Thank you for the advice, I will use the mailing list next time.
Best regards.
Klauss.
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discu
Hi Klauss,
> is it new ?
Not really, no. It's been around since ca April 2012.
If there's no "Polyphase Clock Sync":
What version of GNU Radio are you using?
Best regards,
Marcus
PS: I always recommend not using ruby-forum but directly signing up to
the mailing list:
https://lists.gnu.org/mailm
Wow ! Thank you all for your reply. Very interesting !
Tom, I didn't find the "pfb_clock_recovery block" in my GNU Radio
Companion, is it new ?
Best regards.
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradi
Hi Tom,
why do/I/ have to advertise the PFB approach? Arguing against Mueller &
Müller feels strange. Anyway:
Mueller & Müller in the classical, real valued approach [1, eq (49), p.
524] in its core is
eqn. (49) page 524
with $z_k$ being the timing estimate ,$x_k$ being the input samples, and
$a
On Thu, Jul 30, 2015 at 3:03 PM, Iluta V wrote:
> Hi, Tom,
>
> Could you be more specific where exactly it is not "the right algorithm"?
> We'd appreciate that and would correct that in own work as well, if
> Security Research Assessment made a mistake here.
>
> I will be looking forward to your
Thanks for your explanation! That's worth while looking into!
On Fri, Jul 31, 2015 at 1:17 AM, Francisco Albani <
francisco.alb...@gmail.com> wrote:
> From Matlab MM documentation [1]:
>
> "[...] Typically, the input signal is the output of a receive filter that
> is matched to the transmitting
>From Matlab MM documentation [1]:
"[...] Typically, the input signal is the output of a receive filter that
is matched to the transmitting pulse shape. [...]"
Assuming the MM Gnuradio implementation has the same hypothesis on the
input signal (anybody can confirm this?), I deduced this block is
Hi, Tom,
Could you be more specific where exactly it is not "the right algorithm"?
We'd appreciate that and would correct that in own work as well, if
Security Research Assessment made a mistake here.
I will be looking forward to your response,
Iluta
On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondea
On Thu, Jul 30, 2015 at 2:38 PM, Iluta V wrote:
> Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of
> Using GNU Radio Companion for Security Research and Assessment) deals with
> Clock Recovery MM, I attached the paper, have a look at:
>
> 6.Section 6.Counting the Bits
> 7.A
Another point to keep in mind is that the M&M block isn't great in fading
environments. It's really suboptimal in general. Look at the
pfb_clock_recovery block, instead.
Tom
On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara
wrote:
> Hi Klauss,
>
> You could also take a look at
> https://www.tabli
Hi Klauss,
You could also take a look at
https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
it helped me quite a bit!
Best regards...
Daniel
On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun
wrote:
> Klaus,
>
> the manual page for this block has a paper referenc
Klaus,
the manual page for this block has a paper reference in it:
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details
M
On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
> Hello,
>
> I would like to find a proper documentation on MM algorithm block (paper
>
Hello,
I would like to find a proper documentation on MM algorithm block (paper
for example). Any ideas ?
Thank you.
Regards.
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/
On 09 Sep 2014, at 15:42, Tom Rondeau wrote:
> On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl wrote:
> Hi all,
>
> looking at the clock recovery MM code, I wonder if d_omega_relative_limit is
> a relative or absolute deviation from d_omega.
>
> Here it looks like absolute
> https://github.c
On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl
wrote:
> Hi all,
>
> looking at the clock recovery MM code, I wonder if d_omega_relative_limit
> is a relative or absolute deviation from d_omega.
>
> Here it looks like absolute
>
> https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/cloc
Hi all,
looking at the clock recovery MM code, I wonder if d_omega_relative_limit is a
relative or absolute deviation from d_omega.
Here it looks like absolute
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107
Here it is relative
https://github.com/
16 matches
Mail list logo
