Hi Marcus,
> Theoretically, there'll be analog group delays that will add some
> harder-to-predict latency, but they'll be much smaller than the
> time interval represented by the timestamps.
Ok, we can consider those analog delays negligible. Sorry to insist but, do
I still need to compensate for the digital rx path delays then? So far I'm
assuming uhd::rx_metadata_t::time_spec value refers to whenever the first
sample enters the kernel radio buffer.
If you use a timed command to set the gain, then you can at least get a
> bound on which samples are likely to represent the post-gain-change.
But given that this is an analog process, there'd be almost no way to
> get down-to-the-sample precise.
>
Well, I overlooked those commands all these years. UHD drivers never ceases
to amaze me.
However, are you sure this should work with *set_rx_gain* command? I can't
make it work.
I configured the streamer as follows:
*uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);*
*uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);*
*stream_cmd.num_samps = num_samples;*
*stream_cmd.stream_now = true;*
*rx_stream->issue_stream_cmd(stream_cmd);*
I set commands to increase the gain linearly with time (3 dB every one
second), rx_gain = 3 * t:
*const uhd::time_spec_t now = usrp->get_time_now();*
*for (int i = 0; i < 16; ++i) {*
* usrp->set_command_time(now + uhd::time_spec_t(i * 1.0));*
* usrp->set_rx_gain(3*i);*
*}*
*usrp->clear_command_time();*
Then I start a capture of 20 seconds straight away, but there are no
changes in the received power signal whatsoever. The actual applied gain
during the whole capture is the last configured/commanded value (g=48), as
if the set_command_time instruction was completely ignored.
Regards,
Brais.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
