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.w...@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 <rkoss...@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.w...@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@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
