Re: The shortest pulse length

GNU Radio
1

Hi

Thanks very much for your explaination. I wasn’t so sure what was
happening with my setup. I have a vector source producing a sine wave,
and then I’m using gr.head to limit the number of samples sent. From
your explanation, I should be ok with even a low number of samples. When
I tested my setup, I couldn’t catch anything on the scope. There is
probably some problem in how I made the app.

I saw something mentioned elsewhere in the discussion archives that the
usrp dumps the first few samples it receives from the host before
transmitting. Is this still something to take note of?

Regards

Lance

----- Original Message ----
From: Lee P. [email protected]
To: seph 004 [email protected]
Cc: [email protected]
Sent: Friday, February 23, 2007 6:07:45 PM
Subject: Re: [Discuss-gnuradio] The shortest pulse length

The shortest pulse duration which you can transmit is going to be
limited by:
a) the sampling rate of the converters
b) the USB interface
c) the bandwidth of IF/RF components

I don’t know your exact setup. So, let me provide an example of what
I’m doing:

I transmit and receive in an always-on fashion using a single USRP in 4
Byte/sample mode (2 for real, 2 for complex) Therefore, for each sample
that must be transmitted and received, 8 bytes will traverse the USB (4
for Tx, 4 for Rx). The USRP is limited to 32 MB/s across the USB.
Therefore, I can only handle signals 4 MHz wide. Because the USRP does
complex sampling, 4 MHz becomes the maximum sampling rate I can use to
generate my signal at baseband. (This signal will be interpolated to
128 MHz on the USRP.) Because the fastest I can generate samples is 4
MHz, the smallest interval between samples is 1/4e6 = 250 ns. That is
(theoretically) the shortest pulse width.

Now, anytime you signal using one sample you will suffer more system
distortion than if you used, say, two. This is because the converters
will act as a really wide low-pass filter. However, with that said, I
am able to do it. I believe the minimum interpolation factor is 16.
Therefore, in a transmit-only mode, I believe the minimum pulse width
would be 1/8MHz = 125 ns.

I haven’t had coffee yet to day. So, caveat emptor on these
calculations, but I hope they help.

-Lee

2

On Mon, 2007-02-26 at 00:55 -0800, seph 004 wrote:

I have a vector source producing a sine wave, and then I’m using
gr.head to limit the number of samples sent.

I’m sure you checked this, but are you trying to capture the first few
samples of sin(x)? I so, sin(x) = x for small angles, and sin(0)=0.
So, you won’t see anything in the first few samples anyway.

From your explanation, I should be ok with even a low number of
samples. When I tested my setup, I couldn’t catch anything on the
scope. There is probably some problem in how I made the app.

I saw something mentioned elsewhere in the discussion archives that
the usrp dumps the first few samples it receives from the host before
transmitting. Is this still something to take note of?

I don’t know whether or not the USRP dumps the first few samples. I
don’t think I’ve ever experienced it though. I can say that there is an
unpredictable delay from the generation of the first sample in software
until the time it actually reaches the output port.

I haven’t tried to do what you’re doing – i.e., capture the first few
output samples on a scope. How is the scope triggered? (What I did was
create a loopback whereby I transmit and receive by reading the
bleedover on the daugherboard.)

-Lee