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 <derek.ko...@ettus.com>:
>
> 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
>
> <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 <mailto: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/5273a550867ef1d966741b6e93cacd55#file-multi_usrp_error-cpp-L38
>
> <https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55#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
>> <mailto: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
>>
>> <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 <mailto: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
>> <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 <mailto:USRP-users@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@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
