RE: [Discuss-gnuradio] Running usrp2_wfm_rcv.py
For both those functions you need to pass in the variable you want assigned the value as an input parameter. Look at gnuradio/trunk/gr-usrp2/src/usrp2_source_base.cc for the function definitions of adc_rate and daughterboard_id. Tim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Catalin LACATUS Sent: Thursday, November 13, 2008 8:48 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Running usrp2_wfm_rcv.py Hello, -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I got the following error. ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'¨ -After I set the adc_rate=100e6, I got the following error: AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'daughterboard_id' -Testing ./find-usrps script is running fine with following result. 00:50:c2:85:30:0a hw_rev = 0x0300 My configuration is -Ubuntu 8.04, with the latest svn (7 days old)-USRP2 with a BasicRX - I am using Netgear Gigabit switch to connect to fast Ethernet port on my laptop. I could not directly connect my Gigabit PCMCIA card to USRP2. Please let me know how I can fix the error AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'daughterboard_id' Thank you, -Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running usrp2_wfm_rcv.py
On Thu, 2008-11-13 at 08:48 -0500, Catalin LACATUS wrote: -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I got the following error. ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'¨ This likely a bug in the host driver for the USRP2; I will work on this today. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Running usrp2_wfm_rcv.py
On Thu, 2008-11-13 at 10:12 -0500, Newman, Timothy wrote: For both those functions you need to pass in the variable you want assigned the value as an input parameter. Look at gnuradio/trunk/gr-usrp2/src/usrp2_source_base.cc for the function definitions of adc_rate and daughterboard_id. Actually, that is correct for the C++ API, but for Python we add a small shim to make it return the value instead of passing a pointer into it. So the code in usrp2_fft.py is calling it correctly. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running usrp2_wfm_rcv.py
On Thu, Nov 13, 2008 at 5:48 AM, Catalin LACATUS [EMAIL PROTECTED] wrote: -I tried to run usrp2_wfm_rcv.py to test my USRP2 with a BasicRX board and I got the following error. ¨AttributeError: 'usrp2_source_32fc_sptr' object has no attribute 'adc_rate'¨ Could you please confirm which repository revision of software you are using? Change into the top level directory that you checked out the source code into, and type: $ svn info On the surface, this looks like a version mismatch between the usrp2_fft.py script and the rest of GNU Radio. It could be other things as well, however. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with GNU radio installation in UBUNTU 8.10
On Wed, Nov 12, 2008 at 4:57 AM, gohar anwar [EMAIL PROTECTED] wrote: I am trying to install GNU radio on Ubuntu 8.10. I followed the script method (apt-get) step by step as described in wiki. All the packages are completey installed without any error.(during installation). But still GNU radio cant access the USRP. I am using USRP1 with my sony vaio fw160j. Following error occured when i tried to run th example usrp_benchmark_usb.py RuntimeError: can't open usrp1 The at least two possible reasons I can think of that would generate your symptoms: 1) You don't have access to the hardware. The binary package install adds the group 'usrp' and allows members of that group to access the USRP, but you need to add your userid to that group (this is in the wiki page you used.) 2) You have a physical cabling issue (such as not using a USB2.0 standard rated cable). -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with GNU radio installation in UBUNTU 8.10
Johnathan Corgan wrote: 1) You don't have access to the hardware. The binary package install adds the group 'usrp' and allows members of that group to access the USRP, but you need to add your userid to that group (this is in the wiki page you used.) A simple test if this is your error is to run the benchmark as root. If it works, you need to fix permissions to the hardware. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem receiving square wave
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: 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 10 Is the value with -f option correct? We assume that -f option refers to center frequency at antenna but in an http://lists.gnu.org/archive/html/discuss-gnuradio/2006-07/msg00097.html 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. 1. 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. 2. Do we need to do anything with the USRP tune function? Can we specify the IF frequency at the transmitter and receiver explicitly? 3. 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 4. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem receiving square wave
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem receiving square wave
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 Padalino wrote: 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem receiving square wave
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with carrier sense in USRP
Hi,
I am testing the carrier sense mechanism on USRP based on code from
benchmark_tx.py and tunnel.py. My scenario is to receive packets from two
distinctive nodes simultaneously at the third node. I am prefixing the
payload with sender node name to identify the sender.
When I am trying to send the packets from two nodes simultaneously, the
packets are still colliding, though I have incorporated carrier sense
mechanism in to my code. Please help me in this respect and if possible
suggest me a solution.
I think, packets are being sent by the lower level C++ processing blocks and
send_pkt() just enqueues the packets. So rather than holding sending of
packet, this code is just holding the packet from getting enqueued in
message queue. Which is not really the holding of packet till carrier is
free. Once packets are in message queue, they are transmitted irrespective
of carrier availability. So there is still possibility of packet collision.
Am I correct in my understanding of this real-time scenario?
Attached following is the code of sender application. Receiving application
is more or less similar to benchmark_rx.py with ability to identify the
packets.
Tx_carrier_sense.py
class my_top_block(gr.top_block):
def __init__(self, modulator, demodulator, rx_callback, options):
gr.top_block.__init__(self)
self.txpath = transmit_path(modulator, options)
self.rxpath = receive_path(demodulator, rx_callback, options)
self.connect(self.txpath)
self.connect(self.rxpath)
#
/
# main
#
/
def main():
def send_pkt(payload='', eof=False):
return tb.txpath.send_pkt(payload, eof)
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
pass
def rx_callback(ok, payload):
print ok = %r % (ok)
def carrier_sensed():
Return True if the receive path thinks there's carrier
return tb.rxpath.carrier_sensed()
demods = modulation_utils.type_1_demods()
mods = modulation_utils.type_1_mods()
parser = OptionParser(option_class=eng_option,
conflict_handler=resolve)
expert_grp = parser.add_option_group(Expert)
parser.add_option(-m, --modulation, type=choice,
choices=mods.keys(),
default='gmsk',
help=Select modulation from: %s [default=%%default]
% (', '.join(mods.keys()),))
parser.add_option(-s, --size, type=eng_float, default=1500,
help=set packet size [default=%default])
parser.add_option(-M, --megabytes, type=eng_float, default=1.0,
help=set megabytes to transmit [default=%default])
parser.add_option(,--discontinuous, action=store_true,
default=False,
help=enable discontinous transmission (bursts of 5
packets))
parser.add_option(,--from-file, default=None,
help=use file for packet contents)
receive_path.add_options(parser, expert_grp)
transmit_path.add_options(parser, expert_grp)
for mod in mods.values():
mod.add_options(expert_grp)
fusb_options.add_options(expert_grp)
(options, args) = parser.parse_args ()
if len(args) != 0:
parser.print_help()
sys.exit(1)
if options.tx_freq is None:
sys.stderr.write(You must specify -f FREQ or --freq FREQ\n)
parser.print_help(sys.stderr)
sys.exit(1)
if options.from_file is not None:
source_file = open(options.from_file, 'r')
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
pass
# build the graph
tb = my_top_block(mods[options.modulation], demods[options.modulation],
rx_callback, options)
r = gr.enable_realtime_scheduling()
if r != gr.RT_OK:
print Warning: failed to enable realtime scheduling
tb.start() # start flow graph
# generate and send packets
nbytes = int(1e6 * options.megabytes)
n = 0
pktno = 0
pkt_size = int(options.size)
min_delay = 0.0001
while n nbytes:
if options.from_file is None:
data = C-node + (pkt_size - 8) * chr(pktno 0xff)
else:
data = source_file.read(pkt_size - 2)
if data == '':
break;
payload = struct.pack('!H', pktno 0x) + data
delay = min_delay
while carrier_sensed():
print sensed
time.sleep(delay)
if delay 0.050:
delay = delay * 2 # exponential back-off
send_pkt(payload)
n += len(payload)
sys.stderr.write('.')
if options.discontinuous and pktno % 5 == 4:
time.sleep(0.3) # default = 1
pktno += 1
delay = min_delay
while
Re: [Discuss-gnuradio] problem with carrier sense in USRP
Collisions are still very likely in a software-defined radio
architecture if you implement the carrier sense mechanism on the host
(your machine running GNU Radio). If you think about it, carrier sense
needs to check if the medium is idle, if it is, it then sends.
If you think about the USRP and GNU Radio, the information it uses to
check if the medium is idle is as old as it takes to get from the RF
frontend on the USRP to GNU Radio. That time to get all the way up to
your processing blocks is likely over 1 or 2ms. Therefore, when it says
oh, the channel is idle! What's is really saying is: oh, the channel
was idle 1 or 2ms ago. That essentially breaks carrier sense.
To make matters even worse, when it thinks its captured the channel by
choosing to transmit, the transmission takes another 1ms to actually get
from the carrier sense decision mechanism to the USRP. So, your carrier
sense is roughly 2ms off, and anything can happen during that period.
This is referred to as a carrier sense blind-spot. The larger the
blind-spot, the more poor carrier sense is going to perform.
We have done work here on getting around these high latency issues by
implementing a split-functionality architecture to core MAC functions on
GNU Radio and the USRP. The idea is: implement part of the function on
the USRP, but leave the control completely at the host. So for example,
we modified GNU Radio and the USRP where GNU Radio sets the carrier
sense threshold on the USRP, and the USRP performs the carrier sense.
We've measured the blind spot in GNU Radio to be ~2ms, and with our
split-functionality it is ~1.5us. Major difference.
Our code release is pending on functionality in GNU Radio, and includes
many other optimizations for MAC functionality in software-defined radios.
- George
Shirve wrote:
Hi,
I am testing the carrier sense mechanism on USRP based on code from
benchmark_tx.py and tunnel.py. My scenario is to receive packets from two
distinctive nodes simultaneously at the third node. I am prefixing the
payload with sender node name to identify the sender.
When I am trying to send the packets from two nodes simultaneously, the
packets are still colliding, though I have incorporated carrier sense
mechanism in to my code. Please help me in this respect and if possible
suggest me a solution.
I think, packets are being sent by the lower level C++ processing blocks and
send_pkt() just enqueues the packets. So rather than holding sending of
packet, this code is just holding the packet from getting enqueued in
message queue. Which is not really the holding of packet till carrier is
free. Once packets are in message queue, they are transmitted irrespective
of carrier availability. So there is still possibility of packet collision.
Am I correct in my understanding of this real-time scenario?
Attached following is the code of sender application. Receiving application
is more or less similar to benchmark_rx.py with ability to identify the
packets.
Tx_carrier_sense.py
class my_top_block(gr.top_block):
def __init__(self, modulator, demodulator, rx_callback, options):
gr.top_block.__init__(self)
self.txpath = transmit_path(modulator, options)
self.rxpath = receive_path(demodulator, rx_callback, options)
self.connect(self.txpath)
self.connect(self.rxpath)
#
/
# main
#
/
def main():
def send_pkt(payload='', eof=False):
return tb.txpath.send_pkt(payload, eof)
if __name__ == '__main__':
try:
main()
except KeyboardInterrupt:
pass
def rx_callback(ok, payload):
print ok = %r % (ok)
def carrier_sensed():
Return True if the receive path thinks there's carrier
return tb.rxpath.carrier_sensed()
demods = modulation_utils.type_1_demods()
mods = modulation_utils.type_1_mods()
parser = OptionParser(option_class=eng_option,
conflict_handler=resolve)
expert_grp = parser.add_option_group(Expert)
parser.add_option(-m, --modulation, type=choice,
choices=mods.keys(),
default='gmsk',
help=Select modulation from: %s [default=%%default]
% (', '.join(mods.keys()),))
parser.add_option(-s, --size, type=eng_float, default=1500,
help=set packet size [default=%default])
parser.add_option(-M, --megabytes, type=eng_float, default=1.0,
help=set megabytes to transmit [default=%default])
parser.add_option(,--discontinuous, action=store_true,
default=False,
help=enable discontinous transmission (bursts of 5
packets))
parser.add_option(,--from-file, default=None,
help=use file for packet contents)
receive_path.add_options(parser, expert_grp)
[Discuss-gnuradio] GRBR paper is published. Open to public.
Colleagues, I am happy to announce that one paper based on GNU Radio is published online in the journal Earth, Planets and Space (EPS) E-letter section. This is to show the newly developed digital beacon receiver GNU Radio Beacon Receiver (GRBR) and its successful measure of the total electron content (TEC) of the ionosphere. The paper is open to anybody in the internet. Yamamoto, M., Digital beacon receiver for ionospheric TEC measurement developed with GNU Radio, Earth Planets Space, Vol. 60, pp. e21-e24, 2008. http://www.terrapub.co.jp/journals/EPS/pdf/2008e/6011e021.pdf EPS E-letter section, 2008 contents are shown here. http://www.terrapub.co.jp/journals/EPS/elp/60.html Detailed information of the digital receiver is also shown at the following URL. http://www.rish.kyoto-u.ac.jp/digitalbeacon/ Regards, Mamoru Yamamoto Research Institute for Sustainable Humanosphere (RISH) Kyoto University [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to change the channel width when data is transmitting
cao jing wrote: Hi, I am working on change the channel width dynamically when data is transmitting. I tried to use set_interp_rate to change the interpolation when data is transmitting, but it caused a program crashed. Does anybody know how to do it correctly? I checked in a fix to the verilog to allow this. However, the released rbf files haven't been updated yet, so you will need to compile it yourself. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 questions
Quoc Lai wrote: Eric Blossom wrote: On Wed, Sep 17, 2008 at 01:48:34AM +0300, Juha Vierinen wrote: What does it mean that USRP2 can only do MIMO with eight receivers? What are the options for doing MIMO with, say 16 receviers? You would need to design and build some kind of hub that would provide the clocks and synchronization for the 16 receivers using their MIMO interfaces. Depending on how you programmed the hub, you could just send the control from there, and then send the sample data over the ethernet interfaces on each of the 16 USRPs. You'd need some serious computational power to process 16 channels, each streaming 100MB/s of data. Sounds like fun :) Eric Hi Eric, Is the hub needed for any MIMO systems using USRP2? I want to build a 4x4 MIMO. Do I have the synchronization problem? Each USRP2 can handle 1 antenna with most daughterboards, or 2 if you have your own external RF sections connected to the USRP2 at IF. A dual USRP2 system does not need a hub, only a cable. A quad USRP2 system would need a hub unless you were willing to have 4 ethernet connections to the host computer. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
