# Reading two rx channels on usrp2

**URL:** <https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370>\
**Category:** GNU Radio\
**Created:** [January 27, 2010, 4:11am UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370 "2010-01-27T04:11:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![virgin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/f17d59/32.png) [@virgin](https://www.ruby-forum.com/u/virgin)\
**Post date:** [January 27, 2010, 4:11am UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370/1 "2010-01-27T04:11:23Z")

</div>

I am in the process of hacking up the usrp2 host and firmware to  
support two receiver channels. I’m at the point where  
“start\_rx\_streaming” is being acknowledged for channel 1 but there is  
no data being returned for that channel. I don’t actually understand  
yet where the receiver data is packaged to be sent over the ethernet  
(I haven’t really looked into that yet) but I have been trying to  
understand how which receiver channel is selected…

I’m guessing that the bits in rx\_mux in dsp\_rx\_regs\_t are used to  
connect one of two DACs to one (or two?) inputs of the digital down  
converter. I note that the current setting of rx\_mux is 0x44444444  
which I am guessing (based on the comments in memory\_map.h) could mean  
“constant 0” for one input and “DAC A” for the other input to the  
DDC… Am I interpreting that correctly? Can anyone give me some  
hints as to what the setting would be if I want to enable both  
channels? Any other insights as to how to access both channels in the  
USRP2 firmware?

-Tom

---

<div class="post-metadata">

**Author:** ![virgin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/f17d59/32.png) [@virgin](https://www.ruby-forum.com/u/virgin)\
**Post date:** [January 27, 2010, 7:12pm UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370/2 "2010-01-27T19:12:13Z")

</div>

On Tue, Jan 26, 2010 at 10:09:01PM -0500, Tom G. wrote:

> I am in the process of hacking up the usrp2 host and firmware to  
> support two receiver channels. I’m at the point where  
> “start\_rx\_streaming” is being acknowledged for channel 1 but there is  
> no data being returned for that channel. I don’t actually understand  
> yet where the receiver data is packaged to be sent over the ethernet  
> (I haven’t really looked into that yet) but I have been trying to  
> understand how which receiver channel is selected…

The standard firmware and FPGA only implement a single channel.  
There is only a single DDC instantiated in the FPGA.

> I’m guessing that the bits in rx\_mux in dsp\_rx\_regs\_t are used to  
> connect one of two DACs to one (or two?) inputs of the digital down  
> converter. I note that the current setting of rx\_mux is 0x44444444  
> which I am guessing (based on the comments in memory\_map.h) could mean  
> “constant 0” for one input and “DAC A” for the other input to the  
> DDC… Am I interpreting that correctly?

No.

/\*!

- \brief input mux configuration.
- 
- This determines which ADC (or constant zero) is connected to
- each DDC input. There are N DDCs (1 now). Each has two inputs.
- 
- 
```

```
- Mux value:
- 
- 3 2 1
- 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
- ±------±------±------±------±------±------±------±------+
- | |Q0 |I0 |
- ±------±------±------±------±------±------±------±------+
- 
- Each 2-bit I field is either 00 (A/D A), 01 (A/D B) or 1X (const  
zero)
- Each 2-bit Q field is either 00 (A/D A), 01 (A/D B) or 1X (const  
zero)
- 
- The default value is 0x4
- 

\*/  
volatile uint32\_t rx\_mux; // called adc\_mux in  
dsp\_core\_rx.v

The bottom 4-bits of 0x44444444 connect A/D A to DDC0’s I-input and  
A/D B to DDC0’s Q input.

> Can anyone give me some  
> hints as to what the setting would be if I want to enable both  
> channels? Any other insights as to how to access both channels in the  
> USRP2 firmware?

See comment above about there currently being only a single DDC in the  
FPGA. If you want two channels, amongst other things, you’ll need to  
instantiate two DDCs, and add code that interleaves the samples from  
the two DDCs. You’ll also have to create host and firmware that can  
select the 1 or 2 channel case.

Eric

---

<div class="post-metadata">

**Author:** ![virgin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/f17d59/32.png) [@virgin](https://www.ruby-forum.com/u/virgin)\
**Post date:** [January 27, 2010, 7:32pm UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370/3 "2010-01-27T19:32:10Z")

</div>

On Wed, Jan 27, 2010 at 10:05, Eric B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> See comment above about there currently being only a single DDC in the  
> FPGA. If you want two channels, amongst other things, you’ll need to  
> instantiate two DDCs, and add code that interleaves the samples from  
> the two DDCs. You’ll also have to create host and firmware that can  
> select the 1 or 2 channel case.

There is a custom USRP2 top-level FPGA build that creates two  
synchronous DDCs (they share a CORDIC NCO phase accumulator) in the  
usrp2/fpga/top/u2\_rev3\_2rx\_iad directory. It is designed to  
synchronously sample the two inputs of a BasicRX or LFRX as separate  
real signals.

(It also implements an integrate-and-dump decimator instead of the CIC  
and HB, for unrelated reasons.)

The complex outputs of the two DDCs are interleaved and placed into a  
single data stream, are started and stopped at the same time, and  
share a common frequency and decimation rate. Thus, the host and  
firmware code are unchanged. If this serves your purpose, it would be  
a good place to start. It does sound like, though, from your original  
post, that you are looking to have independent streams, and the above  
won’t help you.

Johnathan

---

<div class="post-metadata">

**Author:** ![virgin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/f17d59/32.png) [@virgin](https://www.ruby-forum.com/u/virgin)\
**Post date:** [January 27, 2010, 7:37pm UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370/4 "2010-01-27T19:37:26Z")

</div>

On Wed, Jan 27, 2010 at 10:23, Johnathan C.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> There is a custom USRP2 top-level FPGA build that creates two  
> synchronous DDCs (they share a CORDIC NCO phase accumulator) in the  
> usrp2/fpga/top/u2\_rev3\_2rx\_iad directory.

I just realized that the Makefile for this build has not been updated  
since the move to the new GbE MAC implementation, so this would have  
to be done before you could synthesize it. This is basically updating  
the list of .v files to match what is now in the standard u2\_rev3  
Makefile.

Johnathan

---

<div class="post-metadata">

**Author:** ![virgin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/f17d59/32.png) [@virgin](https://www.ruby-forum.com/u/virgin)\
**Post date:** [January 27, 2010, 8:02pm UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370/5 "2010-01-27T20:02:37Z")

</div>

thanks Johnathan and Eric, I’m glad I asked before spending too much  
time trying to make this work! 🙂

Johnathan, the custom FPGA firmware you describe sounds like it might  
be perfect for what we want to do, provided it’s not impossible to  
demux the data stream. I haven’t seen any usrp2 FPGA sources (they  
don’t appear to be in either the 3.2.2 or 3.3.3 tarballs) - I guess  
this means I need to figure out the new “git” stuff…

it sounds like I will need to get a Xilinx compiler to build them,  
once I find them.

On Wed, Jan 27, 2010 at 1:23 PM, Johnathan C.

---

<div class="post-metadata">

**Author:** ![virgin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/f17d59/32.png) [@virgin](https://www.ruby-forum.com/u/virgin)\
**Post date:** [January 27, 2010, 8:13pm UTC](https://www.ruby-forum.com/t/reading-two-rx-channels-on-usrp2/182370/6 "2010-01-27T20:13:45Z")

</div>

On Wed, Jan 27, 2010 at 10:54, Tom G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Johnathan, the custom FPGA firmware you describe sounds like it might  
> be perfect for what we want to do, provided it’s not impossible to  
> demux the data stream.

It’s straightforward. Just use gr.deinterleave(gr.sizeof\_gr\_complex)  
after the usrp2.source\_32fc block, and attach two separate complex  
input block chains to outputs 0 and 1 of the deinterleaver. Also, the  
minimum decimation rate becomes 8 instead of 4 (this isn’t checked  
for.)

> I haven’t seen any usrp2 FPGA sources (they  
> don’t appear to be in either the 3.2.2 or 3.3.3 tarballs) - I guess  
> this means I need to figure out the new “git” stuff…

The FPGA code is not distributed as part of GNU Radio (it’s a product  
of Ettus R.). It’s currently hosted inside the [gnuradio.org](http://gnuradio.org)  
repository, though that will be changing. For now, though, the only  
git fu you need to know is:

$ git clone git://gnuradio.org/gnuradio

…to create your own complete repository (assuming you already have  
git installed.)

> it sounds like I will need to get a Xilinx compiler to build them,  
> once I find them.

Yes. FYI, the USRP2 FPGA requires the full version of the Xilinx ISE  
tools; the free version won’t work. Also, you specifically need  
release 10.1 with SP3. There are currently problems synthesizing even  
the standard image with newer versions of the tools.

Johnathan