Hi Rob Many thanks for your response. The change in syntax seemed to do the trick!
Oliver From: Rob Kossler [mailto:[email protected]] Sent: 16 March 2021 18:22 To: Oliver Towlson <[email protected]> Cc: Marcus D Leech <[email protected]>; [email protected]; Tom Stacey <[email protected]> Subject: Re: [USRP-users] Re: X310 with dual TwinRX set up Hi Oliver, This is with a single X310 with 2 TwinRx? I noticed in the python you have addr0 and addr1 both set. This is the syntax used when there are multiple X310, not a single x310. With a single X310, you should use addr=xxx, second_addr=yyy. In fact, maybe just try it first without "second_addr" as long as your data rates are at or below 50 MS/s on 4 channels. Rob On Tue, Mar 16, 2021 at 2:06 PM Oliver Towlson <[email protected]<mailto:[email protected]>> wrote: Hi Thanks so much for your responses. I tried not setting the master clock rate, and reducing the sample rate to 500kS/s but still got the same error message. I had an external clock source connected so I disconnected that and then also did not specify the clock or time source – same error message. I also tried only grabbing data off a single channel, but got the same error. I did have some success running the example Python script rx_to_file.py though, and that seemed to run ok and produce a binary file without a problem. That script isn’t much direct use though as it seems to be calling the uhd libraries directly so I’m not sure what I could edit I’ve attached the Python script we have so far for our X310 data collection for 4 channels. Any insight anyone has would be greatly appreciated – have we made an obvious mistake? Thanks very much Oliver From: Marcus D Leech [mailto:[email protected]<mailto:[email protected]>] Sent: 12 March 2021 15:22 To: Rob Kossler <[email protected]<mailto:[email protected]>> Cc: Oliver Towlson <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [USRP-users] Re: X310 with dual TwinRX set up Also try running at a lower sample rate at first. Just to see that you have the logic correct. Sent from my iPhone On Mar 12, 2021, at 9:18 AM, Rob Kossler <[email protected]<mailto:[email protected]>> wrote: Is there any chance that your code is attempting to set the master clock rate? If so, perhaps see what happens if you don't set it in order to let it be set automatically. On Fri, Mar 12, 2021 at 8:55 AM Oliver Towlson <[email protected]<mailto:[email protected]>> wrote: Hi everyone Thanks so much for your quick responses. Seems like the thing we were missing was that subdev spec – once that was set it was straightforward to generate the code. We tried running it and got the following: [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5 [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000) [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1317 MB/s) [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1301 MB/s) [INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001) [INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001) [INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000) [INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000) [INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000) [INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000) [WARNING] [X300] Cannot update master clock rate! X300 Series does not allow changing the clock rate during runtime. terminate called after throwing an instance of 'uhd::io_error' what(): EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response packet - AssertionError: bool(buff) in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned int] at /build/uhd-FRfZNJ/uhd-3.15.0.0/host/lib/rfnoc/ctrl_iface.cpp:151 Aborted (core dumped) Googling didn’t result in any answers beyond resetting the whole device. But it does seem like a common error. As you say, the 4xRF_in set-up is fairly standard so I’m not sure what is causing the issue. The example rx_samples_to_file script runs fine (although it doesn’t seem to write anything, but it does seems to stream data fine) Let me know if you need any more information. Thanks very much Oliver P Please consider the environment before printing this e-mail. _______________________________________________ USRP-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ USRP-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> P Please consider the environment before printing this e-mail. P Please consider the environment before printing this e-mail.
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
