[Discuss-gnuradio] seg fault due to the callback in bin_statitics
last week every thing was fine until today when i want to sense the spectrum i faced this problem >>./usrp_spectrum_sense.py 1901M 1983M > file.tr Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! Traceback (most recent call last): File "./usrp_spectrum_sense.py", line 237, in tb = my_top_block() File "./usrp_spectrum_sense.py", line 135, in __init__ num_channels=1) File "/usr/local/lib/python2.7/ dist-packages/gnuradio/uhd/__init__.py", line 116, in constructor_interceptor return old_constructor(*args) File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2885, in usrp_source return _uhd_swig.usrp_source(*args) RuntimeError: LookupError: KeyError: No devices found for -> Device Address: addr: 192.168.10.2 although i am using usrp 1 so i added this args >>usrp_spectrum_sense.py 1901M 1983M >file.tr --address="type=usrp1" linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-24-g8630807c Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... Using Volk machine: ssse3_64 gain = 25.75 Segmentation fault When i added "file.tr" to the command it gave me this error and when i wrote the command without "file.tr" it worked without any problems and usrp start to sense. But i need to save this data. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Updates to build-gnuradio
build-gnuradio has been updated to include support for Debian Squeeze, and the Ubuntu support now installs python-gtk2 as a pre-req. Normally, python-gtk2 is already installed as part of the base system, but if it's missing, GRC won't build. Seems that Kubuntu doesn't install python-gtk2 (I guess that makes sense, since it's KDE, rather than Gnome). -- 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
[Discuss-gnuradio] Problems with DC offsets, leakage and other stuff
Hi, This is a problem I have been having for a while, but I've never given it enough importance until now. Basically I have a USRP2 as a receiver and no transmitter. So basically, I am just measuring noise. I am using the 5GHz band. Here are the fft plots for freq. 5GHz and gain 30 and 50. http://old.nabble.com/file/p33690634/pic1.jpg http://old.nabble.com/file/p33690634/pic2.jpg As you can see the peak at center frequency is eliminated by changing the gain. So I guess it was just some DC offset that wasn't removed by the USRP. However, the other peak at -30kHz approximately remains. I tried to use uhd.tune_request thinking it was some leakage but the peak doesn't move. When I use a center freq. greater than 5GHz and lesser than 5.5GHz I get this: http://old.nabble.com/file/p33690634/pic3.jpg http://old.nabble.com/file/p33690634/pic4.jpg In this case I have a peak at center frequency which isn't attenuated even if I change the gain. The peak at -30kHz remains also. I tried using the uhd.tune_request treating these peaks as leakage but they didn't move at all once more. At 5.5GHz, I don't have any peak (I don't think it is necessary to post a image in this case) except for a small DC offset which is eliminated with a increase in the gain. The peak at the center frequency (but not the -30kHz peak), however, appears again for frequencies greater than 5.5GHz but less than 6 GHz. Someone answered me in another post about the leakage problem and how to solve it. However, those tools are not working in this case. -- View this message in context: http://old.nabble.com/Problems-with-DC-offsets%2C-leakage-and-other-stuff-tp33690634p33690634.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] Build 3.5.3 fails linking gr-fcd (undefined reference to `clock_gettime')
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 Did you work this issue out? I'm about to cut bug fix release 3.5.3.1, but would like to include any fix for this issue. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about underrun
On 04/16/2012 07:25 AM, Pan, Luyuan wrote: > Hello everyone, > I am wondering what will the USRP and GnuRadio do if an underrun > happens? i.e. The console/terminal print out U. Does the USRP restart > again or the flow-graph restart? I now face the problem that USRP takes > more time to transmit all the data out(I need to add time.sleep() to > make sure all the data are sent out successfully), does it have some > relation with the underrun. > Any suggestion is appreciated. Thank you for your help! UHD docs about underflow: http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes In terms of gnuradio, nothing happens. Gnuradio continues to push data into the usrp sink block. Also, you can read the async message stream to discover if an underflow event had occurred. If you are using something newer than USRP1, I *highly* recommend using the burst tags to schedule transmits, rather than timing flowgraph.start() with a sleep. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Disable HPF in LFRX (Companion Only User)
On 04/16/2012 04:06 AM, Kanbier, J.W. wrote: > Hi, > > I am struggling disabling the DC Highpass filter on the LFRX, I need to > do some audio measurement which require respone down to DC. > The problem is that I am only familiar with GRC so I need a way to > modify the UHD USRP Source so it goes down to DC. > I dont think there is a hook for this in gnuradio companion, but you can add a call to disable the automatic DC offset correction. Simply add a line to the generated python code http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h#n283 -Josh > Ideally Create a Second Block specifically for this task.. > > Any Ideas? > > Jasper Kanbier > Unix Beheer > BVS > > ICT Shared Service Centre > Universiteit Leiden > +31 71 527 6894 > j.w.kanb...@issc.leidenuniv.nl > > <> > > ISSC Universiteit Leiden > Niels Bohrweg 1 > 2333 CA Leiden > www.issc.leidenuniv.nl http://www.issc.leidenuniv.nl/> > > Helpdesk > +31 71 527 > helpd...@issc.leidenuniv.nl > > > > > > ___ > 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] Volk library invalid opcode exception
On Mon, Apr 16, 2012 at 5:50 AM, Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:
> On 04/16/12 14:20, Joanna Rutkowska wrote:
> /.../
> >
> > So, it seems like it is not a Xen issue, but instead that the kernel
> > I'm using in the VM (essentially a vanilla 3.0.4) is not enabling AVX
> > in XCR0. It would be interesting if anybody could try this on a
> > non-Xen system with a similarly old kernel as I have (and on the
> > AVX-capable processor, of course).
> >
>
> Interestingly, I tried another kernel in the VM (essentially a vanilla
> 3.2.7), and again the AVX seemed to be disabled in the VM (volk used
> sse4 again).
>
> So, I quickly looked through the kernel sources and I think that the
> kernel enables AVX in this code:
>
> static void __init xstate_enable_boot_cpu(void)
> {
> /.../
>cpuid_count(XSTATE_CPUID, 0, &eax, &ebx, &ecx, &edx);
>pcntxt_mask = eax + ((u64)edx << 32);
>
>if ((pcntxt_mask & XSTATE_FPSSE) != XSTATE_FPSSE) {
>printk(KERN_ERR "FP/SSE not shown under xsave features 0x%llx\n",
> pcntxt_mask);
>BUG();
>}
>
>/*
> * Support only the state known to OS.
> */
>pcntxt_mask = pcntxt_mask & XCNTXT_MASK;
>
>xstate_enable();
>
>
> The XSTATE_FPSSE and XCNTXT_MASK are defined as follows:
>
> #define XSTATE_FP 0x1
> #define XSTATE_SSE 0x2
> #define XSTATE_YMM 0x4
>
> #define XSTATE_FPSSE(XSTATE_FP | XSTATE_SSE)
> #define XCNTXT_MASK (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
>
> The YMM corresponds to the AVX enable flag (not sure why they call it
> differently?).
>
> Anyway, this shows that, assuming CPUID returns correct values (that
> indicate AVX to be enabled), then the (guest) kernel should enable AVX
> (and Xen should emulate this and allow for this, as indicated in the
> previous message). And if CPUID was not returning correct values (i.e.
> omitting the AVX flag), then we would not have this whole discussion.
>
> So, what am I missing?
>
> Can you point out which kernels do you use that you have AVX working fine?
>
Linux smidgen 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
I really do think it's a Xen issue; do you have a kernel you can try to run
outside the hypervisor?
In any case, it's mostly a moot point, as there are very few Volk kernels
which make use of AVX, and those which do don't appear to be significantly
faster than their SSE3 counterparts. I think that's due to either memory
bandwidth or instruction promotion of SSE3 intrinsics, but that's a
different story.
--n
>
> joanna.
>
>
> ___
> 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] Volk library invalid opcode exception
On Mon, Apr 16, 2012 at 05:20, Joanna Rutkowska wrote: >> Joanna, let us know how this works for you. I'm going to be on the >> road for the next few days, so I'll be sparsely available. > > Yes, it works! I can now use the gr_add block to add to sin signals, how > cool! ;) > > BTW, as Nick's patch didn't apply cleanly on v3.5.3, I pulled from the > git and applied it on top of the HEAD -- please let me know if you think > it can get me into troubles to work on GR/GRC build from the HEAD > instead of from some v3.5.x tag. Thanks for testing. I'll go ahead and merge this, but I'll do it in a way that makes it available for both the master branch (what you're calling HEAD) and for the maintenance branch, so that this will eventually go into tarball releases 3.5.3.1 and 3.6.0. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about underrun
Hello everyone, I am wondering what will the USRP and GnuRadio do if an underrun happens? i.e. The console/terminal print out U. Does the USRP restart again or the flow-graph restart? I now face the problem that USRP takes more time to transmit all the data out(I need to add time.sleep() to make sure all the data are sent out successfully), does it have some relation with the underrun. Any suggestion is appreciated. Thank you for your help! -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk library invalid opcode exception
On 04/16/12 14:20, Joanna Rutkowska wrote:
/.../
>
> So, it seems like it is not a Xen issue, but instead that the kernel
> I'm using in the VM (essentially a vanilla 3.0.4) is not enabling AVX
> in XCR0. It would be interesting if anybody could try this on a
> non-Xen system with a similarly old kernel as I have (and on the
> AVX-capable processor, of course).
>
Interestingly, I tried another kernel in the VM (essentially a vanilla
3.2.7), and again the AVX seemed to be disabled in the VM (volk used
sse4 again).
So, I quickly looked through the kernel sources and I think that the
kernel enables AVX in this code:
static void __init xstate_enable_boot_cpu(void)
{
/.../
cpuid_count(XSTATE_CPUID, 0, &eax, &ebx, &ecx, &edx);
pcntxt_mask = eax + ((u64)edx << 32);
if ((pcntxt_mask & XSTATE_FPSSE) != XSTATE_FPSSE) {
printk(KERN_ERR "FP/SSE not shown under xsave features 0x%llx\n",
pcntxt_mask);
BUG();
}
/*
* Support only the state known to OS.
*/
pcntxt_mask = pcntxt_mask & XCNTXT_MASK;
xstate_enable();
The XSTATE_FPSSE and XCNTXT_MASK are defined as follows:
#define XSTATE_FP 0x1
#define XSTATE_SSE 0x2
#define XSTATE_YMM 0x4
#define XSTATE_FPSSE(XSTATE_FP | XSTATE_SSE)
#define XCNTXT_MASK (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
The YMM corresponds to the AVX enable flag (not sure why they call it
differently?).
Anyway, this shows that, assuming CPUID returns correct values (that
indicate AVX to be enabled), then the (guest) kernel should enable AVX
(and Xen should emulate this and allow for this, as indicated in the
previous message). And if CPUID was not returning correct values (i.e.
omitting the AVX flag), then we would not have this whole discussion.
So, what am I missing?
Can you point out which kernels do you use that you have AVX working fine?
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
On 04/16/12 13:47, Tom Rondeau wrote:
> On Sun, Apr 15, 2012 at 8:24 PM, Nick Foster wrote:
>> > 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
> Wonderful, Nick, thanks.
>
> Joanna, let us know how this works for you. I'm going to be on the
> road for the next few days, so I'll be sparsely available.
Yes, it works! I can now use the gr_add block to add to sin signals, how
cool! ;)
BTW, as Nick's patch didn't apply cleanly on v3.5.3, I pulled from the
git and applied it on top of the HEAD -- please let me know if you think
it can get me into troubles to work on GR/GRC build from the HEAD
instead of from some v3.5.x tag.
Anyway, I looked into Xen sources and it seems like Xen *does allow* the
guest PV kernel to set bits 1 and 2 in the XCR0 register -- here's the
relevant code (I think):
case 0xd1: /* XSETBV */
{
u64 new_xfeature = (u32)regs->eax | ((u64)regs->edx << 32);
if ( lock || rep_prefix || opsize_prefix
|| !(v->arch.guest_context.ctrlreg[4] & X86_CR4_OSXSAVE) )
{
do_guest_trap(TRAP_invalid_op, regs, 0);
goto skip;
}
if ( !guest_kernel_mode(v, regs) )
goto fail;
switch ( (u32)regs->ecx )
{
case XCR_XFEATURE_ENABLED_MASK:
/* bit 0 of XCR0 must be set and reserved bit must
not be set */
if ( !(new_xfeature & XSTATE_FP) || (new_xfeature &
~xfeature_mask) )
goto fail;
v->arch.xcr0 = new_xfeature;
v->arch.xcr0_accum |= new_xfeature;
set_xcr0(new_xfeature);
break;
default:
goto fail;
}
break;
So, it seems like it is not a Xen issue, but instead that the kernel I'm
using in the VM (essentially a vanilla 3.0.4) is not enabling AVX in
XCR0. It would be interesting if anybody could try this on a non-Xen
system with a similarly old kernel as I have (and on the AVX-capable
processor, of course).
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
On Sun, Apr 15, 2012 at 8:24 PM, Nick Foster wrote: > 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 Wonderful, Nick, thanks. Joanna, let us know how this works for you. I'm going to be on the road for the next few days, so I'll be sparsely available. Tom > On Sun, Apr 15, 2012 at 4:09 PM, Nick Foster wrote: >> >> On Sun, Apr 15, 2012 at 2:26 PM, Joanna Rutkowska >> 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Disable HPF in LFRX (Companion Only User)
Hi, I am struggling disabling the DC Highpass filter on the LFRX, I need to do some audio measurement which require respone down to DC. The problem is that I am only familiar with GRC so I need a way to modify the UHD USRP Source so it goes down to DC. Ideally Create a Second Block specifically for this task.. Any Ideas? Jasper Kanbier Unix Beheer BVS ICT Shared Service Centre Universiteit Leiden +31 71 527 6894 j.w.kanb...@issc.leidenuniv.nl <> ISSC Universiteit Leiden Niels Bohrweg 1 2333 CA Leiden www.issc.leidenuniv.nl http://www.issc.leidenuniv.nl/> Helpdesk +31 71 527 helpd...@issc.leidenuniv.nl <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] REF Signal specs for USRP B100
Hi everybody, can anybody indicate if ref signal specs for the USRP B100 are to be considered the same as those for N210 as specified here? http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz thank you and regards vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
