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.
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
