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
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment