while acquiring a 10 kHz 0.3 V p-p signal. The max value shown in the
waveform on the gui is just over 25,000, which is way too much compared to
the standard usrp_fft.py, which by the way is no longer in the examples
directory; I used one from a previous release. If I increase the input
voltage level to 0.4 V p-p, I get a jagged waveform with sharp
discontinuities.
So, my problem remains. Any ideas?
What’s your test signal? Is it your 100kHz wide signal?
Can you try it with -d 400 as described below?
Eric
On Tue, 9 Oct 2007, Eric B. wrote:
With the halfbands, it’s flat to about 70% of the passband.
decim = 320 gives 200kS/s complex baseband, a bit more than you’ll
need.
Without the halfbands, I’d use about 4x the bandwidth of interest,
then filter and decimate in the host for the final channel selection.
In your case, I’d use decim = 160 giving 400kS/s.
The input signal is again a 10 kHz sine wave. In the first image, the
voltage level is 1.3 V p-p. In the second, 1.4 V p-p. In both cases I
have zero db of gain and decimation of 180, with the LF_RX tuned to 0 Hz.
As you can see, at 1.3 V P-P the result is perfect. However at 1.4 V P-P,
the signal is seriously corrupted and jagged.
The second one is showing clipping. Note how the peaks are folded in
on top of themselves.
Which rbf are you using for these? std_2rxhb_2tx.rbf (the default),
or std_4rx_0tx.rbf (the one without the halfband).
Can you run the same experiment using the other rbf and post those
pictures too?
The graphs are great. Thanks for posting the links.
The figures I showed you previously used std_4rx_0tx.rbf.
To test with the standard std_2rxhb_2tx.rbf, I use the usrp_fft.py (with
-S). I tested two cases, both with decimation 180, 1 kHz input, tuned
to
0 Hz with 0 db gain. The first is with the voltage level of 1.4 V P-P
(which cuases the clipping on the std_4rx_0tx.rbf), the second figure is
at the full scale voltage of 2 V P-P. Neither show clipping. The
clipping is clearly dependent on which rbf file is used.
OK. So it looks like the non-halfband case needs some adjustment to
reduce the gain so that it matches (more closely) the halfband case.
We don’t have any multipliers. What power of 2 would you like?
The fix goes on lines 83 and 102 of rx_chain.v. Just change which
bits of hb_in_i are assigned to i_out and likewise for Q.
Can you give me an example? I’ve never worked with verilog code before.
Also- this fix you are proposing- is it a simple scaling of gain that
would be independent of decimation? Because as you can see from the
following figure, the amplitudes scale directly with the decimation for
values above 128 on the 4 rcv rbf.
Both rbf’s produce a flat response below 128 decimation; greater than
this
is where the change occurs. The standard half-band rbf does have a
couple
of dips but is basically flat.
using -d 160 the problem goes away with this latest build, but remains
for
higher decimation values. For example, at decimation of 180, I can
reproduce the problem. As a picture is worth a thousand words, I’ve put
two jpg’s up online at:
The input signal is again a 10 kHz sine wave. In the first image, the
voltage level is 1.3 V p-p. In the second, 1.4 V p-p. In both cases I
have zero db of gain and decimation of 180, with the LF_RX tuned to 0
Hz.
As you can see, at 1.3 V P-P the result is perfect. However at 1.4 V
P-P,
the signal is seriously corrupted and jagged.
The criteria you indicated, ie acquisition rate at 4x bandwidth, seems
not
to be the issue; I am measuring a 10 kHz sine wave at an effective
sampling rate of 355 kHz and the problem remains.
In fact, the problem seems to be independent of the frequency of the
incoming sine wave, as I get the same thing with a frequency of 1 kHz as
opposed to 10 kHz:
The CIC filter has some bit-growth associated based on your decimation
rate. This growth is deifned for decimations up to 128 in that file.
It basically takes a different “slice” of the CIC “comb” section at
the end.
The reason it might be happening in the FPGA that doesn’t have the
halfband filter is because the halfband filter also decimates by 2 -
so you would need 1/2 the decimation by the CIC. So for cases where
you would normally decimate by 192, the CIC is decimating by 96 and
the halfband by 2. In the case where there is no halfband, the CIC
takes on all the responsibility and the extra growth is not accounted
for.
If this was defined for values larger than 128, then the growth
wouldn’t happen and it could all be alleviated in the FPGA. Hopefully
this makes sense to everyone.
Well, this seems logical, and if so then we’ve finally stumbled on the
point of the matter. So what’s the fix? Is it a simple matter of
extending the “definitions” to other decimations in the file Brian
cites?
Well, this seems logical, and if so then we’ve finally stumbled on the
point of the matter. So what’s the fix? Is it a simple matter of
extending the “definitions” to other decimations in the file Brian cites?
Either that or just do the extra decimation on the host computer.
Do you think you can handle a 500ksps stream for filtering/decimation?
takes on all the responsibility and the extra growth is not accounted
for.
If this was defined for values larger than 128, then the growth
wouldn’t happen and it could all be alleviated in the FPGA. Hopefully
this makes sense to everyone.
… and since the maximum USRP decimation is 256, 128 is the most you
would need in the CIC for the standard RBF… and no one ever got around
to/realized it needed to be done for higher decimation values when the
halfband is turned off? Seems logical.
-Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Well, this seems logical, and if so then we’ve finally stumbled on the
point of the matter. So what’s the fix? Is it a simple matter of
extending the “definitions” to other decimations in the file Brian cites?
thanks Brian and Eric,
eric
of dips but is basically flat.
OK. In the interest of expediency, use the decimation values that
work, then complete the decimation in the host. The reason that
there’s a version that DOESN’T have the halfband is to save space.
Making anything bigger (e.g., width of CIC) is contraindicated
Ok, that works in principle, but I’m finding that I cannot sustain the
same data rate as before on a fast dual core machine.
I’m acquiring all 4 channels, and I’m doing both low-pass and high-pass
filtering on all of them. I am also displaying 5 sinks simultaneously; 1
fft and 4 scopes.
You’ll most likely find that the bulk of your cycles are spent in the
gui. Try disabling it.
So, in the long term it would help to have this sorted out in the fpga if
that’s possible; is that impossible as things stand now, or is there
sufficient space in the 4rx no hb fpga?
IIRC, the std_4rx_0tx.rbf configuration uses about 86% of the FPGA.
I’m sure you are right about the gui taking the majority of the cycles,
but it’s the real-time feedback that makes gnuradio so attractive.
Ideally one would beable to switch them on and off as needed during
operation of the program, which it is my understanding will be possible
with the implementation of mblocks.
As things stand now, is there a “refresh rate” control that I can
modify,
so that the scope sinks use less cycles?
I’m sure you are right about the gui taking the majority of the cycles,
but it’s the real-time feedback that makes gnuradio so attractive.
Ideally one would beable to switch them on and off as needed during
operation of the program, which it is my understanding will be possible
with the implementation of mblocks.
As things stand now, is there a “refresh rate” control that I can
modify, so that the scope sinks use less cycles?
Yes, you can set the following parameters.
sink param default less cycles Function
oscope frame_decim 1 >1 keep one block in every “frame_decim”
fft fft_rate 15.0 <15.0 refresh rate of fft_display
so for less GUI cycles set frame_decim to 10 or even 100
set fft_rate to 5.0 or even 1.0
I wished that fft_rate was set to 5.0 default because allmost allways
15.0 is too much a load on my machines.
Ok, that works in principle, but I’m finding that I cannot sustain the
same data rate as before on a fast dual core machine.
I’m acquiring all 4 channels, and I’m doing both low-pass and high-pass
filtering on all of them. I am also displaying 5 sinks simultaneously;
1
fft and 4 scopes.
I set the decimation in the fpga to 128, and in the host to a further 10
for an effective data sampling rate of 50 kHz, and while the gain
problem
is gone I’m seeing some uO errors.
With the decimation set to 250 in the fpga, as I was doing previously, I
can sustain data rates of 128 kHz without a problem while having all 5
sinks going, albeit with the gain problem.
So, in the long term it would help to have this sorted out in the fpga
if
that’s possible; is that impossible as things stand now, or is there
sufficient space in the 4rx no hb fpga?
Hi,
Thanks everybody, this thread helped me a lot to understand the multi
antenna cabability of gnuradio.
I tried to run the multi_scope.py on a cingle USRP having two rfx2400
daughterboards with following changes in current multi_scope.py:
On line 44: nchan changed to 2 from 4
On Line 67: “len(self.subdev) != 4)” changed to “len(self.subdev) !=
2)”
On line 68 and 69: usrp_dbid.BASIC_RX changed to
usrp_dbid.FLEX_2400_RX_MIMO_B
I generate sinusoid of 2.43G on a different machine/gnuradio and then
run
the command ./multi_scope.py -f2.43G -d128 -g0 on another machine with
above
changes, but i dont see anything other than noise on my scope. I tried
different rbf files std_2rxhb_2tx.rbf, multi_2rxhb_2tx.rbf and got
nothing,
but the noise.
Next I changed the fpga_filename to multi_4rx_0tx.rbf, but i got
following
error:
Can’t find fpga bitstream: multi_4rx_0tx.rbf
and program stoped with runtime error of “Can’t open USRP”
Any suggestion?
Regards,
Tarun Mani Tiwari
MSEE student,
Multimedia Comm Lab,
UT Dallas
On Thu, Oct 11, 2007 at 08:16:24PM +0200, Martin D. wrote:
sink param default less cycles Function
oscope frame_decim 1 >1 keep one block in every “frame_decim”
fft fft_rate 15.0 <15.0 refresh rate of fft_display
so for less GUI cycles set frame_decim to 10 or even 100
set fft_rate to 5.0 or even 1.0
I wished that fft_rate was set to 5.0 default because allmost
allways 15.0 is too much a load on my machines.
Martin,
you can set the default in ~/.gnuradio/config.conf.
Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax: (574) 631-8355
Thank you Eric. Your suggestions helped me a lot and I was able to see
the
two channels on my scope.
After looking at the scope, I see that the second channel does not have
equal recieved power as that of first channel. Is it because of 4
channel
deinterleaver or something else? Please see the line 76 of multi_fft.py
which follows:
deinterleave two channels from FPGA
di = gr.deinterleave(gr.sizeof_gr_complex)
I am using the command ./multi_fft.py -f2.43G -d128 -g50
One more question On line 46 in multi_fft.py,
why do we use sw_decim as 4 rather than 1 after we enable channel
filter?
Does it have to do anything with the refresh rate of scope?
Thanks again.
Regards,
Tarun Mani Tiwari
MSEE Student,
Research Assistant,
Multimedia Comm Lab,
UT Dallas
On line 46 in multi_fft.py,