Re: [USRP-users] Passing arguments to an RFNOC block

2019-03-01 Thread Paul Boven via USRP-users
Hi again, After way too much time spent trying to debug my issues, and renaming all the variables, I wasn't getting anywhere. Then I discovered xmllint which pointed out a few (!) more xml errors in a completely different section of the rfnocblock XML file. After fixing this, I've got the res

Re: [USRP-users] Hardware clocks, X310

2019-03-01 Thread Cherif Diouf via USRP-users
Ian and Jason, So if I understand Although if it possible to work with different clock domains, and while some examples are available for such scenario, it would be preferable to keep working with the same 200 MHz reference and only switch to another frequency only when it is really needed. M

[USRP-users] Problems getting started with N310 (Could not find MAC address for IP address 192.168.20.1)

2019-03-01 Thread Janos Buttgereit via USRP-users
Hi, I’m about to port an application that was working with a setup of two X300 devices to a new N310 device. For a first step the N310 should simply be used to stream four RF channels to a host. However before using it for streaming I wanted to perform some simple operations like getting the d

Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Jason Matusiak via USRP-users
Probably not the approved way, but I made an FFT 2048 block a while back. I didn't much with packet sizes or anything, I just sucked in two 1024 packets, did the FFT, and then sent two 1024 packets back out. It seemed to work fine. The only issue is that you have to remember downstream that y

Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Rob Kossler via USRP-users
Turns out there was a surprisingly simple modification to allow FFTs longer than 1024. The axi_wrapper will automatically resize packets for you if you configure it to do so. All I had to do was set RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output packets to be resized to

Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Jonathon Pendlum via USRP-users
Hi Rob, I'm glad you found those options useful. Unfortunately, there are a number of corner cases that those options do not handle. You can run into synchronization issues when overflows and dropped packets occur. In the overflow case, if one occurs while the FFT is being filled then the next FFT

Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Sylvain Munaut via USRP-users
> but I think for general usage the block will need to be updated to handle > them properly. Just my 2ct, but I think RFNoC globally would benefit from a way to handle larger vector size split across packets.Even in some limited form, like for instance some config register that would say that pac