Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On Tue, Feb 26, 2013 at 04:10:55PM -0600, Joel Mayer wrote: Dear GNU Radio aficionado's- Whatever happened to resistance, capacitance, and inductance? When I joined this thread I was hoping you would once in a while talk about ways of using the software in the computer to modify the resonant circuit in the hardware radio by making adjustments to the resistors, capacitors, and inductors. Oh, one of my favourite topics :) I'll have to point out that I'm completely biased here: When I started playing around with radio, the thingy between antenna and the computer was a total black box, just producing the bits and bytes I needed. In fact, that's what got me attracted to the SDR world, because I could already program, but those Smith charts... but that's not the point. First, I'll give you a practical answer: This mailing list is about GNU Radio, which is in a sense very hardware-independent. So there you go. But it's also very important to understand that Software Radio is not about modelling hardware. Using software allows the use of DSP, which means we can do stuff like linear-phase filters etc. (good luck tuning your R/C/I to do that), and we can create transceivers for digitally modulated signals very easily, which is really awkward in discrete hardware (although analog modulations are also easily coded). So, perhaps I just misunderstood your question. But despite not knowing how you would modify an inductor through software, this wouldn't help in building a transceiver that, upon sensing a change in the radio environment, would reconfigure itself and change the waveform used-- which is one goal of GNU Radio. Of course, this comes with some abstraction, which means that changing the resonant circuit of my USRP is nothing more than a library call to set_center_frequency() or whatever it's called. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpG31DzLG2VC.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working.
On 02/26/2013 06:55 PM, Sajjad Safdar wrote: HI, I am using tunnel.py command to setup a TCP/IP link between two usrp1. When i try to use the command , i get this error ./tunnel.py linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-29-g3cb515f7 Traceback (most recent call last): File ./tunnel.py, line 295, in module main() File ./tunnel.py, line 241, in main (tun_fd, tun_ifname) = open_tun_interface(options.tun_device_filename) File ./tunnel.py, line 79, in open_tun_interface ifs = ioctl(tun, TUNSETIFF, struct.pack(16sH, gr%d, mode)) IOError: [Errno 1] Operation not permitted Try running it with root rights, i.e. sudo ./tunnel.py. Also make sure that the device actually exists, run ifconfig tun0. -Andre ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] callback function called twice
Hi again GNURADIOers,
I have a set member function which is also used as a callback from GRC. It
looks like this:
void
test_file_sink::set_sensitivity(double milisecond)
{
d_n_samples = (unsigned
int)(milisecond*d_sample_rate/1000.0)*d_itemsize;
printf(\nd_n_samples: %d\n, d_n_samples);
init_old_data_buff();
}
When I run flowgraph, and change sensitivity, my callback function is
called twice.
Is this normal action?
Best
--
Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
Timothy L. Vance Chief Engineer, Expeditionary Electronic Warfare Naval Surface Warfare Center, Crane Building 3330N, 300 Hwy 361 Crane, IN 47522 Office: 812-854-5499 Cell: 812-296-1192 Email: timothy.va...@navy.mil SIPR:timothy.va...@navy.smil.mil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On Tue, Feb 26, 2013 at 5:10 PM, Joel Mayer joelm_armill...@msn.com wrote: ** Dear GNU Radio aficionado's- Whatever happened to resistance, capacitance, and inductance? When I joined this thread I was hoping you would once in a while talk about ways of using the software in the computer to modify the resonant circuit in the hardware radio by making adjustments to the resistors, capacitors, and inductors. Am I just dreaming? Am I on the wrong page? Is there any hope? Resistance? As in uprising? Ah a DSP counter revolution!! :-) Are you referring to the stuff in the black (err... white) box known as the USRP? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- M. Ranganathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduler Question
Hi Almohanad - From my (now old) memory of the GR runtime scheduler (STS and TBP), I believe you are roughly correct in the technical terminology, except that the schedules are not guaranteed to be periodic. They are opportunistic / aperiodic: process as much data as makes sense given the blocks constraints and how much data is available and how much output space is available. Tom (et.al.) have done some work on the TBP scheduler more recently than my memories, so maybe they have been tweaked to be truly periodic? That said, I do not believe either scheduler was created specifically with those terms or concepts in mind; I believe the current scheduler(s) were programmed as they are because they work well and were original creations. They might have been influenced by reading others works on SDF and the like, but I really doubt there was any true intent on recreating others works. Again, these are memories that I believe are correct; but then who knows. I believe Eric Blossom wrote both of the schedulers, and he's no longer around on this list to answer more officially (though I understand that folks do interact with him in person). - MLD On Feb 27, 2013, at 1:54 AM, Almohanad Fayez almohanad.fa...@gmail.com wrote: I've been reading through the code in gnuradio-core/runtime for a few days to understand the internal workings of the gnuradio scheduler. It seems to me that gnuradio was originally based on a synchronous dataflow (sdf) model of computation and the single thread schedule is an SDF sequential runtime schedule, or a periodic admissible sequential schedule (PASS), and the thread per block schedule is a parallel SDF scheduler, or a parallel admissible parallel schedule (PAPS). Does this sound like an accurate description of the schedulers and underlying gnuradio model of computation or am I reading too much into it? thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working.
Hi, Yes now it works but can not able to ping the Machines. I am using RFX400 daughter card and set 192.168.200.1 and 192.168.200.2 respectively on machine A and B. On machine A: # sudo ./tunnel.py --freq 423.0M --bitrate 500k -A TX/RX -v # # in another window on A, # ifconfig gr0 192.168.200.1 On machine B: # sudo ./tunnel.py --freq 423.0M --bitrate 500k -A TX/RX -v # # in another window on B # ifconfig gr0 192.168.200.2 I got the following outputs ON MACHINE A after setting up the virtual ethernet by sudo ifconfig gr0 192.168.200.1: helmut@ubuntu:~/gnuradio/gnuradio/gr-digital/examples/narrowba$ sudo ./tunnel.py --freq 423.0M --bitrate 500k -A TX/RX -v linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.001-29-g3cb515f7 gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 32.50 (from [0.00, 65.00]) UHD Receiver: UHD Args: Freq: 423MHz Gain: 32.50 dB Sample Rate: 1Msps Antenna: TX/RX Spec: None No gain specified. Setting gain to -10.00 (from [-20.00, 0.00]) UHD Transmitter: Args: Freq: 423MHz Gain: -10.00 dB Sample Rate: 1Msps Antenna: TX/RX Subdev Sec: None bits per symbol = 1 Gaussian filter bt = 0.35 Using Volk machine: ssse3_32 Tx amplitude 0.25 modulation: gmsk_mod bitrate: 500kb/s samples/symbol: 2. Differential: False bits per symbol = 1 MM clock recovery omega = 2.00 MM clock recovery gain mu = 0.175000 MM clock recovery mu = 0.50 MM clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: modulation: gmsk_demod bitrate: 500kb/s samples/symbol: 2. Differential: False modulation: gmsk freq: 423M bitrate: 500kb/sec samples/symbol: 2 Carrier sense threshold: 30 dB Allocated virtual ethernet interface: gr0 You must now use ifconfig to set its IP address. E.g., $ sudo ifconfig gr0 192.168.200.1 Be sure to use a different address in the same subnet for each machine. UUTx: len(payload) = 90 Tx: len(payload) = 54 Rx: ok = True len(payload) = 90 UTx: len(payload) = 81 URx: ok = True len(payload) = 54 Tx: len(payload) = 299 Tx: len(payload) = 202 Rx: ok = True len(payload) = 81 Rx: ok = True len(payload) = 299 UUTx: len(payload) = 299 Rx: ok = False len(payload) = 299 UUTx: len(payload) = 299 Rx: ok = False len(payload) = 299 URx: ok = False len(payload) = 101 Tx: len(payload) = 78 UUTx: len(payload) = 275 Rx: ok = False len(payload) = 275 UUTx: len(payload) = 81 UUTx: len(payload) = 202 URx: ok = True len(payload) = 81 UTx: len(payload) = 70 Tx: len(payload) = 110 Rx: ok = True len(payload) = 70 UUTx: len(payload) = 101 Rx: ok = True len(payload) = 110 Tx: len(payload) = 377 Tx: len(payload) = 192 Tx: len(payload) = 105 Tx: len(payload) = 222 Rx: ok = True len(payload) = 101 URx: ok = True len(payload) = 377 Rx: ok = True len(payload) = 192 Rx: ok = True len(payload) = 105 UTx: len(payload) = 236 URx: ok = True len(payload) = 222 Rx: ok = False len(payload) = 236 UTx: len(payload) = 377 Tx: len(payload) = 192 Rx: ok = True len(payload) = 377 URx: ok = False len(payload) = 192 UTx: len(payload) = 377 Tx: len(payload) = 192 URx: ok = True len(payload) = 377 Rx: ok = False len(payload) = 192 UTx: len(payload) = 353 Tx: len(payload) = 180 Rx: ok = True len(payload) = 353 Rx: ok = False len(payload) = 180 UUTx: len(payload) = 101 UUTx: len(payload) = 222 Rx: ok = True len(payload) = 101 UUTx: len(payload) = 81 UUTx: len(payload) = 319 Rx: ok = False len(payload) = 319 UUTx: len(payload) = 353 Tx: len(payload) = 152 Rx: ok = True len(payload) = 353 Rx: ok = False len(payload) = 152 UTx: len(payload) = 90 UUTx: len(payload) = 303 Rx: ok = False len(payload) = 303 UUTx: len(payload) = 54 UUTx: len(payload) = 101 UUTx: len(payload) = 323 Rx: ok = False len(payload) = 323 UUTx: len(payload) = 353 Tx: len(payload) = 180 Rx: ok = True len(payload) = 353 Tx: len(payload) = 70 Rx: ok = False len(payload) = 180 UUTx: len(payload) = 81 UUTx: len(payload) = 101 UUTx: len(payload) = 70 UUTx: len(payload) = 81 UUTx: len(payload) = 101 UU FROM the MACHINE B after setting virtual ethernet sudo ifconfig gr0 192.168.200.2 hw@E-Lab:~/gnuradio/gr-digital/examples/narrowband$ sudo ./tunnel.py --freq 423.0M --bitrate 500k -A TX/RX -v linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.005.001-25-ge134b863 gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 32.50 (from [0.00, 65.00]) UHD Receiver: UHD Args: Freq: 423MHz Gain: 32.50 dB Sample Rate: 1Msps Antenna: TX/RX Spec: None No gain specified.
Re: [Discuss-gnuradio] Scheduler Question
On Wed, Feb 27, 2013 at 9:06 AM, Michael Dickens m...@alum.mit.edu wrote: Hi Almohanad - From my (now old) memory of the GR runtime scheduler (STS and TBP), I believe you are roughly correct in the technical terminology, except that the schedules are not guaranteed to be periodic. They are opportunistic / aperiodic: process as much data as makes sense given the blocks constraints and how much data is available and how much output space is available. Tom (et.al.) have done some work on the TBP scheduler more recently than my memories, so maybe they have been tweaked to be truly periodic? That said, I do not believe either scheduler was created specifically with those terms or concepts in mind; I believe the current scheduler(s) were programmed as they are because they work well and were original creations. They might have been influenced by reading others works on SDF and the like, but I really doubt there was any true intent on recreating others works. Again, these are memories that I believe are correct; but then who knows. I believe Eric Blossom wrote both of the schedulers, and he's no longer around on this list to answer more officially (though I understand that folks do interact with him in person). - MLD Yeah, that about sums it up from my understanding of the history, too. The single-threaded scheduler was basically a dataflow model and I'm sure Eric used that concept to inform his design. When it comes to the TPB scheduler, the task was to make GNU Radio multi-threaded. So Eric adapted the STS one and rethought how it could work in parallel with some push-pull concepts about how much data is available on the input versus how much buffer space is available on the output. At this point, I'm not sure any strict concepts of scheduler theory were necessarily adhered to, though it wouldn't surprise me to learn that it's similar to some standard model(s) of computation (Eric has a long history in that area, so he would be well aware of the various concepts, models, and ideas). Tom On Feb 27, 2013, at 1:54 AM, Almohanad Fayez almohanad.fa...@gmail.com wrote: I've been reading through the code in gnuradio-core/runtime for a few days to understand the internal workings of the gnuradio scheduler. It seems to me that gnuradio was originally based on a synchronous dataflow (sdf) model of computation and the single thread schedule is an SDF sequential runtime schedule, or a periodic admissible sequential schedule (PASS), and the thread per block schedule is a parallel SDF scheduler, or a parallel admissible parallel schedule (PAPS). Does this sound like an accurate description of the schedulers and underlying gnuradio model of computation or am I reading too much into it? thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On Wed, Feb 27, 2013 at 3:04 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Feb 26, 2013 at 04:10:55PM -0600, Joel Mayer wrote: Dear GNU Radio aficionado's- Whatever happened to resistance, capacitance, and inductance? When I joined this thread I was hoping you would once in a while talk about ways of using the software in the computer to modify the resonant circuit in the hardware radio by making adjustments to the resistors, capacitors, and inductors. Oh, one of my favourite topics :) I'll have to point out that I'm completely biased here: When I started playing around with radio, the thingy between antenna and the computer was a total black box, just producing the bits and bytes I needed. In fact, that's what got me attracted to the SDR world, because I could already program, but those Smith charts... but that's not the point. First, I'll give you a practical answer: This mailing list is about GNU Radio, which is in a sense very hardware-independent. So there you go. But it's also very important to understand that Software Radio is not about modelling hardware. Using software allows the use of DSP, which means we can do stuff like linear-phase filters etc. (good luck tuning your R/C/I to do that), and we can create transceivers for digitally modulated signals very easily, which is really awkward in discrete hardware (although analog modulations are also easily coded). So, perhaps I just misunderstood your question. But despite not knowing how you would modify an inductor through software, this wouldn't help in building a transceiver that, upon sensing a change in the radio environment, would reconfigure itself and change the waveform used-- which is one goal of GNU Radio. Of course, this comes with some abstraction, which means that changing the resonant circuit of my USRP is nothing more than a library call to set_center_frequency() or whatever it's called. MB On the other hand, one of the major areas of work that we are still pursuing lies in the RF front end. We have wideband systems. Ettus has produced a number of daughterboards that cover multiple GHz of spectrum, which is fantastic. But through that, we suffer a bit on the amplifiers and filters needed for some kinds of communications tasks. What Ettus has done is produced very good IP3s, NFs, gains, etc over these large bandwidths, but that doesn't exactly compare to having a filter and amplifier specific to a small bandwidth for something like cellular communications. Or even, for that matter, antennas for various waveforms. Even today's wideband RFICs tend to have a lot of tweakable/tunable parameters to meet specific needs of different areas of spectrum. Are there software solutions that could be used to automatically adjust these parameters? Or an RLC matching circuit? Some of this, I know, requires advances in the materials and components to make any sense, in other cases the feedback loop could be a bit long to make any significant impact. But it's fun to think about. Goes back to my dissertation days, actually :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Padding for USRP
On Tue, Feb 26, 2013 at 9:12 PM, Josh Blum j...@ettus.com wrote: On 02/26/2013 08:03 PM, Manu T S wrote: In gnuradio/digital/packet_utils, the packets are padded to make it a multiple of 512 bytes to be sent across the USB(As per the comment there). USRP2 and N210 uses ethernet connection. Is it important to have padding for USRP in for these devices? If so is it the same number? ( 512 bytes to be sent across ethernet ) You should not need any padding. All of the devices (except usrp1) send samples encapsulated in a packet format so the boundaries of the samples are known by the device. I dont think you need the padding for USRP1 either, since UHD will flush out the buffer to a 512 byte multiple if it sees the EOB specified. -josh Yeah, that requirement comes from back in the libusrp days where it was just a pipe that we provided samples to and had to make sure the boundaries were met ourselves before sending along. With the UHD interface, you can safely ignore it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working.
On Wed, Feb 27, 2013 at 9:28 AM, Sajjad Safdar engrsajjadsaf...@yahoo.com wrote: Hi, Yes now it works but can not able to ping the Machines. I am using RFX400 daughter card and set 192.168.200.1 and 192.168.200.2 respectively on machine A and B. On machine A: # sudo ./tunnel.py --freq 423.0M --bitrate 500k -A TX/RX -v # # in another window on A, # ifconfig gr0 192.168.200.1 On machine B: # sudo ./tunnel.py --freq 423.0M --bitrate 500k -A TX/RX -v # # in another window on B # ifconfig gr0 192.168.200.2 Try using different transmit and receive frequencies. tunnel.py has some serious issues, and among them is with how data is handled with the UHD interface where it doesn't really handle the proper SOB and BOB concepts that would allow you to do full duplex on the same frequency. At this point, I'm not even sure doing FDD is going to work properly with it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Importing newly created C++ block
Hi all, We created a new module called radar(gr-radar folder created) and a block called lfm_source_c. Eventually, this new block will create a chirp style signal. We are trying to use in a Python file. The Python code was working perfectly fine when we used the gr signal source to generate a square wave. The wave transmitted to a scope sink and to our USRP N210. We successfully installed the new module with make install. We added an import radar statement at the beginning of the file which in and of itself didn't cause any errors. We got a whole list of errors when we tried to use the source in python. src = radar.lfm_source_c (wave_freq, pulse_width, pulse_rep_int, sample_rate, 2.0, 0) gr-radar is in our home path, but not the GNU Radio path (which I think is correct). Can anyone give us any insight into this problem? This is the first block we've created so don't have any experience with this. I will also include our error list below. Thanks for any help you can give! Below is the terminal output: Traceback (most recent call last): File chirp_test_gui.py, line 82, in module main () File chirp_test_gui.py, line 78, in main app = stdgui2.stdapp(tx_sink, Transmitted Signal, nstatus=1) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 38, in __init__ wx.App.__init__ (self, redirect=False) File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 42, in OnInit self._max_noutput_items) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 64, in __init__ self.panel = stdpanel (self, self, top_block_maker, max_nouts) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 86, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File chirp_test_gui.py, line 69, in __init__ sig0 = tx_test(options.freq,options.pulse_width,options.pulse_rep_int,options.samp_rate) File chirp_test_gui.py, line 26, in __init__ 0) # DC Offset File /usr/local/lib/python2.7/dist-packages/radar/radar_swig.py, line 319, in __init__ def __init__(self, *args, **kwargs): raise AttributeError(No constructor defined) AttributeError: No constructor defined ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Importing newly created C++ block
On Wed, Feb 27, 2013 at 10:42 AM, Brooke Hayden sdrat...@gmail.com wrote: Hi all, We created a new module called radar(gr-radar folder created) and a block called lfm_source_c. Eventually, this new block will create a chirp style signal. We are trying to use in a Python file. The Python code was working perfectly fine when we used the gr signal source to generate a square wave. The wave transmitted to a scope sink and to our USRP N210. We successfully installed the new module with make install. We added an import radar statement at the beginning of the file which in and of itself didn't cause any errors. We got a whole list of errors when we tried to use the source in python. src = radar.lfm_source_c (wave_freq, pulse_width, pulse_rep_int, sample_rate, 2.0, 0) gr-radar is in our home path, but not the GNU Radio path (which I think is correct). Can anyone give us any insight into this problem? This is the first block we've created so don't have any experience with this. I will also include our error list below. Thanks for any help you can give! Below is the terminal output: Traceback (most recent call last): File chirp_test_gui.py, line 82, in module main () File chirp_test_gui.py, line 78, in main app = stdgui2.stdapp(tx_sink, Transmitted Signal, nstatus=1) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 38, in __init__ wx.App.__init__ (self, redirect=False) File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 42, in OnInit self._max_noutput_items) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 64, in __init__ self.panel = stdpanel (self, self, top_block_maker, max_nouts) File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py, line 86, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File chirp_test_gui.py, line 69, in __init__ sig0 = tx_test(options.freq,options.pulse_width,options.pulse_rep_int,options.samp_rate) File chirp_test_gui.py, line 26, in __init__ 0) # DC Offset File /usr/local/lib/python2.7/dist-packages/radar/radar_swig.py, line 319, in __init__ def __init__(self, *args, **kwargs): raise AttributeError(No constructor defined) AttributeError: No constructor defined Brooke, How did you create the block? Was it using gr_modtool or did you roll it yourself from scratch? It looks like something in the SWIG interface is probably wrong. Do you have a separate interface (.i) file for this block or are you just including the header file in a radar_swig.i file? (The latter is the preferred way.) So make sure you have a make function and that the block is properly included in a SWIG interface file. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On 27/02/13 10:08 AM, Tom Rondeau wrote: On the other hand, one of the major areas of work that we are still pursuing lies in the RF front end. We have wideband systems. Ettus has produced a number of daughterboards that cover multiple GHz of spectrum, which is fantastic. But through that, we suffer a bit on the amplifiers and filters needed for some kinds of communications tasks. What Ettus has done is produced very good IP3s, NFs, gains, etc over these large bandwidths, but that doesn't exactly compare to having a filter and amplifier specific to a small bandwidth for something like cellular communications. Or even, for that matter, antennas for various waveforms. Even today's wideband RFICs tend to have a lot of tweakable/tunable parameters to meet specific needs of different areas of spectrum. Are there software solutions that could be used to automatically adjust these parameters? Or an RLC matching circuit? Some of this, I know, requires advances in the materials and components to make any sense, in other cases the feedback loop could be a bit long to make any significant impact. But it's fun to think about. Goes back to my dissertation days, actually :) Tom In some sense, what we're talking about here is the difference between Software *Controlled* Radio, and Software *Defined* Radio. A chain of DSP blocks applies a series of mathematical transforms to a digitized signal, in similar ways to the way a series of R/L/C/Gain components do to an analog signal. One can think of the R/L/C approach as performing rough *approximations* to a transform that is defined in strict mathematical terms. The DSP approach, in general, is able to achieve a higher fidelity of those transforms with a higher degree of flexibility and reconfigurability than could possibly be achieved with analog hardware. Although, at some considerable cost--a simple FM demodulator chip is $0.35 in bulk, whereas the amount of compute-gear you require to do the same thing is considerably more costly. But DSP/SDR doesn't require that you break out the soldering iron and parts bin every time you want to tweak/repurpose things. Now, having said that, the notion of having some kind of tracking filtering isn't a bad idea, the problem comes down to implementation, and the cost trade-offs involved. Considering things like daughter cards covering 30Mhz to 4.4Ghz, exactly how many cuts across that bandwidth do you make, and how much are people willing to pay for additional dynamic range implied by band-limiting at the RF end of things? The technology is mostly there -- GaAsFET RF switches, LTCC filter modules, saw filters, dielectric filters, etc, are all out there. But almost any hard decision made by the manufacturer in such things is likely to be wrong in enough cases that perhaps all of that should be done externally to a daughtercard, with provision for a generic switching interface (like the existing GPIOs on many Ettus daughtercards). In an ideal world, you wouldn't need much front-end filtering. Your gain stages would be uber-linear up to ridiculous input powers, and you'd have a 24-bit ADC sampling at several Gsps. We aren't anywhere near there yet. -- 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
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On Wed, Feb 27, 2013 at 11:38 AM, Marcus D. Leech mle...@ripnet.com wrote: On 27/02/13 10:08 AM, Tom Rondeau wrote: On the other hand, one of the major areas of work that we are still pursuing lies in the RF front end. We have wideband systems. Ettus has produced a number of daughterboards that cover multiple GHz of spectrum, which is fantastic. But through that, we suffer a bit on the amplifiers and filters needed for some kinds of communications tasks. What Ettus has done is produced very good IP3s, NFs, gains, etc over these large bandwidths, but that doesn't exactly compare to having a filter and amplifier specific to a small bandwidth for something like cellular communications. Or even, for that matter, antennas for various waveforms. Even today's wideband RFICs tend to have a lot of tweakable/tunable parameters to meet specific needs of different areas of spectrum. Are there software solutions that could be used to automatically adjust these parameters? Or an RLC matching circuit? Some of this, I know, requires advances in the materials and components to make any sense, in other cases the feedback loop could be a bit long to make any significant impact. But it's fun to think about. Goes back to my dissertation days, actually :) Tom In some sense, what we're talking about here is the difference between Software *Controlled* Radio, and Software *Defined* Radio. A chain of DSP blocks applies a series of mathematical transforms to a digitized signal, in similar ways to the way a series of R/L/C/Gain components do to an analog signal. One can think of the R/L/C approach as performing rough *approximations* to a transform that is defined in strict mathematical terms. The DSP approach, in general, is able to achieve a higher fidelity of those transforms with a higher degree of flexibility and reconfigurability than could possibly be achieved with analog hardware. Although, at some considerable cost--a simple FM demodulator chip is $0.35 in bulk, whereas the amount of compute-gear you require to do the same thing is considerably more costly. But DSP/SDR doesn't require that you break out the soldering iron and parts bin every time you want to tweak/repurpose things. Now, having said that, the notion of having some kind of tracking filtering isn't a bad idea, the problem comes down to implementation, and the cost trade-offs involved. Considering things like daughter cards covering 30Mhz to 4.4Ghz, exactly how many cuts across that bandwidth do you make, and how much are people willing to pay for additional dynamic range implied by band-limiting at the RF end of things? The technology is mostly there -- GaAsFET RF switches, LTCC filter modules, saw filters, dielectric filters, etc, are all out there. But almost any hard decision made by the manufacturer in such things is likely to be wrong in enough cases that perhaps all of that should be done externally to a daughtercard, with provision for a generic switching interface (like the existing GPIOs on many Ettus daughtercards). Well said. In an ideal world, you wouldn't need much front-end filtering. Your gain stages would be uber-linear up to ridiculous input powers, and you'd have a 24-bit ADC sampling at several Gsps. We aren't anywhere near there yet. Yeah that's a hard one to swallow. The near-far problem in some bands makes even what you're considering here problematic. ~140 dB dynamic range does sound pretty good for most things, though :) There are other proposed solutions out there that take this concept even farther but require much greater investment in hardware cost (we're talking multiple ADCs, DSP units, etc.). But we're still going to need front end filtering and amplifiers for a while longer. Oh, and let's still not forget the antenna, though there are decent solutions for narrowband signals over large bandwidths (that is, good performance over a large bandwidth with varying group delays along the way, so you can only get away with narrowband signals or clever correction algorithms). Tom -- 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
Re: [Discuss-gnuradio] Google Summer of Code 2013
Ideas, ideas, ideas! Everyone, we need ideas. The GSoC application deadline is coming closer, and we still are lacking some ideas. So what cool feature of GNU Radio are *you* missing? Head over here, and write them down: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC At this point, any random idea is OK. Also, you're not signing up for anything if you post an idea. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpL0HDrUVHnc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2013
Really great documentation would be nice. I know that it has been improving, but maybe GSOC is an excuse for a sprint? Ideally, the documenter is someone who really knows DSP and what is going on behind the curtains. References to examples in the documentation would help out immensely. I often resort to hunting down a block's source code or other blocks and examples that use the block to understand it. I have always wanted an auto-magically generated list of references to other blocks/examples that use the block being documented. I think this would be easy to do in python. When building the docs, a script could search for instances of each block in other blocks and examples, then insert them as references in the block's documentation. As someone with little DSP backrground, I would like to be able to see some great documentation when I open up a block in GRC or introspect it in python. Very Respectfully, Dan CaJacob -- This email contains sensitive proprietary and confidential information. The technical data contained herein is/may be controlled under the U.S. International Traffic in Arms Regulations (ITAR) and may not be exported to a Foreign Person, either in the U.S. or abroad, without the proper authorization by the U.S. Department of State. -- On Wed, Feb 27, 2013 at 12:39 PM, Martin Braun (CEL) martin.br...@kit.eduwrote: Ideas, ideas, ideas! Everyone, we need ideas. The GSoC application deadline is coming closer, and we still are lacking some ideas. So what cool feature of GNU Radio are *you* missing? Head over here, and write them down: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC At this point, any random idea is OK. Also, you're not signing up for anything if you post an idea. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2013
On Wed, Feb 27, 2013 at 10:49 AM, Dan CaJacob dan.caja...@gmail.com wrote: I have always wanted an auto-magically generated list of references to other blocks/examples that use the block being documented. I think this would be easy to do in python. When building the docs, a script could search for instances of each block in other blocks and examples, then insert them as references in the block's documentation. Great idea. Let us know if you do any work towards this--I'd be happy to review and see how to integrate it into the main GNU Radio software base. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2013
On 02/27/2013 10:49 AM, Dan CaJacob wrote: Really great documentation would be nice. I know that it has been improving, but maybe GSOC is an excuse for a sprint? Ideally, the documenter is someone who really knows DSP and what is going on behind the curtains. GSoC is for code related work, not documentation work. However, a proposal to write some code that would improve usability should be OK. Philip References to examples in the documentation would help out immensely. I often resort to hunting down a block's source code or other blocks and examples that use the block to understand it. I have always wanted an auto-magically generated list of references to other blocks/examples that use the block being documented. I think this would be easy to do in python. When building the docs, a script could search for instances of each block in other blocks and examples, then insert them as references in the block's documentation. As someone with little DSP backrground, I would like to be able to see some great documentation when I open up a block in GRC or introspect it in python. Very Respectfully, Dan CaJacob -- This email contains sensitive proprietary and confidential information. The technical data contained herein is/may be controlled under the U.S. International Traffic in Arms Regulations (ITAR) and may not be exported to a Foreign Person, either in the U.S. or abroad, without the proper authorization by the U.S. Department of State. -- On Wed, Feb 27, 2013 at 12:39 PM, Martin Braun (CEL) martin.br...@kit.eduwrote: Ideas, ideas, ideas! Everyone, we need ideas. The GSoC application deadline is coming closer, and we still are lacking some ideas. So what cool feature of GNU Radio are *you* missing? Head over here, and write them down: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC At this point, any random idea is OK. Also, you're not signing up for anything if you post an idea. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2013
Hi there, I would like to ask you about the participation in GSoC 2013 of the GNSS-SDR project under the umbrella of GNU Radio. Last year I served as a mentor and we all (the student, other developers and I) had a nice experience adding Galileo capabilities to the GNSS software receiver. We enjoyed it, benefited from it, and I would love to participate again in this year's edition, but I personally feel that only GNSS-SDR took advantage from the work done in GSoC 2012, having no impact for the majority of GNU Radio users. GNSS-SDR is an open source Global Navigation Satellite System software receiver written in C++ that uses GNU Radio's scheduler, block hierarchy and some processing blocks. In that sense, we are *users* of GNU Radio but we do not contribute directly to the project. Since I'm aware that the slots are limited, I understand that developing other features for general GNU Radio usage (e.g. the Great Documentation proposal) can have a wider impact and more people can benefit from it. Otherwise, if you feel that having third-party applications based on GNU Radio is positive to the project, I will immediately rewrite the description at http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC with new (and hopefully cool) proposals for this summer :-) Best regards, Carles On Wed, Feb 27, 2013 at 8:04 PM, Philip Balister phi...@balister.orgwrote: On 02/27/2013 10:49 AM, Dan CaJacob wrote: Really great documentation would be nice. I know that it has been improving, but maybe GSOC is an excuse for a sprint? Ideally, the documenter is someone who really knows DSP and what is going on behind the curtains. GSoC is for code related work, not documentation work. However, a proposal to write some code that would improve usability should be OK. Philip References to examples in the documentation would help out immensely. I often resort to hunting down a block's source code or other blocks and examples that use the block to understand it. I have always wanted an auto-magically generated list of references to other blocks/examples that use the block being documented. I think this would be easy to do in python. When building the docs, a script could search for instances of each block in other blocks and examples, then insert them as references in the block's documentation. As someone with little DSP backrground, I would like to be able to see some great documentation when I open up a block in GRC or introspect it in python. Very Respectfully, Dan CaJacob -- This email contains sensitive proprietary and confidential information. The technical data contained herein is/may be controlled under the U.S. International Traffic in Arms Regulations (ITAR) and may not be exported to a Foreign Person, either in the U.S. or abroad, without the proper authorization by the U.S. Department of State. -- On Wed, Feb 27, 2013 at 12:39 PM, Martin Braun (CEL) martin.br...@kit.eduwrote: Ideas, ideas, ideas! Everyone, we need ideas. The GSoC application deadline is coming closer, and we still are lacking some ideas. So what cool feature of GNU Radio are *you* missing? Head over here, and write them down: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC At this point, any random idea is OK. Also, you're not signing up for anything if you post an idea. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2013
On Wed, Feb 27, 2013 at 11:12 AM, Carles Fernandez carles.fernan...@gmail.com wrote: ...but I personally feel that only GNSS-SDR took advantage from the work done in GSoC 2012, having no impact for the majority of GNU Radio users. As we discussed at the GNU Radio conference last year, it would be very useful to go through the GNSS-SDR code to identify signal processing blocks you had to create, but weren't directly part of the GPS/Galileo implementation code. These are good candidates for things that are missing from GNU Radio and would of be of use to the wider community. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working.
Tom what do you mean by using different Tx Rx frequencies. Also recently I did following. I connected 2 usrp with a single PC and ran 2 instances of tunnel in it with 1 usrp for each. Made two virtual ethernet interfaces gr0 gr1 also set two different ip addresses. And I was able to ping from one ip address to another. I also did ssh and scp. Now suddenly I am getting doubt that was that a wireless ping ?? Or was it just withing a system i.e ping between two virtual ethernet interfaces inside the system. If it was within the system then I might have made a wrong screen cast on this tunnel thing which I recently uploaded on my channel http://www.youtube.com/watch?v=CLvV2Q7vh-o PS : Video is a bit blurred but one can easily make out -- View this message in context: http://gnuradio.4.n7.nabble.com/tunnel-py-command-not-working-tp39857p39886.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bandwidth control approach
Hi everyone: I need to manage a span that can be bigger than the USRP span limit. I have been looking at usrp_spectrum_sense.py but I would rather prefer to solve this matter in C++ with a control block that changes the central frequency and span (I don't understand how to apply the usrp_spectrum_sense approach to my blocks). Is this possible? Can a block manage the variables that are used by the UHD:USRP Source? Thanks in advance :) Este documento puede contener información privilegiada o confidencial. Por tanto, usar esta información y sus anexos para propósitos ajenos a los de la Universidad Icesi, divulgarla a personas a las cuales no se encuentre destinado este correo o reproducirla total o parcialmente, se encuentra prohibido en virtud de la legislación vigente. La universidad no asumirá responsabilidad sobre información, opiniones o criterios contenidos en este correo que no estén directamente relacionados con la Icesi. Si usted no es el destinatario autorizado o por error recibe este mensaje, por favor informe al remitente y posteriormente bórrelo de su sistema sin conservar copia del mismo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I patch UCSBJello files to my existing gnuradio version?
Thanks a lot, Tom. I am trying to follow the instructions of https://www.cgran.org/wiki/UCSBJello line-by-line. However, I am facing the following issues in step 1 and step 2. Any feedback will be appreciated. *Step 1: Download gnuradio-3.2.2 tarball ( http://gnuradio.org/redmine/wiki/gnuradio/Release32Branch)* The mentioned website does not exist any more. Which command shall I use? Shall I download the latest weekly development code from http://gnuradio.org/files/builds/gnuradio-current.tar.gz? *Step 2: Patch Jello files to gnuradio * It means that I will have to download the jello files separately and then copy to the GNUradio folder, right? I tried the following wget command to recursively download all files of the jello folder ( https://www.cgran.org/browser/projects/ucsb_jello). wget -r --no-parent --reject index.html* --no-check-certificate https://www.cgran.org/browser/projects/ucsb_jello However, it is not downloading a lot of files correctly, i.e., some .cpp and .py files are getting downloaded in corrupt version. I have always installed gnuradio through Marcus's build-gnuradio code. Therefore, I am sorry if these tarball related questions are very novice. Thanks, Nazmul On Fri, Feb 22, 2013 at 9:54 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Feb 21, 2013 at 4:34 PM, Nazmul Islam mnis...@winlab.rutgers.edu wrote: Hello, I am trying to patch UCSBJello files to my (already installed) gnuradio version. I installed the latest version of gnuradio a couple of days ago using the build-gnuradio script. The UCSBJello project page in CGRAN (https://cgran.org/wiki/UCSBJello) tells to download the tarball, patch the files and then run the build gnuradio command. Since, I have gnuradio running in my laptop already, how can I patch the UCSB Jello files to my existing gnuradio version? I can download each file of UCSB Jello one-by-one and see if that works. However, that will take a long time and I wonder if there is any shortcut. I am sorry if this sounds a very novice question. Any feedback will be very appreciated. Thanks, Nazmul Nazmul, I don't think there's really a short-cut. I'm not sure exactly what you mean by downloading each file, but then again, I'm not familiar with that UCSB project. I would just download the project, extract it, then try to build by hand and see where the compiler tells you there are problems. If this was written against another version of GNU Radio, there are probably going to be some API changes between the versions that affect you. Just work through these until the compiler is happy. Tom -- Muhammad Nazmul Islam Graduate Student Electrical Computer Engineering Wireless Information Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple Correlator Input Requirements
I believe the GRC Simple Correlator is the inverse of the Simple Framer, yet it takes float inputs. What is the proper format of the input data? I see that the code does some slicing on the input, so I expect the floats to be positive and negative float values representing ones or zeros respectively. Asked another way, what is wrong with the simple flowgraph below? File Source (byte) - Simple Framer (Payload Size = 6) - Throttle - Packed to Unpacked (Byte,1 bit per Chunk, MSB) - This block causes the bits to be represented as serial bytes. - Char to Float (scale 1) - Add Const (float, -0.5) This removes the DC bias to facilitate slicing. - Simple Correlator (Payload Byte Size = 6) - File Sink (byte). No data comes out of the Simple Correlator, but using GUI sinks, I see that all the other blocks work. There is mention on the Internet that the Simple Correlator requires 8x oversampling. Is that true? I only need correlation at the bit level, not at the symbol timing. Is the Simple Correlator the wrong block to undo the Simple Framer? -Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Usage of Message Queues
Thank you again for your answer. I looked up the Header File of gr_message and it should have the msg() attribute. But when I tried to access, it gave me the error that this attribute isnt existing. Anyway, I now figured out a way which is enough for me: I converted the returned string to a list of bits, and then conert them to a list of bytes, This gives me back the wanted output stream of the demodulator. -- View this message in context: http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39893.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple Correlator Input Requirements
On Wed, Feb 27, 2013 at 3:56 PM, Douglas Ellena dell...@cti1.net wrote: I believe the GRC Simple Correlator is the inverse of the Simple Framer, yet it takes float inputs. What is the proper format of the input data? I see that the code does some slicing on the input, so I expect the floats to be positive and negative float values representing ones or zeros respectively. Asked another way, what is wrong with the simple flowgraph below? File Source (byte) - Simple Framer (Payload Size = 6) - Throttle - Packed to Unpacked (Byte,1 bit per Chunk, MSB) - This block causes the bits to be represented as serial bytes. - Char to Float (scale 1) - Add Const (float, -0.5) This removes the DC bias to facilitate slicing. - Simple Correlator (Payload Byte Size = 6) - File Sink (byte). No data comes out of the Simple Correlator, but using GUI sinks, I see that all the other blocks work. There is mention on the Internet that the Simple Correlator requires 8x oversampling. Is that true? I only need correlation at the bit level, not at the symbol timing. Is the Simple Correlator the wrong block to undo the Simple Framer? -Thanks Yes, it's true that you need to oversample by 8 for this block. I'm pretty sure it was a block that was written quickly for a very specific purpose and was never updated after that. For how to use it, I, just this week in fact, created QA for this block, so you can use that as an example of how it works with the simple_framer. Note also that I moved the block into gr-digital and made what I think was a bug fix to the code itself, so you'll want to use that one when referencing the QA. (I didn't 'fix' the bug in the block found in gnuradio-core because it was possibly not a bug and a misuse on my part; I didn't want to affect anyone using the old version that might have it working for them.) My suggestion would be to take this block and reimplement it where it doesn't do the 8x oversampling. Or maybe just add the number of sps as a parameter that can be used in the algorithm for doing the correlation. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On Wed, Feb 27, 2013 at 11:52 AM, Tom Rondeau t...@trondeau.com wrote: On Wed, Feb 27, 2013 at 11:38 AM, Marcus D. Leech mle...@ripnet.com wrote: On 27/02/13 10:08 AM, Tom Rondeau wrote: On the other hand, one of the major areas of work that we are still pursuing lies in the RF front end. We have wideband systems. Ettus has produced a number of daughterboards that cover multiple GHz of spectrum, which is fantastic. But through that, we suffer a bit on the amplifiers and filters needed for some kinds of communications tasks. What Ettus has done is produced very good IP3s, NFs, gains, etc over these large bandwidths, but that doesn't exactly compare to having a filter and amplifier specific to a small bandwidth for something like cellular communications. Or even, for that matter, antennas for various waveforms. Even today's wideband RFICs tend to have a lot of tweakable/tunable parameters to meet specific needs of different areas of spectrum. Are there software solutions that could be used to automatically adjust these parameters? Or an RLC matching circuit? Some of this, I know, requires advances in the materials and components to make any sense, in other cases the feedback loop could be a bit long to make any significant impact. But it's fun to think about. Goes back to my dissertation days, actually :) Tom In some sense, what we're talking about here is the difference between Software *Controlled* Radio, and Software *Defined* Radio. A chain of DSP blocks applies a series of mathematical transforms to a digitized signal, in similar ways to the way a series of R/L/C/Gain components do to an analog signal. One can think of the R/L/C approach as performing rough *approximations* to a transform that is defined in strict mathematical terms. The DSP approach, in general, is able to achieve a higher fidelity of those transforms with a higher degree of flexibility and reconfigurability than could possibly be achieved with analog hardware. Although, at some considerable cost--a simple FM demodulator chip is $0.35 in bulk, whereas the amount of compute-gear you require to do the same thing is considerably more costly. But DSP/SDR doesn't require that you break out the soldering iron and parts bin every time you want to tweak/repurpose things. Now, having said that, the notion of having some kind of tracking filtering isn't a bad idea, the problem comes down to implementation, and the cost trade-offs involved. Considering things like daughter cards covering 30Mhz to 4.4Ghz, exactly how many cuts across that bandwidth do you make, and how much are people willing to pay for additional dynamic range implied by band-limiting at the RF end of things? The technology is mostly there -- GaAsFET RF switches, LTCC filter modules, saw filters, dielectric filters, etc, are all out there. But almost any hard decision made by the manufacturer in such things is likely to be wrong in enough cases that perhaps all of that should be done externally to a daughtercard, with provision for a generic switching interface (like the existing GPIOs on many Ettus daughtercards). Well said. In an ideal world, you wouldn't need much front-end filtering. Your gain stages would be uber-linear up to ridiculous input powers, and you'd have a 24-bit ADC sampling at several Gsps. We aren't anywhere near there yet. Yeah that's a hard one to swallow. The near-far problem in some bands makes even what you're considering here problematic. ~140 dB dynamic range does sound pretty good for most things, though :) There are other proposed solutions out there that take this concept even farther but require much greater investment in hardware cost (we're talking multiple ADCs, DSP units, etc.). But we're still going to need front end filtering and amplifiers for a while longer. Oh, and let's still not forget the antenna, though there are decent solutions for narrowband signals over large bandwidths (that is, good performance over a large bandwidth with varying group delays along the way, so you can only get away with narrowband signals or clever correction algorithms). Tom -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org For those interested, this DARPA project was pointed out to me: https://www.fbo.gov/index?s=opportunitymode=formid=7c438631d57659b7b9f932df6d3da484tab=core_cview=1 Here's a brief write-up that summarizes the effort (apologies for the in-your-face ad at the top): http://www.militaryaerospace.com/articles/2012/08/darpa-rf-fpga.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working.
On Wed, Feb 27, 2013 at 2:01 PM, sumitstop sumit.ku...@research.iiit.ac.in wrote: Tom what do you mean by using different Tx Rx frequencies. I mean exactly that: use different frequencies like in an FDD system. Set the transmit frequency to f_tx and the receive frequency to f_rx. When you run tunnel.py -h, you'll see options --tx-freq and --rx-freq. Just setting --freq automatically sets tx_freq = rx_freq = freq. Also recently I did following. I connected 2 usrp with a single PC and ran 2 instances of tunnel in it with 1 usrp for each. Made two virtual ethernet interfaces gr0 gr1 also set two different ip addresses. And I was able to ping from one ip address to another. I also did ssh and scp. Now suddenly I am getting doubt that was that a wireless ping ?? Or was it just withing a system i.e ping between two virtual ethernet interfaces inside the system. It was probably being done internally. First check your routing table, but your system is probably being smart and just passing packets over the loopback device. You can use wireshark/tcpdump to check this out. If it was within the system then I might have made a wrong screen cast on this tunnel thing which I recently uploaded on my channel http://www.youtube.com/watch?v=CLvV2Q7vh-o PS : Video is a bit blurred but one can easily make out Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I patch UCSBJello files to my existing gnuradio version?
On Wed, Feb 27, 2013 at 4:10 PM, Nazmul Islam mnis...@winlab.rutgers.edu wrote: Thanks a lot, Tom. I am trying to follow the instructions of https://www.cgran.org/wiki/UCSBJello line-by-line. However, I am facing the following issues in step 1 and step 2. Any feedback will be appreciated. Step 1: Download gnuradio-3.2.2 tarball (http://gnuradio.org/redmine/wiki/gnuradio/Release32Branch) The mentioned website does not exist any more. Which command shall I use? Shall I download the latest weekly development code from http://gnuradio.org/files/builds/gnuradio-current.tar.gz? If you're trying to get it working with the latest code, then yes, ignore this step and install based on either the latest master from git, the latest 3.6.4 release, or that tarball you linked to (although that's 'current' as of about 3 months ago; it's a long story but a new one should be up soon). My recommendation would be to go with the latest release so you know that your patches are tied to a specific stable version of GNU Radio. You can find all of the releases here: http://gnuradio.org/releases/gnuradio/ Step 2: Patch Jello files to gnuradio It means that I will have to download the jello files separately and then copy to the GNUradio folder, right? I tried the following wget command to recursively download all files of the jello folder (https://www.cgran.org/browser/projects/ucsb_jello). wget -r --no-parent --reject index.html* --no-check-certificate https://www.cgran.org/browser/projects/ucsb_jello However, it is not downloading a lot of files correctly, i.e., some .cpp and .py files are getting downloaded in corrupt version. That sounds like a problem on the hosting side. Can you manually download the same files without them being corrupted? wget shouldn't be getting in the way of anything. Tom I have always installed gnuradio through Marcus's build-gnuradio code. Therefore, I am sorry if these tarball related questions are very novice. Thanks, Nazmul On Fri, Feb 22, 2013 at 9:54 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Feb 21, 2013 at 4:34 PM, Nazmul Islam mnis...@winlab.rutgers.edu wrote: Hello, I am trying to patch UCSBJello files to my (already installed) gnuradio version. I installed the latest version of gnuradio a couple of days ago using the build-gnuradio script. The UCSBJello project page in CGRAN (https://cgran.org/wiki/UCSBJello) tells to download the tarball, patch the files and then run the build gnuradio command. Since, I have gnuradio running in my laptop already, how can I patch the UCSB Jello files to my existing gnuradio version? I can download each file of UCSB Jello one-by-one and see if that works. However, that will take a long time and I wonder if there is any shortcut. I am sorry if this sounds a very novice question. Any feedback will be very appreciated. Thanks, Nazmul Nazmul, I don't think there's really a short-cut. I'm not sure exactly what you mean by downloading each file, but then again, I'm not familiar with that UCSB project. I would just download the project, extract it, then try to build by hand and see where the compiler tells you there are problems. If this was written against another version of GNU Radio, there are probably going to be some API changes between the versions that affect you. Just work through these until the compiler is happy. Tom -- Muhammad Nazmul Islam Graduate Student Electrical Computer Engineering Wireless Information Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resistance? Capacitance? Inductance?
On 27/02/13 05:45 PM, Tom Rondeau wrote: For those interested, this DARPA project was pointed out to me: https://www.fbo.gov/index?s=opportunitymode=formid=7c438631d57659b7b9f932df6d3da484tab=core_cview=1 Here's a brief write-up that summarizes the effort (apologies for the in-your-face ad at the top): http://www.militaryaerospace.com/articles/2012/08/darpa-rf-fpga.html Tom Some of the commercial broadish-band tuner chips already have some of this with switchable 3rd-order filter networks on-chip (or partially on-chip). The E4000, R820T, TDA18272, and others have some of this, targetted at the DVB-T/ATSC markets. -- 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
Re: [Discuss-gnuradio] Importing newly created C++ block
i am stucking to add code in places, i think i am forgetting someone could
you write its steps, thank you.
2013/2/28 Tom Rondeau t...@trondeau.com
Look inside the files that are generated. You have to edit these and
add your own code in places for it to work. It's not magic.
See: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
Tom
On Wed, Feb 27, 2013 at 6:12 PM, Serhat BOYNUKALIN
serhatboynuka...@gmail.com wrote:
bynkln@ubuntu:~$ gr_modtool.py create myQpsk
i was added python code to new created gr-myQpsk python path than
bynkln@ubuntu:~$ cd gr-myQpsk
bynkln@ubuntu:~/gr-myQpsk$ gr_modtool.py add
Operating in directory .
GNU Radio module name identified: myQpsk
Enter code type: hier
Language: C++
Enter name of block/code (without module name prefix): QPSK
Block/code identifier: QPSK
Enter valid argument list, including default arguments: VAL1,VAL2
Add Python QA code? [Y/n] Y
Add C++ QA code? [Y/n] Y
Traversing lib...
Adding file 'QPSK_impl.h'...
Adding file 'QPSK_impl.cc'...
Adding file 'QPSK.h'...
Adding file 'qa_QPSK.cc'...
Adding file 'qa_QPSK.h'...
Traversing swig...
Editing swig/myQpsk_swig.i...
Adding Python QA...
Adding file 'qa_QPSK.py'...
Editing python/CMakeLists.txt...
Traversing grc...
Adding file 'myQpsk_QPSK.xml'...
Editing grc/CMakeLists.txt...
bynkln@ubuntu:~/gr-myQpsk$ mkdir build
bynkln@ubuntu:~/gr-myQpsk$ cd build
bynkln@ubuntu:~/gr-myQpsk/build$ cmake ../
-- The CXX compiler identification is GNU 4.7.2
-- The C compiler identification is GNU 4.7.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.49.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- Found PkgConfig: /usr/bin/pkg-config (found version 0.26)
-- checking for module 'gruel'
-- found gruel, version 3.6.4git
-- Found GRUEL: /usr/local/lib/libgruel.so
-- checking for module 'gnuradio-core'
-- found gnuradio-core, version 3.6.4git
-- Found GNURADIO_CORE: /usr/local/lib/libgnuradio-core.so
-- checking for module 'cppunit'
-- found cppunit, version 1.12.1
-- Found CPPUNIT: /usr/lib/libcppunit.so;dl
-- Found SWIG: /usr/bin/swig2.0 (found version 2.0.7)
-- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found
version 2.7.3)
-- Found PythonInterp: /usr/bin/python (found version 2.7.3)
-- Found Doxygen: /usr/bin/doxygen (found version 1.8.1.2)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bynkln/gr-myQpsk/build
bynkln@ubuntu:~/gr-myQpsk/build$ make
Scanning dependencies of target gnuradio-myQpsk
[ 5%] Building CXX object
lib/CMakeFiles/gnuradio-myQpsk.dir/QPSK_impl.cc.o
In file included from /home/bynkln/gr-myQpsk/lib/QPSK_impl.h:24:0,
from /home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:26:
/home/bynkln/gr-myQpsk/include/myQpsk/QPSK.h:49:25: error: ‘VAL1’ has
not been declared
/home/bynkln/gr-myQpsk/include/myQpsk/QPSK.h:49:30: error: ‘VAL2’ has
not been declared
In file included from /home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:26:0:
/home/bynkln/gr-myQpsk/lib/QPSK_impl.h:35:21: error: expected ‘)’ before
‘,’ token
/home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:32:16: error:
‘gr::myQpsk::QPSK::sptr gr::myQpsk::QPSK::make’ is not a static member
of ‘class gr::myQpsk::QPSK’
/home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:32:16: error: ‘VAL1’ was not
declared in this scope
/home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:32:21: error: ‘VAL2’ was not
declared in this scope
/home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:33:5: error: expected ‘,’ or ‘;’
before ‘{’ token
/home/bynkln/gr-myQpsk/lib/QPSK_impl.cc:40:25: error: expected
constructor, destructor, or type conversion before ‘(’ token
make[2]: *** [lib/CMakeFiles/gnuradio-myQpsk.dir/QPSK_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-myQpsk.dir/all] Error 2
make: *** [all] Error 2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Maximum length of packets using benchmark_tx/rx and packet_utils
Hey all, I'm curious if there is a reason why the maximum length for a digital packet payload is 4096 bits in packet_utils.py Currently this is limited because of the length of the whitening mask, but if whitening is not used...could this be increased? I know the framer_sink limits the length of the total packet to 16 bits, but I'm using far less than this with no success. I've tried disabling whitening and commenting out the packet length restriction of 4096 bits and put a larger packet through and it will transmit fine, but not receive a correct packet. The received packet is truncated as if all 16 bits in the framer_sink d_header_len limit aren't being used. Am I correct in this? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Add ldconfig to build instructions?
Hi, My problems a few days ago, when switching between branches, simply came from a missing sudo ldconfig at the end of the procedure. Maybe it may be useful to add a more obvious hint? In http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide it is not mentioned, and in http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall only in the broken libtool section. Of course, the pro should know it, but for beginners this is a PITA, and the error message regarding the python path is very misleading. I can't validate if this is a (K)Ubuntu problem or a more common cause for trouble... With best regards Ralph. -- Ralph A. Schmid Mondstr. 10 90762 Fürth +49-171-3631223 ra...@schmid.xxx http://www.bclog.de/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP N210 MIMO Syn problem
Hi everyone, I have a question about USRP N210 MIMO syn. Right now I already have set the parameters like following： Device addr: addr0=192.168.10.1,addr1=192.168.10.3 Sync = don't sync Num Mboards = 2 Mb0 Clk Src = Default Mb0 Time Src = Default … Mb1 Clk Src = MIMO Cable Mb1 Time Src = MIMO Cable but I still cannot syn two USRP. Can anyone give me some suggestions? Thanks a lot. Lin -- View this message in context: http://gnuradio.4.n7.nabble.com/USRP-N210-MIMO-Syn-problem-tp39902.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AttributeError: 'Block' object has no attribute 'horizontal_label'
when i run my own block in gnuradio-companion square_ff ,the following error i
get
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/ActionHandler.py,
line 307, in _handle_action
self.get_flow_graph().update()
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 312, in update
self.create_labels()
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Element.py,
line 64, in create_labels
for child in self.get_children(): child.create_labels()
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
134, in create_labels
markups = [param.get_markup() for param in self.get_params() if
param.get_hide() not in ('all',
'part')]
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/python/Param.py,
line 209, in get_hide
lambda p: ' '.join([p._type, p._nports]), self.get_parent().get_ports())
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/python/Param.py,
line 209, in lambda
lambda p: ' '.join([p._type, p._nports]), self.get_parent().get_ports())
TypeError: sequence item 0: expected string, instance found
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in _handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 281, in draw
element.draw(gc, window)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
185, in
draw
window.draw_drawable(gc, self.horizontal_label, 0, 0,
x+BLOCK_LABEL_PADDING, y+(self.H-self.label_height)/2, -1, -1)
AttributeError: 'Block' object has no attribute 'horizontal_label'
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in _handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 281, in draw
element.draw(gc, window)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
185, in draw
window.draw_drawable(gc, self.horizontal_label, 0, 0,
x+BLOCK_LABEL_PADDING, y+(self.H-self.label_height)/2, -1, -1)
AttributeError: 'Block' object has no attribute 'horizontal_label'
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in _handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 281, in draw
element.draw(gc, window)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
185, in draw
window.draw_drawable(gc, self.horizontal_label, 0, 0,
x+BLOCK_LABEL_PADDING, y+(self.H-self.label_height)/2, -1, -1)
AttributeError: 'Block' object has no attribute 'horizontal_label'
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in _handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 281, in
draw
element.draw(gc, window)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
185, in draw
window.draw_drawable(gc, self.horizontal_label, 0, 0,
x+BLOCK_LABEL_PADDING, y+(self.H-self.label_height)/2, -1, -1)
AttributeError: 'Block' object has no attribute 'horizontal_label'
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in _handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 281, in draw
element.draw(gc, window)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
185, in draw
window.draw_drawable(gc, self.horizontal_label, 0, 0, x+BLOCK_LABEL_PADDING,
y+(self.H-self.label_height)/2, -1, -1)
AttributeError: 'Block' object has no attribute 'horizontal_label'
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in _handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/FlowGraph.py,
line 281, in draw
element.draw(gc, window)
File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Block.py, line
185, in draw
window.draw_drawable(gc, self.horizontal_label, 0, 0,
x+BLOCK_LABEL_PADDING, y+(self.H-self.label_height)/2, -1, -1)
AttributeError: 'Block' object has no attribute 'horizontal_label'
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/DrawingArea.py, line
132, in
_handle_window_expose
self._flow_graph.draw(gc, self._pixmap)
File
