Timed dual channel B210 capture gives error "UHD source block got error code 0x2" (ERROR_CODE_LATE_C

GNU Radio
1

When you start a dual channel timed capture in the near future with a
B210, the work method of usrp_source_impl.cc prints out

“UHD source block got error code 0x2”

error codes are defined in:
metadata.hpp line 99:
//! A stream command was issued in the past.
ERROR_CODE_LATE_COMMAND = 0x2,

No matter what starttime (in the future) was chosen, UHD always thinks a
command is scheduled to be run in the past (too late)

When I do the same with a single-channel script on the same B210
everything works fine without errors.

The dual channel always prints out the error, and the single channel
always seems to work fine.
I have tried different settings for the delay, which sets how long in
the future the capture is set to start.
But 0.1 0.2 1.0 2.0 5.0 seconds all seem to fail.

I also tried with or without using 1 PPS to set the clock time, but that
did not help either.

code snippet:

usrp_source_impl.cc
line 663:
switch(_metadata.error_code) {
…
line 692:
default:
std::cout << boost::format(“UHD source block got error code 0x%x”)
% _metadata.error_code << std::endl;
return num_samps;

I created an issue on gnuradio.org and attached example python scripts
there to demonstrate the error. Dual channel script fails, single
channel works.
http://gnuradio.org/redmine/issues/769
The defaults are fine for demonstrating the behaviour so you do not need
to give any arguments.
Note that I used a B210 with an embedded GPSDO, which might be
important.

It is also very possible that I am doing something very wrong.
Please let me know.

With best regards,

Martin Dudok van Heel

2

Small addition.
I just want to start capturing on both channels of a B210 at the exact
same time. I do not mind which time that is, as long as the samples are
aligned.

I have read a discussion on this mailinglist which made it clear that
you do need to set a start_time (timed_capturing) with dual-channel
capturing with a B210 to have both channels synchronized.
You should not set the internal B210 clock with set_time_now, since this
would set a slightly different time in the two different channels.
This would then result in a random clock misalignment betwen the
channels of up to 250 usec.

it was advised to use set_time_unknown_PPS or leave the time at the
default internal initiated time. This way both channels should have an
aligned internal clock.

Then using a start_time in the near future should result in perfectly
aligned captures. But as I said in my previous mail, this results (for
me) in the UHD error.
“UHD source block got error code 0x2”

Martin

3

On 02/22/2015 04:26 PM, Martin wrote:

This would then result in a random clock misalignment betwen the

Martin

I use a GR flow-graph to do this for interferometry, without having to
specify anything special.

I use a subdev spec of “A:A A:B” and specify two channels in the source
block. Everything lines up nicely. You might look at the code that
situation generates if you’re hand-coding.

4

On 22-02-15 22:35, Marcus D. Leech wrote:

this would set a slightly different time in the two different channels.
“UHD source block got error code 0x2”

Martin

I use a GR flow-graph to do this for interferometry, without having to
specify anything special.

I use a subdev spec of “A:A A:B” and specify two channels in the source
block. Everything lines up nicely. You might look at the code that
situation generates if you’re hand-coding.

Thanks for the tip. I am going to test this.

I read the following thread on the usrp-users list which suggests
several (counterintuitive) things you need to do right to get
sample-aligned dual-channel capturing on B210:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011360.html

Are you sure that you get sample-aligned samples without using a
start-time. The thread mentioned above suggests that you could get up to
250 usec time difference between the channels.

Note that I generated the basis for my flowgraph with GRC and manually
added the start_time code.

See my code as attachments at:
http://gnuradio.org/redmine/issues/769

I hope that you are right and that I do not need the start_time code for
this application.
But even if I do not need it. I think it should work without errors. For
some (other)applications I actually do need timed capturing.

Thanks,

Martin