Re: [Discuss-gnuradio] More dumpeths

[Josh Blum]

On 04/14/2012 01:38 PM, Johnathan Corgan wrote:
> On Sat, Apr 14, 2012 at 13:30, Marcus D. Leech  wrote:
> 
>>> Please try commit c787fb66, which is the merge on the former 'next'
>>> branch of a PMT library modification (this is one of the ones that
>>> failed in trellis for you, hopefully you can make it work.)
>>>
>> This commit fails.  But I had to roll-back to an older version of UHD to get
>> it to build.  Still failed though.
>>
>>
>>> If this last fails, please try branch 'test/undo-pmt-deleter', which
>>> I've pushed to the main gnuradio repository.
>>>
>> That works. No segfaults on exit.
> 
> Excellent, thanks.  As this is in the 3.5.3 release, I'm going to
> rebase this 'fix' off the last 3.5.3 maint, but hold off merging it.
> I'm hoping Josh can supply an actual fix soon so we don't have to take
> that functionality out altogether.
> 

Maybe its deleting itself: http://pastebin.com/XMSxLJk5

-Josh

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

[Discuss-gnuradio] First try with RTL2832

[Farhad Abdolian]

Hi folks,
Yesterday after a long wait I received my DVB-T unit in the mail (it arrived on 
my birthday). After some initial work, I got it to work with GNU Radio and GRC 
and today I made my first working FM receiver using the same blocks as the 
video from Ettus Research (building GR FM Radio in 10 minutes).

The design is using the Linux driver and the GR blocks made by Balint Seeber 
(thanks a million mate).

I have attached the GRC with this e-mail, hope you find it useful. I am now 
going to work on the RTL2832 block to fine tune it (I have the complete 
datasheet) and add more feature to it. 

The problem I have is that the signals are not very strong, no matter how much 
I change the gain, the signal level is pretty low and the received audio is 
pretty noisy. I have managed to sample at 2Msps without any problems but when I 
sample more than that on my laptop, I get a lot of overflow.

I keep you posted on my progress, this is really exciting :)

Best regards,
Farhad




>
> From: Josh Blum 
>To: Johnathan Corgan  
>Cc: "Discuss-gnuradio@gnu.org"  
>Sent: Sunday, April 15, 2012 9:08 AM
>Subject: Re: [Discuss-gnuradio] More dumpeths
> 
>
>
>On 04/14/2012 01:38 PM, Johnathan Corgan wrote:
>> On Sat, Apr 14, 2012 at 13:30, Marcus D. Leech  wrote:
>> 
 Please try commit c787fb66, which is the merge on the former 'next'
 branch of a PMT library modification (this is one of the ones that
 failed in trellis for you, hopefully you can make it work.)

>>> This commit fails.  But I had to roll-back to an older version of UHD to get
>>> it to build.  Still failed though.
>>>
>>>
 If this last fails, please try branch 'test/undo-pmt-deleter', which
 I've pushed to the main gnuradio repository.

>>> That works. No segfaults on exit.
>> 
>> Excellent, thanks.  As this is in the 3.5.3 release, I'm going to
>> rebase this 'fix' off the last 3.5.3 maint, but hold off merging it.
>> I'm hoping Josh can supply an actual fix soon so we don't have to take
>> that functionality out altogether.
>> 
>
>Maybe its deleting itself: http://pastebin.com/XMSxLJk5
>
>-Josh
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>

fm_rx_rtl2832.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First try with RTL2832

[Alexandru Csete]

On Sun, Apr 15, 2012 at 10:50 AM, Farhad Abdolian 
wrote:
> Hi folks,
> Yesterday after a long wait I received my DVB-T unit in the mail (it
arrived
> on my birthday). After some initial work, I got it to work with GNU Radio
> and GRC and today I made my first working FM receiver using the same
blocks
> as the video from Ettus Research (building GR FM Radio in 10 minutes).
>
> The design is using the Linux driver and the GR blocks made by Balint
Seeber
> (thanks a million mate).
>
> I have attached the GRC with this e-mail, hope you find it useful. I am
now
> going to work on the RTL2832 block to fine tune it (I have the complete
> datasheet) and add more feature to it.
> The problem I have is that the signals are not very strong, no matter how
> much I change the gain, the signal level is pretty low and the received
> audio is pretty noisy. I have managed to sample at 2Msps without any
> problems but when I sample more than that on my laptop, I get a lot of
> overflow.

Hi Farhad,

As you may have seen in my on air tests I just
posted,
I have no problem with low signal levels, however, there is an active
hardware AGC which may be causing you troubles. If you have a strong signal
in the analog passband of the tuner it will drive the gain down and the
weaker signal you are trying to receive will become noisy. You can see that
in all 3 videos which show an EzCAP666 with E4000 tuner in action.

I don't know if this AGC is in the RTL chip or the E4000 tuner. I suspect
it is in the tuner.

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

[Discuss-gnuradio] Build 3.5.3 fails linking gr-fcd (undefined reference to `clock_gettime')

[Barry Jackson]

Could anyone please help me resolve this.

CMakeFiles/gnuradio-fcd.dir/hid/hid-libusb.c.o: In function 
`hid_read_timeout':
/home/baz/BLD/CO9a/gnuradio/BUILD/gnuradio-3.5.3/gr-fcd/lib/hid/hid-libusb.c:990: 
undefined reference to `clock_gettime'

collect2: ld returned 1 exit status
make[2]: *** [gr-fcd/lib/libgnuradio-fcd-3.5.3.so.0.0.0] Error 1

I am building from from git tag v3.5.3. with cmake, make.

I have patched hid-libusb.c to add:-
#include 
...with no change.

Is there a new build require that I am missing?
I currently have the BRs that were needed for 3.5.1 in the spec file. as 
I am updating our distro package from 3.5.1.


Thanks
Barry

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

[Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

Hello, I'm getting the invalid opcode exception whenever the volk
library is used from gr/grc. It is also easy to reproduce by executing
volk_profile:

[user@rflab gnuradio]$ volk_profile
Using Volk machine: avx_64
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
Illegal instruction
[user@rflab gnuradio]$ dmesg
[ 6920.211094] volk_profile[25627] trap invalid opcode ip:7f8145b74d40
sp:7fff41dfac78 error:0 in libvolk.so.0.0.0[7f8145ad7000+cf000]

I tried v3.5.2 and v3.5.2 build directly from git, using the building
script from here:

http://gnuradio.org/redmine/repositories/changes/gnuradio/README

Here's my cpuinfo:

[user@rflab gnuradio]$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
stepping: 7
cpu MHz : 2591.660
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 1
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2
ss ht syscall nx lm constant_tsc nopl aperfmperf pni pclmulqdq ssse3
cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat epb pln
pts dts
bogomips: 5183.32
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

(and repeated 3x times for the other cores).

And, FWIW, this is the autoconfig snippet:

-- Configuring volk support...
--   Enabling volk support.
--   Override with -DENABLE_VOLK=ON/OFF
-- Boost version: 1.46.0
-- Found the following Boost libraries:
--   unit_test_framework
-- checking for module 'orc-0.4'
--   found orc-0.4, version 0.4.16
-- Found ORC: /usr/lib64/liborc-0.4.so
-- Check size of void*
-- Check size of void* - done
-- Performing Test have_maltivec
-- Performing Test have_maltivec - Failed
-- Performing Test have_mfpu=neon
-- Performing Test have_mfpu=neon - Failed
-- Performing Test have_mfloat-abi=softfp
-- Performing Test have_mfloat-abi=softfp - Failed
-- Performing Test have_funsafe-math-optimizations
-- Performing Test have_funsafe-math-optimizations - Success
-- 32 overruled
-- Performing Test have_m64
-- Performing Test have_m64 - Success
-- Performing Test have_m3dnow
-- Performing Test have_m3dnow - Success
-- Performing Test have_msse4.2
-- Performing Test have_msse4.2 - Success
-- Performing Test have_mpopcnt
-- Performing Test have_mpopcnt - Success
-- Performing Test have_mmmx
-- Performing Test have_mmmx - Success
-- Performing Test have_msse
-- Performing Test have_msse - Success
-- Performing Test have_msse2
-- Performing Test have_msse2 - Success
-- Performing Test have_lorc-0.4
-- Performing Test have_lorc-0.4 - Success
-- Performing Test have_msse3
-- Performing Test have_msse3 - Success
-- Performing Test have_mssse3
-- Performing Test have_mssse3 - Success
-- Performing Test have_msse4a
-- Performing Test have_msse4a - Success
-- Performing Test have_msse4.1
-- Performing Test have_msse4.1 - Success
-- Performing Test have_mavx
-- Performing Test have_mavx - Success
-- Available arches:
generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
-- Available machines:
generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64;avx_only
-- Using install prefix: /usr/local
-- Found Doxygen: /usr/bin/doxygen

One more thing to note that I'm running in a Xen PV VM, although this
should not matter, as the usermode instructions execute directly on the
CPU in this mode.

Thanks,
joanna.



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 13:07, Joanna Rutkowska wrote:
> Hello, I'm getting the invalid opcode exception whenever the volk
> library is used from gr/grc. It is also easy to reproduce by executing
> volk_profile:
> 
> [user@rflab gnuradio]$ volk_profile
> Using Volk machine: avx_64
> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
> Illegal instruction
> [user@rflab gnuradio]$ dmesg
> [ 6920.211094] volk_profile[25627] trap invalid opcode ip:7f8145b74d40
> sp:7fff41dfac78 error:0 in libvolk.so.0.0.0[7f8145ad7000+cf000]
> 
> I tried v3.5.2 and v3.5.2 build directly from git, using the building
> script from here:
> 

I meant: v3.5.2 and v3.5.3, of course.

> http://gnuradio.org/redmine/repositories/changes/gnuradio/README
> 
> Here's my cpuinfo:
> 
> [user@rflab gnuradio]$ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family: 6
> model : 42
> model name: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
> stepping  : 7
> cpu MHz   : 2591.660
> cache size: 3072 KB
> physical id   : 0
> siblings  : 4
> core id   : 1
> cpu cores : 1
> apicid: 3
> initial apicid: 3
> fpu   : yes
> fpu_exception : yes
> cpuid level   : 13
> wp: yes
> flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2
> ss ht syscall nx lm constant_tsc nopl aperfmperf pni pclmulqdq ssse3
> cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat epb pln
> pts dts
> bogomips  : 5183.32
> clflush size  : 64
> cache_alignment   : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> 
> (and repeated 3x times for the other cores).
> 
> And, FWIW, this is the autoconfig snippet:
> 
> -- Configuring volk support...
> --   Enabling volk support.
> --   Override with -DENABLE_VOLK=ON/OFF
> -- Boost version: 1.46.0
> -- Found the following Boost libraries:
> --   unit_test_framework
> -- checking for module 'orc-0.4'
> --   found orc-0.4, version 0.4.16
> -- Found ORC: /usr/lib64/liborc-0.4.so
> -- Check size of void*
> -- Check size of void* - done
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Failed
> -- Performing Test have_mfpu=neon
> -- Performing Test have_mfpu=neon - Failed
> -- Performing Test have_mfloat-abi=softfp
> -- Performing Test have_mfloat-abi=softfp - Failed
> -- Performing Test have_funsafe-math-optimizations
> -- Performing Test have_funsafe-math-optimizations - Success
> -- 32 overruled
> -- Performing Test have_m64
> -- Performing Test have_m64 - Success
> -- Performing Test have_m3dnow
> -- Performing Test have_m3dnow - Success
> -- Performing Test have_msse4.2
> -- Performing Test have_msse4.2 - Success
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Success
> -- Performing Test have_mmmx
> -- Performing Test have_mmmx - Success
> -- Performing Test have_msse
> -- Performing Test have_msse - Success
> -- Performing Test have_msse2
> -- Performing Test have_msse2 - Success
> -- Performing Test have_lorc-0.4
> -- Performing Test have_lorc-0.4 - Success
> -- Performing Test have_msse3
> -- Performing Test have_msse3 - Success
> -- Performing Test have_mssse3
> -- Performing Test have_mssse3 - Success
> -- Performing Test have_msse4a
> -- Performing Test have_msse4a - Success
> -- Performing Test have_msse4.1
> -- Performing Test have_msse4.1 - Success
> -- Performing Test have_mavx
> -- Performing Test have_mavx - Success
> -- Available arches:
> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
> -- Available machines:
> generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64;avx_only
> -- Using install prefix: /usr/local
> -- Found Doxygen: /usr/bin/doxygen
> 
> One more thing to note that I'm running in a Xen PV VM, although this
> should not matter, as the usermode instructions execute directly on the
> CPU in this mode.
> 
> Thanks,
> joanna.
> 
> 
> 
> This body part will be downloaded on demand.




signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First try with RTL2832

[Farhad Abdolian]

HI,
I am sorry but the datasheet I have is specifically made for my company after 
we signed the NDA with them and I can't share it with anyone outside the 
company.

You can ask the company for the info and I am sure you will be able get one 
from them.

Best regards,
Farhad


>
> From: "Zhigang ZHOU (SIMIT, CAS)" 
>To: Farhad Abdolian ; "Discuss-gnuradio@gnu.org" 
> 
>Sent: Sunday, April 15, 2012 12:46 PM
>Subject: Re: [Discuss-gnuradio] First try with RTL2832
> 
>
>  
>Could you email us the RTL2832 data sheet for reference.
>I think many people in this list is seeking this data sheet, thanks a 
lot!
> 
>
>
> 
>Zhigang ZHOU (SIMIT, CAS)
> 
>From: Farhad 
Abdolian
>Date: 2012-04-15 16:50
>To: Discuss-gnuradio@gnu.org
>Subject: [Discuss-gnuradio] First try with 
RTL2832
>Hi folks,
>Yesterday after a long wait I received my DVB-T unit in the mail (it arrived 
>on my birthday). After some initial work, 
I got it to work with GNU Radio and GRC and today I made my first working FM 
receiver using the same blocks as the video from Ettus Research (building GR FM 
Radio in 10 minutes).
>
>
>The design is using the Linux driver and the GR blocks made by Balint Seeber 
>(thanks a million mate).
>
>
>I have attached the GRC with this e-mail, hope you find it useful. I 
am now going to work on the RTL2832 block to fine tune it (I have the complete 
datasheet) and add more feature to it. 
>
>The problem I have is that the signals are not very strong, no matter how 
much I change the gain, the signal level is pretty low and the received audio 
is 
pretty noisy. I have managed to sample at 2Msps without any problems but when I 
sample more than that on my laptop, I get a lot of overflow.
>
>
>I keep you posted on my progress, this is really exciting 
:)
>
>
>Best regards,
>Farhad
>
>
>
>
>>
>> From: Josh Blum  
>>To: Johnathan Corgan   
>>Cc: "Discuss-gnuradio@gnu.org"   
>>Sent: Sunday, April 15, 2012 9:08  AM
>>Subject: Re:  [Discuss-gnuradio] More dumpeths
>>
>>
>>
>>On 04/14/2012 
  01:38 PM, Johnathan Corgan wrote:
>>> On Sat, Apr 14, 2012 at 13:30, 
  Marcus D. Leech  wrote:
>>> 
> Please try commit c787fb66, which is the merge on the former 
  'next'
> branch of a PMT library modification (this is one of 
  the ones that
> failed in trellis for you, hopefully you can 
  make it work.)
>
 This commit fails.  But I had 
  to roll-back to an older version of UHD to get
 it to build.  
  Still failed though.


> If this last 
  fails, please try branch 'test/undo-pmt-deleter', which
> I've 
  pushed to the main gnuradio repository.
>
 That 
  works. No segfaults on exit.
>>> 
>>> Excellent, thanks.  As this 
  is in the 3.5.3 release, I'm going to
>>> rebase this 'fix' off the last 
  3.5.3 maint, but hold off merging it.
>>> I'm hoping Josh can supply an 
  actual fix soon so we don't have to take
>>> that functionality out 
  altogether.
>>> 
>>
>>Maybe its deleting itself: 
  http://pastebin.com/XMSxLJk5
>>
>>-Josh
>>
>>___
>>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] First try with RTL2832

[Farhad Abdolian]

Hi Alex,
Thanks for the videos, I had seen some of them before, I am not sure we are 
using the same modules, the one i am using a much smaller one like the image I 
have attached. 

I am 'playing' with the different parameters today and hopefully I can get some 
good results from it. My signals are really weak (about -90db with strong FM 
channel). 


BR,
Farhad




>
> From: Alexandru Csete 
>To: "Discuss-gnuradio@gnu.org"  
>Sent: Sunday, April 15, 2012 12:10 PM
>Subject: Re: [Discuss-gnuradio] First try with RTL2832
> Hi Farhad,
>
>
>As you may have seen in my on air tests I just posted, I have no problem with 
>low signal levels, however, there is an active hardware AGC which may be 
>causing you troubles. If you have a strong signal in the analog passband of 
>the tuner it will drive the gain down and the weaker signal you are trying to 
>receive will become noisy. You can see that in all 3 videos which show an 
>EzCAP666 with E4000 tuner in action.
>
>I don't know if this AGC is in the RTL chip or the E4000 tuner. I suspect it 
>is in the tuner.
>
>Alex
>___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Where's next?

[Martin Braun]

On Sat, Apr 14, 2012 at 02:07:14PM -0700, Johnathan Corgan wrote:
> > it seems 'next' is gone? Tried to build 'next' using build-gnuradio, and
> > was just about to blame the script--when I figured out that the next
> > branch does not seem to exist on the remote repository.
> > (Sorry Marcus for doubting you :)
> 
> The 'next' branch was merged back into 'master' a few days ago (this
> was announced in advance on the list) in order to switch over to the
> 3.6 API.

Oh, now I feel stupid. Thanks for clarifying--I had even read the
message, I just didn't expect next to vanish.

Looks like releases are popping out quite quickly at the moment! I sure
love what's happening here!

MB
-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpIl5udmvo3s.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP inserts a peak in the carrier frequency

[frankist]

Now I have another problem related to peaks in the fft plot, but in this
case, with no transmitter.

Why does a peak appears at the center of the fft plot for some frequencies
and not for the others. I mean, I am using a USRP2 to receive just noise and
plot its fft and when I center my receiver in the frequencies 5.0GHz, 5.5
GHz and 6.0 GHz I have no peaks but for the other frequencies in the same
band I do have them.

In this case it is not related to LO leakage since I can't get rid of them
and I have no transmitter. Also, the peak always appears at the center of
the plot


frankist wrote:
> 
> Oops. problem solved. I had to increase the LO offset in the transmitter
> (not the receiver)! *Facepalm*
> 
> Thanks for the support
> 
> 
> mleech wrote:
>> 
>> On 07/04/12 10:12 AM, frankist wrote:
>>> Hi,
>>>
>>> I am using GNU Radio for 2 weeks. I always get in the receiver side a
>>> signal
>>> with a peak in the carrier frequency when I turn on the transmitter even
>>> if
>>> I send a signal made of zeros. You can see it in the picture 
>>> http://old.nabble.com/file/p33648622/usrp_carrier_peak.png 
>>>
>>> In spite of being handy to discover the frequency offset of my signal,
>>> it is
>>> influencing my results when I try to measure the power of the received
>>> signal. I thought this was the DC offset, but I read somewhere that
>>> USRP2
>>> eliminates the DC Offset.
>>>
>>> So, do you know what it is and how to remove it?
>>>   
>> This is LO leakage. What is you setup here--two USRPs with XCVR cards?
>> 
>> Mixers always have some amount of LO leakage at the output port. 
>> Depending on your signal bandwidth,
>>  you can use an LO offset to move that leakage outside of your
>> applications passband, but there'll still be
>>  leakage--just not at a place that matters to you.
>> 
>> -- 
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>> 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/USRP-inserts-a-peak-in-the-carrier-frequency-tp33648622p33688986.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Tom Rondeau]

On Sun, Apr 15, 2012 at 7:07 AM, Joanna Rutkowska
 wrote:
> Hello, I'm getting the invalid opcode exception whenever the volk
> library is used from gr/grc. It is also easy to reproduce by executing
> volk_profile:
>
> [user@rflab gnuradio]$ volk_profile
> Using Volk machine: avx_64
> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
> Illegal instruction
> [user@rflab gnuradio]$ dmesg
> [ 6920.211094] volk_profile[25627] trap invalid opcode ip:7f8145b74d40
> sp:7fff41dfac78 error:0 in libvolk.so.0.0.0[7f8145ad7000+cf000]
>
> I tried v3.5.2 and v3.5.2 build directly from git, using the building
> script from here:
>
> http://gnuradio.org/redmine/repositories/changes/gnuradio/README
>
> Here's my cpuinfo:
>
> [user@rflab gnuradio]$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 42
> model name      : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
> stepping        : 7
> cpu MHz         : 2591.660
> cache size      : 3072 KB
> physical id     : 0
> siblings        : 4
> core id         : 1
> cpu cores       : 1
> apicid          : 3
> initial apicid  : 3
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 13
> wp              : yes
> flags           : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse 
> sse2
> ss ht syscall nx lm constant_tsc nopl aperfmperf pni pclmulqdq ssse3
> cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat epb pln
> pts dts
> bogomips        : 5183.32
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
>
> (and repeated 3x times for the other cores).
>
> And, FWIW, this is the autoconfig snippet:
>
> -- Configuring volk support...
> --   Enabling volk support.
> --   Override with -DENABLE_VOLK=ON/OFF
> -- Boost version: 1.46.0
> -- Found the following Boost libraries:
> --   unit_test_framework
> -- checking for module 'orc-0.4'
> --   found orc-0.4, version 0.4.16
> -- Found ORC: /usr/lib64/liborc-0.4.so
> -- Check size of void*
> -- Check size of void* - done
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Failed
> -- Performing Test have_mfpu=neon
> -- Performing Test have_mfpu=neon - Failed
> -- Performing Test have_mfloat-abi=softfp
> -- Performing Test have_mfloat-abi=softfp - Failed
> -- Performing Test have_funsafe-math-optimizations
> -- Performing Test have_funsafe-math-optimizations - Success
> -- 32 overruled
> -- Performing Test have_m64
> -- Performing Test have_m64 - Success
> -- Performing Test have_m3dnow
> -- Performing Test have_m3dnow - Success
> -- Performing Test have_msse4.2
> -- Performing Test have_msse4.2 - Success
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Success
> -- Performing Test have_mmmx
> -- Performing Test have_mmmx - Success
> -- Performing Test have_msse
> -- Performing Test have_msse - Success
> -- Performing Test have_msse2
> -- Performing Test have_msse2 - Success
> -- Performing Test have_lorc-0.4
> -- Performing Test have_lorc-0.4 - Success
> -- Performing Test have_msse3
> -- Performing Test have_msse3 - Success
> -- Performing Test have_mssse3
> -- Performing Test have_mssse3 - Success
> -- Performing Test have_msse4a
> -- Performing Test have_msse4a - Success
> -- Performing Test have_msse4.1
> -- Performing Test have_msse4.1 - Success
> -- Performing Test have_mavx
> -- Performing Test have_mavx - Success
> -- Available arches:
> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
> -- Available machines:
> generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64;avx_only
> -- Using install prefix: /usr/local
> -- Found Doxygen: /usr/bin/doxygen
>
> One more thing to note that I'm running in a Xen PV VM, although this
> should not matter, as the usermode instructions execute directly on the
> CPU in this mode.
>
> Thanks,
> joanna.

Can you try to build using cmake? We've had some issues with the
autotools scripts setting up the right Volk machines and being on a VM
might be confusing it.

Tom

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

Re: [Discuss-gnuradio] Build 3.5.3 fails linking gr-fcd (undefined reference to `clock_gettime')

[Michael Dickens]

Hi Barry - In order to help you out, we (the list) need the OS and build system 
info.  Although buried a bit, 3 clicks from the top-level wiki on gnuradio.org 
is "Mailing Lists" :: "Reporting Errors" :: "I've done everything above, and I 
still have a question. How do I ask it?" [1].  I encourage you (and, anyone 
posting such issues) to read through this section before posting; doing so will 
provide the greatest chance of you obtaining positive results quickly. - MLD

[1] < 
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors#Ive-done-everything-above-and-I-still-have-a-question-How-do-I-ask-it
 > 

On Apr 15, 2012, at 6:10 AM, Barry Jackson wrote:

> Could anyone please help me resolve this.
> 
> CMakeFiles/gnuradio-fcd.dir/hid/hid-libusb.c.o: In function 
> `hid_read_timeout':
> /home/baz/BLD/CO9a/gnuradio/BUILD/gnuradio-3.5.3/gr-fcd/lib/hid/hid-libusb.c:990:
>  undefined reference to `clock_gettime'
> collect2: ld returned 1 exit status
> make[2]: *** [gr-fcd/lib/libgnuradio-fcd-3.5.3.so.0.0.0] Error 1
> 
> I am building from from git tag v3.5.3. with cmake, make.
> 
> I have patched hid-libusb.c to add:-
> #include 
> ...with no change.
> 
> Is there a new build require that I am missing?
> I currently have the BRs that were needed for 3.5.1 in the spec file. as I am 
> updating our distro package from 3.5.1.


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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 15:28, Tom Rondeau wrote:
> On Sun, Apr 15, 2012 at 7:07 AM, Joanna Rutkowska
>  wrote:
>> Hello, I'm getting the invalid opcode exception whenever the volk
>> library is used from gr/grc. It is also easy to reproduce by executing
>> volk_profile:
>>
>> [user@rflab gnuradio]$ volk_profile
>> Using Volk machine: avx_64
>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
>> Illegal instruction
>> [user@rflab gnuradio]$ dmesg
>> [ 6920.211094] volk_profile[25627] trap invalid opcode ip:7f8145b74d40
>> sp:7fff41dfac78 error:0 in libvolk.so.0.0.0[7f8145ad7000+cf000]
>>
>> I tried v3.5.2 and v3.5.2 build directly from git, using the building
>> script from here:
>>
>> http://gnuradio.org/redmine/repositories/changes/gnuradio/README
>>
>> Here's my cpuinfo:
>>
>> [user@rflab gnuradio]$ cat /proc/cpuinfo
>> processor   : 0
>> vendor_id   : GenuineIntel
>> cpu family  : 6
>> model   : 42
>> model name  : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
>> stepping: 7
>> cpu MHz : 2591.660
>> cache size  : 3072 KB
>> physical id : 0
>> siblings: 4
>> core id : 1
>> cpu cores   : 1
>> apicid  : 3
>> initial apicid  : 3
>> fpu : yes
>> fpu_exception   : yes
>> cpuid level : 13
>> wp  : yes
>> flags   : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse 
>> sse2
>> ss ht syscall nx lm constant_tsc nopl aperfmperf pni pclmulqdq ssse3
>> cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat epb pln
>> pts dts
>> bogomips: 5183.32
>> clflush size: 64
>> cache_alignment : 64
>> address sizes   : 36 bits physical, 48 bits virtual
>> power management:
>>
>> (and repeated 3x times for the other cores).
>>
>> And, FWIW, this is the autoconfig snippet:
>>
>> -- Configuring volk support...
>> --   Enabling volk support.
>> --   Override with -DENABLE_VOLK=ON/OFF
>> -- Boost version: 1.46.0
>> -- Found the following Boost libraries:
>> --   unit_test_framework
>> -- checking for module 'orc-0.4'
>> --   found orc-0.4, version 0.4.16
>> -- Found ORC: /usr/lib64/liborc-0.4.so
>> -- Check size of void*
>> -- Check size of void* - done
>> -- Performing Test have_maltivec
>> -- Performing Test have_maltivec - Failed
>> -- Performing Test have_mfpu=neon
>> -- Performing Test have_mfpu=neon - Failed
>> -- Performing Test have_mfloat-abi=softfp
>> -- Performing Test have_mfloat-abi=softfp - Failed
>> -- Performing Test have_funsafe-math-optimizations
>> -- Performing Test have_funsafe-math-optimizations - Success
>> -- 32 overruled
>> -- Performing Test have_m64
>> -- Performing Test have_m64 - Success
>> -- Performing Test have_m3dnow
>> -- Performing Test have_m3dnow - Success
>> -- Performing Test have_msse4.2
>> -- Performing Test have_msse4.2 - Success
>> -- Performing Test have_mpopcnt
>> -- Performing Test have_mpopcnt - Success
>> -- Performing Test have_mmmx
>> -- Performing Test have_mmmx - Success
>> -- Performing Test have_msse
>> -- Performing Test have_msse - Success
>> -- Performing Test have_msse2
>> -- Performing Test have_msse2 - Success
>> -- Performing Test have_lorc-0.4
>> -- Performing Test have_lorc-0.4 - Success
>> -- Performing Test have_msse3
>> -- Performing Test have_msse3 - Success
>> -- Performing Test have_mssse3
>> -- Performing Test have_mssse3 - Success
>> -- Performing Test have_msse4a
>> -- Performing Test have_msse4a - Success
>> -- Performing Test have_msse4.1
>> -- Performing Test have_msse4.1 - Success
>> -- Performing Test have_mavx
>> -- Performing Test have_mavx - Success
>> -- Available arches:
>> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
>> -- Available machines:
>> generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64;avx_only
>> -- Using install prefix: /usr/local
>> -- Found Doxygen: /usr/bin/doxygen
>>
>> One more thing to note that I'm running in a Xen PV VM, although this
>> should not matter, as the usermode instructions execute directly on the
>> CPU in this mode.
>>
>> Thanks,
>> joanna.
> 
> Can you try to build using cmake? We've had some issues with the
> autotools scripts setting up the right Volk machines and being on a VM
> might be confusing it.
> 
Hm... actually I've been using cmake already... Anyway, I tried to run
cmake only for the volk component manually:

[user@rflab gnuradio]$ cd volk/
[user@rflab volk]$ mkdir build
[user@rflab volk]$ cd build/
[user@rflab build]$ cmake -D GR_RUNTIME_DIR=bin ..
/.../
[user@rflab build]$ make
/.../
[user@rflab build]$ apps/volk_profile
Using Volk machine: avx_64
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
Illegal instruction

Perhaps you meant to not use cmake? Can you provide the specific build
instructions I should try?

Thanks,
joanna.



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.

[Discuss-gnuradio] USRP1 reclocking

[naruto canada]

hi

I've found some OCXO clocks on ebay:
http://www.ebay.com/itm/Pletronics-26MHz-OCXO-Miniature-Oscillator-NEW-/140398082881
Maybe someone with enough knowledge can tell if this clock will work with USRP1?
(I am researching on my own too)

I've just bought the board fairly recent, so believe it is rev.4
Does the information on this page still apply:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClockModifications

One more question:
If I replace the clock on USRP1, will all the software (or hardware)
(or some combination) mistake frequencies? (or some parameter)
How does the hardware know itself is powered by some frequency of
clock and not another clock?
Is there a central place to communicate this info to hardware and software?

Thanks

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

Re: [Discuss-gnuradio] USRP inserts a peak in the carrier frequency

[Marcus D. Leech]

On 15/04/12 09:27 AM, frankist wrote:
> Now I have another problem related to peaks in the fft plot, but in this
> case, with no transmitter.
>
> Why does a peak appears at the center of the fft plot for some frequencies
> and not for the others. I mean, I am using a USRP2 to receive just noise and
> plot its fft and when I center my receiver in the frequencies 5.0GHz, 5.5
> GHz and 6.0 GHz I have no peaks but for the other frequencies in the same
> band I do have them.
>
> In this case it is not related to LO leakage since I can't get rid of them
> and I have no transmitter. Also, the peak always appears at the center of
> the plot
>   
Direct conversion receivers suffer from the so-called "DC anomaly" --
spectral features caused by imbalances and 
  LO leakage in the analog mixer.  LO leakage will contribute to a small
DC offset appearing in the signals coming
  out of the mixer, which leads to a "bogus" spectral feature around
0Hz.  The USRP-family FPGAs have a
  DC-offset removal algorithm in them, but it isn't perfect, and the
degree of imperfection will change with
  center frequency. This "feature" is usually very narrowband in nature,
and for many types of modulations,
  it is merely a distraction rather than than a disaster.  You can use
offset-tuning on reception to arrange for
  the DC-anomaly to appear outside your passband.

I've attached a small flow-graph that allows you to see the effects of
DC offset, and phase/amplitude imbalance
  in a complex-sampled system, using a 10Khz pure signal with additive
noise.


 

-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

[Discuss-gnuradio] strange problem with packet sink

[Josh Stevens]

Hey all,
   The benchmark_rx.py file uses the generic_mod_demod.py and on the
receiver side to be specific generic_demod whose input is
gr.io_signature(1, 1, gr.sizeof_gr_complex), # Input signatureand the
output signature is
gr.io_signature(1, 1, gr.sizeof_char))   # Output signature .
It also uses gr_framer_sink_1.cc which is for the basic benchmark purposes.
   What i am currently working with is a modified packet structure at the
transmitter side keeping the modulation- demodulation of the system intact
but a slight modification in the way it is received. I placed a packet sink
giving it the default_access_code , the msg_queue and the required
threshold , but the problem comes in when the demodulation with a "CHAR"
outpout signature is connected to a packet_sink whose signtaures are :
gr_make_io_signature (1, 1, sizeof(float)), #input signature
gr_make_io_signature (0, 0, 0)),   #output signature

I didnt realise it at first when i did the usual self.connect(self
,self._demodulator , self._packet_sink) at the receiver side ,
and i get a TypeError : Itemsize mismatch error . Is there another
alternative to this or would i have to create another packet_sink according
to my requirements ?

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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Tom Rondeau]

On Sun, Apr 15, 2012 at 10:11 AM, Joanna Rutkowska
 wrote:
> On 04/15/12 15:28, Tom Rondeau wrote:
>> On Sun, Apr 15, 2012 at 7:07 AM, Joanna Rutkowska
>>  wrote:
>>> Hello, I'm getting the invalid opcode exception whenever the volk
>>> library is used from gr/grc. It is also easy to reproduce by executing
>>> volk_profile:
>>>
>>> [user@rflab gnuradio]$ volk_profile
>>> Using Volk machine: avx_64
>>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
>>> Illegal instruction
>>> [user@rflab gnuradio]$ dmesg
>>> [ 6920.211094] volk_profile[25627] trap invalid opcode ip:7f8145b74d40
>>> sp:7fff41dfac78 error:0 in libvolk.so.0.0.0[7f8145ad7000+cf000]
>>>
>>> I tried v3.5.2 and v3.5.2 build directly from git, using the building
>>> script from here:
>>>
>>> http://gnuradio.org/redmine/repositories/changes/gnuradio/README
>>>
>>> Here's my cpuinfo:
>>>
>>> [user@rflab gnuradio]$ cat /proc/cpuinfo
>>> processor       : 0
>>> vendor_id       : GenuineIntel
>>> cpu family      : 6
>>> model           : 42
>>> model name      : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
>>> stepping        : 7
>>> cpu MHz         : 2591.660
>>> cache size      : 3072 KB
>>> physical id     : 0
>>> siblings        : 4
>>> core id         : 1
>>> cpu cores       : 1
>>> apicid          : 3
>>> initial apicid  : 3
>>> fpu             : yes
>>> fpu_exception   : yes
>>> cpuid level     : 13
>>> wp              : yes
>>> flags           : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse 
>>> sse2
>>> ss ht syscall nx lm constant_tsc nopl aperfmperf pni pclmulqdq ssse3
>>> cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat epb pln
>>> pts dts
>>> bogomips        : 5183.32
>>> clflush size    : 64
>>> cache_alignment : 64
>>> address sizes   : 36 bits physical, 48 bits virtual
>>> power management:
>>>
>>> (and repeated 3x times for the other cores).
>>>
>>> And, FWIW, this is the autoconfig snippet:
>>>
>>> -- Configuring volk support...
>>> --   Enabling volk support.
>>> --   Override with -DENABLE_VOLK=ON/OFF
>>> -- Boost version: 1.46.0
>>> -- Found the following Boost libraries:
>>> --   unit_test_framework
>>> -- checking for module 'orc-0.4'
>>> --   found orc-0.4, version 0.4.16
>>> -- Found ORC: /usr/lib64/liborc-0.4.so
>>> -- Check size of void*
>>> -- Check size of void* - done
>>> -- Performing Test have_maltivec
>>> -- Performing Test have_maltivec - Failed
>>> -- Performing Test have_mfpu=neon
>>> -- Performing Test have_mfpu=neon - Failed
>>> -- Performing Test have_mfloat-abi=softfp
>>> -- Performing Test have_mfloat-abi=softfp - Failed
>>> -- Performing Test have_funsafe-math-optimizations
>>> -- Performing Test have_funsafe-math-optimizations - Success
>>> -- 32 overruled
>>> -- Performing Test have_m64
>>> -- Performing Test have_m64 - Success
>>> -- Performing Test have_m3dnow
>>> -- Performing Test have_m3dnow - Success
>>> -- Performing Test have_msse4.2
>>> -- Performing Test have_msse4.2 - Success
>>> -- Performing Test have_mpopcnt
>>> -- Performing Test have_mpopcnt - Success
>>> -- Performing Test have_mmmx
>>> -- Performing Test have_mmmx - Success
>>> -- Performing Test have_msse
>>> -- Performing Test have_msse - Success
>>> -- Performing Test have_msse2
>>> -- Performing Test have_msse2 - Success
>>> -- Performing Test have_lorc-0.4
>>> -- Performing Test have_lorc-0.4 - Success
>>> -- Performing Test have_msse3
>>> -- Performing Test have_msse3 - Success
>>> -- Performing Test have_mssse3
>>> -- Performing Test have_mssse3 - Success
>>> -- Performing Test have_msse4a
>>> -- Performing Test have_msse4a - Success
>>> -- Performing Test have_msse4.1
>>> -- Performing Test have_msse4.1 - Success
>>> -- Performing Test have_mavx
>>> -- Performing Test have_mavx - Success
>>> -- Available arches:
>>> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
>>> -- Available machines:
>>> generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64;avx_only
>>> -- Using install prefix: /usr/local
>>> -- Found Doxygen: /usr/bin/doxygen
>>>
>>> One more thing to note that I'm running in a Xen PV VM, although this
>>> should not matter, as the usermode instructions execute directly on the
>>> CPU in this mode.
>>>
>>> Thanks,
>>> joanna.
>>
>> Can you try to build using cmake? We've had some issues with the
>> autotools scripts setting up the right Volk machines and being on a VM
>> might be confusing it.
>>
> Hm... actually I've been using cmake already... Anyway, I tried to run
> cmake only for the volk component manually:
>
> [user@rflab gnuradio]$ cd volk/
> [user@rflab volk]$ mkdir build
> [user@rflab volk]$ cd build/
> [user@rflab build]$ cmake -D GR_RUNTIME_DIR=bin ..
> /.../
> [user@rflab build]$ make
> /.../
> [user@rflab build]$ apps/volk_profile
> Using Volk machine: avx_64
> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
> Illegal instruction
>
> Perhaps you meant to not use cmake? Can you provide the specific build
> instruction

Re: [Discuss-gnuradio] strange problem with packet sink

[Tom Rondeau]

On Sun, Apr 15, 2012 at 10:29 AM, Josh Stevens
 wrote:
> Hey all,
>    The benchmark_rx.py file uses the generic_mod_demod.py and on the
> receiver side to be specific generic_demod whose input is
> gr.io_signature(1, 1, gr.sizeof_gr_complex), # Input signature    and the
> output signature is
> gr.io_signature(1, 1, gr.sizeof_char))   # Output signature .
> It also uses gr_framer_sink_1.cc which is for the basic benchmark purposes.
>    What i am currently working with is a modified packet structure at the
> transmitter side keeping the modulation- demodulation of the system intact
> but a slight modification in the way it is received. I placed a packet sink
> giving it the default_access_code , the msg_queue and the required threshold
> , but the problem comes in when the demodulation with a "CHAR" outpout
> signature is connected to a packet_sink whose signtaures are :
>     gr_make_io_signature (1, 1, sizeof(float)), #input signature
>     gr_make_io_signature (0, 0, 0)),   #output signature
>
> I didnt realise it at first when i did the usual self.connect(self
> ,self._demodulator , self._packet_sink) at the receiver side ,
> and i get a TypeError : Itemsize mismatch error . Is there another
> alternative to this or would i have to create another packet_sink according
> to my requirements ?
>
> Thanks,
> Joshua.


Yes, you will have to convert the types so they match properly. A sink
that's expecting floats won't know what to do with chars, anyways.

Tom

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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 16:29, Tom Rondeau wrote:
> On Sun, Apr 15, 2012 at 10:11 AM, Joanna Rutkowska
>  wrote:
>> > On 04/15/12 15:28, Tom Rondeau wrote:
>>> >> On Sun, Apr 15, 2012 at 7:07 AM, Joanna Rutkowska
>>> >>  wrote:
 >>> Hello, I'm getting the invalid opcode exception whenever the volk
 >>> library is used from gr/grc. It is also easy to reproduce by executing
 >>> volk_profile:
 >>>
 >>> [user@rflab gnuradio]$ volk_profile
 >>> Using Volk machine: avx_64
 >>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
 >>> Illegal instruction
 >>> [user@rflab gnuradio]$ dmesg
 >>> [ 6920.211094] volk_profile[25627] trap invalid opcode ip:7f8145b74d40
 >>> sp:7fff41dfac78 error:0 in libvolk.so.0.0.0[7f8145ad7000+cf000]
 >>>
 >>> I tried v3.5.2 and v3.5.2 build directly from git, using the building
 >>> script from here:
 >>>
 >>> http://gnuradio.org/redmine/repositories/changes/gnuradio/README
 >>>
 >>> Here's my cpuinfo:
 >>>
 >>> [user@rflab gnuradio]$ cat /proc/cpuinfo
 >>> processor   : 0
 >>> vendor_id   : GenuineIntel
 >>> cpu family  : 6
 >>> model   : 42
 >>> model name  : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
 >>> stepping: 7
 >>> cpu MHz : 2591.660
 >>> cache size  : 3072 KB
 >>> physical id : 0
 >>> siblings: 4
 >>> core id : 1
 >>> cpu cores   : 1
 >>> apicid  : 3
 >>> initial apicid  : 3
 >>> fpu : yes
 >>> fpu_exception   : yes
 >>> cpuid level : 13
 >>> wp  : yes
 >>> flags   : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr 
 >>> sse sse2
 >>> ss ht syscall nx lm constant_tsc nopl aperfmperf pni pclmulqdq ssse3
 >>> cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida arat epb 
 >>> pln
 >>> pts dts
 >>> bogomips: 5183.32
 >>> clflush size: 64
 >>> cache_alignment : 64
 >>> address sizes   : 36 bits physical, 48 bits virtual
 >>> power management:
 >>>
 >>> (and repeated 3x times for the other cores).
 >>>
 >>> And, FWIW, this is the autoconfig snippet:
 >>>
 >>> -- Configuring volk support...
 >>> --   Enabling volk support.
 >>> --   Override with -DENABLE_VOLK=ON/OFF
 >>> -- Boost version: 1.46.0
 >>> -- Found the following Boost libraries:
 >>> --   unit_test_framework
 >>> -- checking for module 'orc-0.4'
 >>> --   found orc-0.4, version 0.4.16
 >>> -- Found ORC: /usr/lib64/liborc-0.4.so
 >>> -- Check size of void*
 >>> -- Check size of void* - done
 >>> -- Performing Test have_maltivec
 >>> -- Performing Test have_maltivec - Failed
 >>> -- Performing Test have_mfpu=neon
 >>> -- Performing Test have_mfpu=neon - Failed
 >>> -- Performing Test have_mfloat-abi=softfp
 >>> -- Performing Test have_mfloat-abi=softfp - Failed
 >>> -- Performing Test have_funsafe-math-optimizations
 >>> -- Performing Test have_funsafe-math-optimizations - Success
 >>> -- 32 overruled
 >>> -- Performing Test have_m64
 >>> -- Performing Test have_m64 - Success
 >>> -- Performing Test have_m3dnow
 >>> -- Performing Test have_m3dnow - Success
 >>> -- Performing Test have_msse4.2
 >>> -- Performing Test have_msse4.2 - Success
 >>> -- Performing Test have_mpopcnt
 >>> -- Performing Test have_mpopcnt - Success
 >>> -- Performing Test have_mmmx
 >>> -- Performing Test have_mmmx - Success
 >>> -- Performing Test have_msse
 >>> -- Performing Test have_msse - Success
 >>> -- Performing Test have_msse2
 >>> -- Performing Test have_msse2 - Success
 >>> -- Performing Test have_lorc-0.4
 >>> -- Performing Test have_lorc-0.4 - Success
 >>> -- Performing Test have_msse3
 >>> -- Performing Test have_msse3 - Success
 >>> -- Performing Test have_mssse3
 >>> -- Performing Test have_mssse3 - Success
 >>> -- Performing Test have_msse4a
 >>> -- Performing Test have_msse4a - Success
 >>> -- Performing Test have_msse4.1
 >>> -- Performing Test have_msse4.1 - Success
 >>> -- Performing Test have_mavx
 >>> -- Performing Test have_mavx - Success
 >>> -- Available arches:
 >>> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
 >>> -- Available machines:
 >>> generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64;avx_only
 >>> -- Using install prefix: /usr/local
 >>> -- Found Doxygen: /usr/bin/doxygen
 >>>
 >>> One more thing to note that I'm running in a Xen PV VM, although this
 >>> should not matter, as the usermode instructions execute directly on the
 >>> CPU in this mode.
 >>>
 >>> Thanks,
 >>> joanna.
>>> >>
>>> >> Can you try to build using cmake? We've had some issues with the
>>> >> autotools script

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 16:32, Joanna Rutkowska wrote:
> On 04/15/12 16:29, Tom Rondeau wrote:
>> > On Sun, Apr 15, 2012 at 10:11 AM, Joanna Rutkowska
>> >  wrote:
 >> > On 04/15/12 15:28, Tom Rondeau wrote:
>> >>> >> On Sun, Apr 15, 2012 at 7:07 AM, Joanna Rutkowska
>> >>> >>  wrote:
  >>> Hello, I'm getting the invalid opcode exception whenever the 
  >>> volk
  >>> library is used from gr/grc. It is also easy to reproduce by 
  >>> executing
  >>> volk_profile:
  >>>
  >>> [user@rflab gnuradio]$ volk_profile
  >>> Using Volk machine: avx_64
  >>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
  >>> Illegal instruction
  >>> [user@rflab gnuradio]$ dmesg
  >>> [ 6920.211094] volk_profile[25627] trap invalid opcode 
  >>> ip:7f8145b74d40
  >>> sp:7fff41dfac78 error:0 in 
  >>> libvolk.so.0.0.0[7f8145ad7000+cf000]
  >>>
  >>> I tried v3.5.2 and v3.5.2 build directly from git, using the 
  >>> building
  >>> script from here:
  >>>
  >>> http://gnuradio.org/redmine/repositories/changes/gnuradio/README
  >>>
  >>> Here's my cpuinfo:
  >>>
  >>> [user@rflab gnuradio]$ cat /proc/cpuinfo
  >>> processor   : 0
  >>> vendor_id   : GenuineIntel
  >>> cpu family  : 6
  >>> model   : 42
  >>> model name  : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
  >>> stepping: 7
  >>> cpu MHz : 2591.660
  >>> cache size  : 3072 KB
  >>> physical id : 0
  >>> siblings: 4
  >>> core id : 1
  >>> cpu cores   : 1
  >>> apicid  : 3
  >>> initial apicid  : 3
  >>> fpu : yes
  >>> fpu_exception   : yes
  >>> cpuid level : 13
  >>> wp  : yes
  >>> flags   : fpu de tsc msr pae cx8 sep cmov pat clflush 
  >>> mmx fxsr sse sse2
  >>> ss ht syscall nx lm constant_tsc nopl aperfmperf pni 
  >>> pclmulqdq ssse3
  >>> cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm ida 
  >>> arat epb pln
  >>> pts dts
  >>> bogomips: 5183.32
  >>> clflush size: 64
  >>> cache_alignment : 64
  >>> address sizes   : 36 bits physical, 48 bits virtual
  >>> power management:
  >>>
  >>> (and repeated 3x times for the other cores).
  >>>
  >>> And, FWIW, this is the autoconfig snippet:
  >>>
  >>> -- Configuring volk support...
  >>> --   Enabling volk support.
  >>> --   Override with -DENABLE_VOLK=ON/OFF
  >>> -- Boost version: 1.46.0
  >>> -- Found the following Boost libraries:
  >>> --   unit_test_framework
  >>> -- checking for module 'orc-0.4'
  >>> --   found orc-0.4, version 0.4.16
  >>> -- Found ORC: /usr/lib64/liborc-0.4.so
  >>> -- Check size of void*
  >>> -- Check size of void* - done
  >>> -- Performing Test have_maltivec
  >>> -- Performing Test have_maltivec - Failed
  >>> -- Performing Test have_mfpu=neon
  >>> -- Performing Test have_mfpu=neon - Failed
  >>> -- Performing Test have_mfloat-abi=softfp
  >>> -- Performing Test have_mfloat-abi=softfp - Failed
  >>> -- Performing Test have_funsafe-math-optimizations
  >>> -- Performing Test have_funsafe-math-optimizations - Success
  >>> -- 32 overruled
  >>> -- Performing Test have_m64
  >>> -- Performing Test have_m64 - Success
  >>> -- Performing Test have_m3dnow
  >>> -- Performing Test have_m3dnow - Success
  >>> -- Performing Test have_msse4.2
  >>> -- Performing Test have_msse4.2 - Success
  >>> -- Performing Test have_mpopcnt
  >>> -- Performing Test have_mpopcnt - Success
  >>> -- Performing Test have_mmmx
  >>> -- Performing Test have_mmmx - Success
  >>> -- Performing Test have_msse
  >>> -- Performing Test have_msse - Success
  >>> -- Performing Test have_msse2
  >>> -- Performing Test have_msse2 - Success
  >>> -- Performing Test have_lorc-0.4
  >>> -- Performing Test have_lorc-0.4 - Success
  >>> -- Performing Test have_msse3
  >>> -- Performing Test have_msse3 - Success
  >>> -- Perform

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Tom Rondeau]

On Sun, Apr 15, 2012 at 10:32 AM, Joanna Rutkowska
 wrote:
> On 04/15/12 16:29, Tom Rondeau wrote:
>> On Sun, Apr 15, 2012 at 10:11 AM, Joanna Rutkowska
>>  wrote:
>> Does 'make test' pass? If not, can you run:
>>
>>    ctest -V -R volk
>>
>> And provide the output.
>
> It fails:
>
> [user@rflab volk]$ cd build/
> [user@rflab build]$ make test
> Running tests...
> Test project /rw/home/user/gnuradio/gnuradio/volk/build
>    Start 1: qa_volk_test_all
> 1/1 Test #1: qa_volk_test_all .***Failed    0.01 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.03 sec
>
> The following tests FAILED:
>          1 - qa_volk_test_all (Failed)
> Errors while running CTest
> make: *** [test] Error 8
> [user@rflab build]$ ctest -V -R volk
> UpdateCTestConfiguration  from
> :/rw/home/user/gnuradio/gnuradio/volk/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from
> :/rw/home/user/gnuradio/gnuradio/volk/build/DartConfiguration.tcl
> Test project /rw/home/user/gnuradio/gnuradio/volk/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 1
>    Start 1: qa_volk_test_all
>
> 1: Test command: /rw/home/user/gnuradio/gnuradio/volk/build/lib/test_all
> 1: Test timeout computed to be: 9.99988e+06
> 1: Running 88 test cases...
> 1: Using Volk machine: avx_64
> 1: RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
> 1: unknown location(0): fatal error in
> "volk_16ic_s32f_deinterleave_real_32f_a_test": signal: illegal operand;
> address of failing instruction: 0x7fed0f681d40
> 1: /rw/home/user/gnuradio/gnuradio/volk/lib/testqa.cc(7): last checkpoint
> 1:
> 1: *** 1 failure detected in test suite "Master Test Suite"
> 1/1 Test #1: qa_volk_test_all .***Failed    0.01 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.02 sec
>
> The following tests FAILED:
>          1 - qa_volk_test_all (Failed)
> Errors while running CTest
>
> joanna.
>

Unfortunately, that doesn't narrow things down. How about running
volk_profile under gdb? Let's see if we can find the instruction it's
puking on.

I find it odd that in your original post, it looks like volk_profile
is running avx_64, but your proc/cpuinfo doesn't show that the
processor has AVX. This shouldn't matter in this case since the
deinterleave kernel doesn't have AVX, but I think something is still
getting confused, probably through Xen.

Tom

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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 16:46, Tom Rondeau wrote:
> Unfortunately, that doesn't narrow things down. How about running
> volk_profile under gdb? Let's see if we can find the instruction it's
> puking on.
> 
> I find it odd that in your original post, it looks like volk_profile
> is running avx_64, but your proc/cpuinfo doesn't show that the
> processor has AVX. This shouldn't matter in this case since the
> deinterleave kernel doesn't have AVX, but I think something is still
> getting confused, probably through Xen.

This is what gdb spits out (without debug symbols):

Program received signal SIGILL, Illegal instruction.
0x77b4cd40 in volk_16ic_s32f_deinterleave_real_32f_a_sse4_1 ()
from /rw/home/user/gnuradio/gnuradio/volk/build/lib/libvolk.so.0.0.0
Missing separate debuginfos, use: debuginfo-install
boost-test-1.46.0-3.fc15.x86_64 glibc-2.14.1-6.x86_64
libgcc-4.6.3-2.fc15.x86_64 libstdc++-4.6.3-2.fc15.x86_64
orc-0.4.16-5.fc15.x86_64

What's the recommended way to build volk with debug symbols using cmake?
Sorry, I don't have much experience with cmake...

joanna.



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Tom Rondeau]

On Sun, Apr 15, 2012 at 10:50 AM, Joanna Rutkowska
 wrote:
> On 04/15/12 16:46, Tom Rondeau wrote:
>> Unfortunately, that doesn't narrow things down. How about running
>> volk_profile under gdb? Let's see if we can find the instruction it's
>> puking on.
>>
>> I find it odd that in your original post, it looks like volk_profile
>> is running avx_64, but your proc/cpuinfo doesn't show that the
>> processor has AVX. This shouldn't matter in this case since the
>> deinterleave kernel doesn't have AVX, but I think something is still
>> getting confused, probably through Xen.
>
> This is what gdb spits out (without debug symbols):
>
> Program received signal SIGILL, Illegal instruction.
> 0x77b4cd40 in volk_16ic_s32f_deinterleave_real_32f_a_sse4_1 ()
> from /rw/home/user/gnuradio/gnuradio/volk/build/lib/libvolk.so.0.0.0
> Missing separate debuginfos, use: debuginfo-install
> boost-test-1.46.0-3.fc15.x86_64 glibc-2.14.1-6.x86_64
> libgcc-4.6.3-2.fc15.x86_64 libstdc++-4.6.3-2.fc15.x86_64
> orc-0.4.16-5.fc15.x86_64
>
> What's the recommended way to build volk with debug symbols using cmake?
> Sorry, I don't have much experience with cmake...
>
> joanna.

You pass the -DCMAKE_BUILD_TYPE="Debug" to cmake when configuring.
That sets the -g flag when building to get us the symbols out.

Tom

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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 16:52, Tom Rondeau wrote:
> On Sun, Apr 15, 2012 at 10:50 AM, Joanna Rutkowska
>  wrote:
>> > On 04/15/12 16:46, Tom Rondeau wrote:
>>> >> Unfortunately, that doesn't narrow things down. How about running
>>> >> volk_profile under gdb? Let's see if we can find the instruction it's
>>> >> puking on.
>>> >>
>>> >> I find it odd that in your original post, it looks like volk_profile
>>> >> is running avx_64, but your proc/cpuinfo doesn't show that the
>>> >> processor has AVX. This shouldn't matter in this case since the
>>> >> deinterleave kernel doesn't have AVX, but I think something is still
>>> >> getting confused, probably through Xen.
>> >
>> > This is what gdb spits out (without debug symbols):
>> >
>> > Program received signal SIGILL, Illegal instruction.
>> > 0x77b4cd40 in volk_16ic_s32f_deinterleave_real_32f_a_sse4_1 ()
>> > from /rw/home/user/gnuradio/gnuradio/volk/build/lib/libvolk.so.0.0.0
>> > Missing separate debuginfos, use: debuginfo-install
>> > boost-test-1.46.0-3.fc15.x86_64 glibc-2.14.1-6.x86_64
>> > libgcc-4.6.3-2.fc15.x86_64 libstdc++-4.6.3-2.fc15.x86_64
>> > orc-0.4.16-5.fc15.x86_64
>> >
>> > What's the recommended way to build volk with debug symbols using cmake?
>> > Sorry, I don't have much experience with cmake...
>> >
>> > joanna.
> You pass the -DCMAKE_BUILD_TYPE="Debug" to cmake when configuring.
> That sets the -g flag when building to get us the symbols out.

With dbg symbols:

Starting program:
/rw/home/user/gnuradio/gnuradio/volk/build/apps/volk_profile
[Thread debugging using libthread_db enabled]
Using Volk machine: avx_64
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a

Program received signal SIGILL, Illegal instruction.
0x77b289bd in volk_16ic_s32f_deinterleave_real_32f_a_sse4_1
(iBuffer=0x7053a0, complexVector=0x77e47020, scalar=4.59163468e-41,
num_points=4160742024) at
/rw/home/user/gnuradio/gnuradio/volk/include/volk/volk_16ic_s32f_deinterleave_real_32f_a.h:17
17  static inline void
volk_16ic_s32f_deinterleave_real_32f_a_sse4_1(float* iBuffer, const
lv_16sc_t* complexVector, const float scalar, unsigned int num_points){


j.



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 16:59, Joanna Rutkowska wrote:
> With dbg symbols:
> 
> Starting program:
> /rw/home/user/gnuradio/gnuradio/volk/build/apps/volk_profile
> [Thread debugging using libthread_db enabled]
> Using Volk machine: avx_64
> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
> 
> Program received signal SIGILL, Illegal instruction.
> 0x77b289bd in volk_16ic_s32f_deinterleave_real_32f_a_sse4_1
> (iBuffer=0x7053a0, complexVector=0x77e47020, scalar=4.59163468e-41,
> num_points=4160742024) at
> /rw/home/user/gnuradio/gnuradio/volk/include/volk/volk_16ic_s32f_deinterleave_real_32f_a.h:17
> 17static inline void
> volk_16ic_s32f_deinterleave_real_32f_a_sse4_1(float* iBuffer, const
> lv_16sc_t* complexVector, const float scalar, unsigned int num_points){
> 

Sorry, this didn't paste in into the last message:

Dump of assembler code for function
volk_16ic_s32f_deinterleave_real_32f_a_sse4_1:
   0x77b289a4 <+0>: push   %rbp
   0x77b289a5 <+1>: mov%rsp,%rbp
   0x77b289a8 <+4>: sub$0x108,%rsp
   0x77b289af <+11>:mov%rdi,-0x158(%rbp)
   0x77b289b6 <+18>:mov%rsi,-0x160(%rbp)
=> 0x77b289bd <+25>:vmovss %xmm0,-0x164(%rbp)


j.



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Build 3.5.3 fails linking gr-fcd (undefined reference to `clock_gettime')

[Johnathan Corgan]

On Sun, Apr 15, 2012 at 03:10, Barry Jackson  wrote:

> CMakeFiles/gnuradio-fcd.dir/hid/hid-libusb.c.o: In function
> `hid_read_timeout':
> /home/baz/BLD/CO9a/gnuradio/BUILD/gnuradio-3.5.3/gr-fcd/lib/hid/hid-libusb.c:990:
> undefined reference to `clock_gettime'
> collect2: ld returned 1 exit status
> make[2]: *** [gr-fcd/lib/libgnuradio-fcd-3.5.3.so.0.0.0] Error 1

Looks like 'librt' is not getting linked in on your system (and
somehow is on others.)  Can you run:

$ ldd gr-fcd/lib/libgnuradio-fcd-3.5.3.so.0.0.0

...and post the output here (along with more detail on your OS and compiler.)

Johnathan

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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Tom Rondeau]

On Sun, Apr 15, 2012 at 11:04 AM, Joanna Rutkowska
 wrote:
> On 04/15/12 16:59, Joanna Rutkowska wrote:
>> With dbg symbols:
>>
>> Starting program:
>> /rw/home/user/gnuradio/gnuradio/volk/build/apps/volk_profile
>> [Thread debugging using libthread_db enabled]
>> Using Volk machine: avx_64
>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
>>
>> Program received signal SIGILL, Illegal instruction.
>> 0x77b289bd in volk_16ic_s32f_deinterleave_real_32f_a_sse4_1
>> (iBuffer=0x7053a0, complexVector=0x77e47020, scalar=4.59163468e-41,
>>     num_points=4160742024) at
>> /rw/home/user/gnuradio/gnuradio/volk/include/volk/volk_16ic_s32f_deinterleave_real_32f_a.h:17
>> 17    static inline void
>> volk_16ic_s32f_deinterleave_real_32f_a_sse4_1(float* iBuffer, const
>> lv_16sc_t* complexVector, const float scalar, unsigned int num_points){
>>
>
> Sorry, this didn't paste in into the last message:
>
> Dump of assembler code for function
> volk_16ic_s32f_deinterleave_real_32f_a_sse4_1:
>   0x77b289a4 <+0>:     push   %rbp
>   0x77b289a5 <+1>:     mov    %rsp,%rbp
>   0x77b289a8 <+4>:     sub    $0x108,%rsp
>   0x77b289af <+11>:    mov    %rdi,-0x158(%rbp)
>   0x77b289b6 <+18>:    mov    %rsi,-0x160(%rbp)
> => 0x77b289bd <+25>:    vmovss %xmm0,-0x164(%rbp)
>
>
> j.

Yes, so the vmovss is an AVX instruction (the AVX version of movss),
but your processor doesn't have AVX according to your flags above.
Except that it does. According to Intel, the i5-2540M processor
supports AVX, but your OS isn't recognizing the avx flag in
/proc/cpuinfo. The Volk build process asks the processor directly for
the flags that it can use.

I really think this is a problem with Xen (or at least something in the setup).

Tom

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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Marcus D. Leech]

On 04/15/2012 11:45 AM, Tom Rondeau wrote:


Yes, so the vmovss is an AVX instruction (the AVX version of movss),
but your processor doesn't have AVX according to your flags above.
Except that it does. According to Intel, the i5-2540M processor
supports AVX, but your OS isn't recognizing the avx flag in
/proc/cpuinfo. The Volk build process asks the processor directly for
the flags that it can use.

I really think this is a problem with Xen (or at least something in the setup).

Tom

So, how is this going to play out with packaged-binaries?  If the 
decisions about which instruction sets to use are made at compile time,
  you could end up with packaged binaries that aren't portable, and 
will blow the heck up.  Or am I mis-understanding what you mean

  by "at build time"?



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Tom Rondeau]

On Sun, Apr 15, 2012 at 11:51 AM, Marcus D. Leech  wrote:
> On 04/15/2012 11:45 AM, Tom Rondeau wrote:
>>
>>
>> Yes, so the vmovss is an AVX instruction (the AVX version of movss),
>> but your processor doesn't have AVX according to your flags above.
>> Except that it does. According to Intel, the i5-2540M processor
>> supports AVX, but your OS isn't recognizing the avx flag in
>> /proc/cpuinfo. The Volk build process asks the processor directly for
>> the flags that it can use.
>>
>> I really think this is a problem with Xen (or at least something in the
>> setup).
>>
>> Tom
>>
> So, how is this going to play out with packaged-binaries?  If the decisions
> about which instruction sets to use are made at compile time,
>  you could end up with packaged binaries that aren't portable, and will blow
> the heck up.  Or am I mis-understanding what you mean
>  by "at build time"?
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org

No, you didn't misunderstand, I misspoke. Josh and the other Volk
developers figured this out already. The system builds libraries for
all intrinsics that the compiler supports. It's at run-time that the
correct machine is chosen from the list of what's available and what
your system can support.

I'm not sure if I'm explaining that exactly or well, but the problem
you brought up was considered in the design to allow for us to do
exactly that with Volk. I think in this case, the OS and the actual
processor are at odds with what they can do, causing the problem.

Tom

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

Re: [Discuss-gnuradio] USRP1 reclocking

[Josh Blum]

On 04/15/2012 07:21 AM, naruto canada wrote:
> hi
> 
> I've found some OCXO clocks on ebay:
> http://www.ebay.com/itm/Pletronics-26MHz-OCXO-Miniature-Oscillator-NEW-/140398082881
> Maybe someone with enough knowledge can tell if this clock will work with 
> USRP1?
> (I am researching on my own too)
> 
> I've just bought the board fairly recent, so believe it is rev.4
> Does the information on this page still apply:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClockModifications
> 
> One more question:
> If I replace the clock on USRP1, will all the software (or hardware)
> (or some combination) mistake frequencies? (or some parameter)
> How does the hardware know itself is powered by some frequency of
> clock and not another clock?
> Is there a central place to communicate this info to hardware and software?
> 

If you are using UHD, these are the instructions to inform the software
of the new clock rate:
http://files.ettus.com/uhd_docs/manual/html/usrp1.html#external-clock-modification

-josh

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

Re: [Discuss-gnuradio] More dumpeths

[Johnathan Corgan]

On Sun, Apr 15, 2012 at 00:08, Josh Blum  wrote:

> Maybe its deleting itself: http://pastebin.com/XMSxLJk5

Marcus, this is now on branch 'test/fix-pmt-deleter' for testing.

Johnathan

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

Re: [Discuss-gnuradio] video streaming on ofdm

[Tom Rondeau]

On Sat, Apr 14, 2012 at 10:46 AM, rara  wrote:
>
> hye...
> i'm using grc for video streaming of ofdm system...
> i manage to transmit the video but the quality is so bad
> and sometime the video can play,but sometime it doesn't play at all...
> how to improve the video quality?is it approriate to add buffer on it?
> and i got this message...what does it meant??

The OFDM you're using is just the PHY layer. There are lots of other
parts to a working video streaming application (all the other layers
of the stack). Any you probably don't even have FEC in the system. So
yes, there are lots of other things you can do to make the stream play
better.

> gst-launch -v playbin uri=file:///root/rx
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> ERROR: from element
> /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
> Stream contains no data.
> Additional debug info:
> gsttypefindelement.c(570): gst_type_find_element_handle_event ():
> /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
> Can't typefind empty stream
> ERROR: pipeline doesn't want to preroll.
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> tq

That's outside of GNU Radio and I have no experience with it. Sorry,
can't help you with this one.

Tom

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

Re: [Discuss-gnuradio] swig gnuradio.i cannot find gruel_common.i in 3.6.0

[Alexandru Csete]

On Tue, Apr 10, 2012 at 7:27 PM, Josh Blum  wrote:
>
> On 04/10/2012 08:49 AM, Justin Ford wrote:
> > I'm trying to build an existing tool against gnuradio 3.6.0 (master
> > branch 3.6.0git-7-g779d8c67).  I'm getting the following error from
> > make when gnuradio.i is included by swig:
> > /usr/local/include/gnuradio/swig/gnuradio.i:28: Error: Unable to find
> > 'gruel_common.i'
> >
> > I have attached gnuradio.i from my build, line 28 is trying to include
> > gruel_common.i.  I found gruel_common.i in
> > /usr/local/include/gruel/swig/, but I think it's expected to be in
> > /usr/local/include/gnuradio/swig/.
> >
> > Is this an issue with my build? Or does a change in the more recent
> > master branch version require a patch to gnuradio.i?
> >
>
> This looks to be a recent change. The gruel swig stuff was moved to a
> new install path include/gruel/swig.
>
> > Should I just copy (or link) the contents of
> > /usr/local/include/gruel/swig/ to /usr/local/include/gnuradio/swig/ as
> > a workaround?
> >
>
> You should add this path to the swig search path for your application.
>

Can someone please tell me how to do this for
https://github.com/balint256/gr-baz
I tried to modify Makefile.common updating swigincludedir but it has
no effect :(

Alex

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

[Discuss-gnuradio] Proposed update to WAV file sink

[Marcus D. Leech]

Currently, the XML for the WAV file sink uses a "file_save" type for the 
filename variable.  This looks like it precludes setting the filename at 
runtime, and thus having a callback that allows you to switch to a new 
output filename at runtime.


So, I'm proposing changing it to a "string" type in the XML, and 
inserting a callback on that parameter so the value can be changed at 
runtime,

  calling the "open" method that's part of the gr_wavfile_sink::  class.

I'm open to other ideas.  But this allows me to provide a convienient 
"Record" feature in the apps I have that produce audio outputs, and to
  conditionally have it record to a file of my choosing, or /dev/null, 
depending on whether I have recording enabled or not.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] swig gnuradio.i cannot find gruel_common.i in 3.6.0

[Tom Rondeau]

On Sun, Apr 15, 2012 at 12:48 PM, Alexandru Csete  wrote:
> On Tue, Apr 10, 2012 at 7:27 PM, Josh Blum  wrote:
>>
>> On 04/10/2012 08:49 AM, Justin Ford wrote:
>> > I'm trying to build an existing tool against gnuradio 3.6.0 (master
>> > branch 3.6.0git-7-g779d8c67).  I'm getting the following error from
>> > make when gnuradio.i is included by swig:
>> > /usr/local/include/gnuradio/swig/gnuradio.i:28: Error: Unable to find
>> > 'gruel_common.i'
>> >
>> > I have attached gnuradio.i from my build, line 28 is trying to include
>> > gruel_common.i.  I found gruel_common.i in
>> > /usr/local/include/gruel/swig/, but I think it's expected to be in
>> > /usr/local/include/gnuradio/swig/.
>> >
>> > Is this an issue with my build? Or does a change in the more recent
>> > master branch version require a patch to gnuradio.i?
>> >
>>
>> This looks to be a recent change. The gruel swig stuff was moved to a
>> new install path include/gruel/swig.
>>
>> > Should I just copy (or link) the contents of
>> > /usr/local/include/gruel/swig/ to /usr/local/include/gnuradio/swig/ as
>> > a workaround?
>> >
>>
>> You should add this path to the swig search path for your application.
>>
>
> Can someone please tell me how to do this for
> https://github.com/balint256/gr-baz
> I tried to modify Makefile.common updating swigincludedir but it has
> no effect :(
>
> Alex


The change was from commit aaa98c095a85724a8782a28717162c1d30d865c2.

Here's the relevant lines changed in Makefile.common to get this to
work. I'm not really sure why, buy swignincludedir is not the right
variable to manipulate here.

diff --git a/gr-howto-write-a-block/Makefile.common
b/gr-howto-write-a-block/Makefile.common
index fca6133..2b9cc75 100644
--- a/gr-howto-write-a-block/Makefile.common
+++ b/gr-howto-write-a-block/Makefile.common
@@ -56,7 +56,8 @@ STD_DEFINES_AND_INCLUDES = \
$(DEFINES) \
-I$(abs_top_srcdir)/lib \
-I$(GNURADIO_CORE_INCLUDEDIR) \
-   -I$(GNURADIO_CORE_INCLUDEDIR)/swig
+   -I$(GNURADIO_CORE_INCLUDEDIR)/swig \
+   -I$(GRUEL_INCLUDEDIR)/gruel/swig


Tom

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

Re: [Discuss-gnuradio] Proposed update to WAV file sink

[Marcus D. Leech]

On 04/15/2012 01:42 PM, Marcus D. Leech wrote:
Currently, the XML for the WAV file sink uses a "file_save" type for 
the filename variable.  This looks like it precludes setting the 
filename at runtime, and thus having a callback that allows you to 
switch to a new output filename at runtime.


So, I'm proposing changing it to a "string" type in the XML, and 
inserting a callback on that parameter so the value can be changed at 
runtime,

  calling the "open" method that's part of the gr_wavfile_sink::  class.

I'm open to other ideas.  But this allows me to provide a convienient 
"Record" feature in the apps I have that produce audio outputs, and to
  conditionally have it record to a file of my choosing, or /dev/null, 
depending on whether I have recording enabled or not.



OK, so I found that the default 'file_save' type is willing to accept 
Python expressions, so the only update is to add a callback for that 
particular parameter, so that it can be changed at runtime--the 
underlying C++ code supports this, it's just that it was never exposed 
in the XML.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] swig gnuradio.i cannot find gruel_common.i in 3.6.0

[Alexandru Csete]

On Sun, Apr 15, 2012 at 8:45 PM, Tom Rondeau  wrote:
> On Sun, Apr 15, 2012 at 12:48 PM, Alexandru Csete  wrote:
>> On Tue, Apr 10, 2012 at 7:27 PM, Josh Blum  wrote:
>>>
>>> On 04/10/2012 08:49 AM, Justin Ford wrote:
>>> > I'm trying to build an existing tool against gnuradio 3.6.0 (master
>>> > branch 3.6.0git-7-g779d8c67).  I'm getting the following error from
>>> > make when gnuradio.i is included by swig:
>>> > /usr/local/include/gnuradio/swig/gnuradio.i:28: Error: Unable to find
>>> > 'gruel_common.i'
>>> >
>>> > I have attached gnuradio.i from my build, line 28 is trying to include
>>> > gruel_common.i.  I found gruel_common.i in
>>> > /usr/local/include/gruel/swig/, but I think it's expected to be in
>>> > /usr/local/include/gnuradio/swig/.
>>> >
>>> > Is this an issue with my build? Or does a change in the more recent
>>> > master branch version require a patch to gnuradio.i?
>>> >
>>>
>>> This looks to be a recent change. The gruel swig stuff was moved to a
>>> new install path include/gruel/swig.
>>>
>>> > Should I just copy (or link) the contents of
>>> > /usr/local/include/gruel/swig/ to /usr/local/include/gnuradio/swig/ as
>>> > a workaround?
>>> >
>>>
>>> You should add this path to the swig search path for your application.
>>>
>>
>> Can someone please tell me how to do this for
>> https://github.com/balint256/gr-baz
>> I tried to modify Makefile.common updating swigincludedir but it has
>> no effect :(
>>
>> Alex
>
>
> The change was from commit aaa98c095a85724a8782a28717162c1d30d865c2.
>
> Here's the relevant lines changed in Makefile.common to get this to
> work. I'm not really sure why, buy swignincludedir is not the right
> variable to manipulate here.
>
> diff --git a/gr-howto-write-a-block/Makefile.common
> b/gr-howto-write-a-block/Makefile.common
> index fca6133..2b9cc75 100644
> --- a/gr-howto-write-a-block/Makefile.common
> +++ b/gr-howto-write-a-block/Makefile.common
> @@ -56,7 +56,8 @@ STD_DEFINES_AND_INCLUDES = \
>        $(DEFINES) \
>        -I$(abs_top_srcdir)/lib \
>        -I$(GNURADIO_CORE_INCLUDEDIR) \
> -       -I$(GNURADIO_CORE_INCLUDEDIR)/swig
> +       -I$(GNURADIO_CORE_INCLUDEDIR)/swig \
> +       -I$(GRUEL_INCLUDEDIR)/gruel/swig
>

Thanks Tom, that helped (together with adding the check for gruel in
gr_standalone.m4).

Alex

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

Re: [Discuss-gnuradio] More dumpeths

[Marcus D. Leech]

On 04/15/2012 12:08 PM, Johnathan Corgan wrote:

Marcus, this is now on branch 'test/fix-pmt-deleter' for testing.

Johnathan

That seems to work.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] Gnuradio Screencast for Absolute Beginners

[sumitstop]

Yes Tom I will be glad to contribute in some or other way for the gnuradio
:-)


Tom Rondeau-2 wrote:
> 
> On Mon, Apr 9, 2012 at 4:42 PM, sumitstop
>  wrote:
>>
>> Hi Community,
>>
>> Just uploaded 11 more screen casts in GNURADIO for absolute beginners.
>> They are mostly related to using benchmark files of digital transmission
>> and
>> ofdm transmission.
>> Some playing with the spectrum sensing code is also there. I have
>> increased
>> the font size as well as bright back ground for better visibility.
>>
>> http://www.youtube.com/user/2011HPS?feature=watch
>>
>> A lot more will be coming.
>>
>> Cheers :working:
> 
> Thanks for putting these up and sharing with everyone!
> 
> Tom
> 
> 
> 
>>
>> heckpiet wrote:
>>>
>>> thx mate !!
>>>
>>> Cheers
>>>
>>> Piet
>>>
>>> Am 8. April 2012 01:07 schrieb sumitstop
>>> :

 Hi Community,

 I have uploaded screencast of some very basic things for the beginners
 in
 gnuradio like installing gnuradio, finding common examples of usrp,
 uhd,
 utilities etc. Also getting information about usrp's / daughterboards,
 antennas, burning SD card etc.

 Here is the link

 http://www.youtube.com/user/2011HPS?feature=watch
 http://www.youtube.com/user/2011HPS?feature=watch


 Although these things are given in enough detail on gnuradio webpage
 but
 I
 think watching on screen will be very helpful for the starters :)

 Enjoy :)

 ** Suggestions/improvements are most welcome

 -
 Sumit Kr.
 Research Assistant
 Communication Research center
 IIIT Hyderabad
 India
 --
 View this message in context:
 http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33650161.html
 Sent from the GnuRadio mailing list archive at Nabble.com.


 ___
 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
>>>
>>>
>>
>>
>> -
>> Sumit Kr.
>> Research Assistant
>> Communication Research center
>> IIIT Hyderabad
>> India
>> --
>> View this message in context:
>> http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33657814.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> ___
>> 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
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33688990.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Gnuradio Screencast for Absolute Beginners

[sumitstop]

Hi Community , some more video are up 

1.In system transmission and reception using digital benchmark and ofdm
benchmark files. 

2. Complete instructions on how to install UHD(latest ver), gnuradio (latest
ver) and gnuradio-companion from source code(for those ppl who enjoy
building by themselves) :-))

** instructions on setting python path as well as library path also shown. 
~~
I also wanted to make some videos on getting started with hardware on
gnuradio but unfortunately my shipment from ettus research worth $9K got
stuck. its showing "Clearance delay - Import "  :,( Anyways I will use my
existing usrp2/1 to make the videos in the coming days
~~

More videos will be up very soon :working:

sumitstop wrote:
> 
> 
> Yes Tom I will be glad to contribute in some or other way for the gnuradio
> :-)
> 
> 
> Tom Rondeau-2 wrote:
>> 
>> On Mon, Apr 9, 2012 at 4:42 PM, sumitstop
>>  wrote:
>>>
>>> Hi Community,
>>>
>>> Just uploaded 11 more screen casts in GNURADIO for absolute beginners.
>>> They are mostly related to using benchmark files of digital transmission
>>> and
>>> ofdm transmission.
>>> Some playing with the spectrum sensing code is also there. I have
>>> increased
>>> the font size as well as bright back ground for better visibility.
>>>
>>> http://www.youtube.com/user/2011HPS?feature=watch
>>>
>>> A lot more will be coming.
>>>
>>> Cheers :working:
>> 
>> Thanks for putting these up and sharing with everyone!
>> 
>> Tom
>> 
>> 
>> 
>>>
>>> heckpiet wrote:

 thx mate !!

 Cheers

 Piet

 Am 8. April 2012 01:07 schrieb sumitstop
 :
>
> Hi Community,
>
> I have uploaded screencast of some very basic things for the beginners
> in
> gnuradio like installing gnuradio, finding common examples of usrp,
> uhd,
> utilities etc. Also getting information about usrp's / daughterboards,
> antennas, burning SD card etc.
>
> Here is the link
>
> http://www.youtube.com/user/2011HPS?feature=watch
> http://www.youtube.com/user/2011HPS?feature=watch
>
>
> Although these things are given in enough detail on gnuradio webpage
> but
> I
> think watching on screen will be very helpful for the starters :)
>
> Enjoy :)
>
> ** Suggestions/improvements are most welcome
>
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India
> --
> View this message in context:
> http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33650161.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> 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


>>>
>>>
>>> -
>>> Sumit Kr.
>>> Research Assistant
>>> Communication Research center
>>> IIIT Hyderabad
>>> India
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33657814.html
>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>
>>>
>>> ___
>>> 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
>> 
>> 
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp33650161p33688991.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Joanna Rutkowska]

On 04/15/12 17:45, Tom Rondeau wrote:
> Yes, so the vmovss is an AVX instruction (the AVX version of movss),
> but your processor doesn't have AVX according to your flags above.
> Except that it does. According to Intel, the i5-2540M processor
> supports AVX, but your OS isn't recognizing the avx flag in
> /proc/cpuinfo. The Volk build process asks the processor directly for
> the flags that it can use.
> 
> I really think this is a problem with Xen (or at least something in the 
> setup).

Assuming that the VM kernel is messing up the info that is exposed to
apps via /proc/cpuinfo (this might be likely, sure), and that volk uses
cpuid instruction to actually figure out whether AVX is supported, it
should still work fine -- volk would just use AVX instruction and it
SHOULD work, because this is a ring3 instruction and Xen has no way to
intercept it or prevent its execution (this is true for both PV and HVM
guests -- in case of HVMs there is no VMX intercept that would trigger
on AVX execution, at least I couldn't find one in the SDM)...

So, why it doesn't work? Is there any way one can configure a processor
(via MSR perhaps?) to disable AVX? Xen could be doing that, and
forgetting to remove the AVX flag from the cpuid info exposed to guests...

Another potential explanations of why this doesn't work I could come up
with:

1) Perhaps volk somehow erroneously interprets cpuid info and assumes
that AVX is present, while it is no...? Tom, can you point out the
specific code in volk that is responsible for deciding whether to use
AVX or not?

2) There is a compiler error with generating this opcode correctly
(which would be, however, very strange, as the gdb displays this
instruction fine...),

3) My processor is buggy :o

Any other idea?

This is getting interesting :)

Thanks,
joanna.



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] video streaming on ofdm

[sumitstop]

try reducing the fps. this worked for me 


rara wrote:
> 
> hye...
> i'm using grc for video streaming of ofdm system...
> i manage to transmit the video but the quality is so bad
> and sometime the video can play,but sometime it doesn't play at all...
> how to improve the video quality?is it approriate to add buffer on it?
> and i got this message...what does it meant??
> 
> gst-launch -v playbin uri=file:///root/rx
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> ERROR: from element
> /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
> Stream contains no data.
> Additional debug info:
> gsttypefindelement.c(570): gst_type_find_element_handle_event ():
> /GstPlayBin:playbin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
> Can't typefind empty stream
> ERROR: pipeline doesn't want to preroll.
> Setting pipeline to NULL ...
> Freeing pipeline ...
> 
> tq
> 
> 
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/video-streaming-on-ofdm-tp33672798p33688992.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver

[Tom Rondeau]

On Sun, Apr 15, 2012 at 1:13 AM, Ben Reynwar  wrote:
> It appears that each test case is being run twice.  I think once to
> generate the xml output, and once to generate output for stdout and
> tell you whether it failed.  The random number generator isn't being
> reseeded at the start of each test so they can produce different
> results, so you can sometimes see debug statements that indicate it
> should fail, but the output to stdout claims that is passes.  I've
> attached a patch that make each test use it's own random number
> generating object which seems a tidier way to do this, and makes the
> tests repeatable.
>
> Since there seem to be a fair number of choices of seed that produce
> an error fraction of over 0.2, I've also increased the acceptable
> error rate in the test to 0.3, as Alick initially suggested.

Hey Ben and Martin,

Both patches have been applied. It fixed the issues on my 32-bit VM,
too, so it looks like we got it.

Thanks for help!

Tom


> On Sat, Apr 14, 2012 at 9:39 AM, Alick Zhao  wrote:
>> On Sat, 14 Apr 2012 13:40:35 +0200, Martin Braun wrote:
>>> On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote:
 Yes the bug still occurs.

 I just wrote a simple script to ran the test for 50 times on T60 with
 Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set
 to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's
 output is almost identical in each set except particular test time
 length. The ones before FREQUENCY_OFFSET change is basically the same as
 test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set
 to 0 is attached below. I guess the almost same contents of output is
 due to fixed random seed.

 I also ran the script on a Dell desktop with Fedora, and the result is
 50/50 pass the test. Then I notice one line in the qa python file says
 that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell
 desktop.
>>>
>>> So,
>>>
>>> I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me
>>> it's using "Volk machine: sse3_32".
>>>
>>> I also noticed the line that says seed=1234 fails. Also, the seed is set
>>> multiple times in the script. If this is the source of the bug or not,
>>> it should be fixed, because the seed is reset somewhere in the guts of
>>> the test. I'll post a patch on patch-gnuradio--this eliminates the
>>> problem on my machine, for some reason. If it does the same for you,
>>> this might actually be the solution.
>>>
>>> MB
>>>
>>>
>>
>> I applied the patch and tested it. No failure, yeah!
>>
>> However, with my debugging line, I can see this:
>>
>> [...]
>> constellation:   differential: True  correct:
>> 0.942307692308
>> constellation:   differential: True  correct:
>> 0.772435897436
>> constellation:   differential: True  correct: 1.0
>> [...]
>>
>> So why 0.77XXX on the second line does not cause the assert to fail?
>>
>> alick
>>
>> ___
>> 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] digital_correlate_access_code_bb

[Nowlan, Sean]

Sorry to bump this... It appears the set_access_code method only occurs once  
from within the constructor code. I'm not arguing that the old method isn't 
faster, but it's functionally imprecise and the overhead of the if-else 
statement isn't huge over the life of the object instance. If a time-variable 
access code scheme were implemented, I could see it adding up, though. But 
set_access_code isn't even SWIGged up as a public method, so I assume there 
hasn't been demand for such a use case...

Sean

-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Tom Rondeau
Sent: Monday, April 09, 2012 5:23 PM
To: Nick Foster
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] digital_correlate_access_code_bb

On Mon, Apr 9, 2012 at 2:02 PM, Nick Foster  wrote:
> On Mon, Apr 9, 2012 at 10:48 AM, Marcus D. Leech  wrote:
>>
>> On 04/09/2012 01:38 PM, Tom Rondeau wrote:
>>>
>>> On Sat, Apr 7, 2012 at 10:12 PM, Marcus D. Leech
>>>  wrote:

 Just looking at this function:

 correlate_access_code_bb

 In the method set_access_code, it takes a string.  Which should be 
 ASCII '1'
 and '0' characters to represent the binary sequence being
  correlated against.

 Here's a little beauty of a code snippet:

  d_access_code = 0;
  for (unsigned i=0; i<  64; i++){
    d_access_code<<= 1;
    if (i<  len)
      d_access_code |= access_code[i]&  1;    // look at LSB only
  }

 This relies on the fact that ASCII '1' and '0' happen to have 
 low-order bits of the right "flavour".  This is insanely dirty and 
 gross and I can't
  believe we let this nonsense in the code base.

 There's no reason not to do the right thing here.


 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
>>>
>>>
>>> Want to submit a patch?
>>>
>>> Tom
>>>
>>>
>> Attached.
>
>
> While you're patching correlate_access_code_bb, please patch 
> correlate_access_code_tag_bb with the attached patch.
>
> --n

So my guess is that the use of the binary & operator is to avoid the need for 
an if/if else/else branching check. It was most likely done for efficiency. So 
while this patch might be the "right" way to do it from a code perspective, it 
could result in slower code (on certain machines that don't handle branch 
prediction well). It does make assumptions about the correctness of the access 
code, though.

Tom

___
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] Update on gr_modtool

[Martin Braun]

Hi,

anyone using gr_modtool and the latest GNU Radio version should update the
former--there were some changes in the templates which would cause modules
created by gr_modtool to no longer work.

Changes were pushed to https://github.com/mbant/gr-modtool.
MB


-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


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

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Nick Foster]

On Sun, Apr 15, 2012 at 2:26 PM, Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:


> Another potential explanations of why this doesn't work I could come up
> with:
>
> 1) Perhaps volk somehow erroneously interprets cpuid info and assumes
> that AVX is present, while it is no...? Tom, can you point out the
> specific code in volk that is responsible for deciding whether to use
> AVX or not?
>

Your CPU has AVX capability, no doubt about it. I agree with Tom that it's
likely that Xen is disabling AVX support with XSETVB -- I'm not sure why it
does that. Normal people do not disable extended instruction sets on new
processors. It's just turning off silicon you paid for, after all. =)

Attached is a patch for Volk which performs the additional step of
verifying AVX with XGETBV to determine that the OS is not turning off
useful things. This doesn't fix the fact that Xen is busted, it just won't
run AVX instructions when the instructions are disabled.

Joanna, please test this patch for me and verify that your Volk machine
enumerates as sse4_2_64. Thanks!

Tom, the patch is available (based on latest master) at
github/bistromath:gnuradio.git on the xgetbv branch.

--n


xgetbv.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk library invalid opcode exception

[Nick Foster]

Attached is a patch with one further check -- to make sure the check that
AVX is enabled by the OS, is enabled by the OS.

No kidding.

--n

On Sun, Apr 15, 2012 at 4:09 PM, Nick Foster  wrote:

> On Sun, Apr 15, 2012 at 2:26 PM, Joanna Rutkowska <
> joa...@invisiblethingslab.com> wrote:
> 
>
> Another potential explanations of why this doesn't work I could come up
>> with:
>>
>> 1) Perhaps volk somehow erroneously interprets cpuid info and assumes
>> that AVX is present, while it is no...? Tom, can you point out the
>> specific code in volk that is responsible for deciding whether to use
>> AVX or not?
>>
>
> Your CPU has AVX capability, no doubt about it. I agree with Tom that it's
> likely that Xen is disabling AVX support with XSETVB -- I'm not sure why it
> does that. Normal people do not disable extended instruction sets on new
> processors. It's just turning off silicon you paid for, after all. =)
>
> Attached is a patch for Volk which performs the additional step of
> verifying AVX with XGETBV to determine that the OS is not turning off
> useful things. This doesn't fix the fact that Xen is busted, it just won't
> run AVX instructions when the instructions are disabled.
>
> Joanna, please test this patch for me and verify that your Volk machine
> enumerates as sse4_2_64. Thanks!
>
> Tom, the patch is available (based on latest master) at
> github/bistromath:gnuradio.git on the xgetbv branch.
>
> --n
>


xgetbv.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] runtime errors vs. logic errors

[Nowlan, Sean]

Kind of a nitpicky C++ thing, but shouldn't argument checks on the access code 
in gr_correlate_access_code_tag_bb.cc throw std::invalid_argument or 
std::range_error, which are both derived from std::runtime_error, versus 
std::out_of_range, which is derived from std::logic_error? My understanding is 
that the latter is used for cases such as referencing index 11 in a string that 
was declared to have length 10, etc, whereas the former are used for checking 
user-supplied parameters. A quick " find. | xargs grep out_of_range" yields the 
attached output. It looks like the uses in /src/lib/swig/guile/std_vector.i are 
correctly used (popping from an empty vector, referencing an out-of-bounds 
index, etc.) but the other cases should be invalid_argument. Thoughts? If this 
gets the go-ahead, I'll make a patch sometime this week.

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

Re: [Discuss-gnuradio] runtime errors vs. logic errors

[Nowlan, Sean]

Sorry for the re-post; forgot to include the attachment.

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nowlan, Sean
Sent: Sunday, April 15, 2012 9:01 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] runtime errors vs. logic errors

Kind of a nitpicky C++ thing, but shouldn't argument checks on the access code 
in gr_correlate_access_code_tag_bb.cc throw std::invalid_argument or 
std::range_error, which are both derived from std::runtime_error, versus 
std::out_of_range, which is derived from std::logic_error? My understanding is 
that the latter is used for cases such as referencing index 11 in a string that 
was declared to have length 10, etc, whereas the former are used for checking 
user-supplied parameters. A quick " find. | xargs grep out_of_range" yields the 
attached output. It looks like the uses in /src/lib/swig/guile/std_vector.i are 
correctly used (popping from an empty vector, referencing an out-of-bounds 
index, etc.) but the other cases should be invalid_argument. Thoughts? If this 
gets the go-ahead, I'll make a patch sometime this week.

Thanks,
Sean
find . | xargs grep out_of_range
./src/lib/general/gri_fft.cc:throw std::out_of_range ("gri_fftw: invalid 
fft_size");
./src/lib/general/gri_fft.cc:throw std::out_of_range ("gri_fftw: invalid 
number of threads");
./src/lib/general/gri_fft.cc:throw std::out_of_range ("gri_fftw: invalid 
fft_size");
./src/lib/general/gri_fft.cc:throw std::out_of_range ("gri_fftw: invalid 
number of threads");
./src/lib/general/gri_fft.cc:throw std::out_of_range ("gri_fftw: invalid 
fft_size");
./src/lib/general/gri_fft.cc:throw std::out_of_range ("gri_fftw: invalid 
number of threads");
./src/lib/general/gr_firdes.i:  ) throw(std::out_of_range);
./src/lib/general/gr_firdes.i:  ) throw(std::out_of_range);
./src/lib/general/gr_firdes.i:   ) throw(std::out_of_range); 
./src/lib/general/gr_firdes.i:   ) throw(std::out_of_range); 
./src/lib/general/gr_firdes.i:   ) throw(std::out_of_range); 
./src/lib/general/gr_firdes.i: ) throw(std::out_of_range);
./src/lib/general/gr_firdes.i: ) throw(std::out_of_range);
./src/lib/general/gr_firdes.i:int ntaps) 
throw(std::out_of_range);
./src/lib/general/gr_firdes.i:  int ntaps) throw(std::out_of_range);
./src/lib/general/gr_correlate_access_code_tag_bb.i:  throw(std::out_of_range);
./src/lib/general/gr_firdes.cc:throw std::out_of_range("Hilbert:  Must have 
odd number of taps");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes:window: 
type out of range");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: sampling_freq > 0");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: 0 < fa <= sampling_freq / 2");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_dirdes check 
failed: transition_width > 0");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: sampling_freq > 0");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: 0 < fa <= sampling_freq / 2");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: 0 < fb <= sampling_freq / 2");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: fa <= fb");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: transition_width > 0");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: sampling_freq > 0");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: 0 < fa <= sampling_freq / 2");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: 0 < fb <= sampling_freq / 2");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: fa <= fb");
./src/lib/general/gr_firdes.cc:throw std::out_of_range ("gr_firdes check 
failed: transition_width > 0");
./src/lib/general/gr_correlate_access_code_tag_bb.cc:throw 
std::out_of_range ("access_code is > 64 bits");
./src/lib/general/gr_unpack_k_bits_bb.cc:throw std::out_of_range 
("interpolation must be > 0");
./src/lib/general/gri_control_loop.cc:throw std::out_of_range 
("gri_control_loop: invalid bandwidth. Must be >= 0.");
./src/lib/general/gri_control_loop.cc:throw std::out_of_range 
("gri_control_loop: invalid damping factor. Must be in [0,1].");
./src/lib/general/gri_control_loop.cc:throw std::out_of_range 
("gri_control_loop: invalid alpha. Must be in [0,1].");
./src/lib/general/gri_control_loop.cc:throw std::out_of_range 
("gri_control_loop: invalid beta. Must be in [0,1].");
./src/lib/filter/gr_interp_fir_filter_XXX.cc.t:throw std::out_of_range 
("interpolation must be > 0");
./src/lib/filter/gr_rational_resampler_base_XXX

Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver

[Alick Zhao]

On Sat, 14 Apr 2012 22:13:50 -0700, Ben Reynwar wrote:

> It appears that each test case is being run twice.  I think once to
> generate the xml output, and once to generate output for stdout and
> tell you whether it failed.  The random number generator isn't being
> reseeded at the start of each test so they can produce different
> results, so you can sometimes see debug statements that indicate it
> should fail, but the output to stdout claims that is passes.  I've
> attached a patch that make each test use it's own random number
> generating object which seems a tidier way to do this, and makes the
> tests repeatable.
> 
> Since there seem to be a fair number of choices of seed that produce
> an error fraction of over 0.2, I've also increased the acceptable
> error rate in the test to 0.3, as Alick initially suggested.
> 

Issue solved too. Thanks all for your help!

alick

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