[Discuss-gnuradio] weekend coding adventure: message passing, new blocks, and integrating grblock
All the work is on my next branch, see here: http://gnuradio.org/cgit/jblum.git/log/?h=next ## # Write gnuradio blocks in python ## This work, formally known as grblock was on my github. The project has now been integrated into gnuradio-core on my next branch. So basically, all of the facilities of a gr_block are now available in python. Overload work, scheduler integration, stream tags, and also the message passing I will mention below. See this wiki page for relevant docs and examples. http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython ## # Useful message passing ## I have create a message passing framework that fits in with the existing gnuradio. Basically, each block can accept messages, and can post messages to other blocks. The coordination of who can post messages to who is handled by the the msg_connect() call which is the message equivalent of the connect() call used on streams. Messages can be used to pass arbitrary serialized data between two blocks. The unit of message passing is the same as the stream tags, which is the pmt library. See gruel/pmt.h for basic usage. I have also extended the pmt blob type (memory container type) to manage memory. This allows blocks to pass messages with bulk data; effectively allowing for a mac/packet layer inside of gnuradio. ## # New blocks - gr_blob_to_stream/gr_stream_to_blob ## These blocks provide a cross over between the streaming domain in gnuradio and a kind of packet-based stream of message blobs. This is useful for testing the various blocks mentioned below: ## # New blocks - gr_blob_to_socket/gr_socket_to_blob ## These blocks read and write sockets (TCP or UDP) and output/input a stream of message blobs. This has a few advantages of the current UDP source/sink: - respects packet boundaries, each blob corresponds to a packet. Consider integration with gstreamer or VLC's udp socket streamers - implements TCP as well, which can offer backpressure when communicating between flowgraphs ## # New blocks - digital packet framer/deframer ## Basically that horrid packet framer in tunnel.py. I took the same packet utils, its the same code, but the important distinction: - the packet framer input messages - the packet deframer outputs messages The blocks are in grc if anyone cares to play. ## # New blocks - tuntap ## A tuntap interface with message input and message output, also available in grc. This is the thing that implements the tunnel in tunnel.py Sorry, linux only, unless someone wants to take a whack it for mac os, or windows (however you do that). ## # Conclusions ## The message passing and making blocks in python work supersedes the need for the old style message queues as the gateway between c++ and python. Someone could make the equivalent of tunnel.py in GRC using the new packet framer/deframer and tuntap block. The implementation would be clearer and smarter. Feedback and testing is welcome! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Chirp Sounder
Hi, I released my beacon satellite receiver a while ago. Now I'm releasing my ionosonde receiver. It can be used to perform oblique and vertical ionospheric soundings with ionosonde (and over the horizon radar) transmitters all around the world. The GNU Chirp Sounder is a software defined radio based receiver for monitoring ionospheric sounders. The software is based on gnuradio and relies on Ettus research USRP2 and USRP N210 based digital receivers. The receiver can be used to receive the whole HF band (typically at 25 MHz bandwidth) simultaneously, and to receive multiple sounders simultaneously. The current receiver can be used to perform single or dual polarization (channel) soundings. The dual channel recorded can be used to determine the polarization form vertical soundings, or for angle of arrival measurements for horizontal soundings. http://www.sgo.fi/~j/gnu_chirp_sounder juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft.py returns Segmentation fault
Hello Josh, thanks for your answer. I have run the programm once again using gdb and the output is: -- Starting program: /usr/bin/python uhd_fft.py -a type=usrp2 -f 935M -s 2M [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae [New Thread 0xb2295b70 (LWP 32150)] [New Thread 0xb1a94b70 (LWP 32151)] -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master Program received signal SIGSEGV, Segmentation fault. 0xb6fdf26f in boost::thread::start_thread() () from /usr/lib/libboost_thread.so.1.46.1 I just used the version that was online Thursday last week. I think this one is up to date... (?) Sebastian On Fri, 28 Oct 2011 07:41:17 -0700 Josh Blum wrote: On 10/28/2011 04:03 AM, doering@googlemail.com wrote: Hello list, I tried to launch the "uhd_fft.py" script with the following command line: "uhd_fft.py -a type=usrp2 -f 935M -s 2M" My problem is that my terminal always returns this output: linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.001.000-a7927ae -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master Segmentation fault Does uhd_usrp_probe work? If so, is there a particular line in uhd_fft.py that causes the seg fault? Have you debugged w/ gdb? In any case, I recommend upgrading to the latest release, then see if there is still a problem. -Josh I am using Linux Ubuntu 11.10, 32bit, Intel® Core™2 Duo CPU P8600 @ 2.40GHz × 2, USRP N210 with WBX. I also use ClockTamer as reference for the internal XO and 2 normal GSM 900 antennas. I would really appreciate if someone has an idea on what I am doing wrong here. Thanks in advance! Sebastian ___ 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] proper antenna for RFX900
Hi, Perhaps a Yagi then? It is very easy to build and inexpensive. I used 3 mm Al tig welding rods for elements and a PVC electrical tube as boom. My 900 MHz Yagi photos, wire list and EZNEC design can be found at http://www.poes-weather.com/~patrik/Yagi-900MHz/ Here is a yagi calculator http://www.vk5dj.com/yagi.html Patrik - Original Message - From: davood ahmady To: Patrik Tast Sent: Monday, October 31, 2011 13:02 Subject: Re: [Discuss-gnuradio] proper antenna for RFX900 On Sun, Oct 30, 2011 at 2:37 PM, Patrik Tast wrote: It helps us alot if you specify what you are about to RX/TX. Q's: -frequency -signal is linear (vertical or horizontal) or circular (right or left) Patrik hello Patrik thanks for reply. I am new in this subject. I am planning to work on 900-1200MHz frequency range. the polarization of the antenna is vertical Ahmad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QPSK with direct-sequence spread spectrum
Hi all, I'm wondering if spreading a bitstream (XOR-ing each bit with SPREAD_FACTOR bits of sequence) before QPSK modulation is equivalent to operating on the modulated stream, i.e., multiplying the complex output with -1's and 1's from the sequence. So far I can't get the math to work out. Any suggestions? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX2
Roger, Thanks Patrik - Original Message - From: "Josh Blum" To: Sent: Monday, October 31, 2011 6:07 Subject: Re: [Discuss-gnuradio] TVRX2 On 10/30/2011 03:50 PM, Patrik Tast wrote: Does a TVRX2 work on a no UHD USRP1? Nope, sorry. Its UHD only. The driver was only written *once* this time. :-) -Josh Patrik ___ 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] ld search path on mac os x
Hi list, I'm trying to build gnu radio from source on a MacOSX 10.6, using MacPorts. I tried both with the git master tree and the 3.4.2 tarball, and both fail at the same point: linking fails in volk/lib with "library not found for -lboost_unit_test_framework-mt". The library files (libboost_unit_test_framework-mt.a and libboost_unit_test_framework-mt.dylib) are installed in /opt/local/lib, along with all the other boost libraries. Compiling and linking works fine in other directories of the source tree. I don't know autotools well enough to identify the source of the problem. Any hints? Thanks! Dimitrios Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can not login USRP E100
Hi list, I used USRP E100 for several months and it has been working well. But today when I was using it and want to open another terminal to login it with SSH, I failed and got the message that "Permission denied, please try again". I closed the terminal and tried to login it again with USB,then I could not login it any more and got the hint that "login incorrect". I can login another E100 box with SSH. So I guess maybe there are something wrong with the file system of the bad box but I don't know exactly what the matter and how to fix it. Do I have to reinstall it? Any suggestion is appreciated. BR, Zhonghua ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can not login USRP E100
On 10/31/2011 12:50 PM, Zhonghua wrote: > Hi list, > > I used USRP E100 for several months and it has been working well. But > today when I was using it and want to open another terminal to login it > with SSH, I failed and got the message that "Permission denied, please > try again". I closed the terminal and tried to login it again with > USB,then I could not login it any more and got the hint that "login > incorrect". I can login another E100 box with SSH. So I guess maybe > there are something wrong with the file system of the bad box but I > don't know exactly what the matter and how to fix it. Do I have to > reinstall it? Any suggestion is appreciated. By usb, you mean the usb console? You can put the sd card in an sd card reader attached to another linux computer and edit the file /etc/passwd to remove the password. That should let you login in again. It might be in the shadow password file also. Yes, it looks like the actual password is in /etc/shadow. Edit this file to remove the password hash. Also, this question is better suited to the usrp-users list, so I copied that list also. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can not login USRP E100
On 10/31/2011 01:36 PM, Philip Balister wrote: By usb, you mean the usb console? You can put the sd card in an sd card reader attached to another linux computer and edit the file /etc/passwd to remove the password. That should let you login in again. It might be in the shadow password file also. Yes, it looks like the actual password is in /etc/shadow. Edit this file to remove the password hash. Also, this question is better suited to the usrp-users list, so I copied that list also. Philip If the filesystem is trashed, mounting it on another machine may not help. If it's a password issue, then how did the password get changed? Someone else logged into it? Some malware logged into it? These are questions the security-geek-instance of myself would be asking. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] grc/gnuradio-companion architecture
gnuradio-companion is a really cool piece of software. I'd like to emulate the style in which blocks are connected together. It is rather intricately tied to gnuradio. Does a design document exist that shows the philosophy of the internal layout, ie how blocks are connected etc? Chris -- Chris Lirakis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc/gnuradio-companion architecture
On 10/31/2011 01:45 PM, Chris Lirakis wrote: gnuradio-companion is a really cool piece of software. I'd like to emulate the style in which blocks are connected together. It is rather intricately tied to gnuradio. Does a design document exist that shows the philosophy of the internal layout, ie how blocks are connected etc? Chris -- Chris Lirakis I don't think there's an architecture document. But GRC "knows" remarkably little about Gnu Radio, per se. Most of that knowledge is encapsulated in the various .XML files that describe blocks semantics, and in particular, the code that needs to be emitted when one of those blocks is instantiated. So, conceivably, you could use GRC to layout "blocks" for an entirely different reason/subsystem--might require *bit* of tweaking, but probably not a complete overhaul. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK with direct-sequence spread spectrum
In general you're right, but it depends on the details. Its usually quite straightforward, but a common mistake is to use the wrong bit-to-symbol mapping. 0 -> +1 and 1 -> -1 means that an XOR applied to bits is equivalent to multiplication applied to symbols. Nowlan, Sean wrote: > > Hi all, > > I'm wondering if spreading a bitstream (XOR-ing each bit with > SPREAD_FACTOR bits of sequence) before QPSK modulation is equivalent to > operating on the modulated stream, i.e., multiplying the complex output > with -1's and 1's from the sequence. So far I can't get the math to work > out. Any suggestions? > > Thanks, > Sean > > ___ > 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/QPSK-with-direct-sequence-spread-spectrum-tp32752034p32754111.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/gnuradio-companion architecture
On 10/31/2011 10:50 AM, Marcus D. Leech wrote: > On 10/31/2011 01:45 PM, Chris Lirakis wrote: >> gnuradio-companion is a really cool piece of software. I'd like to >> emulate the style in which blocks are connected together. It is rather >> intricately tied to gnuradio. Does a design document exist that shows >> the philosophy of the internal layout, ie how blocks are connected etc? >> Chris >> >> -- >> Chris Lirakis >> > I don't think there's an architecture document. > > But GRC "knows" remarkably little about Gnu Radio, per se. Most of that > knowledge is encapsulated in the various .XML files that describe > blocks semantics, and in particular, the code that needs to be emitted > when one of those blocks is instantiated. > > So, conceivably, you could use GRC to layout "blocks" for an entirely > different reason/subsystem--might require *bit* of tweaking, but probably > not a complete overhaul. > I had done exactly this for a project that connected VHDL blocks. It used the same gui and base classes as grc. The link seems to be down now: http://www.flexhdr.org/projects/flexhdr/wiki -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ld search path on mac os x
Last I checked, volk didn't compile on OSX yet -- but my knowledge is probably a month old now, so things might have changed. I just compile with volk disabled. Maybe Johnathan can comment more about volk working on OSX? - MLD On Oct 31, 2011, at 12:02 PM, Dimitris Symeonidis wrote: > I'm trying to build gnu radio from source on a MacOSX 10.6, using MacPorts. > > I tried both with the git master tree and the 3.4.2 tarball, and both > fail at the same point: linking fails in volk/lib with "library not > found for -lboost_unit_test_framework-mt". > > The library files (libboost_unit_test_framework-mt.a and > libboost_unit_test_framework-mt.dylib) are installed in > /opt/local/lib, along with all the other boost libraries. Compiling > and linking works fine in other directories of the source tree. > > I don't know autotools well enough to identify the source of the > problem. Any hints? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wanted TVRX daughtercard USRP1 SN < 500
Want to buy a TVRX with no UHD support for an USRP1 serial number < 500 Shipping address: Los Angeles (Los Alamitos) Patrik___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ld search path on mac os x
On 10/31/2011 12:49 PM, Michael Dickens wrote: > Last I checked, volk didn't compile on OSX yet -- but my knowledge is > probably a month old now, so things might have changed. I just > compile with volk disabled. Maybe Johnathan can comment more about > volk working on OSX? - MLD > It built just fine on the macmini at my office w/ cmake (off of master branch). Im building the rest of gnuradio to see if thats ok too. -josh > On Oct 31, 2011, at 12:02 PM, Dimitris Symeonidis wrote: >> I'm trying to build gnu radio from source on a MacOSX 10.6, using >> MacPorts. >> >> I tried both with the git master tree and the 3.4.2 tarball, and >> both fail at the same point: linking fails in volk/lib with >> "library not found for -lboost_unit_test_framework-mt". >> >> The library files (libboost_unit_test_framework-mt.a and >> libboost_unit_test_framework-mt.dylib) are installed in >> /opt/local/lib, along with all the other boost libraries. >> Compiling and linking works fine in other directories of the source >> tree. >> >> I don't know autotools well enough to identify the source of the >> problem. Any hints? > > > ___ 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] Can't link against libgnuradio-core (cmake)
Greetings, I'm trying to rebuild my gr-fcd block (https://github.com/csete/gr-fcd) with gnuradio v3.5.0rc0-1-g037c5f60 When I build gnuradio using the autotools everything is fine and I can build gr-fcd without problems. When I build using cmake gnuradio still builds and install fine, but when I try to build gr-fcd I get: libtool: link: `/opt/gnuradio/v3.5.0rc0-1-g037c5f60/lib/libgnuradio-core.la' is not a valid libtool archive make[3]: *** [libgnuradio-fcd.la] Error 1 make[3]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git' make: *** [all] Error 2 Looking at the contents of gnuradio-core.la from the two builds I can indeed see many differences, actually they seem to be more different than similar. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny On Thu, Oct 20, 2011 at 11:24 AM, Marcus D. Leech wrote: > On 20/10/2011 10:25 AM, David Barton wrote: > > > I have been troubleshooting an issue with possible packet relflections and > cannot figure out the cause. I am running tunnel.py on two USRP2s that are > cabled together with a 20dB attenuator between them. The settings I am > using on both sides for tunnel.py are: > > Tx Gain: 15 dB > Rx Gain: 10 dB > Carrier Threshold: -80 > Rx Tunnel Freq: 400 MHz > Modulation: GMSK > Bit Rate: 1Mb/sec > > When I use VLC to stream a video from computer A to computer B over the > USRP link it works ok but there are alot of reflected packs being recorded > by computer A. The same thing happens when I try to stream from computer A > to computer B. This also occurs when I use iperf to test the link. > Strangely, though there are NO reflected packets when I ping between the > computers. > > Below is a paste of some of the output from computer A. I put in a > timestamp on the left of when events occur. I also put in an explicit > statement to print out when tunnel is backing off and for how long. I added > sequence number to make it blatantly obvious that the computer is receiving > its own packet. Any packet with a sequence number beginning originates from > computer A. If the packet originated from computer B it shows up at > RX_packet=none. As it shows computer A is receiving its own packets! > [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 > [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 > [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 > [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 > [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 > [ 63.61 ] Backing off for 0.001 sec > [ 63.62 ] Backing off for 0.002 sec > [ 63.62 ] Backing off for 0.004 sec > [ 63.63 ] Backing off for 0.008 sec > [ 63.64 ] Backing off for 0.016 sec > [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 > [ 63.66 ] Backing off for 0.032 sec > [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 > [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 > [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 > [ 63.67 ] Backing off for 0.064 sec > [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 > [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 > [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 > [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 > [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 > [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 > [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 > [ 63.72 ] Backing off for 0.001 sec > [ 63.72 ] Backing off for 0.002 sec > [ 63.73 ] Backing off for 0.004 sec > [ 63.74 ] Backing off for 0.008 sec > [ 63.75 ] Backing off for 0.016 sec > [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 > [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 > [ 63.76 ] Backing off for 0.032 sec > [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 > [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 > [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 > [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 > [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 > [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 > [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 > [ 63.78 ] Backing off for 0.001 sec > [ 63.79 ] Backing off for 0.002 sec > [ 63.79 ] Backing off for 0.004 sec > [ 63.79 ] Backing off for 0.008 sec > [ 63.8 ] Backing off for 0.016 sec > [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 > [ 63.82 ] Backing off for 0.032 sec > [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 > [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 > [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 > [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 > [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 > [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321 > [ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448 > [ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855 > [ 63.84 ] Backing off for 0.001 sec > [ 63.84 ] Backing
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote: I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny We used to have this problem "back in the day" with packet-radio, using analog FM transceivers--they were often notoriously sluggish in turning around the TX/RX logic. You might try zero-stuffing the TX frames--that's basically what we did back in the day. Although the XCVR2450 short turn around fairly quickly, it's not infinitely quick. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
Marcus, What do you mean my zero-stuffing the TX frames? And how would it help with the turn-around time of the XCVR2450 daughterboard? Do you mean I should transmit a zero-filled packet before any real packet, so that the receiving side (A in my scenario) has time to switch back to receiving before the real packet arrives? Johnny On Mon, Oct 31, 2011 at 6:22 PM, Marcus D. Leech wrote: > ** > On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote: > > I have been running into problems using tunnel.py as well so instead of > creating a new post I thought I'll just continue this thread. > > My setting: > USRP2 > XCVR2450 > Ubuntu 10.04 (32bit) > > The problem I have is that after running tunnel, whenever I do ping, my > system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts > an ARP packet to find the MAC address of B's IP. B gets the ARP request, > immediately sends an ARP response back to A with its MAC. However, in my > system, A never gets the ARP reply. > > I seriously can't think of a reason for this. I can guess a possible > cause is that B sends the ARP reply too quickly that A doesn't have enough > time to go from transmit mode to receive mode (XCVR2450 is a half-duplex > daughterboard). But I don't know how to verify this hypothesis. > > Can anyone help me? > > Thank you, > Johnny > > > We used to have this problem "back in the day" with packet-radio, using > analog FM transceivers--they were often notoriously sluggish > in turning around the TX/RX logic. > > You might try zero-stuffing the TX frames--that's basically what we did > back in the day. Although the XCVR2450 short turn around fairly > quickly, it's not infinitely quick. > > > > > >> > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't link against libgnuradio-core (cmake)
On 10/31/2011 01:50 PM, Alexandru Csete wrote: > Greetings, > > I'm trying to rebuild my gr-fcd block > (https://github.com/csete/gr-fcd) with gnuradio v3.5.0rc0-1-g037c5f60 > When I build gnuradio using the autotools everything is fine and I can > build gr-fcd without problems. > When I build using cmake gnuradio still builds and install fine, but > when I try to build gr-fcd I get: > > libtool: link: `/opt/gnuradio/v3.5.0rc0-1-g037c5f60/lib/libgnuradio-core.la' > is not a valid libtool archive > make[3]: *** [libgnuradio-fcd.la] Error 1 > make[3]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git' > make: *** [all] Error 2 > > Looking at the contents of gnuradio-core.la from the two builds I can > indeed see many differences, actually they seem to be more different > than similar. > Basically, the build system is generating .la files for each library using this macro: http://www.vtk.org/Wiki/CMakeMacroLibtoolFile I dont know why we are doing this or why we want it. If you link against libraries in the normal way, everything should be fine. So my best guess is that the generated la files are confusing for autotools. Try deleting the la files. You can also turn the generation off w/ -DLIBRARY_EXTRAS=OFF -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
On 10/31/2011 06:40 PM, Tuan (Johnny) Ta wrote: Marcus, What do you mean my zero-stuffing the TX frames? And how would it help with the turn-around time of the XCVR2450 daughterboard? Do you mean I should transmit a zero-filled packet before any real packet, so that the receiving side (A in my scenario) has time to switch back to receiving before the real packet arrives? The transmit side assumes that the combination of RX-to-TX and TX-to-RX transition experienced by both sides is non-zero. So, you get the transmit side to simply send some idle 0s, and *then* the actual start-of-frame data, etc. What happens in these situations in my experience is that the start-of-frame gets missed during the switchover interval. So if the transmit side sends zeros (or, really, anything other than the start-of-frame sequence) for a "little while" after commencing a transmit burst, you're less likely to run into TX-to-RX transition issues. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't link against libgnuradio-core (cmake)
On Mon, Oct 31, 2011 at 11:44 PM, Josh Blum wrote: > > On 10/31/2011 01:50 PM, Alexandru Csete wrote: >> Greetings, >> >> I'm trying to rebuild my gr-fcd block >> (https://github.com/csete/gr-fcd) with gnuradio v3.5.0rc0-1-g037c5f60 >> When I build gnuradio using the autotools everything is fine and I can >> build gr-fcd without problems. >> When I build using cmake gnuradio still builds and install fine, but >> when I try to build gr-fcd I get: >> >> libtool: link: `/opt/gnuradio/v3.5.0rc0-1-g037c5f60/lib/libgnuradio-core.la' >> is not a valid libtool archive >> make[3]: *** [libgnuradio-fcd.la] Error 1 >> make[3]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib' >> make[2]: *** [all] Error 2 >> make[2]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git/lib' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/alexc/gnuradio/gr-fcd.git' >> make: *** [all] Error 2 >> >> Looking at the contents of gnuradio-core.la from the two builds I can >> indeed see many differences, actually they seem to be more different >> than similar. >> > > Basically, the build system is generating .la files for each library > using this macro: http://www.vtk.org/Wiki/CMakeMacroLibtoolFile > I dont know why we are doing this or why we want it. > > If you link against libraries in the normal way, everything should be > fine. So my best guess is that the generated la files are confusing for > autotools. > > Try deleting the la files. You can also turn the generation off w/ > -DLIBRARY_EXTRAS=OFF > Thanks for the tip! Using -DLIBRARY_EXTRAS=OFF works :) Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't link against libgnuradio-core (cmake)
On Mon, Oct 31, 2011 at 15:44, Josh Blum wrote: > Basically, the build system is generating .la files for each library > using this macro: http://www.vtk.org/Wiki/CMakeMacroLibtoolFile > I dont know why we are doing this or why we want it. > > If you link against libraries in the normal way, everything should be > fine. So my best guess is that the generated la files are confusing for > autotools. > > Try deleting the la files. You can also turn the generation off w/ > -DLIBRARY_EXTRAS=OFF > > You're right, I don't think the .la files are necessary for linking against when using cmake. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
