Don Ward wrote:
Hi Matt,
You are correct that I have been conservative in the scaling of the
signal sent over the data bus. However, there are some things you
need to take into account here.
First, I believe you are sending a single sine wave into the
BasicRX. In normal operation for most of the daughterboards, you
will get signals on both the I and Q inputs. If there were a
quadrature signal on the other channel, then your maximum amplitude
coming out of the CORDIC would be bigger by a factor of sqrt(2), or
~1.41. If you take the max level of 26830 and multiply by 1.4 you
get 37562, which would cause an overflow.
I understand how the magnitude can be too big, but we never take the
magnitude in the FPGA; as long as I and Q are within range, shouldn't
it be ok? The change would limit the usable input signal to complex
values with magnitude less than 2048 (at the A/D output), whereas now
the signal must have each component less than 2048. I can't think of
a practical case where a signal would exceed the limit on the
magnitude without also exceeding the limit on the components.
The CORDIC is rotating the signal. Let's say that the I and Q signals
are both 25000 at some point. When that gets rotated by 45 degrees, it
will become 25000*sqrt(2) for I and 0 for Q.
Second, just because the numbers are going twice as high in your
updated build doesn't mean that there is twice as high of a dynamic
range. The best way to test this would be to perform a two-tone IMD
test. Put two sine waves which are close to each other in frequency
into a combiner and put that into the BasicRX. The levels should be
about 1/2 of the voltage that causes clipping. Using this signal,
measure the intermod products with both the old and new RBFs.
I don't know enough to say how the quantization error affects the IMD
test, but I believe that the quantization/roundoff noise in the output
can be reduced by tweaking the scaling.
Quantization error should be reduced by this change, as should
quantization-induced IMD. However, in a real system, these two are
likely to already be much lower than IMD and noise from the RF front
ends, so overall I don't think you'd see a big change. I could be
wrong, though, so please go ahead with the tests.
Ideally, with a decimation of 256 we should be multiplying the signal
voltage by 256 while multiplying the quantization noise power
(assuming uncorrelated noise) by the same factor. This should
increase the S/N (voltage) ratio by 256/sqrt(256)=16. But in the
USRP, the signal and quantization noise are multiplied by
8*1.647/2=6.59 by the end of the CORDIC. The combination of CIC and
halfband filter reduces the noise by 16 to 6.59/16, but adds back
roundoff error of order 1 when scaling to 16 bits. Put another way,
the total signal gain is 6.59, but the but the noise gain can't be
less than 1, so the total S/N gain during decimation is limited to
6.59. If we double the gain before the CORDIC, we can increase the
S/N gain to 2*6.59. At lower decimations the processing gain should
increase from min( sqrt(d), 6.59 ) to min( sqrt(d), 2*6.59 ).
I don't follow your logic here. Ideally, you want signal gain to be 1,
regardless of decimation rate. If you decimate by 256, then in the
ideal situation, the noise power will be divided by 256. That would be
the noise voltage is divided by 16. This is equivalent to getting 4
more bits of precision. 12 ADC bits plus 4 gives 16. Of course, we
have a scale factor in there that limits this, but in reality there are
roundoff errors in there anyway.
On a somewhat related note, I've been to busy to do this, but it would
be nice if someone put together an RBF build which had only 1 TX and 1
RX channel. That would allow you to devote a lot of resources to really
taking good care of your signal. For example, you'd be able to fit
halfband filters on the TX, and you could put in multipliers to scale
the signal to the ideal ranges. The vast majority of USRP users only
use 1 channel at a time anyway, so this would be very useful. You might
even be able to do a halfband filter that works at the 4X decimation for
the 8-bit case.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
