We originally tried using the timed commands to control the GPIO, and also had the same issue regarding command queue overflow when transmitting many small packets.
Even if we could manage the queue depth to avoid overflows, the concern would be that if one the timed commands to set the GPIO was not processed (due to a late time error, for example), we would damage our front end. So we decided that, save for our own custom FPGA implementation, the ATR approach was the best option. I agree that having a configurable delay on the ATR mode would be very helpful. That being said, I am still perplexed by the lack of symmetry of the delay on the back end of the transmission. I’m not sure what is meant by ‘analog switching effect’ (I’m an FPGA/software guy, not an RF guy). On Thu, May 25, 2023 at 7:15 AM Leon Wabeke <lwab...@csir.co.za> wrote: > We also used timed GPIO to generate certain strobes, however I found at > some point that I could not generate more than about 6k strobes per second > on an X310 (if I recall correctly) (that was with about UHD3.13 if I recall > correctly, thus things might have changed) using the timed commands, or I > ended up overflowing the command queues. Thus we decided in applications > where we need more individual transmits per second (many small packets), we > needed to switch to using the automatically generated strobe and handle the > misalignment that arose from that. > > > > *From: *Marcus D. Leech <patchvonbr...@gmail.com> > *Date: *Thursday, 25 May 2023 at 15:50 > *To: *Rob Kossler <rkoss...@nd.edu>, Leon Wabeke <lwab...@csir.co.za> > *Cc: *usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> > *Subject: *Re: [USRP-users] Re: N320 - GPIO ATR output to TX output delay > > On 25/05/2023 09:41, Rob Kossler wrote: > > I may be off-base here, but I thought that the GPIO control occurred from > the Radio block such that a DUC group delay would not be the place to look. > I am wondering if the GPIO control does not use timed commands. Instead of > the automatic setting of the Tx GPIO, we have used custom GPIO with timed > commands to pulse a GPIO bit as a trigger at the same time as we begin the > radios. But, I have not checked the relative timing between my GPIO pulse > and the RF because I was only interested in repeatability rather than > knowing the precise relative timing. > > It was certainly the case in the past that the ATR logic was somewhat > asynchronous to the state of the DUC. This may well have > changed while I wasn't paying attention. Since I'm not in R&D, and not > an FPGA guy, this could be the case. > > Regardless, my point about T/R control signals occurring > not-precisely-aligned with when sinusoids are coming out the antenna > port remains. It will always be tricky to get it "exact". > > > > > > > > On Thu, May 25, 2023 at 4:55 AM Leon Wabeke <lwab...@csir.co.za> wrote: > > Hi > > > > We have also used a “measure in the lab approach”, together with zero > padding before and after and have at times seen these need to be adjusted > after a UHD upgrade. > > > > We have also in some cases taken the GPIO strobe via another FPGA to > adjust the strobe by adding an extra configurable delays on rising and > falling edges. It is just annoying to use an external function to do this > and it would in my opinion be a very useful feature if such configurable > delays were part of the basic built-in GPIO functionality at least in terms > of the “automatic strobe state machine”, thus not requiring another FPGA or > having to try to integrate custom logic inside the UHD firmware, which > might need to be reintegrated on subsequent updates. > > > > Thanks > > Leon > > > > *From: *Marcus D. Leech <patchvonbr...@gmail.com> > *Date: *Wednesday, 24 May 2023 at 23:14 > *To: *usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> > *Subject: *[USRP-users] Re: N320 - GPIO ATR output to TX output delay > > [The e-mail server of the sender could not be verified (SPF Record)] > > On 24/05/2023 16:22, m...@chaosinc.com wrote: > > Thanks. Two follow up questions: > > 1. For a given sample rate, is there a way to deterministically > calculate the group delay? > > Look at the filter code in the version of the FPGA image that you're > using, determine which filter bits and > pieces are "in circuit" when you select your sample-rate, and calculate > the group delay from that. > > Many folks who have run into the same problem have used a "measure it in > the lab" approach, and done > that for new releases of the FPGA code--the R&D team does occasionally > make changes to the filter > parameters and "doctrine" in order to optimize for certain types of > applications. This may well > de-optimize for others. SDRs are general-purpose devices, which means > that there will be cases where they > aren't "out of the factory" optimized for any *particular* application. > > The approach some have take is to pad at one end or the other (or both) to > account for these delays, which comprise > a deterministic-but-version-dependent component, and an analog component > that is less deterministic, but at much > smaller times scales. > > > > 1. Why do I not see the same delay at the back end of the transmission > (i.e. after the GPIO goes low)? > > My suspicion is that part of what you're seeing is an analog switching > effect, and things like turn-on/turn-off > times are not perfectly symmetric. > > This issue (lack of tight synchronization between ATR signals and actual > waveforms appearing at the antenna) has been > an issue in digital comms since I got involved in the 1980s, albeit, in > the 1980s, the time-scales were much larger. > You simply had to account for these effects for every new radio your > application encountered. In the DSP age, the > effects are at much smaller time-scales, but so are the data rates. > > > > > _______________________________________________ > > USRP-users mailing list -- usrp-users@lists.ettus.com > > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
