Yes it does run better without the file sinks, but the data doesn’t look like I would expect. I need the file sources in there to confirm that the sent data is what it is supposed to be. I can put the chirp into a file sink, but would that help it run faster?
~~~~~~~~~~~~~~~~~~~~~ Laura Huddleston IERUS Technologies, Inc. 256-319-2026x236 From: Derek Kozel <derek.ko...@ettus.com> Sent: Wednesday, May 2, 2018 9:30 AM To: Laura Huddleston <laura.huddles...@ierustech.com> Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU 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<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2ffiles.ettus.com%2fmanual%2fpage_general.html%23general_threading_prio&c=E,1,1GiBdrQgVrqL6yRE8EtIexRzRsrx0LF_YcsIZ01c3Hi_ukVVJhXiJhnTLBySoEJgGCUfqJvv2cCRF2ol9vgSuZ6-S6NXzigM7RQVoY_4t7DzC55R5hK9jS2NnRY,&typo=1> 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<mailto: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<mailto:derek.ko...@ettus.com>] Sent: Tuesday, May 1, 2018 8:46 AM To: Laura Huddleston Cc: discuss-gnuradio@gnu.org<mailto: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<mailto: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<mailto:stiefel.maximil...@online.de>] Sent: Friday, April 27, 2018 6:46 PM To: Laura Huddleston Cc: discuss-gnuradio@gnu.org<mailto: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<mailto: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
