On Tue, May 30, 2023 at 11:15 AM Mena Ghebranious <m...@chaosinc.com> wrote:
> If possible, I'd like to hear what the R&D team thinks - I have worked > with designs in the past where the TX timing lines up and there are no > samples cut off. > > On Tue, May 30, 2023 at 8:08 AM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 30/05/2023 11:02, Mena Ghebranious wrote: >> > Hi Marcus, >> > >> > I took a closer look at the end of my transmission; what originally >> > appeared to be a lack of symmetry between the start and end delays is >> > actually a cutoff of 31 samples at the end of the transmission - in >> > other words, I'm missing the 31 samples at the end of the TX that I >> > put into the TX streamer. >> > >> > Looking into the FPGA logic, I believe there is actually a bug in the >> > most recent implementation - the transmission strobe that controls the >> > TX output is based on the TX state machine in the radio TX core block, >> > who's timing does not take into account the group delay of the DUC >> > filter. Regardless of whether or not we are using ATR to control >> > GPIOs, the transmission gets cut off and the last set of samples do >> > not appear at the TX output (the number of samples missing is equal to >> > the group delay / latency of the filter for a given sample rate.) >> > >> > As a temporary workaround, we could zero pad the end of our TX >> > waveforms, but some of the waveforms we want to run have tight PRFs >> > and this will heavily limit the rate at which we could run them. >> > >> I don't recall there *ever* being a time when the TX state machine >> "knew" the state and depth of the DUC filters, which is why >> nearly-everyone zero-pads their bursts. This has been a "thing" >> with radio hardware at various times scales over the decades >> for systems transmitting digital data. >> >> I'm pretty sure that R&D would consider this behavior "design intent". >> Partially because "it's always been done that way", and >> partially because "fixing" it would be challenging (it would require >> re-architecting parts of the FPGA chain considerably, I think). >> > Not being part of Ettus/NI R&D, but just observing the conversation - the answer is to use the native sample rate and bypass the DUC. If zero stuffing with the group delay of the DUC is unacceptable due to PRF, but band limiting the transmission is still required, then it needs to be up to the user to do it in a way that suits their application. Right? Alternatively, even if the ATR switch is ideally turned on at the beginning of the burst - i.e. while the state of all DUC filtering is 0's and the first non-zero sample enters the DUC chain - and the ATR switch is ideally turned off at the end of the burst - i.e. when the state of the DUC filtering is all 0's - you'd still have the PRF issue, right? I think, in my mind, the only solution is to fix your system to run at the highest possible sample rate and avoid the DUC. Brian
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
