[USRP-users] Using X310/UBX Tx/Rx antenna for single channel pulsed radar

Michael West michael.west at ettus.com
Tue Oct 10 17:25:39 EDT 2017


Hi Rob,

Yes.  The queue is a simple FIFO and does no reordering, so the commands
must be in time order.  Each radio has a separate command queue, so they
will not interfere with each other.

All commands go to the same queue, whether timed or not, so care must be
taken with all commands issued to a particular radio.

Despite the downside of having to properly collate all commands issued to a
single radio, the upside is that you can use a single timed command to
block a series of commands and guarantee the sequence and timing of
operations.  For instance, you could issue a timed command to set the
switch position followed by an RX stream command that is not timed and it
will start streaming as soon as the switch is set.

Regards,
Michael

On Tue, Oct 10, 2017 at 1:33 PM, Rob Kossler <rkossler at nd.edu> wrote:

> Thanks Michael,
> So, do all "timed" commands sent to the command queue need to be in
> strictly ascending order (in time)?  In other words, will a disordered
> queue always produce a Late error or does it depend on how much disordered?
>
> Are there any other "timed" commands to worry about besides the following?
>
>    - commands sent in between set_command_time() and clear_command_time()
>    - rx and tx streaming commands that include a time_spec
>
> Rob
>
> On Tue, Oct 10, 2017 at 4:11 PM, Michael West <michael.west at ettus.com>
> wrote:
>
>> Hi Rob,
>>
>> Yes, that would be a problem.  There is a single command queue for both
>> TX and RX commands to the radio, so something has to collate the T/R
>> switching commands with the RX streaming command so none of the commands
>> arrive late.
>>
>> Regards,
>> Michael
>>
>> On Thu, Oct 5, 2017 at 7:48 AM, Rob Kossler via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Hi Marcus,
>>> Still working on the same issue (sporadically).  I was able to get my
>>> transmit pulse behaving reasonably well (using continuous Tx streaming and
>>> manually controlling the T/R switch using timed commands).  However, I ran
>>> into a problem when I tried to simultaneously stream Rx data.  The RX
>>> streaming reports a single Late command followed by numerous Timeouts.
>>>
>>> Since I am able to
>>> A) run my application in TX-only mode (with separate threads for
>>> transmit streamer and T/R switching), and
>>> B) to run in TX/RX mode without T/R switching
>>>
>>> I am wondering what is the source of my problem when I try to run in
>>> TX/RX mode with T/R switching.  I am wondering if the problem could be
>>> related to ordering of timed commands.  I have made sure that the T/R
>>> switching commands are sent in time-ascending order, but I have no
>>> synchronization between these commands and my Rx streaming command (which
>>> includes a time spec in the meta data).  So, it is possible that my
>>> application is sending a tone of T/R switching commands (filling up the
>>> timed command FIFO) prior to sending the Rx streaming command.  Would this
>>> be a problem?
>>>
>>> Rob
>>>
>>>
>>> On Tue, Sep 26, 2017 at 9:09 PM, Rob Kossler <rkossler at nd.edu> wrote:
>>>
>>>> Hi Marcus,
>>>> Thanks for your response.  I've been away for several days and finally
>>>> had the opportunity to revisit this today.
>>>>
>>>> I modified my code to manually control the TxEnable pin using timed
>>>> commands in order to pulse a continuously streaming TX waveform (100
>>>> MS/s).  This worked until I reached a limit on PRF at around 20 kHz (50 us
>>>> PRI).  When I tried to go faster (e.g., 20 us PRI), the pulse train went a
>>>> bit crazy - likely from the commands arriving late.  I'm guessing that
>>>> there is some limit to how fast I can send these GPIO commands while at the
>>>> same time streaming at 100 MS/s.  The bad news is that this was with one
>>>> channel.  So, I expect that when I implement with 2 TX simultaneously
>>>> (e.g., beamforming), I will need to send twice the number of GPIO commands
>>>> and thus my min PRI will jump to about 100 us (but I haven't tried this
>>>> yet).  By the way, this was implemented with 3.9.LTS and a single 10Gbe
>>>> link.
>>>>
>>>> The other thing I noticed was that the RF pulse width was about 300 ns
>>>> shorter than expected for the specified switching times.  The switch data
>>>> sheet indicates on/off switch times on the order of 45ns.  Thus, enabling
>>>> and disabling of the switch could account for 90 ns, but this is still much
>>>> less than the observed shortfall.  Not sure what the cause is.
>>>>
>>>> In the end, this may be good enough for my application.  Still, I may
>>>> try some things in the FPGA.
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>> On Mon, Sep 18, 2017 at 5:54 PM, Marcus Müller via USRP-users <
>>>> usrp-users at lists.ettus.com> wrote:
>>>>
>>>>> Hey Rob,
>>>>>
>>>>> so, it's probably the good ol' radar bandwidth conundrum: For good
>>>>> range resolution, you'd typically want high TX and RX bandwidth, but at
>>>>> least on TX, it feels kinda bad to stream a full 200MS/s to the USRP, just
>>>>> to be able to turn a sine wave on and off again within a few nanoseconds.
>>>>> And to confirm your suspicion: Yes, if you use a lower rate than that, the
>>>>> X310 will interpolate to the 200MS/s MCR, and that happens with a low-pass
>>>>> filter (to get rid of spectral aliasing in the general use case), and that
>>>>> "washes out" your pulses. So, meh.
>>>>>
>>>>> As long as you're not sending constantly, but more in terms of single
>>>>> pulses or short pulse packets, sending the signal at a full 200 MS/s might
>>>>> be the right thing to do – the USRP would buffer the sample packets until
>>>>> the TX timestamp "happens", and there's no unnecessarily high CPU load.
>>>>>
>>>>> You could also replace the DUC with a simple "repeat" NoC block. Or
>>>>> with an upsampler without an anti-imaging filter (ie. a zero-padder), for
>>>>> that manner. Or, upsample, but use the desired pulse shape as filter.
>>>>>
>>>>> 1) well, close reflections are usually very strong with radar. If
>>>>> you're using an external amplifier, that might be a problem.
>>>>> 2) There's a the auto-TX/RX switching functionality that you can use
>>>>> to switch when you start/stop streamers. Also, yes, antenna switches are
>>>>> just "normal" GPIO, so you can basically look into the daughterboard driver
>>>>> to see which GPIO gets toggled when you change the antenna, and do the same
>>>>> in your application.
>>>>>
>>>>> Hope that helps,
>>>>>
>>>>> best regards,
>>>>>
>>>>> Marcus
>>>>>
>>>>> On 09/18/2017 01:55 PM, Rob Kossler via USRP-users wrote:
>>>>>
>>>>> Hi,
>>>>> I am interested in implementing a pulsed CW radar using a single
>>>>> channel (X310/UBX) via the TX/RX antenna port.
>>>>>
>>>>> My initial implementation works, but not that well.  In this
>>>>> implementation, I continuously stream the receiver with antenna set to
>>>>> TX/RX and I simultaneously send timed transmit bursts for each pulse.  The
>>>>> USRP automatically switches the T/R switch to transmit during the transmit
>>>>> bursts and then back to receive when the transmit burst completes.  The
>>>>> switch time seems good enough for my application.  However, the transmit
>>>>> pulse doesn't look as expected at the beginning - likely due to start up
>>>>> filtering in the DUC.
>>>>>
>>>>> I am considering a different implementation such that transmit and
>>>>> receive both run continuously and I just manually "hot-switch" the T/R
>>>>> switch between transmit and receive using timed commands.  I have 2
>>>>> questions:
>>>>> 1) is there a problem with this approach (e.g., possibility of
>>>>> damaging the device)?
>>>>> 2) how do I manually control the T/R switch?  (I am expecting I need
>>>>> to use the GPIO registers, but I can't find the relevant info in the
>>>>> manual).
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users at lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171010/7e6a9eba/attachment-0002.html>


More information about the USRP-users mailing list