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

Martin Braun martin.braun at ettus.com
Wed Oct 29 04:31:30 EDT 2014


So you're saying that rx_multi_samples works, but your app doesn't,
right? One crucial difference I can see is that you're streaming
immediately. For MIMO ops, you should give the device some setup time
and stream_now=false.

Cheers,
M

On 10/29/2014 09:16 AM, Craig Tong via USRP-users wrote:
> Ok so for the record the number scaling problem I had in
> rx_multi_samples was because I didn't explicitly tune channel 1 only the
> default of channel 0. That now behaves as expected.
> 
> Still no joy with my own implementation though. "Multi-channel alignment
> failed" I'm trying to figure out what I have done that is critically
> different from the example.
> 
> On 10/28/14 18:04, Craig Tong wrote:
>> 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
> 
> -- 
> Craig Tong
> Radar Remote Sensing Group
> Department of Electrical Engineering
> University of Cape Town
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 





More information about the USRP-users mailing list