thanks for your reply. No, I didn’t share a 10MHz and a PPS reference for all
four receivers, although we own an OctoClock that should be able to easily
provide these clocks. I assumed that the multi usrp would be aware of the fact
that it can not expect any synchronized data when all device clocks were
configured as internal and so wouldn’t even try to synchronize samples. This
would have been perfectly okay for me for a first run where just collecting any
multichannel data was the only goal.
However at some point I also thought of a synchronization error while trying to
get it working yesterday and so I tried breaking the setup down to two
receivers linked by a mimo cable. I called
usrp->set_clock_source („internal“, 0);
usrp->set_clock_source („mimo“, 1);
to get the second device in sync with the first one. Now when looking at the
code you linked there is also a setup like this, but the clock-source-settings
which seem comparable to my approach are followed by
//set time on the master (mboard 0)
So I expect setting the time source is what I missed?
I’ve updated my gist - is it likely that these changes will fix my error
Would you expect this to also solve the other problem regarding receiving
unusable data from all but the first device illustrated by the image pasted in
the original mail or is this still another different problem?
> Am 09.08.2017 um 17:44 schrieb Derek Kozel <derek.ko...@ettus.com>:
> 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
> 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.
> On Wed, Aug 9, 2017 at 8:08 AM, Janos Buttgereit via USRP-users
> <firstname.lastname@example.org <mailto:email@example.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:
> 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
> USRP-users mailing list
> USRPfirstname.lastname@example.org <mailto:USRPemail@example.com>
USRP-users mailing list