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

Rob Kossler rkossler at nd.edu
Thu Oct 5 10:48:58 EDT 2017


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171005/afd206dd/attachment-0002.html>


More information about the USRP-users mailing list