[USRP-users] ERROR_CODE_ALIGNMENT (Multi-channel alignment failed) for 2 channel receiving with USRP2 and BasicRx

Craig Tong craigtong04 at gmail.com
Tue Oct 28 12:04:26 EDT 2014


Hi.

I'm not sure if my original email made the list I didn't see it come 
back as a list message. If not please see below.

A further update on that

Investigating the rx_multi_samples is also showing some quite peculiar 
behavior.
When I put a tone into RX-A on the daughterboard and terminate RX-B:

Printing the samples for following

rx_multi_samples --subdev="A:A A:B" --channels="0,1"

gives me as expected: varying large values (for an 8 dBm tone) in 
channel-0 and 0s and +/-1s in channel-1

but if I swap the signal to RX-B and terminate RX-A and run the same program

I get values up to ~ +/-4 in channel-0 and values up to ~ +/-34 in channel 1

Is this correct? I would expect just swapped channels from the first output

Then if I now swap the subdev command to:

rx_multi_samples --subdev="A:B A:A" --channels="0,1"

I get as in the first scenario: varying large values (for 8 dBm tone) in 
channel-0 and 0s and +/-1s in channel 1.

And swapping the RF inputs back again for this subdev gives the same as 
the second and unexpected output values.

I get the feeling I am totally missing something here. Either I'm 
misunderstanding how this is supposed to work or theres a problem.

I'm running UHD 3.7.2 installed out of Gentoo portage. x64 build. I 
updated the USRP2's firmware also from 3.7.2 downloaded straight from 
the website. And I see the same behavior in a 32 bit MSVC2010 Windows build.

Again any input would be much appreciated.

Kind regards.
Craig

On 10/27/14 11:04, Craig Tong wrote:
> Hi
>
> I'm wondering if anyone can give me some pointers.
>
> I'm trying to get 2 separate channels out of a USRP2 using the 
> respective RF connectors on the BasicRx daughter board.
>
> Currently its returning ERROR_CODE_ALIGNMENT (Multi-channel alignment 
> failed) and I'm not getting any data out.
>
> The relevant lines of code are:
>
> m_pUSRP->set_rx_subdev_spec(uhd::usrp::subdev_spec_t("A:A A:B"));
>
>
> uhd::stream_args_t oStreamArgs("sc16", "sc16"); //Use 16 bit complex 
> shorts
>
> std::vector<size_t> vChannelsNumbers;
>
> vChannelsNumbers.push_back(0);
>
> vChannelsNumbers.push_back(1);
>
> oStreamArgs.channels = vChannelsNumbers;
>
> m_pUSRPRxStreamer = m_pUSRP->get_rx_stream(oStreamArgs);
>
>
> Then I'm also setting and checking the RTC on the USRP but I don't 
> imagine this changes anything.
>
> boost::posix_time::ptime oEpoch(boost::gregorian::date(1970,1,1));
>
> boost::posix_time::time_duration oDurationSinceEpoc = 
> boost::posix_time::microsec_clock::universal_time() - oEpoch;
>
> uhd::time_spec_t oTimeNow(time_t(oDurationSinceEpoc.total_seconds()), 
> long(oDurationSinceEpoc.fractional_seconds()), 
> double(boost::posix_time::time_duration::ticks_per_second()));
>
>
> m_pUSRP->set_time_now(oTimeNow);
>
> uhd::time_spec_t oUSRPTime = m_pUSRP->get_time_now(); //Confirm time set
>
>
> And the stream command
> uhd::stream_cmd_t 
> oStreamCmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> oStreamCmd.stream_now = true;
>
> m_pUSRPRxStreamer->issue_stream_cmd(oStreamCmd);
>
> The recv function doesn't return any data. If I change the 
> vChannelNumber vector to contain only 0 or 1 then the code work but 
> only the first of the 2 buffers passed to recv(...) is filled as is to 
> be expected. The data rate into the PC is also half is this case so is 
> seems like data is being streamed in the 2 channel case its just 
> somehow misaligned (by timestamp?) according the UHD library.
>
> If anyone has any ideas I would greatly appreciate it.
>
> Kind regards
> -- 
> Craig Tong
> Radar Remote Sensing Group
> Department of Electrical Engineering
> University of Cape Town

-- 
Craig Tong
Radar Remote Sensing Group
Department of Electrical Engineering
University of Cape Town

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141028/1dad9595/attachment-0002.html>


More information about the USRP-users mailing list