After a bit of digging and comparing to 3.7, it seems like this is due to a regression in gr-runtime introduced in 254fe5e, specifically in tpb_thread_body.cc with the BLKD_IN case and 250 ms timed_wait.
I put some debug statements in the work function of the usrp_source and discovered that when I have it start a few seconds in the future, work was hardly getting called before the USRP started producing samples. For example if the USRP is told to start in 2 seconds, work was only getting called 5 times during those 2 seconds. With the same setup in 3.7, work was called 20 times - which makes a lot more sense given the 0.1 sec recv timeout. It seems like instead of trying to read in samples the block was stuck waiting...then once samples were available, we were already too far behind to catch up (hence the initial overflows). I've verified that reverting tpb_thread_body.cc fixes this. -Michael On Sun, Jan 19, 2020 at 2:02 PM Michael Wentz <[email protected]> wrote: > Hi, > > I recently updated to GNU Radio 3.8 and noticed some code that receives 2 > channels from a B210 is now always printing a single overflow (O) followed > by two drops (DD) right after the flowgraph starts. This happens regardless > of the sample rate and only when using 2 channels. It also doesn't happen > outside of GNU Radio; the UHD examples benchmark_rate and rx_multi_samples > never show overflows or drops. I've tested under macOS 10.14 and RHEL 7, > both with UHD 3.15. I also tried downgrading to GNU Radio to 3.7.13.5 and > problem goes away, so it seems like a GR issue and not UHD. > > In debugging with a file meta sink I've found that the first header for > both channels always shows 38760 items before it gets a new tag. I did some > more testing with a very simple flowgraph of just a USRP source and null > sink. With 1 channel I can stream 20 MSPS without problems. With 2 channels > I tried rates 250 KSPS to 4 MSPS and saw the same behavior every time. > > I thought that maybe the device was starting to stream before the > flowgraph was ready, so tried setting a start time several seconds in the > future, but that didn't make a difference. I also tried resetting the B210 > and the host USB subsystem. > > Any idea what could be going on? A snippet of how the 2 channel B210 is > set up by GRC is below. > > Thanks, > Michael > > --- > > self.uhd_usrp_source_0 = uhd.usrp_source( > ",".join(("", "")), > uhd.stream_args( > cpu_format="sc16", > args='', > channels=[0,1], > ), > ) > self.uhd_usrp_source_0.set_center_freq(1e9, 0) > self.uhd_usrp_source_0.set_gain(0, 0) > self.uhd_usrp_source_0.set_antenna('RX2', 0) > self.uhd_usrp_source_0.set_center_freq(0, 1) > self.uhd_usrp_source_0.set_gain(0, 1) > self.uhd_usrp_source_0.set_antenna('RX2', 1) > self.uhd_usrp_source_0.set_samp_rate(1e6) > self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec()) >
