Hi Janos, The problem is that the single rx_streamer is trying to time align the samples from the four USRPs, but the onboard clocks are not aligned so it is not finding samples from the same moment. Are you sharing 10 MHz and 1PPS references to all the USRPs? If so you will need to set the clock and time sources to external and set the USRPs times synchronously. Take a look at rx_multi_samples. https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_multi_samples.cpp#L97
You can also just set the times asynchronously and the large window (67936 packets in your case) is meant to be wide and catch the coarsely aligned samples. This will result in the four streams pretending to be synchronized, but keep in mind that the actual time offsets between samples with the same timestamp will all depend on the computer and network latencies. Regards, Derek On Wed, Aug 9, 2017 at 8:08 AM, Janos Buttgereit via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello everyone, > > I’m an electrical engineering master-degree student from Münster, Germany. > We have some Ettus devices round here at FH Münster, that were only used > with GNU Radio until now, but for a bigger project I now try to use the UHD > C++ API for the first time to build a custom (and hopefully fast) C++ > application. For this application I need four RF Input streams, coming from > four USRP N120. To achieve this, I bundle them into one multi_usrp object. > I pasted the relevant lines of code including some comments to a gist to > keep this email as short as possible - please take a look here: > https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55 > > The application is developed on Mac OS X at the moment but with > cross-platform compatibility in mind - probably it will be ported to Linux > sooner or later. > > Now, the way I currently set everything up no samples ever get received, > the call to rxStream->recv blocks for about a minute before an error > message is printed to the command line: > > *UHD Error:* > > *The receive packet handler failed to time-align packets.* > > *67936 received packets were processed by the handler.* > > *However, a timestamp match could not be determined.* > > This also happens if I try to use only three or two channels, however, > when I put just *one* channel into the streamArgs.channel vector, > continuos receiving will work. > > But even if no error is thrown in the one-channel-setup, valid data will > only be received if I pass channel 0 to the streamArgs.channels vector. For > test purposes, I connected an oscillator to all four receivers, if I > receive channel 0, a sine wave appears, but if I put any other channel > index first into the channel vector, there is something looking like a > dc-block-capacitor from the analogue front-end charging. I plotted (real > samples only) both scenarios to make this clear: > > > I tried connecting the oscillator to every possible port of all four > devices, but I only get this charging curve from all receivers except for > device 0. I also get a similar curve from device 0 if I disconnect the > oscillator and just leave the RF port open, so it seems to me as if this is > the usual response from an open rf port. Now if I swap the IP-Adresses > passed to multi_usrp::make, so that a different hardware device will > become channel 0, it stays the same - I’m able to receive valid data from > channel 0, no matter which hardware device is channel 0 and all other > channels will provide me the same curve. This makes me sure that it’s no > hardware error, I got all four hardware devices delivering valid samples as > long as their IP address is the first one passed to multi_usrp::make. > > I’m not sure if both errors I described are related or if there are two > completely different reasons for them. Anyway, I’d be glad if you would > check the pasted code snippet for errors. > > And just for your information, I won’t have access to the USRPs for the > next 2 weeks, but it would be great if I came back in 2 weeks to continue > working with some fresh ideas and hopefully a solution. > > Best regards > Janos > > _______________________________________________ > 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
