That is to say, the code is still printing out UUU and I would still like to fix that if possible.
~~~~~~~~~~~~~~~~~~~~~
Laura Huddleston
IERUS Technologies, Inc.
256-319-2026x236
From: Laura Huddleston
Sent: Wednesday, May 2, 2018 10:42 AM
To: Derek Kozel <address@hidden>
Cc: address@hidden
Subject: RE: [Discuss-gnuradio] Frequency hopping code printing UUUUU
I changed it to a file source and took out the file sinks (for now, though I will need them added back in) and now the code doesn't seem to run right. Instead of
chirping ever 99ms, pausing for 1ms, changing center frequency and chirping again, it appears to be just grabbing one value at a time(see waterfall screenshot attached).
The chirp.grc is the code that generates the file of the chirp, and chirp_hopper_copy.grc uses the source to perform the code through the ettus n200.
Laura
From: Discuss-gnuradio [discuss-gnuradio-bounces+address@hidden
on behalf of Laura Huddleston address@hidden
Sent: Wednesday, May 2, 2018 9:55 AM
To: Derek Kozel
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU
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 <address@hidden>
Sent: Wednesday, May 2, 2018 9:30 AM
To: Laura Huddleston <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Frequency hopping code printing UUUUU
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 <address@hidden> wrote:
Hey Derek,
I ran the benchmark_rate and got the following:
$ cd opt/gnuradio/default/lib64/uhd/address@hidden 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
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@hidden> 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
|