Marcus,
Thanks to you and the others who have been helping me, I've managed to
understand this much! Your explanations are what I really needed, once I
understood what to really ask. I think all of my questions regarding
decimation have been answered.
Now, I'm trying to fully understand the VCO. I believe that the FPGA is
providing the clock source directly via pin XTALP (leaving XTALN floating). I
am not certain what is commanding each divider in the RFIC. I believe the
overall goal is for the FPGA to command a baseband rate and then check to see
whether the RFIC could achieve that exact rate. I read somewhere that the
baseband divider can be set from 2 to 64. I'm not worried about the DAC
divider, but I want to understand the one downstream of the baseband and before
the final output mux. I imagine the final mux rate is the MCR that you
explained, so I want to understand what drives the chain from the output of the
FPGA to the output of the RFIC.
Since the only detailed RFIC diagram I have is of the AD9361--and, from my
cursory inspection, the AD9364 data sheet doesn't seem to deviate in the
aspects that concern me--I am assuming that I have captured the entire clock
chain. Please correct me if I am missing any important steps in the process.
Thanks again!
________________________________
From: Marcus Müller [marcus.muel...@ettus.com]
Sent: Thursday, March 01, 2018 2:42 PM
To: Stern, Joseph; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users help needed
Hi Joseph,
to avoid confusion, I'll directly comment within your text:
On Thu, 2018-03-01 at 16:03 +0000, Stern, Joseph via USRP-users wrote:
I wanted to gain a general understanding of the process,
specific to our B200mini hardware, so my approach understandably seems like the
Y and not the X in your statement.
Ah, that's nice! Frankly, I'm pretty amazed how easily you're progressing
through all this – USRPs aren't really trivial systems, DSP-wise! Nice!
With that said, please consider the following points that I am trying to
understand:
- What total decimation is performed?
That depends.
You can adjust two things with the B2xx series:
1. The "user" sampling rate and
2. What we call the master clock rate.
The "master clock rate" is the actual rate of baseband samples coming out of
the frontend IC. Consider it the physical sampling rate.
It can be pretty much any (integer) multiple of your user sampling rate, which
usually is what you care about as someone who needs to process these samples.
So, your decimation rate can be any integer (including 1) up to 512, with
exceptions (for the upper half of decimations, you can only use divisable-by-4
integers, but really, who would need e.g. a 301 decimation, if one can adjust
the master clock rate, too?).
The master clock rate can either be delibarately chosen to be a multiple of the
wanted sampling rate (up to 61.44 MHz in the single-channel case), and the
analog bandwidth of the frontend will be reduced to avoid aliasing.
So, the total decimation is master clock rate / sampling rate. You don't
explicitly configure decimation, though – you specify a sampling rate and an
MCR, and UHD calculates the decimation factor (or complains, if your sampling
rate doesn't cleanly divide your MCR).
- Where does undersampling occur?
not at all!
I understand that the RFIC is being commanded by the FPGA to apply the
necessary clock rate and decimation in order to accommodate the requested
center frequency input within the limits of the output data rate.
So, here is where things get tricky: No, we're not talking about decimation in
the RFIC, we're talking about decimation in the FPGA.
The RFIC itself is a complex beast and does, indeed, internally do
oversampling, but you won't find much explanation or even presence of that in
our source code – it's what the AD936x does internally. For the USRP, the
baseband rate == master clock rate == pre-decimation rate.
I don't yet understand the decimation that occurs in the DSP
chain within the FPGA during the CORDIC and CIC algorithmic computations and
what other decimation occurs.
The cordic is only used to do frequency shifting *prior* to decimation. That
allows you to select arbitrare user sampling rate wide parts of the master
clock rate wide Nyquist band.
The Decimation chain in the FPGA is simply halfband filters (a cascade of two
of them, if I remember correctly), following a CIC decimator. All these three
filters are inherently decimators, i.e. the Halfbands only pass through half
rate if enabled, and the CIC passes through an adjustable 1/N of its input rate.
So, the decimation is first divided by 2, if possible; if that's the case, one
of the halfband decimators is enabled. This happens again, so that the CIC is
used to accomodate the rest of the decimation. Examples:
* MCR=40 MHz, sampling rate = 20 MHz -> CIC bypassed, first HB enabled
(==rate 1/2), second HB bypassed
* MCR=45 MHz, sampling rate = 9 MHz -> CIC enabled (rate 1/5), first HB
bypassed, second HB bypassed (don't do odd MCR/f_sample! You'll see the CIC's
rolloff)
* MCR=32 MHz, sampling rate = 500 kHz -> CIC enabled (rate 1/16), first HB
enabled, second HB enabled
> I also can't determine yet whether undersampling is occurring and where.
We might be using different terminology, but we never do undersampling. This is
a direct conversion architecture that adheres to Nyquist in its naive form at
every step.
Could you explain where you think undersampling comes into play?
I really just need to understand the overall output.
You're now deeper in our device architecture than 99% of customers :) (and I,
quite frankly, like that approach: better to spend a little more time
understanding things than doing something wrong.)
>From most user's perspective, you just tell the USRP the sampling rate you
>want and a center frequency, and it gives them a satisfactory baseband
>representation of [f_center-f_sample/2 ; f_center + f_sample/2].
Does that answer most of your questions?
Best regards,
Marcus Müller
This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
