If you do not need any time synchronization then you can use four separate rx_streamers.
The time source (and clock source) will default to internal. Do you have MIMO cables between the N210s? Given that you have four that won't save you from having to have a separate external 10 MHz and PPS to synchronize all four. I would recommend keeping everything internal or everything external to start with. This does not seem to account for all four USRPs. https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55#file-multi_usrp_error-cpp-L45 What daughterboards do you have installed? I believe there is a problem in your interpretation of the channels vector. I think you need to set the subdev spec to "A:0 A:0 A:0 A:0" for four USRPs. I don't have the hardware on hand to replicate this but provides the context for "channel 2" to mean something. When you are back with your hardware that should be quick to try out. uhd_fft is a good utility for quickly trying these combinations of subdevice spec and channel indexes. I don't know why you get a (very low magnitude) ramp function. Derek On Thu, Aug 10, 2017 at 12:27 PM, Janos Buttgereit < janos.buttger...@fh-muenster.de> wrote: > Hi Derek, > > 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 > usrp->set_time_source("mimo", 1); > //set time on the master (mboard 0) > usrp->set_time_now(uhd::time_spec_t(0.0), 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 > https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd > 55#file-multi_usrp_error-cpp-L38 ? > > 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? > > Regards, > Janos > > 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 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/5273a550867ef1d966741 >> b6e93cacd55 >> >> 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
