Hi,
I was wondering if it is possible to do timing analysis for GNU Radio
blocks? If so, what is the mechanism for finding time usage by an
individual block in a flowgraph?
Thanks in advance.
Yours thankfully,
Shashank Sinha
___
Discuss-gnuradio mailin
On Fri, May 23, 2014 at 1:06 PM, Dan CaJacob wrote:
> Hey Tom,
>
> Yes, it was definitely pulling the correct endpoint. Even though it is
> backgrounded, I have a log for everything that ran.
>
> Very Respectfully,
>
> Dan CaJacob
>
Hey Dan,
Bit of a holiday this weekend, mostly away from my co
On 05/26/2014 10:24 PM, Sid Boyce wrote:
On 27/05/14 02:01, Marcus D. Leech wrote:
On 05/26/2014 08:40 PM, Sid Boyce wrote:
Check if portaudio19-dev installed.
root@sdrbox:~# dpkg -l|grep portaudio
ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio
I/O - shared library
ii l
On 27/05/14 02:01, Marcus D. Leech wrote:
On 05/26/2014 08:40 PM, Sid Boyce wrote:
Check if portaudio19-dev installed.
root@sdrbox:~# dpkg -l|grep portaudio
ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio
I/O - shared library
ii libportaudiocpp0:amd64 19+svn20140130-1
On 05/26/2014 09:56 PM, Sid Boyce wrote:
On 27/05/14 02:01, Marcus D. Leech wrote:
On 05/26/2014 08:40 PM, Sid Boyce wrote:
Check if portaudio19-dev installed.
root@sdrbox:~# dpkg -l|grep portaudio
ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio
I/O - shared library
ii l
On 27/05/14 02:01, Marcus D. Leech wrote:
On 05/26/2014 08:40 PM, Sid Boyce wrote:
Check if portaudio19-dev installed.
root@sdrbox:~# dpkg -l|grep portaudio
ii libportaudio2:amd64 19+svn20140130-1 amd64Portable audio
I/O - shared library
ii libportaudiocpp0:amd64 19+svn20140130-1
On 05/26/2014 08:40 PM, Sid Boyce wrote:
Check if portaudio19-dev installed.
root@sdrbox:~# dpkg -l|grep portaudio
ii libportaudio2:amd64 19+svn20140130-1
amd64Portable audio I/O - shared library
ii libportaudiocpp0:amd64 19+svn20140130-1
On 27/05/14 00:21, Marcus D. Leech wrote:
On 05/26/2014 07:07 PM, Johnathan Corgan wrote:
On 05/26/2014 03:57 PM, Marcus D. Leech wrote:
transfer closed with 88647 bytes remaining to read
error: Unable to find 404ce04347b132e963564099f18345c19e2685c6 under
http://gnuradio.org/git/gnuradio.git
On 05/26/2014 07:07 PM, Johnathan Corgan wrote:
On 05/26/2014 03:57 PM, Marcus D. Leech wrote:
transfer closed with 88647 bytes remaining to read
error: Unable to find 404ce04347b132e963564099f18345c19e2685c6 under
http://gnuradio.org/git/gnuradio.git
Cannot obtain needed blob 404ce04347b132e96
On 05/26/2014 03:57 PM, Marcus D. Leech wrote:
> transfer closed with 88647 bytes remaining to read
> error: Unable to find 404ce04347b132e963564099f18345c19e2685c6 under
> http://gnuradio.org/git/gnuradio.git
> Cannot obtain needed blob 404ce04347b132e963564099f18345c19e2685c6
> while processing
git clone --progress http://gnuradio.org/git/gnuradio.git
Cloning into gnuradio...
error: Unable to get pack file
http://gnuradio.org/git/gnuradio.git/objects/pack/pack-f226f3ea8e0b1778c849c7ac2c27532d22f0fefd.pack
transfer closed with 88647 bytes remaining to read
error: Unable to find 404ce043
Or if building on low memory systems like ARM, specify 4GB of swap.
73 ... Sid.
On 26/05/14 22:30, Michael Hartje wrote:
Thank You all for the hints. Thanks to Marcus, Sid, Bob!
Yes, it works now! I think, the observation from Sid was the way of success.
So the reason was: too low (1GB!) RAM fo
Thank You all for the hints. Thanks to Marcus, Sid, Bob!
Yes, it works now! I think, the observation from Sid was the way of success.
So the reason was: too low (1GB!) RAM for the VM!
After increase up to e.g. 3,5 GB RAM for the VM the buildscript.sh gave
no errors anymore.
Thanks in advance
Ma
Hi Martin:
Thank you so much for your help.It can run.Thanks.
Best regards
xianda
At 2014-05-26 20:40:08,"Martin Braun" wrote:
>On 26.05.2014 13:03, xianda wrote:
>> Hi:
>> Now I run the example(tx_ofdm and rx_ofdm) through two usrps.(The
>> version of my gnuradio is 3.7.4).
>>
Hi Jawad:
Thank you so much for your help.Now it can run.Thanks.
Best regards
At 2014-05-26 20:44:13,"Jawad Seddar" wrote:
First of all, I removed the OFDM receiver part from tx_ofdm and replaced it by
a USRP sink and added a tag debugger to know when the data was generated from
the transmitte
Yes, it is the *generated python* not the *GRC file* itself. You can't open
the python code with GRC. You should open the GRC file.
On Mon, May 26, 2014 at 9:41 AM, jason sam wrote:
> Hi Marcus,
> This python code is generated from GRC.
>
>
> On Mon, May 26, 2014 at 11:52 AM, Marcus Müller
> w
On 26.05.2014 13:03, xianda wrote:
Hi:
Now I run the example(tx_ofdm and rx_ofdm) through two usrps.(The
version of my gnuradio is 3.7.4).
1.But in the receive part I receive two many things like this:
INFO: Detected an invalid packet at item 139632
INFO: Parser returned #f
Xianda,
th
Hi,
I connected the usrp e110 to usb hub(with usb host) which is connected to
a keyboard, a mouse and a pen drive( for swap memory).
When I try to login the mouse pointer doesn't work. I'm sure that the mouse
works well.
Is there any driver to install on usrp e 110 to make the mouse(the
keyboar
Hi Jawad:
Thank you so much for your kindly reply.
But the first problem still exist.Can you send me your test document and I
test.Thank you.
And the second problem is solved.Can you tell me why 200k is ok while 100k
failed?(they are all 10M/(even number)).Thank you.
Best regards,
xianda
At 2014
Hi xianda,
I found out that using a factor of 0.05 in the multiply const works best
for me, with USRPs about 50 - 100 cm appart and rx and tx gains set to 0.
Try using a sample rate of 200k and you shouldn't get that sample rate
error again.
Regards,
Jawad
___
Hi:
Now I run the example(tx_ofdm and rx_ofdm) through two usrps.(The version
of my gnuradio is 3.7.4).
1.But in the receive part I receive two many things like this:
INFO: Detected an invalid packet at item 139632
INFO: Parser returned #f
INFO: Detected an invalid packet at item 139680
INF
Cython?
On Sun, May 25, 2014 at 9:48 PM, Robert McGwier wrote:
> And what is the size of the VM disk limited to and how much RAM have you
> allowed it? The step you are showing as exiting in (SWIG) requires lots of
> resources in building gnuradio. I hate SWIG, but have no idea what in the
>
On ARM it was with 4 threads initially then re-running with 1 thread
gave the same error.
That 3.0.6x distro kernel was built without swap so I had to build and
install a new kernel with swap.
The first go with 2GB swap also failed and I had to make another 2GB
swap file and add it with swapon
Hi all guys,
I am experiencing error when testing 3.7.3. The error report is following:
OK
Using Volk machine: avx_64_mmx
-- Process completed
Passed
95/177 Testing qa_pfb_arb_resampler
Test command: /bin/sh
/home/savi_ne/tools/gnuradio-3.7.3/build/gr-filter/python/filter/qa_pfb_arb_resampler
Thank you,
In GRC, I changed Clock Rate (Hz) by giving a value of 28e6 and it works now.
Date: Sun, 25 May 2014 23:41:01 -0400
From: mle...@ripnet.com
To: user0...@gmail.com
CC: raf...@hotmail.fr; Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to set a master clock rate on USRP B20
Hi Michael and Sid,
how many compiler threads are you spawning? When you use 1 (i.e. make
-j1), is this still a problem?
M
On 25.05.2014 11:29, Michael Hartje wrote:
Dear list,
I try to compile the new GR 3.7.4-git.
But it breaks with pybombs as well as with the script build-grc.sh
The job
On 26.05.2014 08:43, Marcus Müller wrote:
There is a device args field in the current version of GNU Radio, so
this might be where the confusion comes from.
Yes, for the record: In UHD, 'args' and 'addr' (address) are the same
thing. So, this is an addr: "type=b200,master_clock_rate=28e6". Cle
Hi Marcus,
This python code is generated from GRC.
On Mon, May 26, 2014 at 11:52 AM, Marcus Müller wrote:
> Hi Ali,
>
> we're always thankful for feedback; the information you supply is a little
> sparse.
> Usually, I'd ask you to refer to
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Re
28 matches
Mail list logo
