Hi Tom, Thanks for the reply.. I teed the output at the Rx to a file. It showed O's on my screen, but the file had no O's. I came to know from a friend of mine that the O's may be going into the stderr and the file had only stdout output. But the errors you see there were actually preceded by O's. I will run them again after making the changes you suggested.
Thank you On Sun, Feb 17, 2013 at 8:55 PM, Tom Rondeau <[email protected]> wrote: > On Fri, Feb 15, 2013 at 9:46 PM, Manu T S <[email protected]> wrote: > >> Hi, >> >> I was running the benchmark scripts with the following set of parametrs >> >> -f 915M -r 5000000 -m psk -8 >> >> with 30 dB gain set on both Tx and Rx. I was getting cluttered overflows >> and packet received during that time are in error.. Like I'm receiving >> about a 1000 packet without error and then then system runs into overflow >> and about then quite a large number of packets are received in error. >> >> Output is posted >> >> Demodulator: >> bits per symbol: 3 >> RRC roll-off factor: 0.35 >> FLL bandwidth: 6.28e-02 >> Timing bandwidth: 6.28e-02 >> Phase bandwidth: 6.28e-02 >> -- Opening a USRP2/N-Series device... >> -- Current recv frame size: 1472 bytes >> -- Current send frame size: 1472 bytes >> >> UHD Receiver: >> UHD Args: >> Freq: 915MHz >> Gain: 30.000000 dB >> Sample Rate: 3.33333Msps >> Antenna: None >> Spec: None >> >> Demodulator: >> bits per symbol: 3 >> RRC roll-off factor: 0.35 >> FLL bandwidth: 6.28e-02 >> Timing bandwidth: 6.28e-02 >> Phase bandwidth: 6.28e-02 >> >> Receive Path: >> modulation: psk_demod >> bitrate: 5Mb/s >> samples/symbol: 2.0000 >> Differential: True >> Using Volk machine: avx_64_mmx >> ok = True pktno = 1 n_rcvd = 1 n_right = 1 >> ok = True pktno = 2 n_rcvd = 2 n_right = 2 >> ok = True pktno = 3 n_rcvd = 3 n_right = 3 >> . >> . >> . >> ok = True pktno = 2953 n_rcvd = 2953 n_right = 2953 >> ok = True pktno = 2954 n_rcvd = 2954 n_right = 2954 >> ok = True pktno = 2955 n_rcvd = 2955 n_right = 2955 >> ok = True pktno = 2956 n_rcvd = 2956 n_right = 2956 >> ok = False pktno = 2957 n_rcvd = 2957 n_right = 2956 >> ok = False pktno = 2959 n_rcvd = 2958 n_right = 2956 >> ok = False pktno = 2961 n_rcvd = 2959 n_right = 2956 >> ok = False pktno = 2963 n_rcvd = 2960 n_right = 2956 >> ok = False pktno = 2965 n_rcvd = 2961 n_right = 2956 >> ok = False pktno = 2967 n_rcvd = 2962 n_right = 2956 >> . >> . >> . >> ok = False pktno = 3838 n_rcvd = 3369 n_right = 2956 >> ok = False pktno = 3841 n_rcvd = 3370 n_right = 2956 >> ok = False pktno = 3843 n_rcvd = 3371 n_right = 2956 >> ok = True pktno = 3845 n_rcvd = 3372 n_right = 2957 >> ok = True pktno = 3846 n_rcvd = 3373 n_right = 2958 >> ok = True pktno = 3847 n_rcvd = 3374 n_right = 2959 >> ok = True pktno = 3848 n_rcvd = 3375 n_right = 2960 >> . >> . >> . >> >> >> Any idea how to avoid these overflows??? >> -- >> Manu T S >> > > This is usually a problem due to the receiver not being able to keep up > with the flow of samples from the UHD device. Try running at a lower > bitrate. If you're seeing overflows temporarily and then things are > correcting themselves, it looks like you might be right on the edge of your > system's capabilities. In this case, it's like some other process/task is > taking some time away from your app, causing it to slow down just enough to > cause problems, but then things look like they come back. You could also > try to run with realtime privileges enabled to make sure your process gets > priority. > > On the other hand, the output you show here doesn't have any overflow > indication. Are you sure that this is what's happening? You're running at > 915 MHz, the center of the 900 MHz ISM band (depending on where you are). > It's likely to have other signals in it. Maybe this is just a case of > interference? > > Tom > > -- Manu T S
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
