On 30/05/2023 11:13, Mena Ghebranious 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.
I already have a feeler into R&D on this. But historically it has
"always been done this way".
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
