Hello Jens, so, let's talk a short bit about architecture:
The X3x0 is a very FPGA-centric architecture. There's a CPU inside the FPGA image (the ZPU) that is used for all kinds of "housekeeping", basic setup and such. After the FPGA is configured from flash, that CPU starts running the firmware. UHD/LV itself talks through ethernet or PCIe to that firmware, and peeks or pokes registers [1]. The firmware [2] itself is attached to a simple bus that talks to settings registers in the rest of the FPGA. So much for the theory. Now, sadly, from the errors alone you can't tell what's going wrong. Might be a communication breakdown, might be some kind of deadlock, because you made the firmware read something that blocks, or so. Hard to say from the top of my head! Or, you found some incompatibility between the FPGA image that LV uses and what your UHD application expects. So, my foremost question would be: am I understanding this correctly, you're using the same USRPs with both LV and a directly UHD-linking software? Best regards, Marcus [1] uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp [2] uhd/firmware/usrp3 On 24.08.2017 17:43, Jens Abraham via USRP-users wrote: > Hello everyone, > we have a couple of X310 connected via PCIe to a Windows host and I’m trying > to get a slightly more elaborate multi USRP example up and running to dump IQ > data from multiple radio chains. Somehow stuff seems to work alright for a > single radio with two RX chains at 10 MSamples/s or 8 RX chains at 4 > MSamples/s (after a switch to the 3.10.2 UHD driver). Building a compound > device with up to 7 X310 (e.g. 14 rx chains) seems to work fine in the > initialisation phase even though I’m running into overflow issues which might > be related to my usage of recv() and the buffers in the background. I’ll have > a look at the kitchen_sink example that Rob pointed out to see if that might > help with that issue. > > Long story short, above 7 X310 the driver seems to have issues keeping the > parallel communication going. I’ll receive a lot of the following errors: > > UHD Error: > x300 fw communication failure #1 > EnvironmentError: IOError: x300 fw poke32 - operation timed out > > or > UHD Error: > x300 fw communication failure #1 > EnvironmentError: IOError: x300 fw peek32 - operation timed out > > I’m guessing that this is somehow related to how the driver handles the > compound USRP device or some misconfiguration on our side. > Can anyone tell me what the errors actually mean? > Do you have any suggestion how to avoid running into those issues e.g. where > do they come from? > > Our host is running LV Comms with NI drivers in parallel but afaik the UHD > application shouldn’t be confused by that as I’m building against the 3.10.2 > UHD and the application output shows that it uses the current lvbit file from > the runtime folder. > > Thank you in advance, > Jens > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
