Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

2014-12-31 Thread Ralph A. Schmid, dk5ras
The fix worked out :) Thanks a lot!

Ralph.

-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, December 30, 2014 17:01
To: 'Johnathan Corgan'; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

Waaah - and I was so sure that the problem sits in front of the PC :) Well,
at least I had a task during a longer and boring trip by train...

OK, so I will wait for the next commit. Thank you for all the efforts!!

Ralph.

-Original Message-
From: Johnathan Corgan [mailto:johnat...@corganlabs.com]
Sent: Tuesday, December 30, 2014 16:26
To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

 Old Signed by an unverified key: 2014-12-30 at 16:25:35

On 12/30/2014 06:37 AM, Ralph A. Schmid, dk5ras wrote:

 I installed gnuradio master from source on a Kubuntu 14.04 64 bit 
 system, and it appears that all wxgui stuff does not work. What may be 
 the issue here? Gnuradio and uhd build without error, without missing 
 features, but for example uhd_fft gives this output:

This is indeed a bug, an unfortunate side effect of a semi-last minute
commit before the 3.7.6 release.

Fortunately, it's a one line bug fix I'll be committing to the repository
shortly.

--
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services http://corganlabs.com

* Johnathan Corgan johnat...@corganlabs.com
* 0x671DA2F7 - Unverified


___
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] Slow GUI in GRC

2014-12-31 Thread khalid.el-darymli
Hi,

We recently bought a new machine with like 4 GHz processor, 16 GB of RAM.
For the graphic card, we use the Radeon R7 250 1000 MHz GDDR5.

Latest version of Ubuntu (14.04 LTS) was installed along with GNU Radio
built from the source. Everything seems to be installed just fine. However,
when trying to use GNU Radio Companion (GRC), the GUI's are so slow. Every
time I try to place in or move the blocks in GRC, the whole GUI stuck for a
while and it gets so slow. Because of this, I am not able to run GRC.


Prior to this, GRC used to work just fine on another machine with a much
lower specs for the RAM and the processor but with RS880 [Radeon HD 4200]
graphic card.


What is the cause for this problem and how to fix it? Could it be the new
graphic card (Radeon R7 250 GDDR5)?

Thank you.

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


[Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

2014-12-31 Thread Andy Walls
Hi.

Can someone give me a brief clue about the threshold testing in the
correlate_and_sync block?

In the constructor:

  for(size_t i=0; i  d_symbols.size(); i++)
corr += abs(d_symbols[i]*conj(d_symbols[i]));
  d_thresh = 0.9*corr*corr;

corr looks like the value (at offset 0) of the discrete autocorrelation
of the matched filter.

d_thresh looks like 90% of the value of the autocorrelation of the
matched filter squared.

So far this makes sense to me. 


Then in the work function (corr is a totally different array variable
here):

  // Calculate the correlation with the known symbol
  d_filter-filter(noutput_items, in, corr);

  // Find the magnitude squared of the correlation
  std::vectorfloat corr_mag(noutput_items);
  volk_32fc_magnitude_squared_32f(corr_mag[0], corr, noutput_items);

  int i = d_sps;
  while(i  noutput_items) {
if((corr_mag[i] - corr_mag[i-d_sps])  d_thresh) {

This if test confuses me slightly.  We check to see if the value of
the output of the matched filtering has crossed the threshold relative
to one symbol previous?  Why not just check relative to 0?

Regards,
Andy




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


Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

2014-12-31 Thread Andy Walls
On Wed, 2014-12-31 at 14:00 -0500, Andy Walls wrote:
 Hi.
 
 Can someone give me a brief clue about the threshold testing in the
 correlate_and_sync block?
 
 In the constructor:
 
   for(size_t i=0; i  d_symbols.size(); i++)
 corr += abs(d_symbols[i]*conj(d_symbols[i]));
   d_thresh = 0.9*corr*corr;
 
 corr looks like the value (at offset 0) of the discrete autocorrelation
 of the matched filter.
 
 d_thresh looks like 90% of the value of the autocorrelation of the
 matched filter squared.
 
 So far this makes sense to me. 
 
 
 Then in the work function (corr is a totally different array variable
 here):
 
   // Calculate the correlation with the known symbol
   d_filter-filter(noutput_items, in, corr);
 
   // Find the magnitude squared of the correlation
   std::vectorfloat corr_mag(noutput_items);
   volk_32fc_magnitude_squared_32f(corr_mag[0], corr, noutput_items);
 
   int i = d_sps;
   while(i  noutput_items) {
 if((corr_mag[i] - corr_mag[i-d_sps])  d_thresh) {
 
 This if test confuses me slightly.  We check to see if the value of
 the output of the matched filtering has crossed the threshold relative
 to one symbol previous?  Why not just check relative to 0?


An additional note: The if test doesn't work too well, if the preamble
sequence is 101010101010..., since then the correlation will have
peaks at the symbol spacing, d_sps.  Maybe 

if((corr_mag[i] - corr_mag[i-d_sps/2])  d_thresh) {

would be better, since the correlation should sag at the half symbol?

Regards,
Andy





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