Marcus, This is naked hardware - B210 usb into a pretty beefy laptop running Ubuntu 20.04, GNU Radio latest master (3.9) Even with num_recv_frames = 128, still getting "ODD" at startup of the flowgraph
Any other optimizations I should be tuning? Getting no overruns in the steady state, just at startup. Flowgraph is attached. Josh On Wed, Nov 18, 2020 at 4:46 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 11/18/2020 07:27 AM, Josh via USRP-users wrote: > > I'm seeing a difference in behavior between gr-uhd and plain uhd c++ api: > > Setup: > B210, 2 channels, 5MSPS, master_clock_rate 20MSPS, PPS sync > Receive only flowgraph > > With gr-uhd, there is always a "OOD" when the flowgraph first starts > > But, if I replicate the setup in a simple compiled program using the uhd > API with all the same settings, this never occurs. > > So my question is - is the GR scheduler doing something at the beginning > of the flowgraph that delays the work() calls and causes overflows, and are > there settings I use to mitigate this? My problem is that once these > overflows occur, I can't trust my timing synchronization on the received > samples (or have to do further calculations on the rx_time tags). > > Thanks, > Josh > > > _______________________________________________ > > > Try specifying "num_recv_frames=128" in your device arguments. > > Also, are you running this on naked hardware or through a VM? > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
test_usrp_rx.grc
Description: application/gnuradio-grc
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
