Re: [Discuss-gnuradio] Building simple GUIs: Is wxPython still the recommended method?
On Wed, Apr 20, 2011 at 12:38 PM, Joel Koltner zapwire-gro...@yahoo.comwrote: I've been away from GNU Radio for a bit and wanted to ask... is wxPython (and the included wrappers) still the recommended means of building simple GUIs? Or has it been supplanted by, e.g., something Qt or similar? Thanks, ---Joel This isn't a really clear-cut issue right now. I prefer the gr-qtgui (which uses Qt and QWT as well as their Python versions), but qtgui is still missing a few features that would really make it production-ready. I'm working in these things now, though. I find the Qt implementations to have a better look and feel than the Wx stuff, and the concept of signals and slots gives it a lot of power, which I am working on building more into the UI. However, like I said, qtgui is still lacking in some areas and the wxgui interface is a bit more seasoned. It, too, is missing some features, I think. My recommendation is to look at qtgui and see if it does what you want. It's easy to make qtgui apps now in GRC if you are working off the latest from Git. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
On Wed, Apr 20, 2011 at 9:25 AM, David Barton david.barto...@yahoo.comwrote: I am running tunnel.py on gnuradio 3.3.0 . It run successfully for a while but after a period of time (around an hour) the following exception prints out: Rx: ok = True len(payload) = 82 Tx: len(payload) = 82 Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib64/python2.6/threading.py, line 525, in __bootstrap_inner self.run() File /usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pkt.py, line 162, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o)# self inverse File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape After this exception the receive chain seems to stop working. I am still able to transmit but no receive packets are recorded. Anyone have any clue what could be causing this issue? Thanks, Dave I think that the problem is when the receiver thinks it has a zero-length packet (that is, something gets screwed up with the header and it sees 0's there). I'm not positive that this is the real problem, but I'd say it has something to do with a packet getting corrupted in a particular way that's causing this to happen. We would need to put some protections into the unmake_packet to handle this as a dropped packet and then continue, once we find the exact problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building simple GUIs: Is wxPython still the recommended method?
On 21/04/2011 10:15 AM, Tom Rondeau wrote: On Wed, Apr 20, 2011 at 12:38 PM, Joel Koltner zapwire-gro...@yahoo.com mailto:zapwire-gro...@yahoo.com wrote: I've been away from GNU Radio for a bit and wanted to ask... is wxPython (and the included wrappers) still the recommended means of building simple GUIs? Or has it been supplanted by, e.g., something Qt or similar? Thanks, ---Joel This isn't a really clear-cut issue right now. I prefer the gr-qtgui (which uses Qt and QWT as well as their Python versions), but qtgui is still missing a few features that would really make it production-ready. I'm working in these things now, though. I find the Qt implementations to have a better look and feel than the Wx stuff, and the concept of signals and slots gives it a lot of power, which I am working on building more into the UI. My main hope for Qt-GUI is that it will exercise fewer edge cases (or not use at all) in OpenGL. I have an app that still, occasionally, dumpeth the core on *some* platforms due to bugs deep in the bowels of the OpenGL ecosystem. But I agree that gr-qtgui as it currently exists is missing some features that would make it production-ready, including splitting out the individual components of the current qtgui megasink, and strip-chart type features (basically, everything that wxgui currently has). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re ceiving DBPSK side not working.
On Tue, Apr 19, 2011 at 2:35 PM, ish13 ish2...@gmail.com wrote: Ok I had used the muliplier in a previous code using Frequency Modulation which is why I used it again. But thanks for that. I will change it to a smaller value. I also had it set up with the interpolation to 512 and the decimation to 256 but it didn't work either. Though I will set these values to the range it has to fall between. As for the transmitter, I had connected the output of the modulation block to a scope to see if it was transmitting the correct waveform, which it was. Though the problem came when I try to receive. When I tune into the frequency I am transmitting at there is no signal at all, which I am not sure why that is happening. Ismael Just connecting to the scope inside the transmitter isn't likely to tell you too much. You want to see it at the receiver. The fact that you are not seeing it at the receiver helps. What interpolation are you using at the transmitter when looking for the received signal? What gain settings? What frequency? What daughterboards are you using? What version of GNU Radio and GRC? Tom Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:03 PM, ish13 ish2...@gmail.com wrote: I am using DBPSK, but I am not receiving anything when I transmit my signal. I attached the flow-graphs from the companion. Can someone look through it and tell me if it is correct? Thanks Ismael http://old.nabble.com/file/p31434999/Receiver.png Receiver.png http://old.nabble.com/file/p31434999/Transmitter.png Transmitter.png A few issues. First, don't set the multiplier to 32k as you will probably start to over drive the amplifier. I tend to keep this at a max of 15k. More importantly, though, you're interpolation and decimations are set to 4k and 2k, respectively. You cannot use this large of a number. The max (if I recall) are 512 for interp and 256 for decim. It's also helpful to start the transmitter and use the usrp_fft.py program to make sure you are receiving what you think you are receiving. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31435221.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave From: Tom Rondeau trondeau1...@gmail.com To: David Barton david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Thu, April 21, 2011 10:22:39 AM Subject: Re: [Discuss-gnuradio] Tunnel.py exception On Wed, Apr 20, 2011 at 9:25 AM, David Barton david.barto...@yahoo.com wrote: I am running tunnel.py on gnuradio 3.3.0 . It run successfully for a while but after a period of time (around an hour) the following exception prints out: Rx: ok = True len(payload) = 82 Tx: len(payload) = 82 Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib64/python2.6/threading.py, line 525, in __bootstrap_inner self.run() File /usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pkt.py, line 162, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o) # self inverse File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape After this exception the receive chain seems to stop working. I am still able to transmit but no receive packets are recorded. Anyone have any clue what could be causing this issue? Thanks, Dave I think that the problem is when the receiver thinks it has a zero-length packet (that is, something gets screwed up with the header and it sees 0's there). I'm not positive that this is the real problem, but I'd say it has something to do with a packet getting corrupted in a particular way that's causing this to happen. We would need to put some protections into the unmake_packet to handle this as a dropped packet and then continue, once we find the exact problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error handler
On Sat, Apr 16, 2011 at 6:11 PM, Alexandru Csete oz9...@gmail.com wrote: Greetings, I can see there is an error handler class in gnuradio-core / runtime / gr_error_handler and I was wondering if there is an instance of it created by the runtime that can be used by the blocks and maybe the applications? So far I have only found fprintf's for error messages though I haven't looked everywhere. Alex Alex, We don't really use the gr_error_handler at all. All errors and warnings are done through either frpintf to stderr or throwing and catching exceptions. If you have some ideas of how to make error handling better, I'd love to hear and discuss them. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
I've recently been using tunnel.py for 1/2 hr tests with no problems. I'm using the basic_tx/rx boards with a low frequency (5 MHz) and 1 Mbit datarate. On Thu, Apr 21, 2011 at 10:31 AM, David Barton david.barto...@yahoo.comwrote: I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave -- *From:* Tom Rondeau trondeau1...@gmail.com *To:* David Barton david.barto...@yahoo.com *Cc:* discuss-gnuradio@gnu.org *Sent:* Thu, April 21, 2011 10:22:39 AM *Subject:* Re: [Discuss-gnuradio] Tunnel.py exception On Wed, Apr 20, 2011 at 9:25 AM, David Barton david.barto...@yahoo.comwrote: I am running tunnel.py on gnuradio 3.3.0 . It run successfully for a while but after a period of time (around an hour) the following exception prints out: Rx: ok = True len(payload) = 82 Tx: len(payload) = 82 Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib64/python2.6/threading.py, line 525, in __bootstrap_inner self.run() File /usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pkt.py, line 162, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o)# self inverse File /usr/local/lib64/python2.6/site-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape After this exception the receive chain seems to stop working. I am still able to transmit but no receive packets are recorded. Anyone have any clue what could be causing this issue? Thanks, Dave I think that the problem is when the receiver thinks it has a zero-length packet (that is, something gets screwed up with the header and it sees 0's there). I'm not positive that this is the real problem, but I'd say it has something to do with a packet getting corrupted in a particular way that's causing this to happen. We would need to put some protections into the unmake_packet to handle this as a dropped packet and then continue, once we find the exact problem. Tom ___ 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] Bricking and recovery of N210
Hi folks, Firstly, thanks very much for your response Nick - you've answered my main question on how to recover a completely bricked N210 in future. There are two reasons why I'm hesitant to blame UHD: I ran the update while I was (accidentally but foolishly!) streaming data from the USRP, albeit at its minimum rate; and we have modified the UHD host, FPGA and ZPU firmware. I'm pretty sure the fault was at least partially due to network congestion from the streaming, or the USRP being unable to do two things at once, so I'm hesitant to blame any part of the 'vanilla' UHD. I also can't rule out a problem with our firmware/bitstream, though updates have been 100% successful since. With this in mind, the details are: OS: Windows XP SP2 32-bit UHD: modified version, compiled in WinXP/MSVC 10 from source obtained through git on 22 Feb 2011. FPGA/Firmware: as above; firmware compiled in Ubuntu 10.10, FPGA bitstream compiled in Xilinx ISE 12.4 Windows and Linux. The same host files and firmware have worked fine before and since. I have tested our host modifications in Linux with both standalone UHD and Gnuradio, and Windows with standalone UHD and LabVIEW (using a custom C interface to the UHD library). Ethernet card: not available now, I can obtain info if necessary Network environment: when the problem occurred the N210 was directly connected to the host PC. Since recovery the N210 is on a gigabit LAN with no problems. Circumstances of error: Our N210 has the LFRX and LFTX. I had been streaming at the minimum rate (~200 ksps) when I ran: 'python usrp_n2xx_net_burner.py --fw=firmware_location --fpga=bitstream_location' . No other options were enabled. The program hung during writing of the FPGA image, and I realised that streaming was still on and meaningful data was still being received. I forcibly closed the streaming program, left the burner alone for several minutes then ctrl-c'ed out. There were several traceback messages which I unfortunately did not record. I immediately reran the same command, and it appeared to succeed. I rebooted and no lights at all came on except the yellow Ethernet light, which took a few seconds to switch on - I tried safe mode as well, with the same result. I connected a Xilinx platform cable and read the FPGA status bits from within iMPACT; I did not record them but I recall that all the programming-related indicator bits were off, as though the FPGA was not being programmed at all upon power-up. The CRC error indicator bits were also off. I then programmed the FPGA with a .bit file, as you described, at which point it booted successfully - all the programming indicator bits had also switched on. I reran usrp_n2xx_net_burner as above, however the problem was still present after rebooting. I tried this several times with different combinations of FPGA/firmware images, including the most recent vanilla UHD - none worked. I then ran usrp_n2xx_net_burner again with the --overwrite-safe flag and my own images; after rebooting all was well. I do not understand why the FPGA did not seem to be programmed by the flash until the safe image was re-burnt; I have not studied the N210 schematics or the FPGA/flash chip datasheets so I don't understand how the FPGA boots in detail. I'm still debugging our firmware/bitstream, so I've been flashing the N210 regularly --- I'm careful to avoid simultaneous streaming and network congestion, and the problem has not recurred. I'm a bit afraid to recreate the problem, but if it occurs again I'll try to establish exactly what combination of factors causes it. For the time being, however, I'll chalk it up to the simultaneous streaming and ctrl-c'ing (and cosmic rays of course!). Thank you again for the detailed recovery guide. Since we have the host, firmware and FPGA toolchains running, I have access to .bit and .ihx files for our design. Also, I noticed that iMPACT offered to write the flash by writing a temporary bitstream to the FPGA to facilitate JTAG-flash communication, however it seemed to need a lot of configuration settings. Out of curiosity, is this feasible? ( It would be useful to rewrite the flash in one go from iMPACT - not that I dislike RS232 or anything :) ) Best regards, sorry about the wall of text. Hope the detail helps. Vlad -- Forwarded message -- From: Nick Foster n...@ettus.com Date: 20 April 2011 10:29 Subject: Re: [Discuss-gnuradio] Bricking and recovery of N210 To: Vladimir Negnevitsky vneg...@gmail.com Cc: discuss-gnuradio@gnu.org On Wed, 2011-04-20 at 10:13 +1000, Vladimir Negnevitsky wrote: Hi folks, We've recently received an N210. I updated the firmware successfully a few times, but then usrp_n2xx_net_burner.py crashed. I immediately tried rewriting the image, and all seemed to go fine, however both default and backup booting (holding S2 during powerup) failed. I directly programmed the FPGA over JTAG using iMPACT and a Xilinx platform cable, and the firmware loaded correctly. At this
[Discuss-gnuradio] GRC questions
Josh, Two issues in GNU Radio companion. I'm working on a hier_block in GRC and want it to have multiple outputs. When I generate the block, though, I get a few problems. First, only one output pad is exposed. Looking at the generated XML file, I see that only one source block is being created (I have four pad sinks). When I look at the Python file, the io signature for the output is correct, but any calls to the output are all (self,0), so there seems to be no distinction of what pad sink is being used. When I hand-edited the files to what they should be, the block works fine in GRC. Is this a bug or am I doing something wrong? Also, when I double-click on a QtGui sink, I get this message in my console: Traceback (most recent call last): File /usr/local/lib/python2.6/dist-packages/gnuradio/grc/gui/Param.py, line 56, in _update_gui Utils.parse_template(TIP_MARKUP_TMPL, param=self.param).strip(), File /usr/local/lib/python2.6/dist-packages/gnuradio/grc/gui/Utils.py, line 89, in parse_template return str(Template(tmpl_str, kwargs)) File /usr/lib/pymodules/python2.6/Cheetah/Template.py, line 981, in __str__ def __str__(self): return getattr(self, mainMethName)() File cheetah_DynamicallyCompiledCheetahTemplate_1303402270_04_59718.py, line 131, in respond File cheetah_DynamicallyCompiledCheetahTemplate_1303402270_04_59718.py, line 88, in truncate TypeError: lambda() takes exactly 1 argument (0 given) Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
On 04/21/2011 09:19 AM, Tom Rondeau wrote: Josh, Two issues in GNU Radio companion. I'm working on a hier_block in GRC and want it to have multiple outputs. When I generate the block, though, I get a few problems. First, only one output pad is exposed. Looking at the generated XML file, I see that only one source block is being created (I have four pad sinks). When I look at the Python file, the io signature for the output is correct, but any calls to the output are all (self,0), so there seems to be no distinction of what pad sink is being used. When I hand-edited the files to what they should be, the block works fine in GRC. Is this a bug or am I doing something wrong? Thats a long-standing bug thats been around since the vector of io_signatures was added. I guess I will fix it this time before I get too distracted. Also, when I double-click on a QtGui sink, I get this message in my console: Traceback (most recent call last): File /usr/local/lib/python2.6/dist-packages/gnuradio/grc/gui/Param.py, line 56, in _update_gui Utils.parse_template(TIP_MARKUP_TMPL, param=self.param).strip(), File /usr/local/lib/python2.6/dist-packages/gnuradio/grc/gui/Utils.py, line 89, in parse_template return str(Template(tmpl_str, kwargs)) File /usr/lib/pymodules/python2.6/Cheetah/Template.py, line 981, in __str__ def __str__(self): return getattr(self, mainMethName)() File cheetah_DynamicallyCompiledCheetahTemplate_1303402270_04_59718.py, line 131, in respond File cheetah_DynamicallyCompiledCheetahTemplate_1303402270_04_59718.py, line 88, in truncate TypeError: lambda() takes exactly 1 argument (0 given) I have seen that too. Its been innocuous enough to ignore, so i have never looked into the cause. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
On Thu, Apr 21, 2011 at 12:50 PM, Josh Blum j...@joshknows.com wrote: On 04/21/2011 09:19 AM, Tom Rondeau wrote: Josh, Two issues in GNU Radio companion. I'm working on a hier_block in GRC and want it to have multiple outputs. When I generate the block, though, I get a few problems. First, only one output pad is exposed. Looking at the generated XML file, I see that only one source block is being created (I have four pad sinks). When I look at the Python file, the io signature for the output is correct, but any calls to the output are all (self,0), so there seems to be no distinction of what pad sink is being used. When I hand-edited the files to what they should be, the block works fine in GRC. Is this a bug or am I doing something wrong? Thats a long-standing bug thats been around since the vector of io_signatures was added. I guess I will fix it this time before I get too distracted. Great, thanks! Also, when I double-click on a QtGui sink, I get this message in my console: Traceback (most recent call last): File /usr/local/lib/python2.6/dist-packages/gnuradio/grc/gui/Param.py, line 56, in _update_gui Utils.parse_template(TIP_MARKUP_TMPL, param=self.param).strip(), File /usr/local/lib/python2.6/dist-packages/gnuradio/grc/gui/Utils.py, line 89, in parse_template return str(Template(tmpl_str, kwargs)) File /usr/lib/pymodules/python2.6/Cheetah/Template.py, line 981, in __str__ def __str__(self): return getattr(self, mainMethName)() File cheetah_DynamicallyCompiledCheetahTemplate_1303402270_04_59718.py, line 131, in respond File cheetah_DynamicallyCompiledCheetahTemplate_1303402270_04_59718.py, line 88, in truncate TypeError: lambda() takes exactly 1 argument (0 given) I have seen that too. Its been innocuous enough to ignore, so i have never looked into the cause. -Josh Yeah, it doesn't do anything, I just wanted to report it. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Agile Solutions is Pleased to announce USRPSTAR. Yet another addition to GNURADIO
On Wed, 20 Apr 2011 17:12:34 -0500 (CDT), Jeff Brower jbro...@signalogic.com wrote: On 04/19/2011 01:10 PM, i...@agile-sdr-solutions.com wrote: Dear Matt, We honestly went through every material in search on Google but we couldn't locate a single article published successful testing for STBC/SFBC. For whatever reason, we would like to know, if you can confirm on this with your lab setup ? We have done considerable experimental work on this. And we are certain with the results we have have found. We would encourage this exploration in best interest of all from your end. Thank you. Dear Mr. Solutions, Mr. Solutions = Akash Kosgi, Lakshmamma Layout, Banaswadi, Bangalore, 560043, India. -Jeff All USRP systems can do STBC, SFBC, spatial multiplexing, etc. I've said it multiple times and pointed you to multiple sources. Steve Peters told you he and the Hydra team at UT have done it. I have seen it done. I have done it myself. Our customers have been doing it for 6 years now. The WARP boards from Rice do it in the exact same way. Millions of WiFi systems do it the same way. Page 4, section 4 of the following paper says the same thing: http://newport.eecs.uci.edu/~hyousefi/publ/lamacGC09.pdf Our experiments rely on a MANET testbed in which each test node consists of a host PC and a USRP motherboard hosting a pair of frontend RF daughter boards. Since each daughter board is attached to a single antenna, each MANET node is equipped with a pair of antennas. When transmitting, each MANET node utilizes Space-Time Block Coding (STBC) method of [23]. I don't know what more I could possibly say. No matter how many times you ask the question, the answer will always be the same. Just because *you* couldn't get it to work doesn't mean it's impossible. Matt Ettus Dear Mr. Research, This sounds odd if you meant it to be 2x2 Alamouti scheme. When transmitting, each MANET node utilizes Space-Time Block Coding (STBC) method of [23]. When receiving, it utilizes Maximum Ratio Combining (MRC). STBC and MRC are two different methods. If such an article is published, then it is to reviewed to its contents with right experts. A simple signal processing math would be sufficient to understand Space/Time/Frequency diversities. Akash Kosgi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
Thats a long-standing bug thats been around since the vector of io_signatures was added. I guess I will fix it this time before I get too distracted. Try my fix on jblum.git fix/grc/multi_pad: http://gnuradio.org/cgit/jblum.git/commit/?id=a4ac44d7adbd9c6cdd107ec7985e294fea81845a -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re ceiving DBPSK side not working.
Am going to work on it today and see if I get any results from the previous replys. Below the setting that are currently being used but I am changing the interpolation and decimation rates. 4k. Gain=20. Freq= 100.1MHz Board is tvrx Version 3.3 gnuradio and 0.7 grc Ismael Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:35 PM, ish13 ish2...@gmail.com wrote: Ok I had used the muliplier in a previous code using Frequency Modulation which is why I used it again. But thanks for that. I will change it to a smaller value. I also had it set up with the interpolation to 512 and the decimation to 256 but it didn't work either. Though I will set these values to the range it has to fall between. As for the transmitter, I had connected the output of the modulation block to a scope to see if it was transmitting the correct waveform, which it was. Though the problem came when I try to receive. When I tune into the frequency I am transmitting at there is no signal at all, which I am not sure why that is happening. Ismael Just connecting to the scope inside the transmitter isn't likely to tell you too much. You want to see it at the receiver. The fact that you are not seeing it at the receiver helps. What interpolation are you using at the transmitter when looking for the received signal? What gain settings? What frequency? What daughterboards are you using? What version of GNU Radio and GRC? Tom Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:03 PM, ish13 ish2...@gmail.com wrote: I am using DBPSK, but I am not receiving anything when I transmit my signal. I attached the flow-graphs from the companion. Can someone look through it and tell me if it is correct? Thanks Ismael http://old.nabble.com/file/p31434999/Receiver.png Receiver.png http://old.nabble.com/file/p31434999/Transmitter.png Transmitter.png A few issues. First, don't set the multiplier to 32k as you will probably start to over drive the amplifier. I tend to keep this at a max of 15k. More importantly, though, you're interpolation and decimations are set to 4k and 2k, respectively. You cannot use this large of a number. The max (if I recall) are 512 for interp and 256 for decim. It's also helpful to start the transmitter and use the usrp_fft.py program to make sure you are receiving what you think you are receiving. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31435221.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31451604.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] Re ceiving DBPSK side not working.
On Thu, Apr 21, 2011 at 2:14 PM, ish13 ish2...@gmail.com wrote: Am going to work on it today and see if I get any results from the previous replys. Below the setting that are currently being used but I am changing the interpolation and decimation rates. 4k. Gain=20. Freq= 100.1MHz Board is tvrx Version 3.3 gnuradio and 0.7 grc Ismael You are trying to transmit using a TVRX? That's a receive-only board. That's also a really old version of GRC. Tom Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:35 PM, ish13 ish2...@gmail.com wrote: Ok I had used the muliplier in a previous code using Frequency Modulation which is why I used it again. But thanks for that. I will change it to a smaller value. I also had it set up with the interpolation to 512 and the decimation to 256 but it didn't work either. Though I will set these values to the range it has to fall between. As for the transmitter, I had connected the output of the modulation block to a scope to see if it was transmitting the correct waveform, which it was. Though the problem came when I try to receive. When I tune into the frequency I am transmitting at there is no signal at all, which I am not sure why that is happening. Ismael Just connecting to the scope inside the transmitter isn't likely to tell you too much. You want to see it at the receiver. The fact that you are not seeing it at the receiver helps. What interpolation are you using at the transmitter when looking for the received signal? What gain settings? What frequency? What daughterboards are you using? What version of GNU Radio and GRC? Tom Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:03 PM, ish13 ish2...@gmail.com wrote: I am using DBPSK, but I am not receiving anything when I transmit my signal. I attached the flow-graphs from the companion. Can someone look through it and tell me if it is correct? Thanks Ismael http://old.nabble.com/file/p31434999/Receiver.png Receiver.png http://old.nabble.com/file/p31434999/Transmitter.png Transmitter.png A few issues. First, don't set the multiplier to 32k as you will probably start to over drive the amplifier. I tend to keep this at a max of 15k. More importantly, though, you're interpolation and decimations are set to 4k and 2k, respectively. You cannot use this large of a number. The max (if I recall) are 512 for interp and 256 for decim. It's also helpful to start the transmitter and use the usrp_fft.py program to make sure you are receiving what you think you are receiving. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31435221.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31451604.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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re ceiving DBPSK side not working.
No I am using TVRX to receive and basic TX to transmit. I have changed the following values, Receive. Decimation=256 gain = 20 Transmitter. Interpolation= 512 Multiply Const=5000 I am now receiving my audio file and saving the data into another file. Though the data is not the just the file data because the play back of the song it has a lot of noise. But sorry I have version 3.3. Ismael Tom Rondeau wrote: On Thu, Apr 21, 2011 at 2:14 PM, ish13 ish2...@gmail.com wrote: Am going to work on it today and see if I get any results from the previous replys. Below the setting that are currently being used but I am changing the interpolation and decimation rates. 4k. Gain=20. Freq= 100.1MHz Board is tvrx Version 3.3 gnuradio and 0.7 grc Ismael You are trying to transmit using a TVRX? That's a receive-only board. That's also a really old version of GRC. Tom Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:35 PM, ish13 ish2...@gmail.com wrote: Ok I had used the muliplier in a previous code using Frequency Modulation which is why I used it again. But thanks for that. I will change it to a smaller value. I also had it set up with the interpolation to 512 and the decimation to 256 but it didn't work either. Though I will set these values to the range it has to fall between. As for the transmitter, I had connected the output of the modulation block to a scope to see if it was transmitting the correct waveform, which it was. Though the problem came when I try to receive. When I tune into the frequency I am transmitting at there is no signal at all, which I am not sure why that is happening. Ismael Just connecting to the scope inside the transmitter isn't likely to tell you too much. You want to see it at the receiver. The fact that you are not seeing it at the receiver helps. What interpolation are you using at the transmitter when looking for the received signal? What gain settings? What frequency? What daughterboards are you using? What version of GNU Radio and GRC? Tom Tom Rondeau wrote: On Tue, Apr 19, 2011 at 2:03 PM, ish13 ish2...@gmail.com wrote: I am using DBPSK, but I am not receiving anything when I transmit my signal. I attached the flow-graphs from the companion. Can someone look through it and tell me if it is correct? Thanks Ismael http://old.nabble.com/file/p31434999/Receiver.png Receiver.png http://old.nabble.com/file/p31434999/Transmitter.png Transmitter.png A few issues. First, don't set the multiplier to 32k as you will probably start to over drive the amplifier. I tend to keep this at a max of 15k. More importantly, though, you're interpolation and decimations are set to 4k and 2k, respectively. You cannot use this large of a number. The max (if I recall) are 512 for interp and 256 for decim. It's also helpful to start the transmitter and use the usrp_fft.py program to make sure you are receiving what you think you are receiving. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31435221.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31451604.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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Receiving-DBPSK-side-not-working.-tp31434999p31452250.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] GRC questions
On Thu, Apr 21, 2011 at 2:04 PM, Josh Blum j...@joshknows.com wrote: Thats a long-standing bug thats been around since the vector of io_signatures was added. I guess I will fix it this time before I get too distracted. Try my fix on jblum.git fix/grc/multi_pad: http://gnuradio.org/cgit/jblum.git/commit/?id=a4ac44d7adbd9c6cdd107ec7985e294fea81845a -Josh That did the trick all right! Thanks for the quick turnaround! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
On 21/04/2011 4:10 PM, Tom Rondeau wrote: That did the trick all right! Thanks for the quick turnaround! You know, I've previously observed that the object we know as Josh Blum is far too productive to be a single person :-) Although I have met Josh in meat space, and he appeared to consist of a single instance of homo sapiens. But that could be a trick. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
Dave, To bypass this problem, change the pkt.py file. In the end, after msg = self.rcvd_pktq.delete_head() add if (string_len 18) (string_len 4096) : ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) Andrew On 04/21/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Thu, 21 Apr 2011 07:31:33 -0700 (PDT) From: David Bartondavid.barto...@yahoo.com To: Tom Rondeautrondeau1...@gmail.com Cc:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Tunnel.py exception Message-ID:72896.27694...@web120212.mail.ne1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration?lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
On Thu, Apr 21, 2011 at 4:19 PM, Marcus D. Leech mle...@ripnet.com wrote: On 21/04/2011 4:10 PM, Tom Rondeau wrote: That did the trick all right! Thanks for the quick turnaround! You know, I've previously observed that the object we know as Josh Blum is far too productive to be a single person :-) Although I have met Josh in meat space, and he appeared to consist of a single instance of homo sapiens. But that could be a trick. The other bodies were probably charging at the time. They have a large Nissan Leaf solar charging station they converted just for this purpose. We're working on getting the first duplicate of Nick into production soon, too. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
On 21/04/2011 4:29 PM, Tom Rondeau wrote: The other bodies were probably charging at the time. They have a large Nissan Leaf solar charging station they converted just for this purpose. Ah, it's all clear to me now. [You see, something's going to happen. Something wonderful, David Bowman, 2010]. We're working on getting the first duplicate of Nick into production soon, too. Jason once expressed the desire to clone me, and ship my clone off to California so I could be the on-site tech-support guy :-) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunnel.py exception
On Thu, Apr 21, 2011 at 4:26 PM, Feng Andrew Ge gefengflo...@gmail.comwrote: Dave, To bypass this problem, change the pkt.py file. In the end, after msg = self.rcvd_pktq.delete_head() add if (string_len 18) (string_len 4096) : ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) Andrew Thanks, Andrew, that looks about right. I'll keep that in mind to apply a patch soon. Tom On 04/21/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Thu, 21 Apr 2011 07:31:33 -0700 (PDT) From: David Bartondavid.barto...@yahoo.com To: Tom Rondeautrondeau1...@gmail.com Cc:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Tunnel.py exception Message-ID:72896.27694...@web120212.mail.ne1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 I am working with two USRPS wired connection with 25 dB attenuator between them so I didnt expect to much corruption of the packets. The error seems to occur quicker at lower bit rates for some reason , like around after 10s of minutes for below 250 kbps and more like after an hour or more for 1 Mbps. Unfortunatly this makes it unusable for longer duration?lower bandwidth tests until I find a way to fix the problem. Has anyone else had this problem with tunnel.py? Thanks, Dave ___ 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] GRC questions
Is Josh Blum like Nicolas Bourbaki? If so we need to start a Wikipedia page for that committee as well. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC questions
Is Josh Blum like Nicolas Bourbaki? If so we need to start a Wikipedia page for that committee as well. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] anyone know sine wave or square wave external clock is better for usrp
Hi all. I need to use external clock on usrp, there are two kinds of clock: sine wave and square wave. which is better for usrp? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Please give me some advice for purchasing the USRP series!
Hello~ I am trying to implement a relay system. The relay system that I am trying includes 2 TX and 1 RX. And 2 TX must transmit a signal synchronously. Now, I have only one USRP2. So I am planning to purchase one of the USRP series. My original plan was buying one USRP2. But I saw the message “The USRP2 has reached End Of Life (EOL) and is NO LONGER AVAILABLE” at Ettus Research site. So, I am considering as the below. 1) Buy one USRP N200 because of this comment of Ettus “Please consider the USRP N200 series instead of USPR2.” And connect the USRP2 and USRP N200 with MIMO cable to implement the relay system 2) Buy one USRP. Then, use the USRP for 2 TX and the USRP2 for 1 RX. Which of the USRP series is appropriate to the relay system? I want to implement the system as soon as possible. I am looking forward to hearing some advice from you soon. Thanks. - Bomi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named myblock when generating py file in GRC
Hi, I try to add all it needs to put my custom block into this module. I add the corresponding .xml/.cc/.h/.i files into grc/lib/swig folder separately and modify MakeFile.am files in each folders. However, it still cannot work. When generating top_block.py in GRC, the console says: self.myblock_amplifier_ff_0 = myblock.amplifier_ff(1) AttributeError: 'module' object has no attribute 'amplifier_ff' My block is a simple amplifier with a parameter Gain. My module is myblock generated with the out-of-tree-project command. I tried the square_ff block before and it works well in GRC. What does this error exactly mean? Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named myblock when generating py file in GRC
On Thu, Apr 21, 2011 at 10:29 PM, Yulong Yang yyl@gmail.com wrote: Hi, I try to add all it needs to put my custom block into this module. I add the corresponding .xml/.cc/.h/.i files into grc/lib/swig folder separately and modify MakeFile.am files in each folders. However, it still cannot work. When generating top_block.py in GRC, the console says: self.myblock_amplifier_ff_0 = myblock.amplifier_ff(1) AttributeError: 'module' object has no attribute 'amplifier_ff' My block is a simple amplifier with a parameter Gain. My module is myblock generated with the out-of-tree-project command. I tried the square_ff block before and it works well in GRC. What does this error exactly mean? Thank you. It's very likely that you have missed something in the Makefile somewhere. There are a lot of steps here, and since you can import myblock, you've gotten that far. It's just missing the actual block inside of the module. Make sure you really have added everything you need to in the Makefiles in grc, lib, and swig directories and that all of the .i files are accounted for. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help : Is this right that the daughterboard passes data to the usrp board in the I and Q format.
Hi guys , I am using DBSRX , now i am trying to trace the data flow in the usr-gnuradio . I see AD9862 ADC in the usrp and some of the block diagrams , and i think that the daughterboard passes the analog signals to the ADC in the I and Q format . Please guide me if this is right or wrong ... Thanks . -- Phenomenon # Life is the most precious phenomenon ever happen ... # Lets pray and give emotional strength to the innocent brave victims of japan. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
