|
From: | Martin |
Subject: | Re: [Discuss-gnuradio] timed dual channel B210 capture gives error "UHD source block got error code 0x2" (ERROR_CODE_LATE_COMMAND) |
Date: | Mon, 23 Feb 2015 23:32:10 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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" MartinI 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.htmlAre 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/769I 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
[Prev in Thread] | Current Thread | [Next in Thread] |