[Discuss-gnuradio] USRP2 MIMO setup problem
Hi all, I am trying to create a two transmitter setup with two USRP2s connected with the MIMO cable. I use the trunk version of GNURadio (Friday, Jan 29,2010) on laptops running Ubuntu 9.04. >From previous emails and looking at the code, the relevant code for two transmitter setup seems to be the test_mimo_tx file in usrp2/host/apps. I update the firmware of the master USRP2 with mimo_tx.bin as pointed out in http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ. sudo ./u2_flash_tool --dev=/dev/sdb -t s/w apps/mimo_tx.bin -w and for the slave USRP2, I use sudo ./u2_flash_tool --dev=/dev/sdb -t s/w apps/mimo_tx_slave.bin -w When I invoke the transmission program at the sender laptop using sudo ./test_mimo_tx -f 2.412G -I a.dat -i 100 -r I observe the following message: usrp2::ctor reset_db failed. The USRP2 freezes after this and the host cannot find it using find_usrps. The archives of the mailing list suggest updating the firmware to solve this issue. But I want to use the MIMO firmware and not the usual txrx.bin. 1. Is there firmware for the MIMO master and slave, which does not have this problem? 2. What modifications need to be incorporated to the current MIMO files to fix this problem? If there is not a solution already, I am thinking of modifying the existing MIMO USRP2 related files. Any pointers on what are to be taken care of, will be very useful. Thanks, Sri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build Problem - Ubuntu 8.04
Hello, I am installing GNURadio code from the trunk using git on a laptop running Ubuntu 8.04 and have some build problems. I follow the instruction for installing the code given in the wiki. i.e installing the required software using sudo apt-get, installing boost_1_37. Then I do ./bootstrap, ./configure --with-boost=$BOOST_PREFIX --disable-gr-pager. Configure completes and finds the correct boost library, options, etc. The config.log file gives a yes for all boost related items including "checking whether the boost::program_options includes are available". But the make command is not successful and results in the following error. /usr/bin/ld: cannot find -lboost_program_options-gcc42-mt-1_37 collect2: ld returned 1 exit status make[5]: *** [gnuradio-config-info] Error 1 make[5]: Leaving directory `/home/ysjeong/gnu/gnuradio/gnuradio-core/src/lib' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/ysjeong/gnu/gnuradio/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/ysjeong/gnu/gnuradio/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/ysjeong/gnu/gnuradio/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ysjeong/gnu/gnuradio' make: *** [all] Error 2 This error was reported in another mail but there was no response in that thread. Also, there is a previous installation of GNUradio 3.1.2 on a different user account. But I think that should not conflict because it is a separate installation from a different user. Any help to solve this is really appreciated.. Thanks, Sri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Delays
Hi everyone, I am interested in knowing the delay jitter of the total transmission time of a packet/waveform. Specifically, I want to know the time between the time the flowgraph is tsarted in python (tb.run or tb.start) and the time that the first sample is transmitted into the air from the USRP hardware. I want to know if I can reduce the jitter in this time (across runs) to as low a value as possible. I use usrp_siggen.py with gnuradio-3.1.2 to transmit a square waveform .I try to start the flowgraph at a precise time x (in microseconds) by using y=x-time.time() and time.sleep(y) and then tb.start(),time.sleep(0.1) and tb.stop(). I also use an interp of 32 at the Tx. I have a receiver that logs all data (with -d 64). I observe the samples just out of the usrp source. For transmissions that are precisely spaced in time using appropriate values x, the inter transmission delay measured at the receiver is off by a value > than 2 ms. (despite using nice to increase the priority of this process). 1. Is it possible to reduce the jitter between successive Tx.delay measurements to be few 10's of microseconds or lesser? 2. Is there a way to run the usrp_siggen code as a kernel module to improve the delay jitter performance? Thanks in advance for your help, Sri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Switching On and Off the Power Amplifier in python
Hi all, I am trying to perform On Off Keying and I figured out that the way actual chips (TI-Chipcon 1000) do it is by turning on and off the power amplifier. I found out that when I just modify the transmit constellation and use benchmark_tx.py the received power does not go down to 0 when the transmitted symbol is 0+0i. As pointed out by some of you, I found that the stream of symbols have a DC component which results in a beat frequency at the receiver. My question now is, can I just shutdown and power up the (transmit) power amplifier depending on the transmitted symbol to perform On Off Keying. I think, I will not have the DC problem then because the power amplifier would now see only one symbol either 1 or 0 instead of a stream of symbols which have a DC component. In my understanding, the code currently sets auto_tr to true meaning that whenever it is not transmitting/ done transmitting a packet it goes to the receive state and so the power amplifier is off. Is it possible to set the power amplifier On/OFF in Python ? Where can I find the code that performs this or is relevant to this? Thanks, Sri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] On Off Keying
Thanks for all the discussions. It has definitely given me clarity into what is happening. . I understand that the DC component of the transmitted signal, along with the frequency offset causes a strong tone at the receiver. I have linked two plots of the real part of the received baseband samples with and without RRC pulse shaping. http://www.ece.gatech.edu/~sriram/rrc.gif http://www.ece.gatech.edu/~sriram/norrc.gif It is clear that there is a strong tone corresponding to the frequency offset and the data modulation can be seen although not clearly. Also, using the RRC pulse shaping seems to be better when I observe the real part of the received sample (although the power plots are similar with and without RRC). I am just wondering how I could demodulate this and how practical OOK receivers operate. Should this tone be filtered out using a high pass filter (difference of consecutive samples?) ? Since the data sample variation is faster than the frequency offset ( about 100 samples for one cycle of the offset frequency), it looks likely that a filter which passes the high frequency (Data) variations and filters out the low frequency (frequency offset) must be helpful? Am I correct in thinking this way? Feeding this to the costas loop does not help much. The costas loop (with default parameters that work for dBpsk) is unable to demodulate the bits correctly. I am wondering if tweaking its parameters to values different from the default ones might help. I currently use a -i 256 and -d 128, since my laptops don't keep up for lower values. I will experiment to see what happens if they are increased. Thanks, Sri On 9/30/08, Johnathan Corgan <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 29, 2008 at 2:28 PM, Brian Padalino <[EMAIL PROTECTED]> > wrote: > > > Don't some of the daughterboards also have some AGC built in? I can > > see if the interpolation rate is not high enough, the signal power > > will not go down enough (especially after the RRC filtering) to really > > look like much of a difference if any due to the AGC circuitry and > > other transients that may occur on signals quickly coming on then off. > > > None of the daughterboards have AGC as far as I'm aware (Matt, > correct me if I'm wrong on this.) > > It's not that the filtering is preventing the envelope from going to > zero (though it might be; RRC's are intentionally designed to > introduce ISI in a very specific way). It's just that with the > waveform he's sending, there is a strong carrier component at passband > that shows up as a constant beat frequency in the receiver due to > frequency offset. > > > > Please correct me if I am wrong, but I think using a very large > > interpolation rate might help clarify the situation. > > > It would improve things. If the baseband "square wave" had it's > fundamental frequency near the RRC filter limit, or near the Nyquist > limit of the baseband sampling rate if the RRC wasn't in use, there > would be few to no harmonics that make it through the filtering and/or > interpolation. The transmitted waveform would be a carrier and two > sidebands, a classic AM waveform. I think that's what he is seeing. > > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com/ > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] On Off Keying
Hi, I am trying to send a stream of bits using On Off keying and am having some issues. At this stage, I just want to check if 1's and 0's are getting received with a high and low amplitude respectively. I have modified dbpsk.py setting the constellation to 0+0i and 1+0i in psk.py and invoke the tx/rx as in benchmark_tx,benchmark_rx .. My flowgraph is Bytes2symbols ->RRCFilter->USRP USRP->filesink I have a Bytes2symbols file which just writes the complex symbols for a given set of bytes as in gr_chunks2symbols_bc.cc. I have also checked that the complex symbols entering the USRP at the transmitter are as expected. However, at the receiver (USRP baseband samples without any processing) when I measure the power, I do not see the power going low for the 0 bits. Specifically, when I send a 101010... bit stream of 128 samples (just these bits without any headers/trailers). The transmitted baseband complex symbols are as expected with the real part going between 1 and 0 alternatively. *At the receiver, the received power stays almost the same high value throughout the packet duration, whereas I would have expected it to alternatively go high and low*. Adding or removing the RRC filter doesn't affect the observation. The following observations are true for the power and the real part of the baseband samples. 1. For a tx. stream of all 1's, i can see the beat frequency or the frequency offset for the duration of the packet (as expected). 2. For a tx. stream of all 0's , i see a low received value. (almost close to the noise levels) as expected. 3. However, for a tx. stream of 1's and 0's mixed, I still see the received amplitude (real part) showing the beat frequency continuously and not going to 0 for the 0 bits. I am using the latest stable version i.e gnuradio-3.1.3 on Ubuntu laptops. Could this be Inter Symbol Interference or a setting which makes the (carrier) power coming out of the USRP constant for the packet duration irrespective of the tx.data? Any help is greatly appreciated. Thanks, Sri. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BBN's 802.11b code
Hello all, I am trying to understand the BBN code for 802.11b. I must state upfront that I am not an expert in communication systems. 802.11b uses dBPSK and dQPSK modulations for its 1Mbps and 2Mbps rates. I explored how a dBPSK module looks like and I am able to make sense of the code in gnuradio-core/src/python/gnuradio/blks2impl/dbpsk.py. The receiver structure matches with what I have seen in communication textbooks. However, the dBPSK demod receiver used in the BBN code (gr-bbn/src/bbn/bbn_dpsk_demod_cb.cc) seems different from the technique used in main gnuradio dbpsk module. This also does not include timing and carrier sync loops. Can someone explain what this code does and point me to any link/textbook which describes the demodulation technique? Is there some documentation for the BBN code and references to the text/paper for the mod/demod techniques used? Thanks, Sri ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 67, Issue 15
Thanks for the quick reply. Please see inline responses. > > > Date: Fri, 06 Jun 2008 12:19:56 -0400 > From: Greg Troxel <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] 802.11 on USRP+GNURadio > To: "sri ram" <[EMAIL PROTECTED]> > Cc: discuss-gnuradio@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Looking at the archives, I understand that I can receive 1 Mbps > probe/beacon packets with code developed by BBN. I use their code and > see packets at 1 Mbps from different nodes. > However, I don't know of a way to have the USRP as a destination for a > flow using standard packet generation tools like Iperf. So I setup a > > We wrote code to inject the packets (802.11 frames) into a modified > NetBSD tap device that was an 802.11 interface rather than ethernet, and > then were able to use tcpdump. All of this code is on the > acert.ir.bbn.com server. We didn't address all the interactions with > the 802.11 state machines in net80211 and the GNU Radio implementation. > So you should be able to port this to Linux, but it's non-trivial. > Yes. I shall look into that in some time. > > UDP flow between a conventional 802.11bg AP and a Laptop. I capture > the packets on air with the USRP and determine how many of the packets > of this flow I am able to receive. But here, out of 1000 packets (1500 > bytes each) sent at 1 Mbps, the laptop is able to receive around 900 > packets but the USRP captures somewhere between 100 to 550 packets. I > > If the laptop is only gettinng 900, that indicates something is wrong. > Are you sending these back to back as fast as you can? I'd back off to > 200 pps or something like that, and see what happens, and then gradually > increase the rate, watching CPU load. > I was running the GNURadio code and the WLAN card on the same machine. I performed another experiment where the WLAn card and iperf run on one laptop and the GNURadio on another laptop. In this case, the laptop gets all the packets. But the laptop running the GNURadio, receives only a fraction of the packets. I reduced the Iperf sending rate to 200kbps. Still things don't change. Then I found out that just running the bbn_80211b_rx.py code causes the CPU load to increase. top tells me, CPU(s): 79.0% us with a load average increasing very fast greater than 1. This doesn't seem alright to me. Is this normal? Might this have to do with the OS (Ubuntu) or the linux Kernel version (2.6.15)? > > am wondering whether this makes sense. I thought that the BBN code > would capture most of the packets provided the rate is 1 Mbps > (disregarding probe packets from other APs). But this does not seem to > happen.. > > We did get most packets given a reasonable load > > I use gnuradio-3.1.2 on Ubuntu Dapper with a 2 GHz Intel core duo > processor and 2 GB RAM. > > We had 1.6 GHz Pentium M with 2 GB RAM (Thinkpad T43), with NetBSD > current from summer 2006 (pre 4.0). > > > > > I'd appreciate any suggestions on why this happens and what might be an alternative to try. Sriram ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.11 on USRP+GNURadio
Sorry. The subject of my previous mail ought to have been 802.11 on USRP. Sriram ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Parsing a packet
Hello all, I am trying to use the USRP to capture 802.11 packets and have a few questions. Looking at the archives, I understand that I can receive 1 Mbps probe/beacon packets with code developed by BBN. I use their code and see packets at 1 Mbps from different nodes. However, I don't know of a way to have the USRP as a destination for a flow using standard packet generation tools like Iperf. So I setup a UDP flow between a conventional 802.11bg AP and a Laptop. I capture the packets on air with the USRP and determine how many of the packets of this flow I am able to receive. But here, out of 1000 packets (1500 bytes each) sent at 1 Mbps, the laptop is able to receive around 900 packets but the USRP captures somewhere between 100 to 550 packets. I am wondering whether this makes sense. I thought that the BBN code would capture most of the packets provided the rate is 1 Mbps (disregarding probe packets from other APs). But this does not seem to happen.. I use gnuradio-3.1.2 on Ubuntu Dapper with a 2 GHz Intel core duo processor and 2 GB RAM. I would be grateful for any directions/pointers on the above and how I could get the USRP to receive a continuous 1 Mbps 802.11 stream. Thanks, Sriram ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
Hello Dan, Using a higher decimation rate (128) , that problem does not arise. Thanks, Sriram On Dec 24, 2007 3:16 PM, sri ram <[EMAIL PROTECTED]> wrote: > Hello Dan, > I see that the u0 occurs once every 3 entries which could > explain the ratio between the packets that are received and sent. > > I am using a Pentium4 1.8GHz CPU. 'top' tells me that the processor is 98% > free and memory is also 95% free. > Do you still think that this computer is slow or is there any other > problem that could have happened (such as the USB)? > I use a USB PCI card and the usrp_benchmark_usb gives 16MBps without u0s. > > Thanks for your quick response, > Sriram. > > > On Dec 24, 2007 2:58 PM, Dan Halperin <[EMAIL PROTECTED]> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > sri ram wrote: > > > P.S. I am attaching the output of the rx side. > > > > uOok = True pktno = 47 n_rcvd = 48 n_right = 48 > > ok = True pktno = 48 n_rcvd = 49 n_right = 49 > > ok = True pktno = 49 n_rcvd = 50 n_right = 50 > > ok = True pktno = 50 n_rcvd = 51 n_right = 51 > > uOok = True pktno = 51 n_rcvd = 52 n_right = 52 > > ok = False pktno = 52 n_rcvd = 53 n_right = 52 > > ok = False pktno = 54 n_rcvd = 54 n_right = 52 > > uOok = False pktno = 56 n_rcvd = 55 n_right = 52 > > ok = False pktno = 58 n_rcvd = 56 n_right = 52 > > > > - -- > > > > The USRP Overruns (the 'uO's indicated above) mean that your computer is > > > > not fast enough to process this data. Is the processor too slow? Are you > > running other applications in the background? > > > > - -Dan > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.6 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L > > G7g4Eh02xuO44VpTl/KtFr4= > > =CSgi > > -END PGP SIGNATURE- > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
Hello Dan, I see that the u0 occurs once every 3 entries which could explain the ratio between the packets that are received and sent. I am using a Pentium4 1.8GHz CPU. 'top' tells me that the processor is 98% free and memory is also 95% free. Do you still think that this computer is slow or is there any other problem that could have happened (such as the USB)? I use a USB PCI card and the usrp_benchmark_usb gives 16MBps without u0s. Thanks for your quick response, Sriram. On Dec 24, 2007 2:58 PM, Dan Halperin <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > sri ram wrote: > > P.S. I am attaching the output of the rx side. > > uOok = True pktno = 47 n_rcvd = 48 n_right = 48 > ok = True pktno = 48 n_rcvd = 49 n_right = 49 > ok = True pktno = 49 n_rcvd = 50 n_right = 50 > ok = True pktno = 50 n_rcvd = 51 n_right = 51 > uOok = True pktno = 51 n_rcvd = 52 n_right = 52 > ok = False pktno = 52 n_rcvd = 53 n_right = 52 > ok = False pktno = 54 n_rcvd = 54 n_right = 52 > uOok = False pktno = 56 n_rcvd = 55 n_right = 52 > ok = False pktno = 58 n_rcvd = 56 n_right = 52 > > - -- > > The USRP Overruns (the 'uO's indicated above) mean that your computer is > not fast enough to process this data. Is the processor too slow? Are you > running other applications in the background? > > - -Dan > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L > G7g4Eh02xuO44VpTl/KtFr4= > =CSgi > -END PGP SIGNATURE- > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flex2400 and benchmark_rx.py - receiving only fraction of packets
Hi all, I am working with Flex2400 boards and the USRP. I have a question about the digital module (GMSK data transfer). I observe this: When I send 660 packets , I receive less than 400 of them and less than 200 are correct. I setup two PCs with ubuntu and with an USRP each. The antennas were connected to the TX/RX ports on each USRP and separated around 3.2m. Basic tests such as oscope and fft work fine, with one side sending. Then with benchmark, on one end I use: ./benchmark_tx.py -f 2.412G --tx-amplitude=2 -v -r 500k and the other ./benchmark_rx.py -f 2.412G --rx-gain=70 -v -r 500k For different runs, errors happen and in a typical run I get something like ok = False pktno = 662 n_rcvd = 355 n_right = 164 I did the following (which did not help) 1) varied rx gain and tx_amplitude over a range 2) checked the frequency 2.412 (using oscope and iwlist) and also changed to other free frequencies 3) repeated experiment at a different time and day The ratio of the pktno to n_rcvd and n_right remains almost the same for different runs. Further, if I send send traffic the other way, I get lesser number of packets (100) correct. Has anyone seen something like this? Specifically, I am looking at why the RX would receive only a fraction of packets and why only a smaller fraction would pass crc? Thanks for your help, Sri. P.S. I am attaching the output of the rx side. [EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/digital$ ./benchmark_rx.py -f 2.412G --rgain=50 -v -r 500k >>> gr_fir_fff: using SSE bits per symbol = 1 M&M clock recovery omega = 2.00 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.50 M&M clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board B: Flex 2400 Rx MIMO B Rx gain: 50 modulation: gmsk_demod bitrate: 500kb/s samples/symbol:2 decim:64 Rx Frequency:2.412G Warning: Failed to enable realtime scheduling. ok = True pktno =0 n_rcvd =1 n_right =1 ok = True pktno =1 n_rcvd =2 n_right =2 ok = True pktno =2 n_rcvd =3 n_right =3 ok = True pktno =3 n_rcvd =4 n_right =4 ok = True pktno =4 n_rcvd =5 n_right =5 ok = True pktno =5 n_rcvd =6 n_right =6 ok = True pktno =6 n_rcvd =7 n_right =7 ok = True pktno =7 n_rcvd =8 n_right =8 ok = True pktno =8 n_rcvd =9 n_right =9 ok = True pktno =9 n_rcvd = 10 n_right = 10 ok = True pktno = 10 n_rcvd = 11 n_right = 11 ok = True pktno = 11 n_rcvd = 12 n_right = 12 ok = True pktno = 12 n_rcvd = 13 n_right = 13 ok = True pktno = 13 n_rcvd = 14 n_right = 14 ok = True pktno = 14 n_rcvd = 15 n_right = 15 ok = True pktno = 15 n_rcvd = 16 n_right = 16 ok = True pktno = 16 n_rcvd = 17 n_right = 17 ok = True pktno = 17 n_rcvd = 18 n_right = 18 ok = True pktno = 18 n_rcvd = 19 n_right = 19 ok = True pktno = 19 n_rcvd = 20 n_right = 20 ok = True pktno = 20 n_rcvd = 21 n_right = 21 ok = True pktno = 21 n_rcvd = 22 n_right = 22 ok = True pktno = 22 n_rcvd = 23 n_right = 23 ok = True pktno = 23 n_rcvd = 24 n_right = 24 ok = True pktno = 24 n_rcvd = 25 n_right = 25 ok = True pktno = 25 n_rcvd = 26 n_right = 26 ok = True pktno = 26 n_rcvd = 27 n_right = 27 ok = True pktno = 27 n_rcvd = 28 n_right = 28 ok = True pktno = 28 n_rcvd = 29 n_right = 29 ok = True pktno = 29 n_rcvd = 30 n_right = 30 ok = True pktno = 30 n_rcvd = 31 n_right = 31 ok = True pktno = 31 n_rcvd = 32 n_right = 32 ok = True pktno = 32 n_rcvd = 33 n_right = 33 ok = True pktno = 33 n_rcvd = 34 n_right = 34 ok = True pktno = 34 n_rcvd = 35 n_right = 35 ok = True pktno = 35 n_rcvd = 36 n_right = 36 ok = True pktno = 36 n_rcvd = 37 n_right = 37 ok = True pktno = 37 n_rcvd = 38 n_right = 38 ok = True pktno = 38 n_rcvd = 39 n_right = 39 ok = True pktno = 39 n_rcvd = 40 n_right = 40 ok = True pktno = 40 n_rcvd = 41 n_right = 41 ok = True pktno = 41 n_rcvd = 42 n_right = 42 uOok = True pktno = 42 n_rcvd = 43 n_right = 43 ok = True pktno = 43 n_rcvd = 44 n_right = 44 ok = True pktno = 44 n_rcvd = 45 n_right = 45 ok = True pktno = 45 n_rcvd = 46 n_right = 46 ok = True pktno = 46 n_rcvd = 47 n_right = 47 uOok = True pktno = 47 n_rcvd = 48 n_right = 48 ok = True pktno = 48 n_rcvd = 49 n_right = 49 ok = True pktno = 49 n_rcvd = 50 n_right = 50 ok = True pktno = 50 n_rcvd = 51 n_right = 51 uOok = True pktno = 51 n_rcvd = 52 n_right = 52 ok = False pktno = 52 n_rcvd = 53 n_right = 52 ok = False pktno = 54 n_rcvd = 54
