Re: [Discuss-gnuradio] Problem with USRP2 continuous transmission at >10MHz
Hi, > From: Christoph Thein > > We are using Ubuntu 9.04 with the latest trunk version of gnuradio but don't > know enough about the OS realtime scheduling issue to explain it. Does > anybody > have more knowledge about ubuntu and realtime to explain this behaviour? > > Regards, > > Hanwen and Christoph The realtime scheduling can be only used/enabled by administrator (using sudo). Best Reagrds, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USRP2 continuous transmission at >10MHz
Hi Matt, thanks for the advice. We connected the serial port and couldn't observe the underrun message and we enabled the realtime scheduling but there was no improvement. Strangely enough after that the program only works without interrupts if it is started as su in a shell and if this shell window is put in the background of the desktop (meaning that another window is the one we are working in right at that moment). We are using Ubuntu 9.04 with the latest trunk version of gnuradio but don't know enough about the OS realtime scheduling issue to explain it. Does anybody have more knowledge about ubuntu and realtime to explain this behaviour? Regards, Hanwen and Christoph > hanwen wrote: > > Hi, > > > > We use tx_samples.cc to transmit a file with 16bit-short complex samples > > at 10MHz and 20MHz. We use another USRP2 to receive the signal and store > > on disk. We observed there are some unexpected gaps in the received > > samples. Using usrp2_fft.py with the osiliscope view, we also observed > > such kind of gaps. > > We guess this might be caused by underrun at the transmitter side. We > > use the delievered ethernet cable, so this shouldn't be the problem of > > bad cable. > > Anyway, how can we transmit samples contineously and stably without > > underrun at 20MSamples/s?? > > 1 -- Make sure you have realtime scheduling enabled > 2 -- Use a very fast computer > > are you sure you are seeing underruns? Have you connected to the debug > serial port on the USRP2 and seen it send "U"? > > Matt > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USRP2 continuous transmission at >10MHz
Hi, > From: Matt Ettus > > are you sure you are seeing underruns? Have you connected to the debug > serial > port on the USRP2 and seen it send "U"? > > Matt USRP2 has 6 leds. Two of them are ON when every thing is OK. Can you use one/two of others to indicate over/under run? Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USRP2 continuous transmission at >10MHz
hanwen wrote: Hi, We use tx_samples.cc to transmit a file with 16bit-short complex samples at 10MHz and 20MHz. We use another USRP2 to receive the signal and store on disk. We observed there are some unexpected gaps in the received samples. Using usrp2_fft.py with the osiliscope view, we also observed such kind of gaps. We guess this might be caused by underrun at the transmitter side. We use the delievered ethernet cable, so this shouldn't be the problem of bad cable. Anyway, how can we transmit samples contineously and stably without underrun at 20MSamples/s?? 1 -- Make sure you have realtime scheduling enabled 2 -- Use a very fast computer are you sure you are seeing underruns? Have you connected to the debug serial port on the USRP2 and seen it send "U"? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with USRP2 continuous transmission at >10MHz
Hi, We use tx_samples.cc to transmit a file with 16bit-short complex samples at 10MHz and 20MHz. We use another USRP2 to receive the signal and store on disk. We observed there are some unexpected gaps in the received samples. Using usrp2_fft.py with the osiliscope view, we also observed such kind of gaps. We guess this might be caused by underrun at the transmitter side. We use the delievered ethernet cable, so this shouldn't be the problem of bad cable. Anyway, how can we transmit samples contineously and stably without underrun at 20MSamples/s?? Thanks in advnced. Bests, Hanwen & Christoph ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
