Hi Robin, Thank you so much, you pointed me to the right direction!
While nearly all calls I used to configure the device have the default argument ALL_CHANS or ALL_MBOARDS, set_rx_freq has the default argument chan=0. A quick look into the multi_usrp class reference should be enough to find that out, however I overlooked it for some reasons. Now I’m receiving multiple channels as expected. > Am 17.10.2017 um 15:22 schrieb ROBIN TORTORA <ti...@comcast.net>: > > 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
