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

Rob Kossler rkossler at nd.edu
Tue Oct 10 17:39:30 EDT 2017


Thanks again.  Two more clarifications...

   - When you say each "radio" has a separate queue, does that translate
   into each "channel" has a separate queue?  Assuming so, then I suppose a
   streaming command that is for multiple channels will create an entry in
   each of the queues.
   - If successive commands in the same queue have identical time specs
   (e.g., an rx streaming command, a tx streaming command, and a timed GPIO
   switch command), am I basically guaranteed that the 2nd or 3rd successive
   command will not be Late?

Rob

On Tue, Oct 10, 2017 at 5:25 PM, Michael West <michael.west at ettus.com>
wrote:

> 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/678c9706/attachment-0002.html>


More information about the USRP-users mailing list