[USRP-users] E3xx second channel rx_stream setup for calibration channel

Prager, Samuel M (334E) samuel.m.prager at jpl.nasa.gov
Tue Jul 11 13:51:30 EDT 2017


Hello,

We are using our E312 with RFNoC (UHD_4.0.0.rfnoc-devel-931-g0077f0d3) as a stepped frequency LFM radar with a master clock rate of 50MHz and would like to use the second RX channel to obtain a calibration pulse through external loopback each time we tune to a new frequency. So far we have tried

1) Setting up the rx_stream object as a 2 channel streamer ie with:
        rx_stream_args.channels.push_back(radio_chan);
        rx_stream_args.channels.push_back(calib_chan);
        rx_stream = usrp->get_rx_stream(rx_stream_args);

However, with this configuration, UHD throws the following error:
Error: ValueError: current master clock rate (50.000000 MHz) exceeds maximum possible master clock rate (30.720000 MHz) when using 2 channels

We can decrease the clock rate, but It looks like issue_stream_cmd() and recv() are always called on both channels - we only need one calibration pulse for every thousand or so pulses, so this seems like a huge waste of bandwidth.

Is there any way to decouple the two channels so that these calls can be made on one channel or the other?

2) Resetting and reconfiguring rx_stream for each channel using stored arguments ie.

    if (rx_stream)

        rx_stream.reset();

    rx_stream = usrp->get_rx_stream(_rx_cal_stream_args);



    ... Receive Calibration Pulse...



    if (rx_stream)

        rx_stream.reset();

    rx_stream = usrp->get_rx_stream(_rx_stream_args);



This seems like it causes a lot of overhead for what we are trying to do.  And after this is done four times, the following error is thrown:

DRuntimeError: No more free DMA channels available.



What is the proper way to reset an rx_stream so that this doesn't happen?


Is there a simpler way to achieve this without all of the additional overhead? We really just want to get a reference to correct for the LO phase at each tuning. Can the radio channel of an existing rx_stream be 'switched'? Or is there perhaps a loopback register in the AD9361 that we could expose?

Any guidance is appreciated!

Thanks,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170711/fad3b089/attachment-0002.html>


More information about the USRP-users mailing list