I am using gr_uhd_source as the source of my app. At some moment, there
is an overflow, an O is printf’ed and the scheduler stops. The program
is still running but there is no flow of samples between blocks. They
are waiting for something. I added the following lines in the work() of
gr_uhd_source
printf(“no = %d\n”, noutput_items);
if (_metadata.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE)
printf(“Error %d\n”,_metadata.error_code);
and the output, after some time, is
no = 4094
no = 4096
no = 4094
[…]
no = 4096
no = 4094
no = 4096
no = 4096
Ono = 4094
no = 2133
Error 8
no = 2133
Error 1
and here waits for some thing and no more printf take place. Be aware
that this happens when the O appears.
Anybody is expecting the same? Could you provide me some hint?
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
Whats the hardware? Sample rate? And I suppose UHD version as well.
It looks to me like there is an overflow (code 8), and then a timeout
(code 1). I bet the scheduler then prints “block returned 0 marking it
done” something like that…
So it looks to me that the overflow condition is shutting off the
streaming, and UHD is not automatically tuning streaming back on.
Hmm… thats not right.
So let me know the hardware and I will try to replicate the fix the
issue.
The hardware is USRP2 at 10Msps with latest UHD version
UHD_003.004.001-165-unstable.
Well, this surprises me. I have never know USRP2/N210 to internally
overflow. The gigE pipe essentially has no back-pressure, so the
overflowing usually happens on the host, and they dont cause streaming
to shutoff.
Is it possible you accidentally selected a sample rate > available gigE
bandwidth? Thats the only way I know this to happen. But 10Msps should
be fine.
The only other way I can think of is a MTU issue (really really small
MTU). When you run the application, it should print recv frame size
1472. What do you see printed?
The hardware is USRP2 at 10Msps with latest UHD version
UHD_003.004.001-165-unstable.
As you pointed, it seems that does not restart the streamer. I made a
rough patch that works continously. I still get overflows but it does
not stop.
diff --git a/gr-uhd/lib/gr_uhd_usrp_source.cc
b/gr-uhd/lib/gr_uhd_usrp_source.cc
index 8aa9654…75ae3d6 100644
— a/gr-uhd/lib/gr_uhd_usrp_source.cc
+++ b/gr-uhd/lib/gr_uhd_usrp_source.cc
@@ -368,10 +368,12 @@ public:
case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
//Assume that the user called stop() on the flow graph.
//However, a timeout can occur under error conditions.
return WORK_DONE;
// return WORK_DONE;
case uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
_tag_now = true;
stop();
start();
//ignore overflows and try work again
return work(noutput_items, input_items, output_items);
Mainly I made stop/start when timeout or overflow occurs.
Thanks.
On 05/29/2012 07:29 AM, Pol H. wrote:
printf("Error %d\n",_metadata.error_code);
no = 4096
Whats the hardware? Sample rate? And I suppose UHD version as well.
It looks to me like there is an overflow (code 8), and then a timeout
(code 1). I bet the scheduler then prints “block returned 0 marking it
done” something like that…
So it looks to me that the overflow condition is shutting off the
streaming, and UHD is not automatically tuning streaming back on.
Hmm… thats not right.
So let me know the hardware and I will try to replicate the fix the
issue.
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.