Hmmm. I'm not sure. Here are a few comments: - Try running without "second_addr". I realize that you will need it for full rate (4 x 100MS/s for each X310), but you could run at 50 MS/s without second_addr - Try running without shared LO. I don't think you would need to physically change any sharing cables. - I am curious why you needed to modify the streamer, pointer buffer and file writing. I would expect that this would scale with the number of channels such that you didn't need to modify any code in this area - If you were using a more recent UHD, I would recommend switching to the example benchmark_rate which natively supports external PPS and multiple devices. I noticed that even the most recent rx_samples_to_file does not support external PPS (without modifying the code) - I know you mentioned you were unable to upgrade because of compatibility constraints. But, even if you cannot upgrade the OS, would you be able to install a new UHD - perhaps in a local folder that did not interfere with the system-wide UHD 3.12 installation. I typically have multiple UHD versions on my system and switch among them by "sourcing" a given setup file as needed.
On Fri, Dec 15, 2023 at 12:52 AM Anabel Almodovar < [email protected]> wrote: > Dear Rob, > > Yes, I use an external clock configuration. > > *std::this_thread::sleep_for( std::chrono::milliseconds(int64_t(1000 * > setup_time) );* > > > > *usrp->set_clock_source("external", uhd::usrp::multi_usrp::ALL_MBOARDS); > usrp->set_time_source("external", > uhd::usrp::multi_usrp::ALL_MBOARDS);usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));std::this_thread::sleep_for(std::chrono::seconds(1));* > > I have only modified the code to get 8 channels and LO sharing. I want to > get a continuous acquisition setup without losing samples. But I am > starting with something basic at the moment. Any suggestions are welcome. > So I've modified the streamer, the pointer buffer, and added writing files. > > my line is > *$sudo ./rx_samples_to_file_v1 > --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=900000000" > --subdev="A:0 A:1 B:0 B:1" --channel="0,1,2,3,4,5,6,7" --freq 800e6 --rate > 25e6 --bw 25e6 --gain 70 * > > Regards, > > *Anabel* > > > > El jue, 14 dic 2023 a las 18:25, Rob Kossler (<[email protected]>) escribió: > >> Hi Anabel, >> In my opinion, the error you are experiencing has nothing to do with >> streaming performance settings (such as "performance" governor, network >> descriptors, MTU size, etc). The issue seems to be that the two X310 >> devices do not have synchronized clocks. In addition to the physical >> synchronization using OctoClock, you must also configure each device to use >> external synchronization and you must tell each device to reset its FPGA >> clock count at a common PPS. The typical sequence is: (1) wait for a PPS to >> occur (by querying either device), (2) tell each device to reset its FPGA >> clock at the subsequent PPS (this step must complete before the next PPS >> arrives). >> >> You mentioned that you are using rx_samples_to_file. Did you modify it in >> any way? What is your exact command line with all parameters? >> Rob >> >> On Thu, Dec 14, 2023 at 10:29 AM Anabel Almodovar < >> [email protected]> wrote: >> >>> Dear Rob >>> >>> Thank you for your answer. >>> I make use of the CDA-2990 octoclock as a source of synchronization >>> between both USRPs, in addition to local oscillator sharing. I use dual >>> 10GigEth connections and a MTU of 9000 to connect the USRPs to the PC. >>> >>> Due to various compatibility issues I am unable to upgrade the system. >>> >>> When I work with a sample rate of 10MSps I don't get problems but when I >>> increase to 25MSps I start to get the error. I need them working with >>> 100MSps. I have tried changing the CPU governor to "performance" to get the >>> maximum working frequency (*sudo cpupower frequency-set --governor >>> performance*), as well as changing the number of network interface >>> descriptors to maximum (*sudo ethtool -G <interface> tx <max> rx <max>*), >>> or increasing the dirty memory buffer (*sudo sysctl -w >>> vm.dirty_ratio=80; sudo sysctl -w vm.dirty_background_ratio=50*), but I >>> still get the same problem. >>> >>> Regards, >>> Anabel >>> >>> El jue, 14 dic 2023 a las 15:38, Rob Kossler (<[email protected]>) >>> escribió: >>> >>>> Hi Anabel, >>>> How are you sync-ing the clocks on the two units? Do you have an >>>> external PPS source and are you configuring both devices to use this >>>> external source? >>>> >>>> Finally, do you have the ability to upgrade your OS and your UHD >>>> versions? There aren't many user's that are using UHD 3.12 so if you have >>>> issues, it will be hard to get support. >>>> Rob >>>> >>>> On Thu, Dec 14, 2023 at 5:20 AM Anabel Almodovar < >>>> [email protected]> wrote: >>>> >>>>> Dear all, >>>>> >>>>> I am trying to make an acquisition with two X310 equipped with two >>>>> TwinRx. I am using Ubuntu 16.04 LTS 64-bit and UHD 3.12. My PC contains >>>>> 128GB RAM and an Intel® Xeon(R) Silver 4114 CPU @ 2.20GHz × 40 and a 4TB >>>>> SSD. I have modified the example rx_samples_to_file.cpp code to get 8 >>>>> channels and I get the following error: >>>>> >>>>> *D* >>>>> *[ERROR] [STREAMER] The receive packet handler failed to time-align >>>>> packets. 1002 received packets were processed by the handler. However, a >>>>> timestamp match could not be determined.* >>>>> *Timeout while streaming* >>>>> >>>>> *[ERROR] [X300] 192.168.60.2 <http://192.168.60.2>: x300 fw >>>>> communication failure #1* >>>>> *EnvironmentError: IOError: x300 fw poke32 - reply timed out* >>>>> *[ERROR] [UHD] An unexpected exception was caught in a task loop.The >>>>> task loop will now exit, things may not work.AssertionError: >>>>> reply.sequence >>>>> == request.sequence* >>>>> * in virtual void >>>>> x300_ctrl_iface_enet::__poke32(uhd::wb_iface::wb_addr_type, uint32_t)* >>>>> * at >>>>> /home/rs3_lab/workarea-uhd/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:135* >>>>> >>>>> I don't know how to solve the Timeout problem, I have tried to start >>>>> the acquisition 1.1 sg in time. But it didn't work. >>>>> >>>>> >>>>> * stream_cmd.stream_now = false; stream_cmd.time_spec = >>>>> usrp->get_time_last_pps(0)+1.1;* >>>>> >>>>> What is the problem and how can I fix it? >>>>> >>>>> Regards, >>>>> Anabel >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
