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