Starting to get an idea what is going on with the startup overflows
First, suppose I have a raw UHD application that does the following:
{
instantiate usrp object, set freq, gain, samp_rate
issue stream cmd to start some time in the future (2 sec)
while(1)
{
call _rx_stream->recv()
Same deal - with "num_recv_frames=128,master_clock_rate=" +
str(samp_rate*4) I still get "ODD", just about every time.
On Thu, Nov 19, 2020 at 6:52 AM Ron Economos via USRP-users <
usrp-users@lists.ettus.com> wrote:
> The automatic setting of the master clock seems to be getting in the way
> afte
The automatic setting of the master clock seems to be getting in the way
after the PPS transition. Try explicitly setting the master clock.
"num_recv_frames=128,master_clock_rate=" + str(samp_rate*4)
Ron
On 11/19/20 03:33, Josh via USRP-users wrote:
Marcus,
This is naked hardware - B210 usb
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 s
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
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 usin
