I have a very similar app, but I do take a bit of a different approach.
I dont know that any of these issues are related to your implementation, but I will give you some insights into how I implemented my approach. Simple thing first, set_time_unknown_pps can take up to 2 seconds to execute, so I would increase your sleep time to something like this: // Next, we want to set ALL MOTHERBAORD clocks to the same time based on the 1PPS signal. g_usrp->set_time_unknown_pps( uhd::time_spec_t( 0.0 ) ); // Syncing to unknown pps can take up to 2 seconds, wait a bit longer to be sure... std::this_thread::sleep_for( std::chrono::milliseconds( 2100 ) ); Some things happen on a motherboard level, some things happen on a daughtercard level... You may want to check the ref_locked flag on each motherboard before proceeding to insure clock source sync... I think you are only setting the frequency on channel 0... Check the API, but I think set_rx_freq takes a channel number... I think this is your main problem... You also may want to coherently tune the rx freq across daughtercards using timed commands... > On October 17, 2017 at 8:00 AM Janos Buttgereit via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Hi Derek, > > thank you for the quick response. I’m working with SBX 120 daughter > cards. I copied the console output of my program to a comment under the gist > I linked in my first post. Except for one warning about duplicate IP > addresses for the 1GBit Link that never seemed to generate any problems when > successfully running the devices with gnu radio and 10GBit Ethernet all seems > fine to me. I hope this won’t be the problem, as I’m not the only one using > the X300s round here and reconfiguring the IP addresses could lead to > confusion with the other users. But I strongly doubt this to be an IP address > error (I think in this case there would be no communication at all?), I > expect the error to originate from some wrong settings for the signal path > before the ADC. > > Thanks, > Janos > > > > > Am 17.10.2017 um 13:43 schrieb Derek Kozel > <derek.ko...@ettus.com mailto:derek.ko...@ettus.com >: > > > > Hi Janos, > > > > What daughtercards are you using? Can you include the console > > output of your program when it runs? It looks like you have useful log > > messages. > > > > Thanks, > > Derek > > > > On Tue, Oct 17, 2017 at 11:32 AM, Janos Buttgereit via USRP-users > > <usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com > wrote: > > > > > > > Hello everybody, > > > > > > I wrote to the mailing list some month ago as I had problems > > > setting up a multi_usrp from four USRP N210 with the help of the C++ API. > > > As there are other projects with higher priority, I’m just working on the > > > USRP-based stuff from time to time, that explains why there is a problem > > > unsolved for months now. In the end some specifications changed, so I > > > dropped the N210 and I’m now working with a pair of X300 devices. > > > > > > The problem I still have after having solved a lot of other > > > things with your help, is that there’s always only valid data from the > > > first channel. To make sure that there is no bug in my fairly big code, I > > > created a simple command line application, that just records four > > > channels to four .bin files. These files are then loaded in gnu octave In > > > this scenario, both X300 devices are clocked and time synced by an > > > external OctoClock and fed with the same sine-wave, generated by a Signal > > > Generator and split by a power splitter. > > > > > > I pasted my code and a plot of what the received data looks > > > like here: > > > > > > https://gist.github.com/JanosGit/af51ae66c3a5c8a90119ec5f98e01162 > > > https://gist.github.com/JanosGit/af51ae66c3a5c8a90119ec5f98e01162 > > > > > > By the way, a modified version of the rx_multi_samples > > > example which I modified to output the samples to a file instead of > > > dropping them showed the exactly same result. > > > > > > For your Information: I’m working on a fresh Ubuntu > > > installation with the X300 devices connected over SFP Cables to a dual > > > 10GBit Ethernet PCIe Card. Receiving valid data on all four channels > > > works with the same hardware but a slightly older Ubuntu installation on > > > a second computer when using gnu radio (never change a running system), > > > so I don’t think there is any hardware defect. I just need to up- or > > > downgrade the FPGA Image when switching between both systems. While > > > executing the application linked above, all four green LEDs underneath > > > the RX2 Ports are lit. > > > > > > I’m really looking forward to finding a solution with your > > > help! > > > > > > Regards > > > Janos Buttgereit > > > > > > _______________________________________________ > > > USRP-users mailing list > > > USRP-users@lists.ettus.com mailto:USRP-users@lists.ettus.com > > > > > > http://lists.ettus.com/mailman/listinfo/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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
