Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU

On Wed, May 2, 2018 at 3:09 PM, Laura Huddleston <address@hidden> 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 [address@hidden]
Sent: Tuesday, May 1, 2018 8:46 AM

To: Laura Huddleston
Cc: address@hidden
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

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 <address@hiddencom> 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 [address@hidden]
Sent: Friday, April 27, 2018 6:46 PM
To: Laura Huddleston
Cc: address@hidden
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

From:	Derek Kozel
Subject:	Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU
Date:	Wed, 2 May 2018 15:30:10 +0100