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?
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.
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.
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.
On Wed, Jan 27, 2010 at 10:23, Johnathan C. [email protected] 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.
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.
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
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
