<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">FWIW, I found the dynamic threshold set in the corr-est to be far too low. I made some experiments using my custom sync sequence (a variant of m-sequences that gave me a couple of dB extra) and determined that except in degenerate cases, the core peak would be 8 times the average signal  for SNRs down to about 3 dB. So, I believe I set the threshold to be 4 times the average signal. This worked for me because in the TDMA system I had a good idea where the sync sequence might be. It may be okay for a non-TDMA system where you just look at a running history of samples, but I did not consider that scenario.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">good luck,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">steven</div> <br> <div id="bloop_sign_1507500913914281984" class="bloop_sign"></div> <br><p class="airmail_on">On October 8, 2017 at 15:19:07, Vladimir Rytikov (<a href="mailto:kk6ygb@gmail.com">kk6ygb@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>


<title></title>


<div dir="ltr">thanks everyone for help. I looked closer to
correlation estimator output and it is the case. it does generate a
lot of tags(false positive tags) in my case and  overwhelms
the rest of the flow graph. I looked at the loopback flow graph -
it has very different samples pattern than the radio flow graph. It
doesn't have any noise in between packets.
<div>In any case I will need to look closer to the issue and debug
it. I will move the discussion to GNU Radio mail list once I get
more details on this issue.</div>
<div><br></div>
<div>-- Vladimir</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 4, 2017 at 8:16 AM, Steven
Knudsen <span dir="ltr"><<a href="mailto:ee.knud@gmail.com" target="_blank">ee.knud@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Hey Michael,</div>
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
throwing in my 2 cents, I found the same last year and implemented
separate logic to monitor RSSI and set thresholds. In my case I was
receiving in consecutive slots from different radios, so the RSSI
varied a lot. </div>
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
You also have to be careful with any loop tracking algorithms for
the same reason… not always receiving from the same transmitter can
mess things up.</div>
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_-1215448196304881180bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
steven</div>
<br>
<div id="m_-1215448196304881180bloop_sign_1507130042307131136" class="m_-1215448196304881180bloop_sign"></div>
<br>
<p class="m_-1215448196304881180airmail_on">On October 4, 2017 at
08:21:29, Michael Wentz via USRP-users (<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>) wrote:</p>
<blockquote type="cite" class="m_-1215448196304881180clean_bq">
<div>
<div>
<div dir="ltr"><span>Hi,</span>
<div><span><br></span></div>
<div><span>I ran into a similar problem several months ago - what I
found was that the correlation estimator produced a *huge* number
of false positives (and a tag for each of them) which caused the
clock recovery block to be super overwhelmed. If I recall
correctly, there were also some cases that these tags would send
the clock recovery block into an infinite loop. We rolled back the
correlation estimator to the previous version, which uses absolute
thresholds, as a quick fix.</span></div>
<div><span><br></span></div>
<div><span>-Michael</span></div>
</div>
<div class="gmail_extra"><span><br></span>
<div class="gmail_quote"><span>On Tue, Oct 3, 2017 at 9:23 AM,
Marcus Müller via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span>
wrote:<br></span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>That's very interesting, indeed! If I had to infer (sorry, not
right now on a computer where I can test) from the thread name
"header_payload2", I'd say that for some reason that I don't know,
the header/payload demuxer in packet_rx "spins" on something.</p>
<p>If you want to, throw some more runtime analysis at
this: </p>
<p>sudo apt-get install linux-tools<br>
sudo sysctl -w kernel.perf_event_paranoid=-1<br>
perf record -ag python /path/to/uhd_packet_rx.py</p>
<p>[let it run for a while, e.g. 30s, end it]</p>
<p>perf report<br></p>
<p>That should give you a quick insight in which function/code line
your processors where stuck the most time. Maybe that brings us one
step forward.</p>
<p>Best regards,<br>
Marcus<br></p>
<div>
<div class="m_-1215448196304881180h5"><br>
<div class="m_-1215448196304881180m_4272342992238565117moz-cite-prefix">On
03.10.2017 14:41, Vladimir Rytikov wrote:<br></div>
<blockquote type="cite">
<div dir="ltr">
<div>Marcus,</div>
<div><br></div>
cpu: Intel Core i7-7820HQ (Quad Core 2.90GHz, 3.90GHz Turbo,
8MB)<br>
chipset: Intel Mobile CM238<br>
RAM: 32GB (2x16GB) 2400MHz DDR4<br>
<div>OS: ubuntu 16.04 TLS</div>
<div>almost no other software running - only GNU Radio.</div>
<div><br></div>
<div>htop shows digital/packet/uhd_packet_rx.p<wbr>y takes ~192 %
CPU.</div>
<div>header_payload2 - ~100%</div>
<div>pfb_clock_sync2 - ~90%</div>
<div><br></div>
<div>and the flow graph visually is frozen.</div>
<div>I run volk_profile - it saved some files in .volk
directory.</div>
<div>I restarted the test again after it. the same result. htop
shows the same numbers.</div>
<div><br></div>
<div>the RF signal has correct shape at the freq doman - I am
splitting the signal to a spectrum analyzer- no overdriving the
transmitter. the signal inside the coax cable. 433 MHz freq as in
the example. visually looking at the Time tab - input signal
within  -1 to 1. The recv dies at the moment when I press 'On'
check box - it ungates receiver chain and polyphase clock sync
block. transmitter sends bursts every 2 seconds.</div>
<div>the only modifications comparing to the vanila example -
Clock/Time sources - I changed to Default instead of O/B
GPSDO.</div>
<div><br></div>
<div>-- Vladimir</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 3, 2017 at 4:57 AM, Marcus
Müller via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi Vladimir,</p>
<p>synchronization is usually among the most CPU-intense things a
receiver does (only, if at all, contested by channel decoding for
complex codes). So, the 100% CPU utilization don't sound totally
unreasonable, depending on your system.</p>
<p>That being said, I don't want to rule out bugs, but for the time
being, I'd declare this issue as "unclear, probably insufficient
compute power".</p>
<p>Can you tell us a bit about your computer, in terms of CPU
model, motherboard chipset, RAM configuration, OS? If you install
and run "htop"¹, you'll see which block does how much without much
complication, and maybe also significant non-GNU Radio CPU usage
(for example, my mail client and my browser idling use *serious*
amounts of CPU).</p>
<p>Another thing worth trying is to close all software that might
be using CPU (check with htop!) and then run "volk_profile"; this
should test a lot of hand-written implementations for certain math
operations, which might significantly speed up the polyphase clock
sync.<br></p>
<p>Best regards,</p>
<p>Marcus<br></p>
<p><br></p>
<p>¹: I'm assuming you're using windows; after starting htop, press
F2 for setup, go into the "Display Options", enable "Show custom
thread names", press Esc<br></p>
<br>
<div class="m_-1215448196304881180m_4272342992238565117m_-8832106452291134254moz-cite-prefix">
On 03.10.2017 12:54, Vladimir Rytikov via USRP-users
wrote:<br></div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br></div>
<div>I am trying to run an example from GNU Radio -
examples/digital/packet/uhd_pa<wbr>cket_rx and uhd_packet_tx with
real USPR radios connected via an attenuator and a coax
cable.</div>
<div><br></div>
<div>When I enable receiver by clicking on 'On' check box - the
whole RX flow graph freezes.</div>
<div>I think I manually adjusted transmit power and receive gain to
be within reasonable ranges.</div>
<div><br></div>
<div>By disabling different blocks one at a time I found is that
polyphase clock sync inside packet_rx blocks kills the flow graph.
It seems like the signal is gaited by Correlation Estimator and
once it gets the correct sync word - the signal goes to Polyphase
Clock Sync and CPU dies - it is 100% loaded all the time.</div>
<div><br></div>
<div>If I run only loop back simulation the whole flow graph seems
working fine. I wonder if noise or not very good signal destroys
Polyphase Clock Sync.</div>
<div><br></div>
<div>I installed GNU Radio via PyBOMS - 3.7.12git* version. Please
help to find better idea on debugging it.</div>
<div><br></div>
<div>with a different simple flow graphs Polyphase Clock Sync works
fine even when I feed noise to it and signal later.</div>
<div><br></div>
<div>Thanks,</div>
<div>Vladimir </div>
</div>
<br>
<fieldset class="m_-1215448196304881180m_4272342992238565117m_-8832106452291134254mimeAttachmentHeader">
</fieldset>
<br>
<pre>______________________________<wbr>_________________
USRP-users mailing list
<a class="m_-1215448196304881180m_4272342992238565117m_-8832106452291134254moz-txt-link-abbreviated" href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a>
<a class="m_-1215448196304881180m_4272342992238565117m_-8832106452291134254moz-txt-link-freetext" href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman<wbr>/listinfo/usrp-users_lists.ett<wbr>us.com</a>
</pre></blockquote>
<br></div>
<br>
______________________________<wbr>_________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman<wbr>/listinfo/usrp-users_lists.ett<wbr>us.com</a><br>

<br></blockquote>
</div>
<br></div>
</blockquote>
<br></div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" rel="noreferrer" target="_blank">http://lists.ettus.com/mailman<wbr>/listinfo/usrp-users_lists.<wbr>ettus.com</a><br>

<br></blockquote>
</div>
<br></div>
______________________________<wbr>_________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/<wbr>mailman/listinfo/usrp-users_<wbr>lists.ettus.com</a><br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br></div>


</div></div></span></blockquote></body></html>