To expand on what Marcus said about DC, look advanced tuning with tune_request_t:
http://files.ettus.com/uhd_docs/manual/html/general.html#two-stage-tuning-process Cheers, Ben On Tue, Jan 10, 2012 at 3:03 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 01/10/2012 05:48 PM, UB wrote: > >> Here is my code for transmitting data from a file: >> from gnuradio import gr >> from gnuradio import uhd >> >> symbolrate=0.5*10**5 >> samplerate=20*symbolrate # 1M >> fg=gr.top_block() >> src=gr.file_source(gr.sizeof_**gr_complex*1,'data.txt',False) >> snk=uhd.usrp_sink('serial=**1R24X9U1',uhd.io_type.COMPLEX_**FLOAT32,1) >> snk.set_samp_rate(samplerate) >> snk.set_center_freq(2.4*10**9) >> fg.connect(src,snk) >> fg.run() >> >> And I run the uhd_fft.py on another USRP.. i constantly get a peak at >> centr >> frequency for data being sent, why? >> http://old.nabble.com/file/**p33115067/data.txt<http://old.nabble.com/file/p33115067/data.txt>data.txt >> > Many different debugging approaches: > > a) Plot your data with an FFT sink--rather than a usrp_sink. Is there a > spectral peak at DC? > > b) There will always be a small amount of DC offset in both directions (RX > and TX) that will > cause an anomaly around DC. You can null this out to a certain extent > using the calibrate > routines (assuming you have a USRP2/N2XX and either a WBX or SBX card). > > > c) You can always offset tune your TX, to take the DC offset anomaly away > from your main > transmit bandwidth. Similarly in RX. > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > > ______________________________**_________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
