Hello usrp-users, I am not sure if I already addressed this point before but here it is: I am using RFNOC and X310 as a usrp-source in a spectrum sensor flograph where I created my own RFNOC block to aggregate outputs from FFT block into spectrum power bins and later on I intend to create another RFNOC block to average over time the readings. The X310 I am using is connected through Ethernet. I am not exactly sure what is causing overflow errors but here is the output: 2016-10-26 17:42:13 EDT fc = 724.0 MHz. Writing data to file /home/nae/Spectrum-Sensors/X310/10-26-2016_001 -- [GNU Radio] Connecting 0/FFT_0:0 --> 0/binAggr_0:0 -- [0/FFT_0] source_block_ctrl_base::set_destination() 2.112>2.96 -- [0/FFT_0] Setting SID: 2.112>2.96 -- [0/FFT_0] source_block_ctrl_base::configure_flow_control_out() buf_size_pkts==4 -- [0/binAggr_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0, packets=2) -- [GNU Radio] Connecting 0/FIFO_0:0 --> 0/FFT_0:0 -- [0/FIFO_0] source_block_ctrl_base::set_destination() 2.224>2.112 -- [0/FIFO_0] Setting SID: 2.224>2.112 -- Assuming max packet size for 0/FIFO_0 -- [0/FIFO_0] source_block_ctrl_base::configure_flow_control_out() buf_size_pkts==2 -- [0/FFT_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0, packets=1) -- [GNU Radio] Connecting 0/Radio_0:0 --> 0/FIFO_0:0 -- [0/Radio_0] source_block_ctrl_base::set_destination() 2.64>2.224 -- [0/Radio_0] Setting SID: 2.64>2.224 -- Assuming max packet size for 0/Radio_0 -- [0/Radio_0] source_block_ctrl_base::configure_flow_control_out() buf_size_pkts==2 -- [0/FIFO_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0, packets=1) gr::log :INFO: controlport - Apache Thrift: -h localhost -p 9090 -- [RX Streamer] chan 0 connecting to 0/binAggr_0 -- [RX Streamer] creating rx stream recv_buff_size=33554432 -- [RX Streamer] data_sid = 00:11>02:60 actual recv_buff_size = 33554432 -- [0/binAggr_0] source_block_ctrl_base::set_destination() 0.0>0.17 -- [0/binAggr_0] Setting SID: 2.96>0.17 -- [RX Streamer] resp_out_dst_sid == 17 -- [RX Streamer] Number of upstream radio nodes: 1 -- [RX Streamer] spp == 364 -- [RX Streamer] Flow Control Window (minus one) = 18235, Flow Control Handler Window = 569 -- [0/binAggr_0] source_block_ctrl_base::configure_flow_control_out() buf_size_pkts==18235 -- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 1 -- [0/binAggr_0] source_node_ctrl::set_rx_streamer() 0 -> 1 -- [0/FFT_0] source_node_ctrl::set_rx_streamer() 0 -> 1 -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1 -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 0 -> 1 -- [0/Radio_0] x300_radio_ctrl_impl::check_radio_config() -- [Device3] updating RX streamer to RX Terminator 0 -- New tick_rate == 2e+08 New samp_rate == 2e+08 New scaling == 3.05185e-05 -- [0/binAggr_0] source_block_ctrl_base::issue_stream_cmd() -- [0/FFT_0] source_block_ctrl_base::issue_stream_cmd() -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd() -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a -- [RX Terminator 0] rx_stream_terminator::handle_overrun() -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a Ooverrun on chan 0 .... .... .... -- [RX Terminator 0] rx_stream_terminator::handle_overrun() -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a Ooverrun on chan 0 My flowgraph is as the following: [cid:image002.jpg@01D23067.412DEFE0] How to debug and find out what is causing overflows ? But my main concern here is: after a continuous overflow messages, the Radio seems to enter in a unresponsive mode that oblige me to reboot it. Does this makes sense or there is something I need to understand first ? Apart from executing testbenches of BinAggr RFNOC block, I thoguht I may fix the overflow problem with interfacing the USRP with a PCIe cable instead. Is that corect ? However, is I connect the USRP with PCIe instead, anytime an error occurs which makes the USRP hangs (by the way, physically I see REF LED being yellow and stays so) I think I need to reboot it and that will cause a PCIe bus fatal error on the system even though I unlowd niusrp kernel module before power cycling the USRP. I am a bit confused here because there should be another way to fix the connection once flowgraph is not responding after overlows. Thanks and Regards, Naceur El Ouni NIST - Wireless Networks Division (673) 100 Bureau Dr. Building 222-A218 Gaithersburg, MD 20899 (301) 975-3353

Naceur, sorry for the late response! In RFNoC, overruns occur for the same reason as they do in vanilla UHD. In your case, there's 2 sources for Os: 1) Your block is not consuming data on every clock cycle or 2) your host is backing up the pipeline. If you leave out your block and go straight to a null sink, does it work? Cheers, Martin On 10/27/2016 12:32 PM, El Ouni, Naceur (IntlAssoc) via USRP-users wrote: > Hello usrp-users, > > > > I am not sure if I already addressed this point before but here it is: > > I am using RFNOC and X310 as a usrp-source in a spectrum sensor flograph > where I created my own RFNOC block to aggregate outputs from FFT block > into spectrum power bins and later on I intend to create another RFNOC > block to average over time the readings. > > > > The X310 I am using is connected through Ethernet. I am not exactly sure > what is causing overflow errors but here is the output: > > > > 2016-10-26 17:42:13 EDT fc = 724.0 MHz. Writing data to file > /home/nae/Spectrum-Sensors/X310/10-26-2016_001 > > -- [GNU Radio] Connecting 0/FFT_0:0 --> 0/binAggr_0:0 > > -- [0/FFT_0] source_block_ctrl_base::set_destination() 2.112>2.96 > > -- [0/FFT_0] Setting SID: 2.112>2.96 > > -- [0/FFT_0] source_block_ctrl_base::configure_flow_control_out() > buf_size_pkts==4 > > -- [0/binAggr_0] > sink_block_ctrl_base::configure_flow_control_in(cycles=0, packets=2) > > -- [GNU Radio] Connecting 0/FIFO_0:0 --> 0/FFT_0:0 > > -- [0/FIFO_0] source_block_ctrl_base::set_destination() 2.224>2.112 > > -- [0/FIFO_0] Setting SID: 2.224>2.112 > > -- Assuming max packet size for 0/FIFO_0 > > -- [0/FIFO_0] source_block_ctrl_base::configure_flow_control_out() > buf_size_pkts==2 > > -- [0/FFT_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0, > packets=1) > > -- [GNU Radio] Connecting 0/Radio_0:0 --> 0/FIFO_0:0 > > -- [0/Radio_0] source_block_ctrl_base::set_destination() 2.64>2.224 > > -- [0/Radio_0] Setting SID: 2.64>2.224 > > -- Assuming max packet size for 0/Radio_0 > > -- [0/Radio_0] source_block_ctrl_base::configure_flow_control_out() > buf_size_pkts==2 > > -- [0/FIFO_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0, > packets=1) > > > > gr::log :INFO: controlport - Apache Thrift: -h localhost -p 9090 > > > > -- [RX Streamer] chan 0 connecting to 0/binAggr_0 > > -- [RX Streamer] creating rx stream recv_buff_size=33554432 > > -- [RX Streamer] data_sid = 00:11>02:60 actual recv_buff_size = 33554432 > > -- [0/binAggr_0] source_block_ctrl_base::set_destination() 0.0>0.17 > > -- [0/binAggr_0] Setting SID: 2.96>0.17 > > -- [RX Streamer] resp_out_dst_sid == 17 > > -- [RX Streamer] Number of upstream radio nodes: 1 > > -- [RX Streamer] spp == 364 > > -- [RX Streamer] Flow Control Window (minus one) = 18235, Flow Control > Handler Window = 569 > > -- [0/binAggr_0] source_block_ctrl_base::configure_flow_control_out() > buf_size_pkts==18235 > > -- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 1 > > -- [0/binAggr_0] source_node_ctrl::set_rx_streamer() 0 -> 1 > > -- [0/FFT_0] source_node_ctrl::set_rx_streamer() 0 -> 1 > > -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1 > > -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 0 -> 1 > > -- [0/Radio_0] x300_radio_ctrl_impl::check_radio_config() > > -- [Device3] updating RX streamer to RX Terminator 0 > > -- New tick_rate == 2e+08 New samp_rate == 2e+08 New scaling == > 3.05185e-05 > > -- [0/binAggr_0] source_block_ctrl_base::issue_stream_cmd() > > -- [0/FFT_0] source_block_ctrl_base::issue_stream_cmd() > > -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd() > > -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a > > -- [RX Terminator 0] rx_stream_terminator::handle_overrun() > > -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a > > Ooverrun on chan 0 > > …. > > …. > > …. > > -- [RX Terminator 0] rx_stream_terminator::handle_overrun() > > -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a > > Ooverrun on chan 0 > > > > > > My flowgraph is as the following: > > > > > > How to debug and find out what is causing overflows ? > > > > But my main concern here is: after a continuous overflow messages, the > Radio seems to enter in a unresponsive mode that oblige me to reboot it. > > Does this makes sense or there is something I need to understand first ? > > Apart from executing testbenches of BinAggr RFNOC block, I thoguht I may > fix the overflow problem with interfacing the USRP with a PCIe cable > instead. Is that corect ? > > > > However, is I connect the USRP with PCIe instead, anytime an error > occurs which makes the USRP hangs (by the way, physically I see REF LED > being yellow and stays so) I think I need to reboot it and that will > cause a PCIe bus fatal error on the system even though I unlowd niusrp > kernel module before power cycling the USRP. > > I am a bit confused here because there should be another way to fix the > connection once flowgraph is not responding after overlows. > > > > Thanks and Regards, > > > > Naceur El Ouni > > NIST - Wireless Networks Division (673) > > 100 Bureau Dr. Building 222-A218 > > Gaithersburg, MD 20899 > > (301) 975-3353 > > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >