On Tue, May 2, 2023 at 3:25 PM <ri28...@mit.edu> wrote:

> Try interpolating on the host to 200 Msps and see how things go.
>
> I’m not sure what you are suggesting. If I take the “bad” recorded file
> and I interpolate from 25 to 200 Msps, it’s not going to make chopped tail
> the appropriate width.
>
> I also can’t just run the USRP at 200 Msps, because I’m using a UBX-160
> daughterboard which has an analog bandwidth of 160 MHz.
>
Sorry, I meant on the transmit side.  Try transmitting at 200 Msps always,
and do your own interpolation.  That way you bypass the DUC.  You'll
probably run into some similar issues where you expect to transmit 8*1000
samples, but you'll see your transmission get cut off if you do that.  Play
around, see what works for you.

> I think I’m just asking the wrong question somehow. I can’t be the only
> person to have ever tried to write a UHD application and asked “Why is my
> signal shifted by a constant group delay? Why are my final 20 or so samples
> always chopped off?”
>
> I would expect UHD to handle these transparently for me. If there is a
> constant group delay, why doesn’t the timestamp get decremented by N clock
> ticks? If there are X taps in the transmit chain filters and I requested to
> transmit 1000 samples, why aren’t the 1000 samples transmitted taken from
> the useful part of the filter convolution? Do I have to always instead
> transmit 1020 samples at the application layer?
>
> I understand that there are different devices and different configurations
> of devices. But there’s nothing stopping UHD on the host software side from
> reading a register to learn some information about the configured device.
>
UHD could try to guess what it wants to do for you, but it's probably not
what it wants for someone else.

> It may also be because of the RFNoC stuff it’s complicated for the host
> software to figure out some of these values. Even if it can’t be
> automatically figured out in software, I would not expect the answer to be
> “read the Verilog for the Tx filter chain and determine how many taps
> exist” for the average user. Is there an application note that talks about
> best practices somewhere?
>
Not that I'm aware of.

You can get around the RFNoC DUC issue yourself by writing your own
interpolation block - or your own modulation block - and output at 200 Msps
the exact samples you want to transmit.  Beyond that, it just seems like
some assumptions that Ettus/UHD made aren't what you expect.

Brian
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to