8MHz Tx Bandwidth.. Nightmare and Fear

GNU Radio
1

Matt,

Tonight
I have been recording slices of commercial FM spectrum, all centered
right where a good station transmits,

the first slice was 300Khz wide,
the second was 2MHz
the third was 4MHz

then I sent all these signals to my Hifi FM receiver via the basicTX…
all went fine and I could hear a good stereo sound from my recordings…

then I tried my nightmare: the 8MHz slice of spectrum…
the output was extremely weak but you could easily tell from what you
could hear that the samples were not being sent out at 8Msps: the very
poor audio was also “slow” as it happens when you set the interpolation
rate too high, compared to the sample rate your samples were taken at…
well, this is not just some attenuation next to the shoulder of my ofdm
signal… this is the whole signal … gone…

So, I’m really not asking you, Matt, to solve a problem which is my duty
to solve…and don’t even want to bother the whole list with this
stuff…

…but please say it loud, say it clear: “vincenzo, you’ve made very big
mistakes, because the USRP really can transmit an 8MHz wide signal
without distorting it significantly, I’ve tested it”…

…so even if this means that I still got much to learn, and much to work
to find out where I’m doing wrong…

…well, it would be much better than being forced to give up what I’m
working upon…

please…

thanks

vincenzo

PS.
I’m using default FPGA configuration…

2

Hi Vincenzo,

  1. What is your recording system (PC specifications)?.
  2. How fast your hard drive can read/write data? because working with
    8MHz
    means that your hard drive must be able to sustain writing 32MByte/sec?
  3. Do you use ext2 or ext3 ? Ext2 is very efficient in writing.
  4. Are you recording complex or interleaved Short 8 MHz samples?

Firas

Vincenzo P. wrote:

the third was 4MHz
signal… this is the whole signal … gone…
to find out where I’m doing wrong…
PS.
I’m using default FPGA configuration…

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/8MHz-Tx-Bandwidth…-Nightmare-and-Fear-tf4374848.html#a12471008
Sent from the GnuRadio mailing list archive at Nabble.com.

3

Vincenzo P. wrote:

Matt,
…but please say it loud, say it clear: “vincenzo, you’ve made very big
mistakes, because the USRP really can transmit an 8MHz wide signal
without distorting it significantly, I’ve tested it”…

I really don’t know what you’re looking for here. There are a lot of
people transmitting a lot of different signals with the USRP and not
having issues.

There are some things you seem to be missing, though. No system is
capable of using 100% of the nyquist bandwidth, and the USRP is no
exception. On receive, our passband is flat out to about 75 or 80% of
nyquist. For 8 MS/s complex sampling, that gives more than 6 MHz of
flat bandwidth. On transmit, there are no halfband filters in there, so
you will see more rolloff from the CIC filters. If this is a problem,
you have 3 options:

  • If your generated signal is at less than 8 MS/s complex, then you
    should just upsample in software.
  • If your generated signal is at the full 8 MS/s then you can
    predistort your signal to compensate for the CIC rolloff.
  • Otherwise, I would suggest making a new FPGA image with halfband
    filters in the TX side. You can make room in there by removing one
    receive chain (leaving only one).

Matt

PS There is no need to send emails to both the list and to me. I am on
the list, and don’t need 2 copies of every email.

4

I’m recording and replaying interleaved shorts @ 8Msps… how is the
benchmarking software called? I also have noticed a diffference between
my
main, old gnuradio installation and a fresh one just done from trunk on
another disk… the fisrt is all right with transmissions up to 4 MHz
the
second stops at 2MHz, (using the same scripts of mine on both
installations): when, on the fresh installation, I ask for 4MHz I can
hear
only noise being sent out (I think this is a different problem than the
slow
flow)… I’m a bit confused…

thanks

vincenzo

2007/9/7, Firas abbas [email protected]:

5

Hi vincenzo,

No need to be confused , lets put it together again:

  1. The USB benchmark software can be found in the
    gnuradio/gnuradio-examples/python/usrp/benchmark_usb.py

  2. What do you mean by another disk? are both gnuradrio installation
    work from the same operating system ? or each drive has its own OS?

  3. What is you OS?

  4. What is the reading of [hdparm -t /mnt/sda ] on both drives?

  5. Describe you setup please and what do you want to do. Fortunately,
    for one day or less, I have function generator and spectrum analyzer in
    my home with the USRP system and I can run a copy of your experiments at
    my home to see the result on my system.

Firas
Vincenzo P. [email protected] wrote: I’m recording and
replaying interleaved shorts @ 8Msps… how is the benchmarking software
called? I also have noticed a diffference between my main, old gnuradio
installation and a fresh one just done from trunk on another disk… the
fisrt is all right with transmissions up to 4 MHz the second stops at
2MHz, (using the same scripts of mine on both installations): when, on
the fresh installation, I ask for 4MHz I can hear only noise being sent
out (I think this is a different problem than the slow flow)… I’m a bit
confused…

thanks

vincenzo

2007/9/7, Firas abbas [email protected]: Hi Vincenzo,

Are you recording the 8Msps complex or short ?. In recording, I always
prefer the interleaved complex short, because the real coming samples
from the USRP across the USB is 16 bit short. The conversion to float
(32 bit) complex is being done by software in the PC and thus adds no
new information and does not enhance the data. It only complicate file
storage process. If converting to short does not solve your problem, try
to record and play smaller bandwidth like 6.4MHz (decimation 10) or
less. Also test your PC USB 2 speed by using the benchmark software
found the gnuradio truck.

Best Regards,

Firas

Vincenzo P. < [email protected]> wrote:
hi Firas, thanks for help!

i’m doing pretty much everything you suggested, and in fact, really!!, I
do think that my HD is doing a very good work.

nevertheless I keep having the same problem,
this is what I also posted to the list:

I finally have a 7200rpm disk that does keep up very well with 32MBps
and, I guess, even much more…

is then this assumption correct?

8Msps with gr_complex data type ==> 8e6*8bytes per sample = 64 MB/s

8Msps with interleaved shorts ==> 8e6*2bytes per int * 2channels = 32
MB/s

I’m sure now that my drive can keep up with recording and replaying the
32 MB/s
and I guess that even 64 with my new, xfs formatted clean disk is fine

my problem is that in both cases ( both using complex and interleaved
shorts)

If I work with a 4 MHz bandwidth everything looks allright.
I can record and replay a 4 MHz fm band and perfectly listen to the
station at the center of it when sending it back to the receiver

but

when I try to go 8 MHz I can hear a noisy, extremely weak replica of my
signal, which is SLOW… like an old cassette player with flat batteries

and this is consistent with the fact that a file meant to last 10.717
secs @ 32MB/s, when played with usrp_interp= 16 (8MHz Bandwidth)
lasts MORE than 13 secs, while if played with usrp_interp=32 (4MHz),
it lasts exactly the double of the correct value ie: 10.717*2=21.434

has this ever happened to anybody… am I making huge mistakes that I
havent discovered yet?

thanks

vincenzo

On Wed, 2007-09-05 at 13:15 -0700, Firas abbas wrote:

Hi Vincenzo,

Sorry for this delay, but I didn’t saw your email in the mailing list
which I usually check. To solve your problem do :

  1. Buy SATA II harddisk drive
  2. Put Linux in ext3 partition
  3. Create a small Ext2 partition for your recordings (about
    4Gbyte)

Firas

Vincenzo P. wrote:
On Mon, 2007-09-03 at 20:04 -0700, Eng. Firas wrote:
> Hi Vincenzo,
>
>
storing a very few secs of my sample stream to the ram before
> Vincenzo P. wrote:
> > the second was 2MHz
> > could hear that the samples were not being sent out at
8Msps: the very
> > poor audio was also “slow” as it happens when you set the
interpolation
> > rate too high, compared to the sample rate your samples
were taken at…
> > well, this is not just some attenuation next to the
shoulder of my ofdm
> > signal… this is the whole signal … gone…
> >