I just came across a strange behavior in the digital benchmark examples
that I haven’t seen before. The transmitter wouldn’t stop itself after
it
finishes sending the requested data size (specified by -M argument).
Keyboard interrupt (ctrl+C) has no effect. I had to stop it with ctrl+Z
and
kill the job after.
This behavior starts when bitrate exceeds 1M.
If I ran benchmark_rx2.py then a short period after receiving all
packets
(~30 sec), the receiver would continuously spill out “O” (overrun). This
didn’t happen if I ran benchmark_rx.py. (I ran the corresponding tx
code.)
I’m not sure what could be causing it. I was able to run digital
benchmark
code on my older machine at 1.5Mbps prior to UHD (I used Ethernet
driver)
so I’m sure CPU speed isn’t a problem.
To make it work with UHD driver, I made some changes to the
usrp_options.py
and generic_usrp.py.
I’m quite puzzled right now. I’d appreciate any insights!
If I ran benchmark_rx2.py then a short period after receiving all packets
(~30 sec), the receiver would continuously spill out “O” (overrun). This
didn’t happen if I ran benchmark_rx.py. (I ran the corresponding tx code.)
I’m not sure what could be causing it. I was able to run digital benchmark
code on my older machine at 1.5Mbps prior to UHD (I used Ethernet driver)
so I’m sure CPU speed isn’t a problem.
To make it work with UHD driver, I made some changes to the usrp_options.py
and generic_usrp.py.
I believe that tom ported all of the gnuradio “classic” example
applications in 3.5 release. You may want to try those examples, because
I know that he has tested them recently.
Just a thought. Could this be the overhead of the new stream tags? Since I
didn’t see it before.
The tags overhead should be next to nothing. The source block only
produces a tag once on init, and after overflows. The overflows that you
see tell me that the receiver chain is not pulling data out fast enough.
however…
So I was doing a little experiment with the mod/demod blocks and packet
framer/deframer. No USRPs, just a loopback. Somehow, about 2000 packets
(not samples) were getting delayed in the pipeline. Removing the
mod/demod block and replacing it with a packed to unpacked fixed the
delay. So somehow within either mod/demod or both, a crap-ton of samples
were getting buffered.
So something is wrong, not saying that it describes your issue, but it
might. Here is a screen shot of my flow graph: http://i.imgur.com/ZQtEE.png
I’ve upgraded to 3.5rc0. The same thing happened. I got some more
details:
When I ran benchmark_tx on 1 machine, at low bitrate (0.1Mbps or 0.2MSps
I’m using bpsk) the CPU utilization is roughly 9%.
But the receiver, running benchmark_rx showed 110% CPU utilization.
If I up the bitrate to 1Mbps,
the transmitter showed 90% CPU utilization so it scaled linearly.
the receiver starts out showing 110% CPU utilization, so I guess it
processed noise also, which makes sense because there’s no
carrier-sense.
It did nothing for a while (~30 sec), then started showing correct
receptions. Until a point, it started to show overrun. Here’s part of
the
output on the receiver:
Another thing is when I started the transmitter first, then the receiver
started to show received samples right away. If I started the receiver
first, then it had the 30 sec delay mentioned above.
Before I used to run these code on the old gnuradio version (3.2.2) and
Ethernet driver and didn’t have this problem. Could this be related to
the
new implementation of gnuradio and/or the UHD driver? Or is there any
other
possible explanation?
I am not seeing the same buffering issues with GMSK. I’ am guessing that
the recent work on gr-digital may have accidentally messed up our d*psk
blocks. Maybe massive filter coefficients are being calculated?
When Tom gets back I think he can offer some insight.
Can you try/compare the GMSK mod/demod blocks instead?
I think the problematic block might be the FLL used in the PSK
demodulator. I haven’t looked into the issue very deeply, but I have
confirmed that given the same input parameters, the FLL from 3.4.2 works
fine, while the 3.5.0 version causes a lot of overruns.
I think the problematic block might be the FLL used in the PSK
demodulator. I haven’t looked into the issue very deeply, but I have
confirmed that given the same input parameters, the FLL from 3.4.2
works fine, while the 3.5.0 version causes a lot of overruns.
Thanks, I confirmed that the fll band edge filter is the culprit. The
following diff (removing the bandedge) makes may loopback example far
more responsive:
diff --git a/gr-digital/python/generic_mod_demod.py
b/gr-digital/python/generic_mod_demod.py
index ae876e1…cf2d684 100644
— a/gr-digital/python/generic_mod_demod.py
+++ b/gr-digital/python/generic_mod_demod.py
@@ -303,7 +303,7 @@ class generic_demod(gr.hier_block2):
self._setup_logging()
# Connect and Initialize base class
blocks = [self, self.agc, self.freq_recov,
blocks = [self, self.agc,
self.time_recov, self.receiver]
if differential:
blocks.append(self.diffdec)
I think the problematic block might be the FLL used in the PSK
demodulator. I haven’t looked into the issue very deeply, but I have
confirmed that given the same input parameters, the FLL from 3.4.2
works fine, while the 3.5.0 version causes a lot of overruns.