[USRP-users] Still having problems receiving multiple channels

ROBIN TORTORA tilla at comcast.net
Tue Oct 17 09:22:55 EDT 2017


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 at 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.kozel at ettus.com mailto:derek.kozel at 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 at lists.ettus.com mailto:usrp-users at 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 at lists.ettus.com mailto:USRP-users at 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 at lists.ettus.com
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171017/7cc112d9/attachment-0002.html>


More information about the USRP-users mailing list