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). > > >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
