The mapping of channel to radio is a bit muddied. In most cases, each channel will map to a different radio by default. The exception is TwinRX. In that case, each pair of channels is mapped to a radio. And yes, a stream command for multiple channels will duplicate the commands to all radios.
All commands boil down to peeks and pokes. All peeks and pokes will execute even if late, but will be held and block the command FIFO if early. The stream command is actually a series of pokes to the RX control. The pokes include the time at which the streaming is supposed to start. The RX control generates the error if the bit to send immediately is not set and the time poked into its time registers is late. (See the FPGA code here: https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/radio/rx_control_gen3.v ) Regards, Michael On Tue, Oct 10, 2017 at 2:39 PM, Rob Kossler <rkoss...@nd.edu> wrote: > 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
