Re: [Discuss-gnuradio] sampling artefact because of two step mixing?

2006-10-19 Thread Luis Simoes
Hi Don,

the problem is that the second peaks are not at DC in baseband. For example: I 
generate a sine tone at 2.444 Ghz. Then I tune the usrp to centre frequency 
of 2.448 GHz. Now I can see the peak at -3 Mhz in base band. Ok, this is 
correct because what Iam seeing is the original sine. When I tune the USPR to 
centre frequency 2.450 Ghz I see an attenuated peak at 1 MHz in baseband what 
correspond to 2.451Ghz. This second peak is 6 Mhz above the original sine.

If I rise the gain in the usrp_fft.py tool there appear more undesired peaks 
but I am still feeding the USRP with olny one tone. If I decrease the gain to 
eliminate all secondary peaks my original signal gets too weak and it is less 
than 10 db over the noise floor.

I am trying several setting to find out what is the reason of all this. The 
last try was:
1 sine tone at 2.488 Ghz feed into USRP
The result was:
one peak at 2.488 Ghz and one alt 2.432 GHz (20 dB's lower)
Now the secondary peak is 56 MHz away from the original tone!!!

Please, can anyone help me? I am getting desperate...

Luis   

On Wednesday 18 October 2006 20:12, you wrote:
> I have observed a similar phenomenon with the LFRX daughterboard.  It seems
> there is often (or always?) a peak at DC in the baseband (USRP output)
> spectrum, regardless of the tuned frequency of the USRP.  I suspect it is
> due to rounding down in the CIC decimation filter.  Adding a value of
> e*complex(1.0,1.0) where 0.5 <= e <= 0.8 to the USRP output will cancel it.
>
> -- Don W.
>
> - Original Message -
> From: "Luis Simoes" <[EMAIL PROTECTED]>
> [snipped]
>
> > As I feed the USRP with a single sine tone with a frequency of 2.444 GHz
> > and
> > an amplitude of -50dbm I saw on my plot a nice peak at 2.444 GHZ but also
> > a
> > second peak at 2.452 GHZ but attenuated by 15 db's when daughter board is
> > tuned to 2.452 Ghz.



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


Re: [Discuss-gnuradio] TDMA question

2006-10-19 Thread scaperot
>
> Yes, the m-block stuff will provide a reasonable interface for doing
> this.  Besides m-blocks, this also requires considerable work in the
> USRP FPGA to make it happen.
>
> The basic idea is that received packets will have time stamps in them
> that correspond to the arrival time that the first sample.  Likewise,
> you'll be able to indicate that a particular packet should "hit
> the air" at a particular time.
>
> Eric
>

So, currently, among time stamping, isn't latency in configuring the blocks a
limitation?  Perhaps the m-blocks will help with that, but I wasn't sure.  And
I am assuming that you have to do some kind of hardware change (for a TDMA
case) while the flow graph is running (at the very least turning a transmitter
on / off, or changing the frequencies periodically).  in some systems it might
be appropriate to "give up" some slots to reconfig, but is this what you had in
mind?  Is the plan still to have m-blocks around in December?  Currently, I have
been thinking about reconfiguration using the GNU Radio blocks as they are (e.g.
changing frequency, turning the transmitter on / off, etc.),and I found that the
latency was up to 1ms to turn the transmitter on using the 'set_enable' command
(meaning the latency between setting the enable
and moving on to other Python functions with GNU radio set to the highest
priority).  Does this sound reasonable?  Is is processor/OS dependent?  The
code I used to test just turning the transmitter on and off is below.  I am
also getting a warning with the destructor of the flex boards (The output of
the code is below) Could someone please help?

Thanks for your comment in advance,

David Scaperoth


from gnuradio import usrp, gr
import time

#print "directory", dir(usrp)
class benchmark_test(gr.flow_graph):
def __init__(self):
gr.flow_graph.__init__(self)

#USRP RX
self.decim = 128
self.rx_u = usrp.source_c()
adc_rate = self.rx_u.adc_rate()
self.rx_u.set_decim_rate(self.decim)
rx_subdev_spec = (0,0)
self.rx_subdevice = usrp.selected_subdev(self.rx_u, 
rx_subdev_spec)
self.rx_subdevice.set_auto_tr(True)
print "Using RX d'board %s" % 
(self.rx_subdevice.side_and_name(),)
self.rx_u.set_mux(usrp.determine_rx_mux_value(self.rx_u,
rx_subdev_spec))
self.rx_u.tune(self.rx_subdevice._which, 
self.rx_subdevice,900e6)
self.null = gr.null_sink(gr.sizeof_gr_complex)

#USRP TX
self.tx_u = usrp.sink_c ()
dac_rate = self.tx_u.dac_rate();
tx_usb_rate = 500e3
usrp_interp = int(dac_rate // tx_usb_rate)
self.tx_u.set_interp_rate(usrp_interp)
tx_subdev_spec = (0,0)
self.tx_sd = usrp.selected_subdev(self.tx_u, tx_subdev_spec)
self.tx_sd.set_auto_tr(True)
print "Using TX d-board", self.tx_sd.name()
self.tx_u.set_mux(usrp.determine_tx_mux_value(self.tx_u, 
tx_subdev_spec))
self.tx_u.tune(self.tx_sd._which, self.tx_sd,900e6)
self.tx_sd.set_enable(False)

#High Priority
r = gr.enable_realtime_scheduling()
if r != gr.RT_OK:
print "Warning: failed to enable realtime scheduling"

#Cosine
self.tx_sig = gr.sig_source_c(50e3, gr.GR_COS_WAVE, 6500, 1.0)

#Connect
self.connect(self.rx_u, self.null)
self.connect(self.tx_sig, self.tx_u)






def main():
fg = benchmark_test()
fg.start

time.sleep(0.5)
#raw_input("Press Enter To reset the Frequency")
start = time.time()
fg.tx_sd.set_enable(True)
stop  = time.time()
time.sleep(0.5)
fg.tx_sd.set_enable(False)
print "It took", stop - start, "seconds to set transmit."


time.sleep(1.5)
#raw_input("Press Enter To reset the Frequency")
start = time.time()
fg.tx_sd.set_enable(True)
stop  = time.time()
time.sleep(0.5)
fg.tx_sd.set_enable(False)
print "It took", stop - start, "seconds to set transmit."


time.sleep(1.5)
#raw_input("Press Enter To reset the Frequency")
start = time.time()
fg.tx_sd.set_enable(True)
stop  = time.time()
time.sleep(0.5)
fg.tx_sd.set_enable(False)
print "It took", stop - start, "seconds to set transmit."


time.sleep(1.5)
#raw_input("Press Enter To reset the Frequency")
start = time.time()
fg.tx_sd.set_enable(True)
stop  = time.time()
time.sleep(0.5)
fg.tx_sd.set_enable(False)
print "It took", stop - start, "seconds to set transmit."

raw_input("Press Enter to stop the flow graph.")
 

[Discuss-gnuradio] writing to fpga registers

2006-10-19 Thread seph 004
HiI am having a bit of trouble trying to work out how to write to FPGA registers from a c++ program. I found two methods that would do it, namely '_write_fpga_reg' in 'usrp_basic' and 'usrp_write_fpga reg' in 'usrp_prims'. I tried to use the usrp_prims method, but it requires a handle on the usb which if, I'm not mistaken is already held by usrp_standard_tx.I'm trying to transmit with usrp_standard_tx, then write the registers, then receive with usrp_standard_rx. For the usrp_basic method, I'm not sure how to use that method as my attempts have produced segmentation faults. This is what i tried:usrp_basic *ucom;then to write bool fine1 = ucom->_write_fpga_reg (77, 10);RegardsLance___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Compute/Save incoming samples

2006-10-19 Thread Lin Ji
Hi,
  If I plug 2 signals to the daughter board and let the USRP save samples to file, will it be saved in 2 files or just mixed in one file?
 
  And in the FPGA, which module handles the samples? I need to know this cuz I want to make time stamps on the samples.
 
  Thanks s lot
 
/Lin Ji
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio