Re: [Discuss-gnuradio] The shortest pulse length

2007-03-05 Thread seph 004
Thanks for the advice. I don't think that's my only problem though. My vector 
is currently supposed to produce 2500 samples. This combined with an 
interpolation factor of 512, should give me 10 msecs of signal. Have I 
calculated this correctly? Also, I'm using the gr.modulation block to make the 
signal, but if it is producing complex output, does that mean I'm actually 
sending 5000 samples?

At the moment, sending my 2500 samples produces an output only 1 msec long. 

Regards

Lance

- Original Message 
From: Eric Blossom [EMAIL PROTECTED]
To: seph 004 [EMAIL PROTECTED]
Cc: David Scaperoth [EMAIL PROTECTED]; discuss-gnuradio@gnu.org
Sent: Friday, March 2, 2007 7:06:06 PM
Subject: Re: [Discuss-gnuradio] The shortest pulse length

On Fri, Mar 02, 2007 at 12:41:40AM -0800, seph 004 wrote:

 I am only using 1 daughterboard. Sorry about the duc0 = 0
 inclusion. It's something I neglected to remove when I was editing
 the original file. I don't think it should have any effect on what I
 am seeing though. I set the duc frequency to 0 because I wanted to
 transmit at baseband. I've already built the signal I want in the
 gr.vector, I just want the daughterboard to pass it as is. I've
 managed to do that with usrp_siggen.py. By setting the -f option to
 0 and the -w option to some frequency, I get a waveform of the -w
 frequency at the daughterboard output. I'm pretty sure (0, 0) is
 TXA, and (1, 0) is TXB. My waveform does appear at the TXB output
 when I run the script. The problem is the pulse duration I'm seeing
 is much shorter (about 1/10) than what I expect.
 
 Regards
 Lance 

Unless the total number of samples comes out to a multiple of 128,
some will left in the host buffer and not transmitted across the USB.
Try padding your vsource data with zeros to a multiple of 128.

Eric



 
 - Original Message 
 From: David Scaperoth [EMAIL PROTECTED]
 To: seph 004 [EMAIL PROTECTED]
 Cc: discuss-gnuradio@gnu.org
 Sent: Thursday, March 1, 2007 7:15:36 PM
 Subject: Re: [Discuss-gnuradio] The shortest pulse length
 
 
 
 
 On 3/1/07, seph 004 [EMAIL PROTECTED] wrote:
 
 
 
 This is what I did:
 
 def build_graph ():
 nchan = 1
 interp = 512
 duc0 = 0
 duc1 = 0
 fs = 250e3#2nd sample rate 
 between usb and dac
 
 max_dev = 32e3  #1st sample rate divided by 4 
 (1st = 2nd sample rate)
 gain = 16e3
 k = 2 * math.pi * max_dev / fs
 vec1 = Numeric.arange (0.624, 0.656, 0.128)
 
 vsource = gr.vector_source_f(vec1, False)
 fmmod = gr.frequency_modulator_fc (k)
 amp = gr.multiply_const_cc(gain)

 fg = gr.flow_graph ()
 
 u = usrp.sink_c (0, interp, nchan)
 
 tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
 m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
 u.set_mux(m)
 subdev = usrp.selected_subdev(u, tx_subdev_spec)
 subdev.set_enable(True)
 
 
 sample_rate = u.dac_freq () / interp
 u.set_tx_freq (0, duc0)
 u.set_tx_freq (1, duc1)







 

Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-03-02 Thread seph 004
Thanks for the reply.

I mentioned in my response to David's message that I'm purposefully setting the 
duc frequency to 0 to transmit at baseband. Is using .tune to do this better 
than the set_freq method even if I don't want duc to do anything to the signal?

Regards

Lance

- Original Message 
From: Eric Blossom [EMAIL PROTECTED]
To: David Scaperoth [EMAIL PROTECTED]
Cc: seph 004 [EMAIL PROTECTED]; discuss-gnuradio@gnu.org
Sent: Thursday, March 1, 2007 11:32:45 PM
Subject: Re: [Discuss-gnuradio] The shortest pulse length

On Thu, Mar 01, 2007 at 12:15:36PM -0500, David Scaperoth wrote:
 On 3/1/07, seph 004 [EMAIL PROTECTED] wrote:
 
  This is what I did:
 
 def build_graph ():
 nchan = 1
 interp = 512
 duc0 = 0
 duc1 = 0
 fs = 250e3#2nd sample rate
 between usb and dac
 max_dev = 32e3  #1st sample rate divided
 by 4 (1st = 2nd sample rate)
 gain = 16e3
 k = 2 * math.pi * max_dev / fs
 vec1 = Numeric.arange (0.624, 0.656, 0.128)
 vsource = gr.vector_source_f(vec1, False)
 fmmod = gr.frequency_modulator_fc (k)
 amp = gr.multiply_const_cc(gain)
 
 fg = gr.flow_graph ()
 
 u = usrp.sink_c (0, interp, nchan)
 tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
 m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
 u.set_mux(m)
 subdev = usrp.selected_subdev(u, tx_subdev_spec)
 subdev.set_enable(True)
 
 sample_rate = u.dac_freq () / interp
 u.set_tx_freq (0, duc0)
 u.set_tx_freq (1, duc1)
 
 
 Are you trying to use one daughter boards(nchen=1)?   Why did you set duc0 =
 0?   that means your  frequency will not be set at all.  You do not need to
 do set_tx_freq() twice if you are using one daughter board.  you only need :
 u.set_tx_freq (0, duc0) where duc0 is some frequency.  Also, if you are
 using the basic daughterboards, you need to make sure that you have the
 output connector connect to TXA not TXB (according to your tx_subdev_spec)
 
 
 Hope this helped.
 David

Lance, you really want to be using tune, not set_tx_freq.
tune knows about all the daughterboards and does the right thing to
split the work between the digital upconverter and the RF front end (if any).

Take a look at fm_tx4.py or fm_tx_2_daughterboards.py

Eric







 

TV dinner still cooling? 
Check out Tonight's Picks on Yahoo! TV.
http://tv.yahoo.com/___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-03-02 Thread Eric Blossom
On Fri, Mar 02, 2007 at 12:41:40AM -0800, seph 004 wrote:

 I am only using 1 daughterboard. Sorry about the duc0 = 0
 inclusion. It's something I neglected to remove when I was editing
 the original file. I don't think it should have any effect on what I
 am seeing though. I set the duc frequency to 0 because I wanted to
 transmit at baseband. I've already built the signal I want in the
 gr.vector, I just want the daughterboard to pass it as is. I've
 managed to do that with usrp_siggen.py. By setting the -f option to
 0 and the -w option to some frequency, I get a waveform of the -w
 frequency at the daughterboard output. I'm pretty sure (0, 0) is
 TXA, and (1, 0) is TXB. My waveform does appear at the TXB output
 when I run the script. The problem is the pulse duration I'm seeing
 is much shorter (about 1/10) than what I expect.
 
 Regards
 Lance 

Unless the total number of samples comes out to a multiple of 128,
some will left in the host buffer and not transmitted across the USB.
Try padding your vsource data with zeros to a multiple of 128.

Eric



 
 - Original Message 
 From: David Scaperoth [EMAIL PROTECTED]
 To: seph 004 [EMAIL PROTECTED]
 Cc: discuss-gnuradio@gnu.org
 Sent: Thursday, March 1, 2007 7:15:36 PM
 Subject: Re: [Discuss-gnuradio] The shortest pulse length
 
 
 
 
 On 3/1/07, seph 004 [EMAIL PROTECTED] wrote:
 
 
 
 This is what I did:
 
 def build_graph ():
 nchan = 1
 interp = 512
 duc0 = 0
 duc1 = 0
 fs = 250e3#2nd sample rate 
 between usb and dac
 
 max_dev = 32e3  #1st sample rate divided by 4 
 (1st = 2nd sample rate)
 gain = 16e3
 k = 2 * math.pi * max_dev / fs
 vec1 = Numeric.arange (0.624, 0.656, 0.128)
 
 vsource = gr.vector_source_f(vec1, False)
 fmmod = gr.frequency_modulator_fc (k)
 amp = gr.multiply_const_cc(gain)

 fg = gr.flow_graph ()
 
 u = usrp.sink_c (0, interp, nchan)
 
 tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
 m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
 u.set_mux(m)
 subdev = usrp.selected_subdev(u, tx_subdev_spec)
 subdev.set_enable(True)
 
 
 sample_rate = u.dac_freq () / interp
 u.set_tx_freq (0, duc0)
 u.set_tx_freq (1, duc1)


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-03-02 Thread Eric Blossom
On Fri, Mar 02, 2007 at 12:51:31AM -0800, seph 004 wrote:
 Thanks for the reply.
 

 I mentioned in my response to David's message that I'm purposefully
 setting the duc frequency to 0 to transmit at baseband. Is using
 .tune to do this better than the set_freq method even if I don't
 want duc to do anything to the signal?

 
 Regards
 Lance

The good thing about tune is that it works the same way with all
daughterboards.  If you're using Basic Tx or LF Tx boards, the end
result will be the same.  tune will do all the work using the DUC.

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-03-01 Thread David Scaperoth

On 3/1/07, seph 004 [EMAIL PROTECTED] wrote:


 This is what I did:

def build_graph ():
nchan = 1
interp = 512
duc0 = 0
duc1 = 0
fs = 250e3#2nd sample rate
between usb and dac
max_dev = 32e3  #1st sample rate divided
by 4 (1st = 2nd sample rate)
gain = 16e3
k = 2 * math.pi * max_dev / fs
vec1 = Numeric.arange (0.624, 0.656, 0.128)
vsource = gr.vector_source_f(vec1, False)
fmmod = gr.frequency_modulator_fc (k)
amp = gr.multiply_const_cc(gain)

fg = gr.flow_graph ()

u = usrp.sink_c (0, interp, nchan)
tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
u.set_mux(m)
subdev = usrp.selected_subdev(u, tx_subdev_spec)
subdev.set_enable(True)

sample_rate = u.dac_freq () / interp
u.set_tx_freq (0, duc0)
u.set_tx_freq (1, duc1)



Are you trying to use one daughter boards(nchen=1)?   Why did you set duc0 =
0?   that means your  frequency will not be set at all.  You do not need to
do set_tx_freq() twice if you are using one daughter board.  you only need :
u.set_tx_freq (0, duc0) where duc0 is some frequency.  Also, if you are
using the basic daughterboards, you need to make sure that you have the
output connector connect to TXA not TXB (according to your tx_subdev_spec)


Hope this helped.

David
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-03-01 Thread Eric Blossom
On Thu, Mar 01, 2007 at 12:15:36PM -0500, David Scaperoth wrote:
 On 3/1/07, seph 004 [EMAIL PROTECTED] wrote:
 
  This is what I did:
 
 def build_graph ():
 nchan = 1
 interp = 512
 duc0 = 0
 duc1 = 0
 fs = 250e3#2nd sample rate
 between usb and dac
 max_dev = 32e3  #1st sample rate divided
 by 4 (1st = 2nd sample rate)
 gain = 16e3
 k = 2 * math.pi * max_dev / fs
 vec1 = Numeric.arange (0.624, 0.656, 0.128)
 vsource = gr.vector_source_f(vec1, False)
 fmmod = gr.frequency_modulator_fc (k)
 amp = gr.multiply_const_cc(gain)
 
 fg = gr.flow_graph ()
 
 u = usrp.sink_c (0, interp, nchan)
 tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
 m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
 u.set_mux(m)
 subdev = usrp.selected_subdev(u, tx_subdev_spec)
 subdev.set_enable(True)
 
 sample_rate = u.dac_freq () / interp
 u.set_tx_freq (0, duc0)
 u.set_tx_freq (1, duc1)
 
 
 Are you trying to use one daughter boards(nchen=1)?   Why did you set duc0 =
 0?   that means your  frequency will not be set at all.  You do not need to
 do set_tx_freq() twice if you are using one daughter board.  you only need :
 u.set_tx_freq (0, duc0) where duc0 is some frequency.  Also, if you are
 using the basic daughterboards, you need to make sure that you have the
 output connector connect to TXA not TXB (according to your tx_subdev_spec)
 
 
 Hope this helped.
 David

Lance, you really want to be using tune, not set_tx_freq.
tune knows about all the daughterboards and does the right thing to
split the work between the digital upconverter and the RF front end (if any).

Take a look at fm_tx4.py or fm_tx_2_daughterboards.py

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-02-28 Thread seph 004
Well, I have implemented a bit of a strange setup which seems to be working 
somewhat now. I'm not really trying to view only the first few samples, I'm 
currently trying to track where I might of made a mistake with trying to 
generate a defined pulse with a specific length. My aim is to generate a very 
narrow band chirp to transmit on a little ultrasonic tranducer. I figured out 
which numerical values to the gr.modulation block produce which frequencies. 
Using this, I made a vector of the exact number of samples I want with the 
values to produce the frequencies I want. In my case 39-41 kHz. For some reason 
these low frequencies still make it through the transformer on the  basic TX 
db, so I'm using them. Initially I was just generating a sine wave, and trying 
to use gr.head to limit the number of samples, but I've since switched to this 
approach

I figured that if I wanted to produce a wave form lasting 10 msecs, then I 
would need at least 2500 samples. I got this number from the DAC rate of 128M 
and the highest interpolation factor of 512. When I test with the scope set to 
auto store, I spot the waveform, but it is only 1 msec long. So either I've 
lost a lot of samples somewhere, or my scaling is wrong.

I pretty much abandoned using gr.head, as it wasn't producing anything. At 
least now though I can see a waveform, though my scaling seems to have gone 
wrong somewhere. When you say you used a looback, do you mean you connected the 
TX db output  and RX db input, and used the gr.oscope block to view your 
signals?

Regards

Lance

- Original Message 
From: Lee Patton [EMAIL PROTECTED]
To: seph 004 [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Sent: Tuesday, February 27, 2007 12:58:31 AM
Subject: Re: [Discuss-gnuradio] The shortest pulse length

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









 

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-02-28 Thread David Scaperoth


On Feb 28, 2007, at 4:29 AM, seph 004 wrote:

Well, I have implemented a bit of a strange setup which seems to be  
working somewhat now. I'm not really trying to view only the first  
few samples, I'm currently trying to track where I might of made a  
mistake with trying to generate a defined pulse with a specific  
length. My aim is to generate a very narrow band chirp to transmit  
on a little ultrasonic tranducer. I figured out which numerical  
values to the gr.modulation block produce which frequencies. Using  
this, I made a vector of the exact number of samples I want with  
the values to produce the frequencies I want. In my case 39-41 kHz.  
For some reason these low frequencies still make it through the  
transformer on the  basic TX db, so I'm using them. Initially I was  
just generating a sine wave, and trying to use gr.head to limit the  
number of samples, but I've since switched to this approach


I figured that if I wanted to produce a wave form lasting 10 msecs,  
then I would need at least 2500 samples. I got this number from the  
DAC rate of 128M and the highest interpolation factor of 512. When  
I test with the scope set to auto store, I spot the waveform, but  
it is only 1 msec long. So either I've lost a lot of samples  
somewhere, or my scaling is wrong.


How are you creating the flow graph?



I pretty much abandoned using gr.head, as it wasn't producing  
anything. At least now though I can see a waveform, though my  
scaling seems to have gone wrong somewhere. When you say you used a  
looback, do you mean you connected the TX db output  and RX db  
input, and used the gr.oscope block to view your signals?


Regards

Lance

- Original Message 
From: Lee Patton [EMAIL PROTECTED]
To: seph 004 [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Sent: Tuesday, February 27, 2007 12:58:31 AM
Subject: Re: [Discuss-gnuradio] The shortest pulse length

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




Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-02-28 Thread seph 004
This is what I did:

def build_graph ():
nchan = 1
interp = 512
duc0 = 0
duc1 = 0
fs = 250e3#2nd sample rate between 
usb and dac
max_dev = 32e3  #1st sample rate divided by 4 
(1st = 2nd sample rate)
gain = 16e3
k = 2 * math.pi * max_dev / fs
vec1 = Numeric.arange (0.624, 0.656, 0.128)
vsource = gr.vector_source_f(vec1, False)
fmmod = gr.frequency_modulator_fc (k)
amp = gr.multiply_const_cc(gain)

fg = gr.flow_graph ()

u = usrp.sink_c (0, interp, nchan)
tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
u.set_mux(m)
subdev = usrp.selected_subdev(u, tx_subdev_spec)
subdev.set_enable(True)

sample_rate = u.dac_freq () / interp
u.set_tx_freq (0, duc0)
u.set_tx_freq (1, duc1)

   
fg.connect (vsource, fmmod, amp, u)

return fg


I modified a version of siggen_min2.py into the above.

Regards

Lance

- Original Message 
From: David Scaperoth [EMAIL PROTECTED]
To: seph 004 [EMAIL PROTECTED]
Cc: Lee Patton [EMAIL PROTECTED]; discuss-gnuradio@gnu.org
Sent: Thursday, March 1, 2007 5:59:22 AM
Subject: Re: [Discuss-gnuradio] The shortest pulse length


On Feb 28, 2007, at 4:29 AM, seph 004 wrote:

Well, I have implemented a bit of a strange setup which seems to be working 
somewhat now. I'm not really trying to view only the first few samples, I'm 
currently trying to track where I might of made a mistake with trying to 
generate a defined pulse with a specific length. My aim is to generate a very 
narrow band chirp to transmit on a little ultrasonic tranducer. I figured out 
which numerical values to the gr.modulation block produce which frequencies. 
Using this, I made a vector of the exact number of samples I want with the 
values to produce the frequencies I want. In my case 39-41 kHz. For some reason 
these low frequencies still make it through the transformer on the  basic TX 
db, so I'm using them. Initially I was just generating a sine wave, and trying 
to use gr.head to limit the number of samples, but I've since switched to this 
approach

I figured that if I wanted to produce a wave form lasting 10 msecs, then I 
would need at least 2500 samples. I got this number from the DAC rate of 128M 
and the highest interpolation factor of 512. When I test with the scope set to 
auto store, I spot the waveform, but it is only 1 msec long. So either I've 
lost a lot of samples somewhere, or my scaling is wrong.




How are you creating the flow graph?  


I pretty much abandoned using gr.head, as it wasn't producing anything. At 
least now though I can see a waveform, though my scaling seems to have gone 
wrong somewhere. When you say you used a looback, do you mean you connected the 
TX db output  and RX db input, and used the gr.oscope block to view your 
signals?

Regards

Lance

- Original Message 
From: Lee Patton [EMAIL PROTECTED]
To: seph 004 [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Sent: Tuesday, February 27, 2007 12:58:31 AM
Subject: Re: [Discuss-gnuradio] The shortest pulse length

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








 Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your 
fit.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 







 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r

Re: [Discuss-gnuradio] The shortest pulse length

2007-02-26 Thread seph 004
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 Patton [EMAIL PROTECTED]
To: seph 004 [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
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


On Fri, 2007-02-23 at 06:08 -0800, seph 004 wrote:
 Hi
 
 Does anyone know what the shortest duration pulse is which the USRP
 can transmit? I've tried to test it by using gr.head to limit the
 number of samples to produce a short waveform, but I can't catch
 anything appearing at the output. Is there a simple test I could do to
 check?
 
 Regards
 
 Lance
 
 
 
 __
 TV dinner still cooling?
 Check out Tonight's Picks on Yahoo! TV.
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio








 

Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-02-26 Thread Lee Patton
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




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] The shortest pulse length

2007-02-23 Thread Lee Patton
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


On Fri, 2007-02-23 at 06:08 -0800, seph 004 wrote:
 Hi
 
 Does anyone know what the shortest duration pulse is which the USRP
 can transmit? I've tried to test it by using gr.head to limit the
 number of samples to produce a short waveform, but I can't catch
 anything appearing at the output. Is there a simple test I could do to
 check?
 
 Regards
 
 Lance
 
 
 
 __
 TV dinner still cooling?
 Check out Tonight's Picks on Yahoo! TV.
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio