Hi Laura, Yes, your 1 GigE transport is working correctly. Here's the manual page to resolve the thread priority issue. http://files.ettus.com/manual/page_general.html#general_threading_prio
You still have the file sinks in there, does it run better without them? Could you pre-generate your chip samples and read them from a file source on repeat? Underflows mean your computer is not able to send enough samples to the radio in time. Derek On Wed, May 2, 2018 at 3:09 PM, Laura Huddleston < laura.huddles...@ierustech.com> wrote: > Hey Derek, > > I ran the benchmark_rate and got the following: > $ cd opt/gnuradio/default/lib64/uhd/examples[laura.huddleston@illrepute04 > examples]$ ./benchmark_rate --rx_rate 25e6 --tx_rate 25e6 > [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-16); > Boost_105300; UHD_3.11.0.git-776-gdca39145 > [WARNING] [UHD] Unable to set the thread priority. Performance may be > negatively affected. > Please see the general application notes in the manual for instructions. > EnvironmentError: OSError: error in pthread_setschedparam > > Creating the usrp device with: ... > [INFO] [USRP2] Opening a USRP2/N-Series device... > [INFO] [USRP2] Current recv frame size: 1472 bytes > [INFO] [USRP2] Current send frame size: 1472 bytes > [WARNING] [UHD] Unable to set the thread priority. Performance may be > negatively affected. > Please see the general application notes in the manual for instructions. > EnvironmentError: OSError: error in pthread_setschedparam > Using Device: Single USRP: > Device: USRP2 / N-Series Device > Mboard 0: N200r4 > RX Channel: 0 > RX DSP: 0 > RX Dboard: A > RX Subdev: SBXv3 RX > TX Channel: 0 > TX DSP: 0 > TX Dboard: A > TX Subdev: SBXv3 TX > > Setting device timestamp to 0... > [WARNING] [UHD] Unable to set the thread priority. Performance may be > negatively affected. > Please see the general application notes in the manual for instructions. > EnvironmentError: OSError: error in pthread_setschedparam > Testing receive rate 25.000000 Msps on 1 channels > [WARNING] [UHD] Unable to set the thread priority. Performance may be > negatively affected. > Please see the general application notes in the manual for instructions. > EnvironmentError: OSError: error in pthread_setschedparam > Testing transmit rate 25.000000 Msps on 1 channels > > Benchmark rate summary: > Num received samples: 250258351 > Num dropped samples: 0 > Num overflows detected: 0 > Num transmitted samples: 250216989 > Num sequence errors: 0 > Num underflows detected: 0 > Num late commands: 0 > Num timeouts: 0 > > > Done! > > > I assume this means it is working properly (since when I try it with a > transmit/receive rate of 50MS/s, it simply prints a bunch of UUUUU). > > Following your suggestion, I changed the sample rate to 25M and added a > waterfall plot to see what was happening. It now starts off printing UUUU > then switches to UDDUUDUD. > > Attached is the revised flowgraph. > > Any help would be much appreciated > Laura > ------------------------------ > *From:* Derek Kozel [derek.ko...@ettus.com] > *Sent:* Tuesday, May 1, 2018 8:46 AM > > *To:* Laura Huddleston > *Cc:* discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU > > Hi Laura, > > With 16 bit samples, the default, a 1 Gigabit Ethernet link can only carry > 25 MS/s. Thankfully, that's complex IQ samples, so while Nyquist applies > the bandwidth is 1x the highest frequency. > http://files.ettus.com/manual/page_usrp2.html > <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2ffiles.ettus.com%2fmanual%2fpage_usrp2.html&c=E,1,HidUXEnA6CwLjTvpjKWbnnuWOepqSjnKEWVuVPGGrqnVaiNbDZvZDjhP3WISR99TtQP97ApV_eewksWJR_3VseMzCCPXTQDji4o5y-8c1JAgmrJjjC3O&typo=1> > > The N200 has a fixed master clock rate (ADC/DAC rate) of 100 MHz. Only > integer factors of that will be possible, if you look at your console > output there should be a line saying that 40 MS/s is not a possible value > and it is being set to a different one, either 25 MS/s or 50 MS/s. Either > of those isn't what you are expecting so your flowgraph will not produce > the correct values. 25 MS/s would be the best rate for you to use as it > fits your 20 MHz wide signal with some margin on either side to accommodate > filter roll off. It is also an even divisor of the master clock rate so > you'll have better filter performance than using a rate that is an odd > divisor. > > Can you please test with the benchmark_rate that comes with UHD to see if > your system is setup to transport samples at that rate? > > You may also find that it is harder to write 25 MS/s (200 MB/s) to a > harddrive than it is to run the waterfall plotting. > > Regards, > Derek > > On Tue, May 1, 2018 at 2:15 PM, Laura Huddleston < > laura.huddles...@ierustech.com> wrote: > >> I have attached them now. sorry about that. >> >> the sample rate is 40MHz because I am trying to send a chirp over 20MHz, >> so I figured with nyquist's theorem (sampling rate 2x highest frequency), >> that would be the correct one. However any sample rate above ~10MHz causes >> my grc window to freeze. >> >> Thanks for your response!! >> Laura >> ________________________________________ >> From: Maximilian Stiefel [stiefel.maximil...@online.de] >> Sent: Friday, April 27, 2018 6:46 PM >> To: Laura Huddleston >> Cc: discuss-gnuradio@gnu.org >> Subject: Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU >> >> Hello Laura, >> >> It is definitely not afternoon here in Sweden. There is no flowgraph >> attached. Happens to me as well, every time ;) >> >> This output usually indicates you are doing are something, that causes >> samples to be dropped, i.e. not transmitted, because something is not fast >> enough. >> >> What sample rate are we talking about? >> >> Cheers, >> >> Max >> >> Lördag den 28 april 2018 skrev Laura Huddleston: >> > >> > Good afternoon, >> > >> > I am creating a flowgraph that will chirp and then hop center frequency >> and repeat. >> > >> > This is on the ettus n200 with a cable connection the transmit to the >> receive port. >> > >> > The code worked perfectly until I increased the range of the chirp and >> subsequently the sample rate. Now every time I run the code, it outputs >> UUUUUUUUUUU and freezes the GRC window even after closing the pop up window >> printing out the center frequency. >> > >> > Until recently it was graphing the received data on a waterfall plot, >> but I assumed that was the reason the computer couldn't process the higher >> sample rate, so I replaced it with several file meta sinks to prove the >> data was what it was supposed to be. >> > >> > Thanks for any help you can provide, >> > attached is the flowgraph >> > >> > Laura >> > >> >> _______________________________________________ >> 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
