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 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