I again encourage you to look at rx_multi_samples which shows how to
properly set-up a multi-motherboard configuration.
On 2017-08-22 10:34, Janos Buttgereit via USRP-users wrote:
> Hi,
>
> as I said before, I had no chance to access the hardware for some time, but
> today I had some time.
>
> First of all: I got the time synchronization working. In addition to setting
> the time source and setting an initial time through set_time_unknown_pps it
> took some time for me to find out that the stream command for continuous
> streaming should have set streamNow to false and time_spec to a time about
> 1.5 seconds so that it wouldn't look for earlier timestamps while these
> timestamps already passed. Now receiving works without errors.
>
> However I'm still getting useless samples from devices except for the first
> one.
>
> I'm working with N210 USRPs with SBX boards installed. The N210 has two RX
> DSP Chains, the SBX only has one ADC, so your proposal to set the subdev spec
> to "A:0 A:0 A:0 A:0" won't work, as this would try to map the frontend A:0 to
> DSP 0-3 for all four SBX boards - the result in trying this is the following
> error message:
>
> SUBDEVICE SPECIFICATION "A:0 A:0 A:0 A:0" IS TOO LONG.
> THE USER SPECIFIED 4 CHANNELS, BUT THERE ARE ONLY 2 RX DSPS ON MBOARD 0
>
> What works is setting the subdev spec to "A:0 A:0". When doing so with two
> N210 connected, a call to usrp->get_pp_string(); results in the following
> output:
>
> MULTI USRP:
> DEVICE: USRP2 / N-SERIES DEVICE
> MBOARD 0: N210R4
> MBOARD 1: N210R4
> RX CHANNEL: 0
> RX DSP: 0
> RX DBOARD: A
> RX SUBDEV: SBXV3 RX
> RX CHANNEL: 1
> RX DSP: 1
> RX DBOARD: A
> RX SUBDEV: SBXV3 RX
> RX CHANNEL: 2
> RX DSP: 0
> RX DBOARD: A
> RX SUBDEV: SBXV3 RX
> RX CHANNEL: 3
> RX DSP: 1
> RX DBOARD: A
> RX SUBDEV: SBXV3 RX
> TX CHANNEL: 0
> TX DSP: 0
> TX DBOARD: A
> TX SUBDEV: SBXV3 TX
> TX CHANNEL: 1
> TX DSP: 0
> TX DBOARD: A
> TX SUBDEV: SBXV3 TX
>
> So, there are four input channels available now. When trying to receive all
> four channels by setting the stream args channel vector to {0, 1, 2, 3} this
> will result in a time alignment error. However when trying to receive only
> data from dsp 0 OR dsp1 with channel vectors like {0, 2}, {1, 3}, {2, 0}, {3,
> 1} it will work but trying to receive something like {0, 1} (--> both dsp
> chains from the same devices) or {0, 3} will also result in the time
> alignment error. I can't image why the two DSP chains in the same device
> produce unaligned samples.
> If I use one of the working channel vector setups, I will still only get
> valid samples from the channel 0 and 1 (--> DSP 0 and 1 of the first device),
> the second device will still output that ramp function. Changing the order of
> the devices' ip addresses in the uhd::device_addr_t passed to
> uhd::usrp::multi_usrp::make will result in receiving valid samples from a
> different N210 - always the one placed first in the device_addr_t.
>
> Now as I actually don't need DSP1 for anything, I went back to specifying the
> subdev spec "A:0" which results in an output like this:
>
> MULTI USRP:
> DEVICE: USRP2 / N-SERIES DEVICE
> MBOARD 0: N210R4
> MBOARD 1: N210R4
> RX CHANNEL: 0
> RX DSP: 0
> RX DBOARD: A
> RX SUBDEV: SBXV3 RX
> RX CHANNEL: 1
> RX DSP: 0
> RX DBOARD: A
> RX SUBDEV: SBXV3 RX
> TX CHANNEL: 0
> TX DSP: 0
> TX DBOARD: A
> TX SUBDEV: SBXV3 TX
> TX CHANNEL: 1
> TX DSP: 0
> TX DBOARD: A
> TX SUBDEV: SBXV3 TX
>
> So, with this subdev spec both N210 seem to map their frontend A:0 to DSP0
> and nothing to DSP1 which is what I need. Receiving with the channel vector
> {0, 1} and {1, 0} works without time alignment errors but with the same
> misbehaviour as described above: Valid data for the first device, useless
> ramp function for the second on.
>
> You said that uhd_fft is a a good utility for quickly trying combinations of
> subdevice spec and channel indexes - sadly this won't work on my mac due to
> some python module dependency errors (probably because I haven't installed
> gnu radio which it is based upon?) so this doesn't seem to provide a „quick"
> help either but I will try to get this utility working, maybe this will help
> me.
>
> However, I'm quite happy that I've already managed to receive 2 channels
> without sync-errors, I'm trying to see the positive aspects here ;) So,
> although I have no idea what's still wrong with my code, I'm confident that
> the mailing list will also help me with finding the bug that prevents me from
> receiving valid data on all input channels!
>
> So I'm looking forward to your response(s)
>
> Regards
> Janos
>
> Am 10.08.2017 um 16:13 schrieb Derek Kozel <[email protected]>:
>
> 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
> <[email protected]> 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/5273a550867ef1d966741b6e93cacd55#file-multi_usrp_error-cpp-L38
> [1] ?
>
> 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 <[email protected]>:
>
> 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
> [2]
>
> 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
> <[email protected]> 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 [3]
>
> 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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [4]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1]
https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55#file-multi_usrp_error-cpp-L38
[2]
https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_multi_samples.cpp#L97
[3] https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55
[4] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
