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