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@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@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to