Re: [Discuss-gnuradio] timed dual channel B210 capture gives error "UHD source block got error code 0x2" (ERROR_CODE_LATE_COMMAND)

[Martin]

On 22-02-15 22:35, Marcus D. Leech wrote:
> On 02/22/2015 04:26 PM, Martin wrote:
> > 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
> 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


> > On 22-02-15 21:53, Martin wrote:
> > > 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
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio