Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Sumit Kumar]

Hi Bastian,

Yes thats correct. I believe this problem will be there if I do soft bit 
MRC i.e. independent decoding of the two branches. Just combining the 
long sync is not the solution :(


On an other note I have following question :

Inside the general_work in sync_long.cc, *ninput* is computed as follows.

*    int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
8192);*


This is the case when there are two inputs to sync_long i.e. *in* and 
*in_delayed*.


How shall I compute *ninput* when I have another branch coming say *in1* 
and *in1_delayed*.


In sync_short I faced the same issue when I input another branch. There 
I modified as follows :


*int ninput = std::min(std::min(ninput_items[2] 
,std::min(ninput_items[0], ninput_items[1])), std::min(ninput_items[4], 
ninput_items[3]));*


where previously it was

*int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
ninput_items[2]);*


Regards
Sumit
**
On 02/05/2018 08:26, Bastian Bloessl wrote:
The problem with this configuration is that the "Soft frame equalizer" 
blocks  are not synced. It's the same problem as with the Sync Short 
block, just at a later stage. Consider what happens, if one branch 
manages to decode the signal field and one doesn't. Or one thinks it's 
a 100 Byte BPSK 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar  wrote:
So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I 
believe, there wont be any need of synchronization between 
branches. Let me know your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first 
author, but since it was not real-time and for a single-carrier 
scheme, it might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any 
existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining 
for Ultra-Low Power Wildlife Monitoring". However it seems that 
the source code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded 
it. What is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be
Sumit


On 27/04/2018 10:41, Bastian Bloessl wro

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

Hi,

On 05/02/2018 12:04 PM, Sumit Kumar wrote:

Hi Bastian,

Yes thats correct. I believe this problem will be there if I do soft bit 
MRC i.e. independent decoding of the two branches. Just combining the 
long sync is not the solution :(


On an other note I have following question :

Inside the general_work in sync_long.cc, *ninput* is computed as follows.

*    int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
8192);*


This is the case when there are two inputs to sync_long i.e. *in* and 
*in_delayed*.


How shall I compute *ninput* when I have another branch coming say *in1* 
and *in1_delayed*.


In sync_short I faced the same issue when I input another branch. There 
I modified as follows :


*int ninput = std::min(std::min(ninput_items[2] 
,std::min(ninput_items[0], ninput_items[1])), std::min(ninput_items[4], 
ninput_items[3]));*


where previously it was

*int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
ninput_items[2]);* 


That's a bit a confusing way to write it, but I guess it's OK.

You'd do it similarly also in Sync Long but also keep the 8192. You 
could check if there's a better min-function that accepts a variable 
number of arguments.


Best,
Bastian




Regards
Sumit
**
On 02/05/2018 08:26, Bastian Bloessl wrote:
The problem with this configuration is that the "Soft frame equalizer" 
blocks  are not synced. It's the same problem as with the Sync Short 
block, just at a later stage. Consider what happens, if one branch 
manages to decode the signal field and one doesn't. Or one thinks it's 
a 100 Byte BPSK 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar  wrote:
So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I 
believe, there wont be any need of synchronization between 
branches. Let me know your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first 
author, but since it was not real-time and for a single-carrier 
scheme, it might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any 
existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining 
for Ultra-Low Power Wildlife Monitoring". However it seems that 
the source code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar 

[Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Eads, LJ D.]

Hello,
I just setup a USRP X310 that I plan on using with GNURadio over 10 gigabit.. I 
have everything working and functioning properly (drivers and all) but my only 
concern right now is that GNURadio is running off of the sound card on my 
server and not the GPU. GNURadio isn't able to handle practically anything 
because I am limited by the sound card capability.
How would I be able to use the CPU (Sixteen-Core Intel Xeon Processor E5-2683 
v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU Computing 
Accelerator - 24GB GDDR5 - Passive Cooler) for better functionality of the X310?

My current error: "gr::log : INFO: audio_alsa_sink0 - [default]: unable to 
support sample rate 50
Card requested 192000 instead"
https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00418.html - 
This sounds like my issue

Thank you,
LJ Eads


L J Eads
The MITRE Corporation
(937) 874-7240 (Office)
(954) 554-6801 (Mobile)
lje...@mitre.org (FFRDC)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[CEL]

Hi LJ Eads,

I'm a bit confused: What has your sound card to do with GNU Radio, or
the USRP? And how is your sound card comparable to a GPU?

GNU Radio runs on CPUs.

Best regards,
Marcus

On Wed, 2018-05-02 at 13:23 +, Eads, LJ D. wrote:
> Hello,
> I just setup a USRP X310 that I plan on using with GNURadio over 10 gigabit.. 
> I have everything working and functioning properly (drivers and all) but my 
> only concern right now is that GNURadio is running off of the sound card on 
> my server and not the GPU. GNURadio isn’t able to handle practically anything 
> because I am limited by the sound card capability.
> How would I be able to use the CPU (Sixteen-Core Intel Xeon Processor E5-2683 
> v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU Computing 
> Accelerator - 24GB GDDR5 - Passive Cooler) for better functionality of the 
> X310?
>  
> My current error: “gr::log : INFO: audio_alsa_sink0 – [default]: unable to 
> support sample rate 50
> Card requested 192000 instead”
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00418.html - 
> This sounds like my issue
>  
> Thank you,
> LJ Eads
>  
>  
> L J Eads
> The MITRE Corporation
> (937) 874-7240 (Office)
> (954) 554-6801 (Mobile)
> lje...@mitre.org (FFRDC)
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Derek Kozel]

Hello LJ,

It would help to know what type of signal processing you are hoping to do
and how you want to display or save the data. On generally available
consumer hardware GNU Radio has been shown to be able to handle 800+MS/s of
samples being displayed in spectrum plots.

It sounds like you are trying to route too much data to your speakers. Are
you able to share your flowgraph? There is a screenshot function in the
menu or the grc file could be attached.

Regards,
Derek


On Wed, May 2, 2018 at 2:28 PM, Müller, Marcus (CEL) 
wrote:

> Hi LJ Eads,
>
> I'm a bit confused: What has your sound card to do with GNU Radio, or
> the USRP? And how is your sound card comparable to a GPU?
>
> GNU Radio runs on CPUs.
>
> Best regards,
> Marcus
>
> On Wed, 2018-05-02 at 13:23 +, Eads, LJ D. wrote:
> > Hello,
> > I just setup a USRP X310 that I plan on using with GNURadio over 10
> gigabit.. I have everything working and functioning properly (drivers and
> all) but my only concern right now is that GNURadio is running off of the
> sound card on my server and not the GPU. GNURadio isn’t able to handle
> practically anything because I am limited by the sound card capability.
> > How would I be able to use the CPU (Sixteen-Core Intel Xeon Processor
> E5-2683 v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU
> Computing Accelerator - 24GB GDDR5 - Passive Cooler) for better
> functionality of the X310?
> >
> > My current error: “gr::log : INFO: audio_alsa_sink0 – [default]: unable
> to support sample rate 50
> > Card requested 192000 instead”
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/
> msg00418.html - This sounds like my issue
> >
> > Thank you,
> > LJ Eads
> >
> >
> > L J Eads
> > The MITRE Corporation
> > (937) 874-7240 (Office)
> > (954) 554-6801 (Mobile)
> > lje...@mitre.org (FFRDC)
> >
> > ___
> > 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Laura Huddleston]

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.00 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.00 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 U).

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  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 U

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 
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]
Sent: Friday, April 27, 2018 6:46 PM
To: Laura Huddleston
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Frequency hopping code printing U

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

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Derek Kozel]

Hi LJ,

I don't see an audio sink in either of those flowgraphs, are those the ones
causing the error? Is there supposed to be a soundcard involved at any
point in your setup? To just capture, record, and replay the file sink
seems correct (to the limits of your hard drive write/read speeds).

Does sending and receiving to/from the USRP work if you use null sink and
constant source to receive/produce data?

Derek

On Wed, May 2, 2018 at 3:08 PM, Eads, LJ D.  wrote:

> Derek and Marcus,
>
>
>
> Thank you for the quick response! This is my first entry to the mailing
> list.
>
>
>
> So I am trying to capture a very fast frequency hopping signal.. the rate
> is proprietary but probably one of the fastest rates on the market right
> now. I am currently just implementing a basic record/replay. I believe you
> are right that I am trying to route too much data to my speakers and that’s
> what I am trying to get out of.
>
>
>
> I currently have had better success with the X310 right now using the
> GNURadio Live Environment on a USB and running Cat 5E from the X310 to my
> laptop.. now I’m trying to implement what I had on my laptop on this server
> that I setup. I attached the server specs.. currently using ubuntu 16.04.
>
>
>
> Marcus.. I am confused as well! Because I feel like I should be using my
> CPUs and I am not.
>
>
>
> LJ Eads
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Wednesday, May 2, 2018 9:43 AM
> *To:* Müller, Marcus (CEL) 
> *Cc:* discuss-gnuradio@gnu.org; Eads, LJ D. 
> *Subject:* Re: [Discuss-gnuradio] How do I interface my X310 with an
> NVIDIA K80 GPU in GNURadio
>
>
>
> Hello LJ,
>
> It would help to know what type of signal processing you are hoping to do
> and how you want to display or save the data. On generally available
> consumer hardware GNU Radio has been shown to be able to handle 800+MS/s of
> samples being displayed in spectrum plots.
>
> It sounds like you are trying to route too much data to your speakers. Are
> you able to share your flowgraph? There is a screenshot function in the
> menu or the grc file could be attached.
>
> Regards,
>
> Derek
>
>
>
>
>
> On Wed, May 2, 2018 at 2:28 PM, Müller, Marcus (CEL) 
> wrote:
>
> Hi LJ Eads,
>
> I'm a bit confused: What has your sound card to do with GNU Radio, or
> the USRP? And how is your sound card comparable to a GPU?
>
> GNU Radio runs on CPUs.
>
> Best regards,
> Marcus
>
>
> On Wed, 2018-05-02 at 13:23 +, Eads, LJ D. wrote:
> > Hello,
> > I just setup a USRP X310 that I plan on using with GNURadio over 10
> gigabit.. I have everything working and functioning properly (drivers and
> all) but my only concern right now is that GNURadio is running off of the
> sound card on my server and not the GPU. GNURadio isn’t able to handle
> practically anything because I am limited by the sound card capability.
> > How would I be able to use the CPU (Sixteen-Core Intel Xeon Processor
> E5-2683 v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU
> Computing Accelerator - 24GB GDDR5 - Passive Cooler) for better
> functionality of the X310?
> >
> > My current error: “gr::log : INFO: audio_alsa_sink0 – [default]: unable
> to support sample rate 50
> > Card requested 192000 instead”
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/
> msg00418.html - This sounds like my issue
> >
> > Thank you,
> > LJ Eads
> >
> >
> > L J Eads
> > The MITRE Corporation
> > (937) 874-7240 (Office)
> > (954) 554-6801 (Mobile)
> > lje...@mitre.org (FFRDC)
> >
>
> > ___
> > 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
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Derek Kozel]

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.00 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.00 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 U).
>
> 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 
> 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 U
>
> 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 <
> 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 

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Eads, LJ D.]

Derek,

Oops! The error was actually from just a simple WBFM Receiver block which has 
the audio sink. No soundcard involved in my setup.
I still don’t think I will be utilizing the GPU though because GNURadio isn’t 
showing up in the GPU processes.. Will I be at least utilizing the CPU? I will 
test the block diagrams I sent you on the server (I just have tested them on my 
laptop initially) and I will get back to you.

Thank you,

LJ Eads

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: Wednesday, May 2, 2018 10:20 AM
To: Eads, LJ D. 
Cc: Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 
GPU in GNURadio

Hi LJ,
I don't see an audio sink in either of those flowgraphs, are those the ones 
causing the error? Is there supposed to be a soundcard involved at any point in 
your setup? To just capture, record, and replay the file sink seems correct (to 
the limits of your hard drive write/read speeds).
Does sending and receiving to/from the USRP work if you use null sink and 
constant source to receive/produce data?
Derek

On Wed, May 2, 2018 at 3:08 PM, Eads, LJ D. 
mailto:lje...@mitre.org>> wrote:
Derek and Marcus,

Thank you for the quick response! This is my first entry to the mailing list.

So I am trying to capture a very fast frequency hopping signal.. the rate is 
proprietary but probably one of the fastest rates on the market right now. I am 
currently just implementing a basic record/replay. I believe you are right that 
I am trying to route too much data to my speakers and that’s what I am trying 
to get out of.

I currently have had better success with the X310 right now using the GNURadio 
Live Environment on a USB and running Cat 5E from the X310 to my laptop.. now 
I’m trying to implement what I had on my laptop on this server that I setup. I 
attached the server specs.. currently using ubuntu 16.04.

Marcus.. I am confused as well! Because I feel like I should be using my CPUs 
and I am not.

LJ Eads

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: Wednesday, May 2, 2018 9:43 AM
To: Müller, Marcus (CEL) mailto:muel...@kit.edu>>
Cc: discuss-gnuradio@gnu.org; Eads, LJ D. 
mailto:lje...@mitre.org>>
Subject: Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 
GPU in GNURadio

Hello LJ,
It would help to know what type of signal processing you are hoping to do and 
how you want to display or save the data. On generally available consumer 
hardware GNU Radio has been shown to be able to handle 800+MS/s of samples 
being displayed in spectrum plots.
It sounds like you are trying to route too much data to your speakers. Are you 
able to share your flowgraph? There is a screenshot function in the menu or the 
grc file could be attached.
Regards,
Derek


On Wed, May 2, 2018 at 2:28 PM, Müller, Marcus (CEL) 
mailto:muel...@kit.edu>> wrote:
Hi LJ Eads,

I'm a bit confused: What has your sound card to do with GNU Radio, or
the USRP? And how is your sound card comparable to a GPU?

GNU Radio runs on CPUs.

Best regards,
Marcus

On Wed, 2018-05-02 at 13:23 +, Eads, LJ D. wrote:
> Hello,
> I just setup a USRP X310 that I plan on using with GNURadio over 10 gigabit.. 
> I have everything working and functioning properly (drivers and all) but my 
> only concern right now is that GNURadio is running off of the sound card on 
> my server and not the GPU. GNURadio isn’t able to handle practically anything 
> because I am limited by the sound card capability.
> How would I be able to use the CPU (Sixteen-Core Intel Xeon Processor E5-2683 
> v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU Computing 
> Accelerator - 24GB GDDR5 - Passive Cooler) for better functionality of the 
> X310?
>
> My current error: “gr::log : INFO: audio_alsa_sink0 – [default]: unable to 
> support sample rate 50
> Card requested 192000 instead”
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00418.html - 
> This sounds like my issue
>
> Thank you,
> LJ Eads
>
>
> L J Eads
> The MITRE Corporation
> (937) 874-7240 (Office)
> (954) 554-6801 (Mobile)
> lje...@mitre.org (FFRDC)
>
> ___
> 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


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Laura Huddleston]

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 
Sent: Wednesday, May 2, 2018 9:30 AM
To: Laura Huddleston 
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Frequency hopping code printing U

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 
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.00 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.00 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 U).

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  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 U

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 som

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[John Ferguson]

Hi LJ,

If you are trying to record data at very high rates, you GNURadio Companion
may not be able to go as high as you want. Maybe your laptop has a fast SSD
and your server has spinning disks? If you are wanting to test the limits
of recording data with GNURadio to see if it works for your proprietary
data rate, I would advise as follows:

1. Enable real-time scheduling and select "No GUI" in the Options block.
See the transport notes on the E310 for how to get this to work by editing
/etc/security/security.conf
2. Assign each block to a specific processor (Core Affinity) in the
Advanced Tab and also increase the buffer size
3. Make sure you have a disk/array that can handle the rate you are trying
to achieve.
4. You may need to adjust the dirty background radio in the kernel. you do
that by editing /etc/sysctl.conf. This is tricky, so you should read up on
how this works.

I've attached a shell script that you can use to modify add real time
scheduling and adjust the kernel parameters. USE AT YOUR OWN RISK AS
MODIFYING KERNEL PARAMETERS CAN BE TRICKY AND HURT YOUR SYSTEM.

As mentioned above, to test the bottleneck, try sending the data to a null
sink. If it works there, then the issue is that your drive isn't fast
enough can keep up.

You are correct that you are not using the GPU. GNU radio does not natively
support GPU processing. We have had success wrapping pycuda into an OOT
modules, and getting good performance. There are better ways, but that
would be easiest to get started. Your GPU will require extra memory copies:

GNU Radio CPU > CUDA CPU > CUDA GPU > CUDA CPU > GNU Radio CPU

So depending on what kind of latency you can handle, this may or may not
work for you. I'm assuming that the GPU question is not directly related to
the recording question.

I hope that helped.

John



On Wed, May 2, 2018 at 10:32 AM, Eads, LJ D.  wrote:

> Derek,
>
>
>
> Oops! The error was actually from just a simple WBFM Receiver block which
> has the audio sink. No soundcard involved in my setup.
>
> I still don’t think I will be utilizing the GPU though because GNURadio
> isn’t showing up in the GPU processes.. Will I be at least utilizing the
> CPU? I will test the block diagrams I sent you on the server (I just have
> tested them on my laptop initially) and I will get back to you.
>
>
>
> Thank you,
>
>
>
> LJ Eads
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Wednesday, May 2, 2018 10:20 AM
> *To:* Eads, LJ D. 
> *Cc:* Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
>
> *Subject:* Re: [Discuss-gnuradio] How do I interface my X310 with an
> NVIDIA K80 GPU in GNURadio
>
>
>
> Hi LJ,
>
> I don't see an audio sink in either of those flowgraphs, are those the
> ones causing the error? Is there supposed to be a soundcard involved at any
> point in your setup? To just capture, record, and replay the file sink
> seems correct (to the limits of your hard drive write/read speeds).
>
> Does sending and receiving to/from the USRP work if you use null sink and
> constant source to receive/produce data?
>
> Derek
>
>
>
> On Wed, May 2, 2018 at 3:08 PM, Eads, LJ D.  wrote:
>
> Derek and Marcus,
>
>
>
> Thank you for the quick response! This is my first entry to the mailing
> list.
>
>
>
> So I am trying to capture a very fast frequency hopping signal.. the rate
> is proprietary but probably one of the fastest rates on the market right
> now. I am currently just implementing a basic record/replay. I believe you
> are right that I am trying to route too much data to my speakers and that’s
> what I am trying to get out of.
>
>
>
> I currently have had better success with the X310 right now using the
> GNURadio Live Environment on a USB and running Cat 5E from the X310 to my
> laptop.. now I’m trying to implement what I had on my laptop on this server
> that I setup. I attached the server specs.. currently using ubuntu 16.04.
>
>
>
> Marcus.. I am confused as well! Because I feel like I should be using my
> CPUs and I am not.
>
>
>
> LJ Eads
>
>
>
> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Wednesday, May 2, 2018 9:43 AM
> *To:* Müller, Marcus (CEL) 
> *Cc:* discuss-gnuradio@gnu.org; Eads, LJ D. 
> *Subject:* Re: [Discuss-gnuradio] How do I interface my X310 with an
> NVIDIA K80 GPU in GNURadio
>
>
>
> Hello LJ,
>
> It would help to know what type of signal processing you are hoping to do
> and how you want to display or save the data. On generally available
> consumer hardware GNU Radio has been shown to be able to handle 800+MS/s of
> samples being displayed in spectrum plots.
>
> It sounds like you are trying to route too much data to your speakers. Are
> you able to share your flowgraph? There is a screenshot function in the
> menu or the grc file could be attached.
>
> Regards,
>
> Derek
>
>
>
>
>
> On Wed, May 2, 2018 at 2:28 PM, Müller, Marcus (CEL) 
> wrote:
>
> Hi LJ Eads,
>
> I'm a bit confused: What has your sound card to do with GNU Radio, or
> the USRP? And how is your soun

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Eads, LJ D.]

Thanks John,

I will definitely look into this.. I just did a record test on the server 
recording 20 MHz BW and I was only pulling 2% from the CPU so I think that is 
promising. But yes my goal is to record data at very high rates. Thank you!

By the way this thing looks amazing.. We will have to get one:
https://docs.wixstatic.com/ugd/07a03a_bf1ffbe54e0e4fd698485c8c0471a2e4.pdf

LJ Eads

From: John Ferguson [mailto:j...@deepwavedigital.com]
Sent: Wednesday, May 2, 2018 10:57 AM
To: Eads, LJ D. 
Cc: Derek Kozel ; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 
GPU in GNURadio

Hi LJ,

If you are trying to record data at very high rates, you GNURadio Companion may 
not be able to go as high as you want. Maybe your laptop has a fast SSD and 
your server has spinning disks? If you are wanting to test the limits of 
recording data with GNURadio to see if it works for your proprietary data rate, 
I would advise as follows:

1. Enable real-time scheduling and select "No GUI" in the Options block. See 
the transport notes on the E310 for how to get this to work by editing 
/etc/security/security.conf
2. Assign each block to a specific processor (Core Affinity) in the Advanced 
Tab and also increase the buffer size
3. Make sure you have a disk/array that can handle the rate you are trying to 
achieve.
4. You may need to adjust the dirty background radio in the kernel. you do that 
by editing /etc/sysctl.conf. This is tricky, so you should read up on how this 
works.

I've attached a shell script that you can use to modify add real time 
scheduling and adjust the kernel parameters. USE AT YOUR OWN RISK AS MODIFYING 
KERNEL PARAMETERS CAN BE TRICKY AND HURT YOUR SYSTEM.

As mentioned above, to test the bottleneck, try sending the data to a null 
sink. If it works there, then the issue is that your drive isn't fast enough 
can keep up.

You are correct that you are not using the GPU. GNU radio does not natively 
support GPU processing. We have had success wrapping pycuda into an OOT 
modules, and getting good performance. There are better ways, but that would be 
easiest to get started. Your GPU will require extra memory copies:

GNU Radio CPU > CUDA CPU > CUDA GPU > CUDA CPU > GNU Radio CPU

So depending on what kind of latency you can handle, this may or may not work 
for you. I'm assuming that the GPU question is not directly related to the 
recording question.

I hope that helped.

John



On Wed, May 2, 2018 at 10:32 AM, Eads, LJ D. 
mailto:lje...@mitre.org>> wrote:
Derek,

Oops! The error was actually from just a simple WBFM Receiver block which has 
the audio sink. No soundcard involved in my setup.
I still don’t think I will be utilizing the GPU though because GNURadio isn’t 
showing up in the GPU processes.. Will I be at least utilizing the CPU? I will 
test the block diagrams I sent you on the server (I just have tested them on my 
laptop initially) and I will get back to you.

Thank you,

LJ Eads

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: Wednesday, May 2, 2018 10:20 AM
To: Eads, LJ D. mailto:lje...@mitre.org>>
Cc: Müller, Marcus (CEL) mailto:muel...@kit.edu>>; 
discuss-gnuradio@gnu.org

Subject: Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 
GPU in GNURadio

Hi LJ,
I don't see an audio sink in either of those flowgraphs, are those the ones 
causing the error? Is there supposed to be a soundcard involved at any point in 
your setup? To just capture, record, and replay the file sink seems correct (to 
the limits of your hard drive write/read speeds).
Does sending and receiving to/from the USRP work if you use null sink and 
constant source to receive/produce data?
Derek

On Wed, May 2, 2018 at 3:08 PM, Eads, LJ D. 
mailto:lje...@mitre.org>> wrote:
Derek and Marcus,

Thank you for the quick response! This is my first entry to the mailing list.

So I am trying to capture a very fast frequency hopping signal.. the rate is 
proprietary but probably one of the fastest rates on the market right now. I am 
currently just implementing a basic record/replay. I believe you are right that 
I am trying to route too much data to my speakers and that’s what I am trying 
to get out of.

I currently have had better success with the X310 right now using the GNURadio 
Live Environment on a USB and running Cat 5E from the X310 to my laptop.. now 
I’m trying to implement what I had on my laptop on this server that I setup. I 
attached the server specs.. currently using ubuntu 16.04.

Marcus.. I am confused as well! Because I feel like I should be using my CPUs 
and I am not.

LJ Eads

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: Wednesday, May 2, 2018 9:43 AM
To: Müller, Marcus (CEL) mailto:muel...@kit.edu>>
Cc: discuss-gnuradio@gnu.org; Eads, LJ D. 
mailto:lje...@mitre.org>>
Subject: Re: [Discuss-gnur

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Michael Piscopo]

Hi LJ,

Adding to John's recommendations if you have your heart set on the GPU,
check out https://github.com/ghostop14/gr-clenabled.  It's an OOT module
focused on GPU acceleration of many of the core GNURadio blocks.  But as
John mentioned every memcpy to/from the GPU pays a performance hit which in
some cases makes the CPU versions run faster.  Anything with trig or log
functions tend to run faster on the GPU, basic math tends to be faster on
the CPU (it finishes calculations before the first memcpy to the GPU even
finishes).  There's a full performance study doc in the docs directory for
gr-clenabled that'll help you see which ones may be beneficial and I highly
recommend reviewing before dropping on GPU blocks on a flowgraph.  At
really high speeds the CPU does get to be a bottleneck so if there's any
way to reduce the data rates in the FPGA (RFNoC or custom) prior to hitting
the CPU like initial decimating filters that might help your performance
too.

Mike


On Wed, May 2, 2018 at 10:56 AM, John Ferguson 
wrote:

> Hi LJ,
>
> If you are trying to record data at very high rates, you GNURadio
> Companion may not be able to go as high as you want. Maybe your laptop has
> a fast SSD and your server has spinning disks? If you are wanting to test
> the limits of recording data with GNURadio to see if it works for your
> proprietary data rate, I would advise as follows:
>
> 1. Enable real-time scheduling and select "No GUI" in the Options block.
> See the transport notes on the E310 for how to get this to work by editing
> /etc/security/security.conf
> 2. Assign each block to a specific processor (Core Affinity) in the
> Advanced Tab and also increase the buffer size
> 3. Make sure you have a disk/array that can handle the rate you are trying
> to achieve.
> 4. You may need to adjust the dirty background radio in the kernel. you do
> that by editing /etc/sysctl.conf. This is tricky, so you should read up on
> how this works.
>
> I've attached a shell script that you can use to modify add real time
> scheduling and adjust the kernel parameters. USE AT YOUR OWN RISK AS
> MODIFYING KERNEL PARAMETERS CAN BE TRICKY AND HURT YOUR SYSTEM.
>
> As mentioned above, to test the bottleneck, try sending the data to a null
> sink. If it works there, then the issue is that your drive isn't fast
> enough can keep up.
>
> You are correct that you are not using the GPU. GNU radio does not
> natively support GPU processing. We have had success wrapping pycuda into
> an OOT modules, and getting good performance. There are better ways, but
> that would be easiest to get started. Your GPU will require extra memory
> copies:
>
> GNU Radio CPU > CUDA CPU > CUDA GPU > CUDA CPU > GNU Radio CPU
>
> So depending on what kind of latency you can handle, this may or may not
> work for you. I'm assuming that the GPU question is not directly related to
> the recording question.
>
> I hope that helped.
>
> John
>
>
>
> On Wed, May 2, 2018 at 10:32 AM, Eads, LJ D.  wrote:
>
>> Derek,
>>
>>
>>
>> Oops! The error was actually from just a simple WBFM Receiver block which
>> has the audio sink. No soundcard involved in my setup.
>>
>> I still don’t think I will be utilizing the GPU though because GNURadio
>> isn’t showing up in the GPU processes.. Will I be at least utilizing the
>> CPU? I will test the block diagrams I sent you on the server (I just have
>> tested them on my laptop initially) and I will get back to you.
>>
>>
>>
>> Thank you,
>>
>>
>>
>> LJ Eads
>>
>>
>>
>> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
>> *Sent:* Wednesday, May 2, 2018 10:20 AM
>> *To:* Eads, LJ D. 
>> *Cc:* Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
>>
>> *Subject:* Re: [Discuss-gnuradio] How do I interface my X310 with an
>> NVIDIA K80 GPU in GNURadio
>>
>>
>>
>> Hi LJ,
>>
>> I don't see an audio sink in either of those flowgraphs, are those the
>> ones causing the error? Is there supposed to be a soundcard involved at any
>> point in your setup? To just capture, record, and replay the file sink
>> seems correct (to the limits of your hard drive write/read speeds).
>>
>> Does sending and receiving to/from the USRP work if you use null sink and
>> constant source to receive/produce data?
>>
>> Derek
>>
>>
>>
>> On Wed, May 2, 2018 at 3:08 PM, Eads, LJ D.  wrote:
>>
>> Derek and Marcus,
>>
>>
>>
>> Thank you for the quick response! This is my first entry to the mailing
>> list.
>>
>>
>>
>> So I am trying to capture a very fast frequency hopping signal.. the rate
>> is proprietary but probably one of the fastest rates on the market right
>> now. I am currently just implementing a basic record/replay. I believe you
>> are right that I am trying to route too much data to my speakers and that’s
>> what I am trying to get out of.
>>
>>
>>
>> I currently have had better success with the X310 right now using the
>> GNURadio Live Environment on a USB and running Cat 5E from the X310 to my
>> laptop.. now I’m trying to implement what I had on my laptop on this

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[Nick Foster]

Just to provide further clarification:

If you are recording to disk, your bottleneck is *not* the CPU, nor the
GPU, nor the RAM bandwidth. Your bottleneck is the disk. The K80 is a very
nice GPU, but CUDA will not help in your application.

Your flowgraph (pasted above) is doing effectively no processing at all.
It's simply receiving samples from the X310, converting them from fixed to
floating point, and writing them to disk.

20Msps of bandwidth with 8-bit complex samples works out to 40MB/s write
speed. With 16-bit complex samples, 80MB/s. Start spec'ing SSDs that will
handle the required write rate continuously, or content yourself with
writing shorter bursts to a tmpfs partition.

You'll find GPU processing will start to help when you have a block that
has a very high ratio of required cycles to sample rate. Otherwise, as
mentioned above, you'll spend more time copying data into and out of the
GPU than the GPU will spend processing it. Good candidates for GPU blocks
are low-rate block codes, extremely long filters, or channelizers.

Nick

On Wed, May 2, 2018 at 8:56 AM Michael Piscopo 
wrote:

> Hi LJ,
>
> Adding to John's recommendations if you have your heart set on the GPU,
> check out https://github.com/ghostop14/gr-clenabled.  It's an OOT module
> focused on GPU acceleration of many of the core GNURadio blocks.  But as
> John mentioned every memcpy to/from the GPU pays a performance hit which in
> some cases makes the CPU versions run faster.  Anything with trig or log
> functions tend to run faster on the GPU, basic math tends to be faster on
> the CPU (it finishes calculations before the first memcpy to the GPU even
> finishes).  There's a full performance study doc in the docs directory for
> gr-clenabled that'll help you see which ones may be beneficial and I highly
> recommend reviewing before dropping on GPU blocks on a flowgraph.  At
> really high speeds the CPU does get to be a bottleneck so if there's any
> way to reduce the data rates in the FPGA (RFNoC or custom) prior to hitting
> the CPU like initial decimating filters that might help your performance
> too.
>
> Mike
>
>
> On Wed, May 2, 2018 at 10:56 AM, John Ferguson 
> wrote:
>
>> Hi LJ,
>>
>> If you are trying to record data at very high rates, you GNURadio
>> Companion may not be able to go as high as you want. Maybe your laptop has
>> a fast SSD and your server has spinning disks? If you are wanting to test
>> the limits of recording data with GNURadio to see if it works for your
>> proprietary data rate, I would advise as follows:
>>
>> 1. Enable real-time scheduling and select "No GUI" in the Options block.
>> See the transport notes on the E310 for how to get this to work by editing
>> /etc/security/security.conf
>> 2. Assign each block to a specific processor (Core Affinity) in the
>> Advanced Tab and also increase the buffer size
>> 3. Make sure you have a disk/array that can handle the rate you are
>> trying to achieve.
>> 4. You may need to adjust the dirty background radio in the kernel. you
>> do that by editing /etc/sysctl.conf. This is tricky, so you should read up
>> on how this works.
>>
>> I've attached a shell script that you can use to modify add real time
>> scheduling and adjust the kernel parameters. USE AT YOUR OWN RISK AS
>> MODIFYING KERNEL PARAMETERS CAN BE TRICKY AND HURT YOUR SYSTEM.
>>
>> As mentioned above, to test the bottleneck, try sending the data to a
>> null sink. If it works there, then the issue is that your drive isn't fast
>> enough can keep up.
>>
>> You are correct that you are not using the GPU. GNU radio does not
>> natively support GPU processing. We have had success wrapping pycuda into
>> an OOT modules, and getting good performance. There are better ways, but
>> that would be easiest to get started. Your GPU will require extra memory
>> copies:
>>
>> GNU Radio CPU > CUDA CPU > CUDA GPU > CUDA CPU > GNU Radio CPU
>>
>> So depending on what kind of latency you can handle, this may or may not
>> work for you. I'm assuming that the GPU question is not directly related to
>> the recording question.
>>
>> I hope that helped.
>>
>> John
>>
>>
>>
>> On Wed, May 2, 2018 at 10:32 AM, Eads, LJ D.  wrote:
>>
>>> Derek,
>>>
>>>
>>>
>>> Oops! The error was actually from just a simple WBFM Receiver block
>>> which has the audio sink. No soundcard involved in my setup.
>>>
>>> I still don’t think I will be utilizing the GPU though because GNURadio
>>> isn’t showing up in the GPU processes.. Will I be at least utilizing the
>>> CPU? I will test the block diagrams I sent you on the server (I just have
>>> tested them on my laptop initially) and I will get back to you.
>>>
>>>
>>>
>>> Thank you,
>>>
>>>
>>>
>>> LJ Eads
>>>
>>>
>>>
>>> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
>>> *Sent:* Wednesday, May 2, 2018 10:20 AM
>>> *To:* Eads, LJ D. 
>>> *Cc:* Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
>>>
>>> *Subject:* Re: [Discuss-gnuradio] How do I interface my X310 with an
>>> NVIDIA K80 GPU

Re: [Discuss-gnuradio] [PyBOMBS] TypeError: cannot use a string pattern on a bytes-like object

[Martin Braun]

Are you using Python 3?

-- M

On 02/12/2018 03:46 PM, Álvaro Cebrián Juan wrote:
> Hello everyone,
> 
> I was following these instructions
> 
> to install some dependencies using PyBOMBS, but when I add a list of
> default recipes wit|h the command:
> 
> $ pybombs recipes add-defaults |
> 
> I get the following error:
> 
> star@galaxy:~$ pybombs recipes add-defaults
> PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
> Traceback (most recent call last):
>   File "/usr/local/bin/pybombs", line 11, in 
>     load_entry_point('PyBOMBS==2.3.3a0', 'console_scripts', 'pybombs')()
>   File "/usr/local/lib/python3.5/dist-packages/pybombs/main.py", line
> 32, in main
>     return dispatch() or 0
>   File
> "/usr/local/lib/python3.5/dist-packages/pybombs/commands/base.py", line
> 194, in dispatch
>     return get_cmd_dict(cmd_list)[args.command](cmd=args.command,
> args=args).run()
>   File
> "/usr/local/lib/python3.5/dist-packages/pybombs/commands/base.py", line
> 120, in run
>     return self.subcommands[self.args.sub_command]['run'](self)()
>   File
> "/usr/local/lib/python3.5/dist-packages/pybombs/commands/recipes.py",
> line 180, in run_add_defaults
>     if not self.add_recipe_dir(alias, uri):
>   File
> "/usr/local/lib/python3.5/dist-packages/pybombs/commands/recipes.py",
> line 347, in add_recipe_dir
>     Fetcher().fetch_url(uri, recipe_cache_top_level, alias, {}) # No args
>   File "/usr/local/lib/python3.5/dist-packages/pybombs/fetcher.py", line
> 73, in fetch_url
>     result = fetcher.fetch_url(url, dest, dirname, args)
>   File "/usr/local/lib/python3.5/dist-packages/pybombs/fetchers/git.py",
> line 81, in fetch_url
>     git_version = get_git_version()
>   File "/usr/local/lib/python3.5/dist-packages/pybombs/fetchers/git.py",
> line 56, in get_git_version
>     subprocess.check_output(['git', '--version'])
>   File "/usr/lib/python3.5/re.py", line 173, in search
>     return _compile(pattern, flags).search(string)
> TypeError: cannot use a string pattern on a bytes-like object
> 
> I would be grateful if somebody can shed some light on the cause of this
> error and on its possible solutions.
> 
> Best regards,
> 
> Álvaro
> 
> 
> ___
> 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

Re: [Discuss-gnuradio] Build failing on Ubuntu 18.04

[Martin Braun]

On 04/28/2018 07:43 PM, Anshul Thakur wrote:
> Hi all,
> 
> I just finished installing Ubuntu 18.04 on one of my systems and tried
> installing GNURadio using pybombs. The build seems to be misbehaving and
> isn't fully unattended.
> 
> Mine is an x86_64 machine.
> 
> 1. UHD: For some reason, cmake starts to use 'pthreads' instead of
> 'pthread' and the system cannot find it. Commented it out of the recipe
> as I won't be using a UHD device for now.

Wearing my Ettus hat here,

we still need to verify UHD on 18.04 (But it seems like you're not in
urgent need for it anyway).
We're on it!

Cheers,
Martin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] coding problem

[Martin Braun]

On 04/25/2018 03:11 AM, 김무연 wrote:
> Mostly I just followed the way on the internet
> My goal is using 'for' structure and comparing the power
> So save the highest power in pow and send 1
> if not sustain the previous highest power value and send 0
> So my problem is pow does not save the value for running time
> It just save the value for sometimes
> If pow saves the renewed power values from some time it keeps sending 0
> but it doesn't
> So are there any way to prolong the noutput_items?
> Please let me know

Store the power in a class variable inside your block.

-- M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with Pybombs installation

[Martin Braun]

On 04/25/2018 01:42 AM, Sumit Kumar wrote:
> *Qn-2 When installing using pybombs can I choose uhd version. I believe
> it is using 3.10 but I need 3.009.003 *

Sure:

$ pybombs config --package uhd gitbranch UHD-3.9.LTS

-- M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Acquisition detection threshold for Galileo E1 signals

[Martin Braun]

On 04/24/2018 05:13 AM, PRIYANKA PRIYADARSHINI wrote:
> Hello All,
> 
> I have done Galileo E1B signal acquisition and now I want to set a
> threshold so that my correlation peak of  acquisition is compared to the
> threshold value set by me and gives an output of successful or
> unsuccessful acquisition.
> 
> So, I need to know if there is any typical value of threshold for
> Galileo Signal acquisition of it varies from case to case and needs to
> computed for every particular case?
> 
> Thanks,
> Priyanka

Priyanka,

it even depends on the specific setup that you have, so I doubt you'll
get useful responses here. It really depends what you're trying to do.

Cheers,
Martin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Block to Load Taps From File

[Martin Braun]

On 04/21/2018 09:07 AM, Maximilian Stiefel wrote:
> Hello everybody,
> 
> it is as far as I know not that convenient to import taps from a filter
> design file to a design in grc.
> 
> On stackoverflow it was mentioned, that there is apparently a
> workarround using numpy.fromfile('filename'):
> 
> https://stackoverflow.com/questions/36744843/passing-taps-to-the-filter-using-file-in-gnuradio#36771263
> 
> 
> However, this did not work for me, because numpy wants, so it seems, a
> plain csv file with the tap values. For this reason, I wrote a small
> block and pushed it to my fork to make it more convenient to just use
> the taps created with the gorgeous gr filter design tool. The block
> allows the following convenient work-flow:
> 
> Filter Design -> Save to File -> Add File Taps Loader block to grc
> design and by that import taps into grc design -> Change filter design
> in design tool -> Taps are automatically up-to-date.
> 
> https://github.com/m3x1m0m/gnuradio/blob/file_taps_loader/gr-blocks/python/blocks/file_taps_loader.py
> 
> 
> https://github.com/m3x1m0m/gnuradio/blob/file_taps_loader/gr-blocks/python/blocks/qa_file_taps_loader.py
> 
> 
> https://github.com/m3x1m0m/gnuradio/blob/file_taps_loader/gr-blocks/grc/blocks_file_taps_loader.xml
> 
> 
> Is this of any interest for others?

I think anything that makes loading filter taps easier is a great idea.
For the record, Maximilian has also posted this on github:
https://github.com/gnuradio/gnuradio/issues/1746

As well as a PR: https://github.com/gnuradio/gnuradio/pull/1753

Jeff and Andrej have already commented -- please join the review if
you're interested!

> 
> Also, I was for some reason not able to force the block being integrated
> into the section "File Operators". How is this done?

You should just need to put it here:
https://github.com/gnuradio/gnuradio/blob/5d63762a6431ecf0fa5f2d1db1222a1f71b180a7/gr-blocks/grc/blocks_block_tree.xml#L71-L82

Does that not work?

-- M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unused Message port in 'Chunks to Symbols' block?

[Martin Braun]

On 04/18/2018 02:28 AM, Müller, Marcus (CEL) wrote:
> a. Sounds reasonable.
> b. I haven't checked the chunks_to_symbols_bc source code, but it's
> quite possible that whoever added that message port simply didn't add
> the GUI definition to the XML file. A pull request that changes that
> would be utmost welcome!

I would like to also thank Anshul for actually submitting that PR!

Cheers,
Martin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Hunting for DMR issue with gnuradio?

[Ralph A. Schmid, dk5ras]

Hi all,

Not 100% on-topic, but maybe I am not the only one with such problems. 

I am member of a small team that operates a world-wide DMR ham radio network
(BrandMeister, http://brandmeister.network, and I belong to the German
http://bm262.de guys), and we are hunting down (at least we try) an issue
with talker alias and embedded data transmission. Motorola radios sometimes
lose the voice sync when such data are sent - but it only happens on Hytera
repeaters.

Now the idea is, we know the network data stream (as we create it on our
servers), and at least we are convinced that we follow the specs, so
possibly the Hytera repeater alter it before transmitting the stream - thus
we need to monitor the air interface.

I know that solutions like dsd do exist, but before we step deeper into this
- has anybody here some experience with diving deeper into the DMR CAI,
using free tools? We are not commercial, so we do not have any test
equipment for digital radio, but we have gnuradio, have SDRs... What would
be quite useful is logging superframes and frames with their headers, LC,
voice headers...

Any input is highly welcome and may help making our community driven DMR
radio network better!

Thanks in advance, and with best regards

Ralph, dk5ras. 




--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio