Hi fellows
We are trying to transmit and receive train of square wave over
wireless using RFX 2400. We modified the usrp_siggen.py file
accordingly to generate square wave. We used
./usrp_siggen.py -f 2450M -w 100000
Is the value with -f option correct? We assume that -f option refers
to center frequency at antenna but in an
earlier post it was mentioned that it is the DUC frequency. Which
one is correct?
On the receiver side, we used usrp_rx_cfile.py script to write the
received signal samples on a file. The received signal does not look
like a square wave rather a sinusoid. In some cases, the sinusoid
appears to be as harmonic of the square wave, sometimes as a modulated
sinusoid.
If anyone knows the cause and solution for this problem, please guide
us.
-
Are we missing anything here? Without communicating with USRP, we
made sure that gr_sig_source_c.cc (underlying function that
usrp_siggen.py calls) generates a square wave.
-
Do we need to do anything with the USRP tune function? Can we
specify the IF frequency at the transmitter and receiver explicitly?
-
Or we cannot transmit/receive square wave through GNU radio. We
understand that may be some filters on the usrp board or daughter
board will not allow high frequency signals that will distort the
corners of the square wave but getting only a sinusoid does not seem
right…
-
Our ultimate interest is not in square wave. For our purpose, we
need to generate a shortest possible pulse, say Gaussian pulse,
transmit it over the air and implement some ranging algorithms. We
started with square wave and got stuck.
Any help/ideas will be highly appreciated.
Thanks
Faisal
On Thu, Nov 13, 2008 at 12:51 PM, Francesco B. [email protected] wrote:
This post is a bit old… but I’m having a similar problem. Created a
modified gr_sig_source_c block such that attributes are assigned by
pseudo-randomly generated numbers (restricted to ranges such as would be
proper, as well as swapping waveform types for integers 0-5 and randomly
assigning one). It compiles and runs. Amplitude and frequency appear to
vary, but sine/cosine waves are the only ones which generate properly. Is
there a known solution to this?
Is it really a reception issue, or more of a transmission issue? Take
a look at the frequency characteristics of some of these different
waveforms, then look at your overall bandwidth of the signal you’re
able to transmit as well as the overall bandwidth of your received
signal.
You may want to look at the Suggested Reading page on the wiki:
http://gnuradio.org/trac/wiki/SuggestedReading
This will probably preemptively answer a lot of questions you have
with regards to radio communications.
Brian
This post is a bit old… but I’m having a similar problem. Created a
modified gr_sig_source_c block such that attributes are assigned by
pseudo-randomly generated numbers (restricted to ranges such as would be
proper, as well as swapping waveform types for integers 0-5 and randomly
assigning one). It compiles and runs. Amplitude and frequency appear to
vary, but sine/cosine waves are the only ones which generate properly.
Is
there a known solution to this?
~ Francesco B.
Syed Faisal Shah wrote:
to center frequency at antenna but in an
Re: [Discuss-gnuradio] Interpolation in siggen.py
corners of the square wave but getting only a sinusoid does not seem
Faisal
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://www.nabble.com/Problem-receiving-square-wave-tp10009840p20485774.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Thu, Nov 13, 2008 at 02:20:19PM -0800, Francesco B. wrote:
A fair amount of the RF-specific resources there are textbooks I don’t have
access to, though it’s probably a transmission issue, honestly. However, the
code consists a modified version of gr_sig_source_c (saved under an
alternate name) and usrp_siggen.py, with hard-coded values for all wave
properties save for the sampling frequency removed from usrp_siggen, and the
new block assigning pseudo-random numbers to them within a range that should
be tolerable. I’m not finding glaring problems, and it should be at least
mostly working, but is not. Code here:
Have you put the output of your modified sig_gen (that is, the samples
you’re about to send to the USRP) into a file and looked at it with
Octave or your other favorite tool?
http://www.nabble.com/file/p20490559/randsig_source_c.cc randsig_source_c.cc
http://www.nabble.com/file/p20490559/randsig_source_c.h randsig_source_c.h
http://www.nabble.com/file/p20490559/randsig.i randsig.i
http://www.nabble.com/file/p20490559/usrp_randsiggen.py usrp_randsiggen.py
Eric
Not as of yet. The short-term objective for me in terms of this project
has
shifted more from learning the process of compiling one’s own signal
processing block (in the event my project requires it) to bidirectional
communication with DBPSK, which seems to use entirely preexisting
modules. I
will take note of this and investigate it at a later time, however.
~ Francesco
Eric B. wrote:
the
randsig_source_c.cc
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://www.nabble.com/Problem-receiving-square-wave-tp10009840p20590055.html
Sent from the GnuRadio mailing list archive at Nabble.com.
A fair amount of the RF-specific resources there are textbooks I don’t
have
access to, though it’s probably a transmission issue, honestly. However,
the
code consists a modified version of gr_sig_source_c (saved under an
alternate name) and usrp_siggen.py, with hard-coded values for all wave
properties save for the sampling frequency removed from usrp_siggen, and
the
new block assigning pseudo-random numbers to them within a range that
should
be tolerable. I’m not finding glaring problems, and it should be at
least
mostly working, but is not. Code here:
http://www.nabble.com/file/p20490559/randsig_source_c.cc
randsig_source_c.cc
http://www.nabble.com/file/p20490559/randsig_source_c.h
randsig_source_c.h
http://www.nabble.com/file/p20490559/randsig.i randsig.i
http://www.nabble.com/file/p20490559/usrp_randsiggen.py
usrp_randsiggen.py
Brian P. wrote:
–
View this message in context:
http://www.nabble.com/Problem-receiving-square-wave-tp10009840p20490559.html
Sent from the GnuRadio mailing list archive at Nabble.com.