|
| From: | gsmandvoip |
| Subject: | Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 138, Issue 39 |
| Date: | Wed, 28 May 2014 23:28:59 +0530 |
Send Discuss-gnuradio mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Meet-up in Blacksburg, VA (Tom Rondeau)
2. Re: GR and git on non-networked machine (Marcus M?ller)
3. Re: GR and git on non-networked machine (Marcus Leech)
4. Re: GR and git on non-networked machine (Marc H?lscher)
5. Re: Is Simple Framer and Simple Correllator blocks will
synchronize my data? (Tom Rondeau)
6. Re: gnu radio - vhdl (Martin Braun)
7. Re: gnu radio - vhdl (Vanush Vaswani)
8. Re: GNU Radio distribution and build from source. (Sid Boyce)
9. Re: Calling a GRC file in another GUI (jason sam)
10. Debian Jessie update (Activecat)
11. Re: Debian Jessie update (Ralph A. Schmid, dk5ras)
12. Re: Calling a GRC file in another GUI (Marcus M?ller)
13. assertion error beyond 4096 output items (Karan Talasila)
14. Re: assertion error beyond 4096 output items (Marcus M?ller)
15. Re: Debian Jessie update (Activecat)
16. Re: assertion error beyond 4096 output items (Martin Braun)
17. Unable to log in usrpe 110 to get access to gnuradio on
screen? (Wafa Elhajhmida)
18. Re: Debian Jessie update (Marcus M?ller)
19. Re: assertion error beyond 4096 output items (Martin Braun)
20. Re: Debian Jessie update (Activecat)
21. Re: assertion error beyond 4096 output items (Karan Talasila)
22. Re: assertion error beyond 4096 output items (Marcus M?ller)
23. Re: assertion error beyond 4096 output items (Marcus M?ller)
24. Re: GNU Radio Measurement Toolbox -- GSoC '14 Project
(Vanush Vaswani)
25. Re: Unable to log in usrpe 110 to get access to gnuradio on
screen? (Wafa Elhajhmida)
26. Re: assertion error beyond 4096 output items (Karan Talasila)
27. Re: Dynamically changing input index of Selector block.
(Activecat)
28. Out of Tree Encryption block (dushyant.marathe)
29. Re: Unable to log in usrpe 110 to get access to gnuradio on
screen? (West, Nathan)
30. spectrum chunk (gsmandvoip)
31. Re: spectrum chunk (Martin Braun)
32. Re: assertion error beyond 4096 output items (Activecat)
33. Re: Unable to log in usrpe 110 to get access to gnuradio on
screen? (Nick Foster)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 May 2014 12:36:16 -0400
From: Tom Rondeau <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Meet-up in Blacksburg, VA
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I'm at Virginia Tech in Blacksburg, VA this week for the
address@hidden If anyone else is around, either just in the
area or around for
the symposium, we're having a meet-up at Macado's tomorrow night
(Wednesday) at 7pm. Bring your laptop and any handheld radio hardware so we
can move from dinner and drinks to hacking and drinks.
Dinner starts at 7pm, and please RSVP directly to me so I know
approximately how many people may be coming.
Thanks! And see some of you tomorrow!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140527/71c546fc/attachment.html>
------------------------------
Message: 2
Date: Tue, 27 May 2014 18:47:07 +0200
From: Marcus M?ller <address@hidden>
To: madengr <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] GR and git on non-networked machine
Message-ID:
<CAHrJaSUQRuVKcMU3+2Ah511xRooVRAYPuR=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Lou,
yes, you can. That's what git is all about :) Git even has something called
"bare repo" where you save the hassle (and the space) for a working copy.
If you e.g had an USB drive, you could do an
git clone --bare https://github.com/gnuradio/gnuradio.git
and then pulling from that on your not-networked machine:
/home/lou/my-working-dir$ git pull /media/usbdrive/gnuradio.git
When updating GNU Radio, instead of re-cloning you could just git fetch the
newest branch.
However, I might assume that you're doing this because you have a machine
that you only use for deployment, so you most probably wouldn't want to
compile GNU Radio on that but actually wanted to just install it there. If
getting an image of that machine is feasible, look into just reproducing
that machine in a virtualization solution (e.g. Virtualbox) and just
overwrite the filesystem image of the non-networked machine.
Greetings,
Marcus
On Tue, May 27, 2014 at 5:59 PM, madengr <address@hidden> wrote:
> If I want to run GR (and keep it updated via git) on a non-networked
> machine,
> can I "git clone", copy the resulting gnuradio directory to a DVD, then
> "git
> pull" from that DVD (specifically the *.git that is created in the gnuradio
> directory?
>
> Thanks,
> Lou
> KD4HSO
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/GR-and-git-on-non-networked-machine-tp48566.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140527/736b6b01/attachment.html>
------------------------------
Message: 3
Date: Tue, 27 May 2014 16:55:08 +0000 (UTC)
From: Marcus Leech <address@hidden>
To: address@hidden
Cc: address@hidden, address@hidden
Subject: Re: [Discuss-gnuradio] GR and git on non-networked machine
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140527/feef30ab/attachment.html>
------------------------------
Message: 4
Date: Tue, 27 May 2014 17:12:47 +0000
From: Marc H?lscher <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] GR and git on non-networked machine
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
if you did not yet consider, 'git bundle' might be worth a look.
It packs a repository in a single file (archive). You also can specify
which references to ecpect (prior checkout) to only export from that
forward.
Sincerely,
Marc
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x3A363153.asc
Type: application/pgp-keys
Size: 154498 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140527/90694880/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140527/90694880/attachment.pgp>
------------------------------
Message: 5
Date: Tue, 27 May 2014 14:35:17 -0400
From: Tom Rondeau <address@hidden>
To: Martin Braun <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Is Simple Framer and Simple
Correllator blocks will synchronize my data?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
On Tue, May 27, 2014 at 3:51 AM, Martin Braun <address@hidden>wrote:
> Hi Irfan,
>
> you can't remove a filter delay.
>
> If all of your sync is working, the packet encoder/decoder is probably
> what you want to use -- although I think I remember you've tried that
> before...?
> In any case, to get rid of transients, prepend a preamble to your signal.
> As for the simple_* blocks, I don't think they work well over lossy
> channels (the packet decoder will allow some slack w.r.t. bit errors).
>
> Cheers,
> M
Irfan,
Also check out the correlate_access_code blocks. There are a few different
versions of these for different purposes. The tag version might be useful:
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1correlate__access__code__tag__bb.html
And a brand new version that was just checked in last week (documentation
on the web isn't updated for this since it's not in a release yet) called
correlate_access_code_ff_ts that takes floats in, finds the access code,
and produces a tagged stream out. What this means is that the block strips
off the access code and creates a stream of just the payload with a tag to
mark the start of the payload where the tag holds the payload's length. It
uses floats because it expects soft decisions and was designed to work with
FEC.
Tom
> On 27.05.2014 09:03, Irfan Ullah wrote:
>
>> Hi all,
>> I am working on QPSK Transceiver I have done all the synchronization at
>> receiver except frame delays means frame synchronization is lift. there
>> are some delays in my recieved data at start I have some garbage values
>> this delay is due to filters because filters produce one output sample
>> for N input samples (N filter Taps). I want to remove this delay so
>> please any one guide me can simple framer and simple correlator will be
>> used for this purpose? I am currently trying to design my own out of
>> tree blocks for frame synchronization but if the these two blocks(simple
>> framer and simple correlator ) are suitable for this purpose or some
>> modification is required in its code so that I can use it for my purpose.
>>
>> any help will be much appreciated and may your help will solve my many
>> problems of this transciever please help me if YOU CAN.
>>
>> Regards ,
>> Irfan Ullah
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140527/10b4415c/attachment.html>
------------------------------
Message: 6
Date: Tue, 27 May 2014 20:51:17 +0200
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] gnu radio - vhdl
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 05/27/2014 04:10 PM, MHMND Herath wrote:
> Is there a way to convert c++ blocks and connections to VHDL code for
> implementing them in digital way
Not out of the box.
M
------------------------------
Message: 7
Date: Wed, 28 May 2014 08:25:35 +1000
From: Vanush Vaswani <address@hidden>
To: Martin Braun <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] gnu radio - vhdl
Message-ID:
<CAJbabrj6K4WV-sJwo=address@hidden>
Content-Type: text/plain; charset="utf-8"
maybe one day
http://gnuradio.squarespace.com/storage/grcon13_presentations/grcon13_ettus_rfnoc.pdf
On Wed, May 28, 2014 at 4:51 AM, Martin Braun <address@hidden>wrote:
> On 05/27/2014 04:10 PM, MHMND Herath wrote:
> > Is there a way to convert c++ blocks and connections to VHDL code for
> > implementing them in digital way
>
> Not out of the box.
>
> M
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/42f4f376/attachment.html>
------------------------------
Message: 8
Date: Wed, 28 May 2014 00:52:08 +0100
From: Sid Boyce <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GNU Radio distribution and build from
source.
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 27/05/14 15:21, Tom Rondeau wrote:
> On Tue, May 27, 2014 at 10:12 AM, Marcus Leech <address@hidden
> <mailto:address@hidden>> wrote:
>
> Ideally, end-users should never have to build from source--their
> distrib-of-choice should simply have the latest Gnu Radio release in
> ? their repositories.? The reality, however, is much
> different.? The Gnu Radio project has *very little* influence
> over the policy and
> ? decisions with respect to which versions are carried in the
> repos for which Linux distributions.
> ?
> So, there are two "easy build from source" options:
> ?
> ? o build-gnuradio
> ? o pybombs
> ?
> But, well, here's the thing.? There's no such thing as "The Linux
> Operating System".? Instead there are a couple of dozen different
> ? distribs each with their own way of doing things.? ? Both
> "pybombs" and "build-gnuradio" try to encapsulate those
> differences for
> ? *some* of the "top" distributions "out there", but can't
> possibly cover all of them--not without serious amounts of maint
> activity,
> ? which means many, many, many person-hours of dedicated time.?
> We all do this for free, in our spare time.
> ?
> Gnu Radio, like many modern pieces of software has a metric tonne
> of dependencies.? This is pretty normal.? The only way to
> ? get away from that is to have the user population agree to a
> sudden and massive loss in functionality, and a release schedule
> ? that is measured in decades, as the Gnu Radio crew try to
> re-build all that functionality from "bare metal".? Modern software
> ? does a *lot* of "standing on the shoulders of giants".? That
> isn't ever likely to change.? ? When you install from the "packages"
> ? offered by your favourite distrib, all of that pain has been
> undertaken by the packagers, so all you have to do is "install".
> ? But you may end up with older Gnu Radio--sometimes, *much* older.
> ?
> Gnu Radio uses modern build tools, like Cmake, which actually do a
> *LOT* of work to configure things so that the source builds.
> ? Sometimes, on some systems, that doesn't always work right.?
> Remember the *massive* diversity-of-Linux thing I talked about
> ? above?? Well, the folks who write our Cmake files cannot, as a
> matter of practicality, always get it right for every version of
> ? every Linux disttribution out there, so, bug reports come in
> from the field, and the Cmake files become, over time, more
> ? "encompassing".
> ?
> So, short of the Gnu Radio project inventing their own,
> yet-another-build-system, and ditching all the dependencies and
> writing
> ? from "bare metal", I'm not sure that the path forward would be
> any different than what we have now.
>
>
>
> And I agree that it /should/ be easy. But the thing is, I think that
> it /is/ easy. However... One issue is that the project has evolved a
> lot over its lifetime and a lot even in the past year. So that means
> that a) there's a lot of bad information out there about working with
> older releases and b) people want the latest and greatest. So they try
> one thing, and it only gives them an older version, like 3.6, so they
> want to update. Without properly removing everything from their
> system, they try and build from scratch or use on of the build tools
> Marcus mention, which then causes conflicts. Many of the installation
> questions are really related to Linux and it just happens to be GNU
> Radio that's causing them to run into these OS problems.
>
> Tom
>
> ?
>
> ?
> on May 27, 2014, *Mike Harpe* <address@hidden
> <mailto:address@hidden>> wrote:
>
> I think the distribution and build system needs some improvement.
>
> I say that because a disproportionate amount of traffic on
> this list seems to pertain to building the software from
> source. It shouldn't be this hard given the tools that are
> available.
> ?
> Mike Harpe, N4PLE
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Ubuntu supplies 3.7.2 for 14.04, Fedora 20 and openSUSE supply 3.7.3 but
I prefer to build my own.
I use SDR apps such as quisk, qsdr and ghpsdr3-alex which have quite a
number of dependencies that help to reduce the number needed by
gnuradio. I needed only about 4 to build the latest git on Fedora 20.
Once I have built those apps, especially ghpsdr3-alex which details a
number of pre-reqs to be installed, it makes light work of building
gnuradio.
I use 3 cmake scripts, one for x86_64, one for Ubuntu x86_64 and one for
Ubuntu ARM.
x86_64 openSUSE and Fedora which use /usr/lib64
==============================
#!/bin/sh
cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7
-DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr .
Ubuntu x86_64 which uses /usr/lib
=====================
#!/bin/sh
cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7
-DPYTHON_LIBRARY=/usr/lib/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr .
ARM Ubuntu on Pandaboard, ODROID-X and Parallella-16.
===================================
#!/bin/sh
cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7
-DPYTHON_LIBRARY=/usr/lib/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr
-DENABLE_PYTHON=ON -DENABLE_VOLK=ON -DENABLE_GRC=ON ..
73 ... Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/b4cb0992/attachment.html>
------------------------------
Message: 9
Date: Wed, 28 May 2014 07:59:38 +0500
From: jason sam <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: discuss-gnuradio <address@hidden>
Subject: Re: [Discuss-gnuradio] Calling a GRC file in another GUI
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
ok but whats a hier block?
Regards,
Ali
On Tue, May 27, 2014 at 6:06 PM, Marcus M?ller <address@hidden>wrote:
> Yes, you can generate python out of that GRC file.
>
> The usual way to go is creating a GRC flowgraph, and generating a hier
> block out of that, then using that hier block in your main Python program.
>
> Greetings,
> Marcus
>
>
> On 27.05.2014 11:37, jason sam wrote:
>
> Hi,
> If i make a GUI in python language and i want to call a GRC file from that
> GUI by pressing a button or something,then it's possible to call a file
> like that??
> Regards,
> Ali
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/a7378cdc/attachment.html>
------------------------------
Message: 10
Date: Wed, 28 May 2014 11:32:25 +0800
From: Activecat <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Debian Jessie update
Message-ID:
<CANfBnZ5i43mp=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi,
I am not able to run GRC after updating my Debian Jessie. (apt-get update,
apt-get dist-upgrade, apt-get autoremove)
I am using Debian jessie. Before this GRC run well.
address@hidden: ~ $ gnuradio-config-info -v
gnuradio-config-info: error while loading shared libraries:
libboost_program_options.so.1.54.0: cannot open shared object file: No such
file or directory
~ $ uname -a
Linux rsLAPTOP 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64
GNU/Linux
~ $ gcc --version
gcc (Debian 4.8.2-21) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Probably the latest libboost doesn't work very well with gnuradio v3.7.3.
How to solve this? How to fall back?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/fd922c8c/attachment.html>
------------------------------
Message: 11
Date: Wed, 28 May 2014 08:22:56 +0200
From: "Ralph A. Schmid, dk5ras" <address@hidden>
To: "'Activecat'" <address@hidden>, <address@hidden>
Subject: Re: [Discuss-gnuradio] Debian Jessie update
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
I guess you will have to re-build everything regarding gnuradio. I did this yesterday due to an update from libboost 1.53 to 1.54.
Ralph.
From: discuss-gnuradio-bounces+ralph=address@hidden [mailto:discuss-gnuradio-bounces+ralph=address@hidden] On Behalf Of Activecat
Sent: Wednesday, May 28, 2014 5:32 AM
To: address@hidden
Subject: [Discuss-gnuradio] Debian Jessie update
Hi,
I am not able to run GRC after updating my Debian Jessie. (apt-get update, apt-get dist-upgrade, apt-get autoremove)
I am using Debian jessie. Before this GRC run well.
address@hidden: ~ $ gnuradio-config-info -v
gnuradio-config-info: error while loading shared libraries: libboost_program_options.so.1.54.0: cannot open shared object file: No such file or directory
~ $ uname -a
Linux rsLAPTOP 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 GNU/Linux
~ $ gcc --version
gcc (Debian 4.8.2-21) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Probably the latest libboost doesn't work very well with gnuradio v3.7.3.
How to solve this? How to fall back?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/1fd2212b/attachment.html>
------------------------------
Message: 12
Date: Wed, 28 May 2014 09:11:47 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Calling a GRC file in another GUI
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ali,
that's a core concept explained in the "Writing Python Applications"
tutorial and is referenced in the "How to write an OOT module"
tutorial. I was assuming you read both; if not, please do.
Greetings,
Marcus
On 28.05.2014 04:59, jason sam wrote:
> ok but whats a hier block? Regards, Ali
>
>
> On Tue, May 27, 2014 at 6:06 PM, Marcus M?ller
> <address@hidden>wrote:
>
>> Yes, you can generate python out of that GRC file.
>>
>> The usual way to go is creating a GRC flowgraph, and generating a
>> hier block out of that, then using that hier block in your main
>> Python program.
>>
>> Greetings, Marcus
>>
>>
>> On 27.05.2014 11:37, jason sam wrote:
>>
>> Hi, If i make a GUI in python language and i want to call a GRC
>> file from that GUI by pressing a button or something,then it's
>> possible to call a file like that?? Regards, Ali
>>
>>
>>
>>
>> _______________________________________________ Discuss-gnuradio
>> mailing
>> address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>>
_______________________________________________
>> Discuss-gnuradio mailing list address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJThYwzAAoJEBQ6EdjyzlHt7osIAIvGe+hTX0kRitb8zye3V5Wo
WF8H2uzQVoeJLL4TxLb15p9GUv3SIWLmlWYYE3C9BfRstbCIokh+oFfHfCf9QVRn
fe+Gx9toKXuHSW87cEvpemQf1TVC/wgmQx4DwlQ99vwsoEIXud/C2PFk/Msbzh2J
G1sEdMkSupZTNX5S/Emv0mc14uKHKR4wGetDBU4JoKoPYX4QbgfnZSlmOrSLM/yk
HHNSpZJnigt/jQ4TQaC/i2dvN8wQJ+QZHKbvwD98FhZ83keIW0dpMpIvmYBme8zf
vgkITZ73uNXBfWN48R2nFyD+3G641q6nD2dg2ganxZmfjRdB/nxdLzPZZGx8F6U=
=0Kws
-----END PGP SIGNATURE-----
------------------------------
Message: 13
Date: Wed, 28 May 2014 13:15:52 +0530
From: Karan Talasila <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] assertion error beyond 4096 output items
Message-ID:
<CAOqO_Xh5Q7M+GyoLugRXT_P4SSivQCifnAkQsidr=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi
we have written a c++ block using out of tree modules which uses a sync
block that outputs same no of items as input items given. we have written a
python test file where the inputs and outputs are complex floats. The test
code is running well until 4096 items. But when the output items size is
greater than or equal to 8192, ctest shows an assertion error which says
-10+5j !=10+5j beyond 7 places.
we are unsure what the error is. Is it got something to do with gnuradio
architecture with limitation beyond 4096*2 items or is it anything else we
are doing wrong. I cannot see an error in the logic of the program. I can
attach the program if necessary.
--
Regards
Karan Talasila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/7da76d68/attachment.html>
------------------------------
Message: 14
Date: Wed, 28 May 2014 10:16:15 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Karan,
how does your test look like?
Usually, to test a blocks functionality, you construct a minimal flow
graph in the python test script:
vector_source->block under test->vector sink
fill it with sample data, and let GNU Radio run that flowgraph.
Then you have no control on how large your noutput_items is, because
this is up to GNU Radio to decide
at runtime.
Generally, it'd be nice to know which version of GNU Radio you are
running etc.
If you want to share your code, best way to do this is usually either
pasting just the C++ block and the python test to
pastebin or gist.github.com, or even better, making a git repo out of
your project and pushing it to github or similar.
Greetings,
Marcus
On 28.05.2014 09:45, Karan Talasila wrote:
> Hi
> we have written a c++ block using out of tree modules which uses a sync
> block that outputs same no of items as input items given. we have written a
> python test file where the inputs and outputs are complex floats. The test
> code is running well until 4096 items. But when the output items size is
> greater than or equal to 8192, ctest shows an assertion error which says
>
> -10+5j !=10+5j beyond 7 places.
>
> we are unsure what the error is. Is it got something to do with gnuradio
> architecture with limitation beyond 4096*2 items or is it anything else we
> are doing wrong. I cannot see an error in the logic of the program. I can
> attach the program if necessary.
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/49df1b93/attachment.html>
------------------------------
Message: 15
Date: Wed, 28 May 2014 17:09:50 +0800
From: Activecat <address@hidden>
To: "Ralph A. Schmid, dk5ras" <address@hidden>,
"address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Debian Jessie update
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
On Wed, May 28, 2014 at 2:22 PM, Ralph A. Schmid, dk5ras
<address@hidden>wrote:
> I guess you will have to re-build everything regarding gnuradio. I did
> this yesterday due to an update from libboost 1.53 to 1.54.
>
> Ralph.
>
Yes, re-installation solves the problem.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/73ba565f/attachment.html>
------------------------------
Message: 16
Date: Wed, 28 May 2014 11:13:59 +0200
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 28.05.2014 09:45, Karan Talasila wrote:
> Hi
> we have written a c++ block using out of tree modules which uses a
> sync block that outputs same no of items as input items given. we have
> written a python test file where the inputs and outputs are complex
> floats. The test code is running well until 4096 items. But when the
> output items size is greater than or equal to 8192, ctest shows an
> assertion error which says
>
> -10+5j !=10+5j beyond 7 places.
This looks like floating point quantization errors. Show us your QA, and
make sure you're using the assertFloatTuplesAlmostEqual (not sure if
that's the right name) call.
M
------------------------------
Message: 17
Date: Wed, 28 May 2014 11:16:03 +0200
From: Wafa Elhajhmida <address@hidden>
To: Marcus M?ller <address@hidden>, Marcus Leech
<address@hidden>, discuss-gnuradio <address@hidden>,
Ettus Research Support <address@hidden>,
address@hidden, usrp-users-request
<address@hidden>
Subject: [Discuss-gnuradio] Unable to log in usrpe 110 to get access
to gnuradio on screen?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi,
I made a reboot of the usrp e110. I got on the screen a button login.
But I'm unable to login with a mouse. In fact, the mouse doesn't work on
usrp. But the mouse works well on my laptop.
In fact, I even connected the mouse directly to a usrp e100 with a cable
which is provided by Ettus(on host port).
According to you what can be the problem ?
Best regards,
Wafa HAJ HMIDA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/94b4abf8/attachment.html>
------------------------------
Message: 18
Date: Wed, 28 May 2014 11:17:42 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Debian Jessie update
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
To explain: Binaries are generally linked against binaries, ie.
against a certain set of symbols only present in a certain build of a
binary; thus, usually libraries link against specific versionized
libraries.
If you update a library, binaries linked against the old version are
bound to stop working. In most unixoid systems, this is circumvented
(sometimes) by having the ability to have multiple libraries in
different versions installed [1](libgrandmascheesecake.so.1.0.0,
libgrandmascheesecake.so.1.1.2) and a symlink from the general name to
the recent one (libgrandmascheesecake.so ->
libgrandmascheesecake.so.1.1.2). However, usually you don't want to
have conflicting versions, so package management usually goes miles to
ensure that all packages in a certain distribution version are built
against the same library version.
Greetings,
Marcus
[1] windows-y systems usually ship all the libraries in the same
directory as the executable, which is --from a storage point of view--
quite like static linking.
On 28.05.2014 11:09, Activecat wrote:
> On Wed, May 28, 2014 at 2:22 PM, Ralph A. Schmid, dk5ras
> <address@hidden>wrote:
>
>> I guess you will have to re-build everything regarding gnuradio.
>> I did this yesterday due to an update from libboost 1.53 to
>> 1.54.
>>
>> Ralph.
>>
>
> Yes, re-installation solves the problem. Thanks.
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTham2AAoJEBQ6EdjyzlHtDcwIAItAbigJQVIVc/FKgaFIUCM/
dm8LoLnZOFAov5ssERAdcRIkWD1eu9lzEkZ3pjo7UEUZGepvAWgw6BuSGDilg38K
PlCkVH9pdbwTj6Uvhj+ZXDf4i+NM9E5ZVyIxrrl9kM9C1aj+bxFEX4g4oq5ey0Hc
Q5/Joct7e0/UJ93UobBdeooQdiy40pZ14KH3xsWTJtXRQ3PDv8cskbvckr+ba6lb
dJI8I+tRhAIF6EBtkfJB3hSyt9qzIW1YTi9Sb3cC2XjO+50s0f/60/ZNwKjQ1q+m
Zan/5nJ3ikOrmOcsHLmjpekjrzCgFhyzipmFC8i1XKYfDSBd4GlHw/wg9su/IUY=
=pGQ/
-----END PGP SIGNATURE-----
------------------------------
Message: 19
Date: Wed, 28 May 2014 11:28:37 +0200
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 28.05.2014 11:13, Martin Braun wrote:
> On 28.05.2014 09:45, Karan Talasila wrote:
>> Hi
>> we have written a c++ block using out of tree modules which uses a
>> sync block that outputs same no of items as input items given. we have
>> written a python test file where the inputs and outputs are complex
>> floats. The test code is running well until 4096 items. But when the
>> output items size is greater than or equal to 8192, ctest shows an
>> assertion error which says
>>
>> -10+5j !=10+5j beyond 7 places.
>
> This looks like floating point quantization errors. Show us your QA, and
> make sure you're using the assertFloatTuplesAlmostEqual (not sure if
> that's the right name) call.
Ah, as Marcus M points out, this is a signature error, rather than
quantization :)
Still, this all points to your code being incorrect, or your QA making
invalid assumptions.
Maybe you should be tracking state in your block (these number indicate
that more than 1 work function call seem unveil your bug).
M
------------------------------
Message: 20
Date: Wed, 28 May 2014 17:30:10 +0800
From: Activecat <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Debian Jessie update
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
On Wed, May 28, 2014 at 5:17 PM, Marcus M?ller <address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> To explain: Binaries are generally linked against binaries, ie.
> against a certain set of symbols only present in a certain build of a
> binary; thus, usually libraries link against specific versionized
> libraries.
>
> If you update a library, binaries linked against the old version are
> bound to stop working. In most unixoid systems, this is circumvented
> (sometimes) by having the ability to have multiple libraries in
> different versions installed [1](libgrandmascheesecake.so.1.0.0,
> libgrandmascheesecake.so.1.1.2) and a symlink from the general name to
> the recent one (libgrandmascheesecake.so ->
> libgrandmascheesecake.so.1.1.2). However, usually you don't want to
> have conflicting versions, so package management usually goes miles to
> ensure that all packages in a certain distribution version are built
> against the same library version.
>
> Greetings,
> Marcus
>
> [1] windows-y systems usually ship all the libraries in the same
> directory as the executable, which is --from a storage point of view--
> quite like static linking.
>
Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/b2344c2c/attachment.html>
------------------------------
Message: 21
Date: Wed, 28 May 2014 15:30:41 +0530
From: Karan Talasila <address@hidden>
To: Martin Braun <address@hidden>, address@hidden
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID:
<CAOqO_XiFkGOJYVMYCL=address@hidden>
Content-Type: text/plain; charset="utf-8"
@Marcus. Instead of using a grc gui flowgraph to test our block, we have
written a qa test code in python which connects vector source, block that
we are testing and vector sink just like the example given in out of tree
modules to generate square of the input items.
We are writing an alamouti code block which takes in an input stream of N
complex numbers and gives out 2 output steams of N items each. I will
attach the C++ code of block( http://pastebin.com/Kdnk1t8x ) and also the
python qa test code below(http://pastebin.com/da21Ww4B).
<http://pastebin.com/da21Ww4B>
On Wed, May 28, 2014 at 2:58 PM, Martin Braun <address@hidden>wrote:
> On 28.05.2014 11:13, Martin Braun wrote:
>
>> On 28.05.2014 09:45, Karan Talasila wrote:
>>
>>> Hi
>>> we have written a c++ block using out of tree modules which uses a
>>> sync block that outputs same no of items as input items given. we have
>>> written a python test file where the inputs and outputs are complex
>>> floats. The test code is running well until 4096 items. But when the
>>> output items size is greater than or equal to 8192, ctest shows an
>>> assertion error which says
>>>
>>> -10+5j !=10+5j beyond 7 places.
>>>
>>
>> This looks like floating point quantization errors. Show us your QA, and
>> make sure you're using the assertFloatTuplesAlmostEqual (not sure if
>> that's the right name) call.
>>
>
> Ah, as Marcus M points out, this is a signature error, rather than
> quantization :)
> Still, this all points to your code being incorrect, or your QA making
> invalid assumptions.
>
> Maybe you should be tracking state in your block (these number indicate
> that more than 1 work function call seem unveil your bug).
>
>
> M
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
--
Regards
Karan Talasila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/a8da5460/attachment.html>
------------------------------
Message: 22
Date: Wed, 28 May 2014 12:02:32 +0200
From: Marcus M?ller <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8
Hi!
On 28.05.2014 12:00, Karan Talasila wrote:
> @Marcus. Instead of using a grc gui flowgraph to test our block, we have
> written a qa test code in python which connects vector source, block that
> we are testing and vector sink just like the example given in out of tree
> modules to generate square of the input items.
Excellent, that's what I meant to suggest :)
> We are writing an alamouti code block which takes in an input stream of N
> complex numbers and gives out 2 output steams of N items each. I will
> attach the C++ code of block( http://pastebin.com/Kdnk1t8x ) and also the
> python qa test code below(http://pastebin.com/da21Ww4B).
> <http://pastebin.com/da21Ww4B>
Thanks, will have a look at it.
Greetings,
Marcus
>
> On Wed, May 28, 2014 at 2:58 PM, Martin Braun <address@hidden>wrote:
>
>> On 28.05.2014 11:13, Martin Braun wrote:
>>
>>> On 28.05.2014 09:45, Karan Talasila wrote:
>>>
>>>> Hi
>>>> we have written a c++ block using out of tree modules which uses a
>>>> sync block that outputs same no of items as input items given. we have
>>>> written a python test file where the inputs and outputs are complex
>>>> floats. The test code is running well until 4096 items. But when the
>>>> output items size is greater than or equal to 8192, ctest shows an
>>>> assertion error which says
>>>>
>>>> -10+5j !=10+5j beyond 7 places.
>>>>
>>> This looks like floating point quantization errors. Show us your QA, and
>>> make sure you're using the assertFloatTuplesAlmostEqual (not sure if
>>> that's the right name) call.
>>>
>> Ah, as Marcus M points out, this is a signature error, rather than
>> quantization :)
>> Still, this all points to your code being incorrect, or your QA making
>> invalid assumptions.
>>
>> Maybe you should be tracking state in your block (these number indicate
>> that more than 1 work function call seem unveil your bug).
>>
>>
>> M
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
------------------------------
Message: 23
Date: Wed, 28 May 2014 12:10:41 +0200
From: Marcus M?ller <address@hidden>
To: Karan Talasila <address@hidden>, Martin Braun
<address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8
Your Problem is actually here:
(C++ work function)
" while ( i < d_fft_length ) {"
you never check that your in[] and out[] indices are within noutput_items!
You only get a limited amount of items per work call. For sync blocks,
this is noutput_items.
What you do is just ignore that number, take d_fft_length items (whether
there are more or less
available) and process them. Then you "return noutput_items", which is
also wrong,
because you actually process d_fft_length.
What you most probably want to do is either directly process vectors, or
set an output multiple.
A vector is actually just an item with vector_length*single_itemsize
size, so you need to change your in- and
output signatures by multiplying sizeof(whatever) with fft_length; then,
in your work, you only process
one vector, thus you should return 1;.
If you use set_output_multiple, your item size stays the same
(sizeof(gr_complex)), and you don't have to change your code,
aside from replacing return noutput_items by what you've actually
consumed (ie. d_fft_length).
Greetings,
Marcus
On 28.05.2014 12:00, Karan Talasila wrote:
> @Marcus. Instead of using a grc gui flowgraph to test our block, we have
> written a qa test code in python which connects vector source, block that
> we are testing and vector sink just like the example given in out of tree
> modules to generate square of the input items.
>
> We are writing an alamouti code block which takes in an input stream of N
> complex numbers and gives out 2 output steams of N items each. I will
> attach the C++ code of block( http://pastebin.com/Kdnk1t8x ) and also the
> python qa test code below(http://pastebin.com/da21Ww4B).
> <http://pastebin.com/da21Ww4B>
>
>
> On Wed, May 28, 2014 at 2:58 PM, Martin Braun <address@hidden>wrote:
>
>> On 28.05.2014 11:13, Martin Braun wrote:
>>
>>> On 28.05.2014 09:45, Karan Talasila wrote:
>>>
>>>> Hi
>>>> we have written a c++ block using out of tree modules which uses a
>>>> sync block that outputs same no of items as input items given. we have
>>>> written a python test file where the inputs and outputs are complex
>>>> floats. The test code is running well until 4096 items. But when the
>>>> output items size is greater than or equal to 8192, ctest shows an
>>>> assertion error which says
>>>>
>>>> -10+5j !=10+5j beyond 7 places.
>>>>
>>> This looks like floating point quantization errors. Show us your QA, and
>>> make sure you're using the assertFloatTuplesAlmostEqual (not sure if
>>> that's the right name) call.
>>>
>> Ah, as Marcus M points out, this is a signature error, rather than
>> quantization :)
>> Still, this all points to your code being incorrect, or your QA making
>> invalid assumptions.
>>
>> Maybe you should be tracking state in your block (these number indicate
>> that more than 1 work function call seem unveil your bug).
>>
>>
>> M
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
------------------------------
Message: 24
Date: Wed, 28 May 2014 20:23:55 +1000
From: Vanush Vaswani <address@hidden>
To: Bogdan Diaconescu <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] GNU Radio Measurement Toolbox -- GSoC
'14 Project
Message-ID:
<CAJbabrjyyuHAGoWYSf1=yY030Xe18miO5rjzNBb24TwKk=Ye=address@hidden>
Content-Type: text/plain; charset="utf-8"
https://github.com/guruofquality/gras/wiki/History
On Mon, May 26, 2014 at 6:46 AM, Bogdan Diaconescu
<address@hidden>wrote:
> Hi Marcus,
>
> take your time :) this is not a simple problem to solve and hence it does
> not have a simple solution. I like the idea of starting with changing the
> scheduler behaviour first to experiment with. Indeed it will take a lot of
> measurements, talks, experiments (not exactly in this order) to understand
> what is to be optimized.
>
> But this talk is touching the gnuradio scheduler area which is an area of
> its own and it brings me to one question: what happen with GRAS?
>
> Thanks,
> Bogdan
>
>
> On Sunday, May 25, 2014 10:14 PM, Marcus M?ller <address@hidden>
> wrote:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Bogdan,
>
> thanks for your comment :)
>
> Such an optimizer would be really, really fancy.
>
> In a way, though, GNU Radio already does this when running a flow
> graph: It just asks blocks to compute a reasonable amount of items to
> fill up the downstream buffer. This actually (conceptually simple)
> approach is one great strength, because it just keeps the computer
> "busy" as much as possible.
>
> There might be space for optimization, though, I agree: Maybe it would
> be better for some blocks just to wait longer (and thus, not utilize
> the CPU) if it was computationally beneficial to work on larger
> chunks, as long as there are enough other blocks competing for CPU power.
>
> However, this leads to the problem of balancing average throughput
> with latency.
>
> What the GNU Radio infrastructure does to approach this is actually
> quite simple:
> 1. Although it might be "fastest" to process all data at once, buffer
> lengths set a natural limit to the chunk size, and thus latency. So we
> have an upper boundary.
> 2. It is best to be closest possible to that upper boundary. To
> achieve that, block developers are always encouraged to consume as
> many input items and produce as much output as possible, even if the
> overhead of having multiple (general_)work calls is minute. This
> ensures that adjacent blocks don't get asked to produce / consume
> small item chunks (which will happen if they were in a waiting state
> and a small number of items was produced or a small amount of output
> buffer was marked as read).
>
> Optimizing this will be hard. Maybe one could profile the same
> flowgraph with a lot of different settings of per-block maximum output
> chunk sizes, but I do believe this will only give as little more
> information than what the block developer already knew when he
> optimized the block in the first place. If he didn't optimize, his
> main interest will be if his block poses a problem at at all; for
> that, standard settings should be employed.
>
> To give developers an API to inform the runtime of item amount
> preference, different methods exist, however. I'll give a short
> rundown of them.
>
> 1. Most notable are the ``fixed_rate properties`` of ``gr::block``, as
> implemented in ``sync_block``, and the ``decimator`` and
> ``interpolator`` block types
> 2. If your block will only produce a multiples of a certain number of
> items, the ``set_output_multiple`` is a method that will potentially
> decrease overhead introduced by pointless calls to ``forecast`` and/or
> ``work``.
> 3. In hardware optimization, alignment is often the performance
> critical factor. To account for that, set_alignment was introduced.
> It's working very similar to ``set_output_multiple``, but does not
> *enforce* the multiples, but sets an unaligned flag if non-multiple
> consumption occurred. The runtime will always try to achieve that the
> start of your current item chunk is memory-aligned to a certain item
> multiple. If however less was produced, your block might still be
> called, to keep the data flowing.
>
> To properly apply these flags, you'll basically need a human
> understanding of what the block does. It may, nevertheless, be very
> helpful to understand how well your block performs with different item
> chunk sizes. To realize that, some mechanism to change scheduling
> behavior
>
> I will look into that; I think it should be possible to manipulate the
> ``block_executors`` to manipulate them into changing their
> forecasting/work calling behavior at runtime, but I'm quite sure that
> this will bring new code into the main tree[1].
>
> All in all, right now I'm really stuck with what I actually want to
> improve with the performance analysis of GNU Radio flowgraphs offered
> by performance counters/gr-perf-monitorx, because they address many of
> these issues already. Your execution-per-item over chunk size idea is
> excellent!
>
> So long,
> Greetings,
> Marcus
>
> [1] I'll really have to take a deeeep look at block_executor and the
> tpb scheduler to tell; if I decide to add functionality that
> introduces significant runtime overhead or changes too much of
> internal behaviour, noone will be pleased, so I might take this slow
> and will have to discuss it with experienced core developers. I'm not
> very hesitant when it comes to fiddling with in-tree source code, but
> my workings almost never make it to the public, because I always
> figure they don't address a problem properly or break too much in
> comparison to what they can possibly improve.
>
> On 25.05.2014 19:34, Bogdan Diaconescu wrote:
> > Hi Marcus,
> >
> > I like the approach you take by looking at what real life users
> > will want from gnuradio when transitioning from an academic
> > perspective to realtime system. Measurements are always not enough
> > to understand the specifics of your system so I'm looking forward
> > to see how your project provides measurements to the gnuradio
> > user.
> >
> >
> > Building on block computing performance measurements there is one
> > thing I would like to see in gnuradio and that is a flowgraph
> > optimizer.
> >
> >
> > To be more specific, a flowgraph optimizer would try to adapt the
> > parameters of the blocks (e.g. the data chunk passed to each block)
> > in order to optimize one/more parameter(s) of a flowgraph (e.g.
> > overall processing time). In a normal way this optimizer should be
> > run just once to determine the optimum parameters that will be used
> > subsequently. If we see the problem to solve from a general
> > perspective the optimizer would fall in the category of
> > multi-objective optimization which has a numerous solutions and has
> > been thoroughly discussed in the academia and industry (gaming is
> > usualy doing multi-bjective optimization through AI). Another
> > real-life example would be the optimizer in the 4Nec2 antenna
> > simulation program that uses AI to optimize the antenna when a set
> > of objectives (variables) is set by the user, e.g. minimum SWR, Z
> > close to a value, etc.
> >
> > In my opinion gnuradio will really benefit from such an optimizer
> > as the values of block parameters can provide quite different end
> > results.
> >
> > Not sure if this can be part of your GSOC project but I thought it
> > worth mentioning to you and gnuradio users on this list. Maybe can
> > be part of the next GSOC.
> >
> > Thanks, Bogdan
> >
> >
> >
> >
> >
> >
> >
> > On Thursday, May 22, 2014 7:49 PM, Marcus M?ller
> > <address@hidden> wrote:
> >
> >
> >
> > Hi, GR community!
> >
> > I was elected to do a Google Summer of Code project. Thanks for
> > all the constructive feedback on my proposal, and all the support,
> > ideas and hints I got the last weeks!
> >
> > As I just finished setting up my blog, I'm now happy to announce
> > the beginning of the GNU Radio Measurement Toolbox.
> >
> > Its purposes are basically two-fold: 1. Ease the process of
> > gathering data through changing flowgraph characteristics to get
> > things like BER curves out of GNU Radio, and 2. Help optimizing GNU
> > Radio and VOLK by offering the same automated data gathering for
> > performance data.
> >
> > This covers generating a few measurement blocks, writing a
> > framework to let developers run their flowgraphs through a
> > pre-defined set of parametrizations, evaluating performance
> > counters, dealing with the gathered data, visualization and
> > automated task distribution.
> >
> > To not bore you to death here on the mailing list, I've made an
> > introductory blog entry [1]. You may find it on
> > http://gsoc.hostalia.de
> >
> > Then, there will be code; you will find that on my github page
> > [2].
> >
> > Looking forward to a load of criticism, and even more fun hacking,
> >
> > Greetings, Marcus
> >
> >
> > [1]
> >
> http://gsoc.hostalia.de/posts/a-measurement-toolbox-for-gnu-radio-my-google-summer-of-code-project.html
> >
> > _______________________________________________ Discuss-gnuradio
> > mailing list address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTgkEuAAoJEBQ6EdjyzlHtM54H/0cXRJiq7y0qdrm7N0jdeHVj
> vu9Tjbl6XfvPUwHnPejfi/OPskQVTfTF+3sMDtQ3QWXW5K+HBPob7ci7xpTOob3z
> zmkHBzXK+7X3Uvgfo0zV7zp1cnMWwCsnIdzK7aOelusK7unGZps5Zh7kUoSbqcto
> Dajf5RfG4YbCCzkv30Ykg5i3tqSPWtqDKqWsZnEC1wIBR7eLS9UgCn98CawhJYhB
> ittApa73nNcPtJl8Q6REzWufXRqa6asmxdZwXYqFguQrYUueqxUAtphwv1Sy4Ync
> BXAEyj48saXsvzmL2li0S4A8CC7dydPwAJnwTczS0cAlwuS2/c/J9BtwdOappUM=
> =A0bm
>
> -----END PGP SIGNATURE-----
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/e195f239/attachment.html>
------------------------------
Message: 25
Date: Wed, 28 May 2014 14:03:58 +0200
From: Wafa Elhajhmida <address@hidden>
To: Marcus M?ller <address@hidden>, Marcus Leech
<address@hidden>, discuss-gnuradio <address@hidden>,
Ettus Research Support <address@hidden>,
address@hidden, usrp-users-request
<address@hidden>
Subject: Re: [Discuss-gnuradio] Unable to log in usrpe 110 to get
access to gnuradio on screen?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Please any suggestion is appreciated.
Thanks in advance.
Best regards,
Wafa HAJ HMIDA
2014-05-28 11:16 GMT+02:00 Wafa Elhajhmida <address@hidden>:
> Hi,
>
> I made a reboot of the usrp e110. I got on the screen a button login.
>
> But I'm unable to login with a mouse. In fact, the mouse doesn't work on
> usrp. But the mouse works well on my laptop.
>
> In fact, I even connected the mouse directly to a usrp e100 with a cable
> which is provided by Ettus(on host port).
>
> According to you what can be the problem ?
>
> Best regards,
>
> Wafa HAJ HMIDA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/1aad2dcb/attachment.html>
------------------------------
Message: 26
Date: Wed, 28 May 2014 18:06:28 +0530
From: Karan Talasila <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thank you for evaluating our code and help debugging it.
what we understand from your reply is that work function at a time
processes noutput_items and this can be lesser than or more than the
fft_length. As an example in our code when we give the fft length as 8192,
but the noutput_items is still 4096, so does that mean it has to execute
work function twice to process 4096*2=8192 items?
Regarding the first approach you suggested, we change the input signature
and output signature to (sizeof (gr_complex)*fft_length) so that it is a
single vector that is being processed. Then we return 1 as suggested. But
it is throwing an itemsize mismatch error. I have attached the c++ file
here ( http://pastebin.com/TKemtbxN ). The error says
ERROR: test_001_t (__main__.qa_al_enc)
2: ------------------------------
----------------------------------------
2: Traceback (most recent call last):
2: File "/home/sagar/gr-alamouti/python/qa_al_enc.py", line 66, in
test_001_t
2: self.tb.connect(src,opr)
2: File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line
130, in connect
2: self._connect(points[i-1], points[i])
2: File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line
142, in _connect
2: dst_block.to_basic_block(), dst_port)
2: File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
4350, in primitive_connect
2: return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
2: ValueError: itemsize mismatch: vector_source_c1:0 using 8, al_enc1:0
using 65536
The python qa file link is (http://pastebin.com/da21Ww4B).
<http://pastebin.com/da21Ww4B>
For the second method suggested should we write a general work function and
a forecast function which would mean doing away with sync block that we are
using with work function right now?
<http://pastebin.com/da21Ww4B>
On Wed, May 28, 2014 at 3:40 PM, Marcus M?ller <address@hidden>wrote:
> Your Problem is actually here:
> (C++ work function)
> " while ( i < d_fft_length ) {"
>
> you never check that your in[] and out[] indices are within noutput_items!
> You only get a limited amount of items per work call. For sync blocks,
> this is noutput_items.
> What you do is just ignore that number, take d_fft_length items (whether
> there are more or less
> available) and process them. Then you "return noutput_items", which is
> also wrong,
> because you actually process d_fft_length.
>
> What you most probably want to do is either directly process vectors, or
> set an output multiple.
> A vector is actually just an item with vector_length*single_itemsize
> size, so you need to change your in- and
> output signatures by multiplying sizeof(whatever) with fft_length; then,
> in your work, you only process
> one vector, thus you should return 1;.
>
> If you use set_output_multiple, your item size stays the same
> (sizeof(gr_complex)), and you don't have to change your code,
> aside from replacing return noutput_items by what you've actually
> consumed (ie. d_fft_length).
>
> Greetings,
> Marcus
>
> On 28.05.2014 12:00, Karan Talasila wrote:
> > @Marcus. Instead of using a grc gui flowgraph to test our block, we have
> > written a qa test code in python which connects vector source, block that
> > we are testing and vector sink just like the example given in out of tree
> > modules to generate square of the input items.
> >
> > We are writing an alamouti code block which takes in an input stream of N
> > complex numbers and gives out 2 output steams of N items each. I will
> > attach the C++ code of block( http://pastebin.com/Kdnk1t8x ) and also
> the
> > python qa test code below(http://pastebin.com/da21Ww4B).
> > <http://pastebin.com/da21Ww4B>
> >
> >
> > On Wed, May 28, 2014 at 2:58 PM, Martin Braun <address@hidden
> >wrote:
> >
> >> On 28.05.2014 11:13, Martin Braun wrote:
> >>
> >>> On 28.05.2014 09:45, Karan Talasila wrote:
> >>>
> >>>> Hi
> >>>> we have written a c++ block using out of tree modules which uses
> a
> >>>> sync block that outputs same no of items as input items given. we have
> >>>> written a python test file where the inputs and outputs are complex
> >>>> floats. The test code is running well until 4096 items. But when the
> >>>> output items size is greater than or equal to 8192, ctest shows an
> >>>> assertion error which says
> >>>>
> >>>> -10+5j !=10+5j beyond 7 places.
> >>>>
> >>> This looks like floating point quantization errors. Show us your QA,
> and
> >>> make sure you're using the assertFloatTuplesAlmostEqual (not sure if
> >>> that's the right name) call.
> >>>
> >> Ah, as Marcus M points out, this is a signature error, rather than
> >> quantization :)
> >> Still, this all points to your code being incorrect, or your QA making
> >> invalid assumptions.
> >>
> >> Maybe you should be tracking state in your block (these number indicate
> >> that more than 1 work function call seem unveil your bug).
> >>
> >>
> >> M
> >>
> >>
> >> _______________________________________________
> >> Discuss-gnuradio mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> >
>
>
--
Regards
Karan Talasila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/2ae74d79/attachment.html>
------------------------------
Message: 27
Date: Wed, 28 May 2014 21:13:24 +0800
From: Activecat <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Dynamically changing input index of
Selector block.
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
On Tue, May 27, 2014 at 3:07 PM, dushyant.marathe <address@hidden
> wrote:
> My GRC flow graph design is as follows:
>
> Two different signal sources => selector (with 2 input & 1 output) => scope
>
> Now I want to change input index of 'Selector' block automatically so that
> for fixed time 1st input is selected and then 2nd.
>
You may try to use Stream Mux, not Selector.
When its Lengths is determined correctly, it select 1st input for a
predetermined fixed time, then select 2nd input.
In this case the second number of Length is a big number, approximate
infinity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/27fb82bf/attachment.html>
------------------------------
Message: 28
Date: Wed, 28 May 2014 06:25:04 -0700 (PDT)
From: "dushyant.marathe" <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Out of Tree Encryption block
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
I want to simulate a voice transmission system in GNURadio Companion (GRC).
My system configuration is as follows:
TRANSMITTER : Wav file source --> encoder --> encryption --> modulator -->
RF
RECEIVER : speaker/Wav file sink <-- decoder <-- decryption <-- demodulator
<-- RF
I have simulated the above configuration in Ubuntu 12.04 machine but
without
encryption/decryption blocks.
If you can point me to an existing OoTM of digital encryption, it would be
nice.
Thanks and Regards,
Dushyant
--
View this message in context: http://gnuradio.4.n7.nabble.com/Out-of-Tree-Encryption-block-tp48595.html
Sent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 29
Date: Wed, 28 May 2014 09:43:10 -0400
From: "West, Nathan" <address@hidden>
To: Wafa Elhajhmida <address@hidden>
Cc: discuss-gnuradio <address@hidden>
Subject: Re: [Discuss-gnuradio] Unable to log in usrpe 110 to get
access to gnuradio on screen?
Message-ID:
<CALkxiLJ3iPP=address@hidden>
Content-Type: text/plain; charset=UTF-8
On Wed, May 28, 2014 at 8:03 AM, Wafa Elhajhmida
<address@hidden> wrote:
> Please any suggestion is appreciated.
>
> Thanks in advance.
>
> Best regards,
>
> Wafa HAJ HMIDA
>
>
>
>
> 2014-05-28 11:16 GMT+02:00 Wafa Elhajhmida <address@hidden>:
>
>> Hi,
>>
>> I made a reboot of the usrp e110. I got on the screen a button login.
>>
>> But I'm unable to login with a mouse. In fact, the mouse doesn't work on
>> usrp. But the mouse works well on my laptop.
>>
>> In fact, I even connected the mouse directly to a usrp e100 with a cable
>> which is provided by Ettus(on host port).
>>
>> According to you what can be the problem ?
>>
>> Best regards,
>>
>> Wafa HAJ HMIDA
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
First of all, your method of asking questions is ineffective. For a
guide on how to get better help read this:
http://www.catb.org/esr/faqs/smart-questions.html . I would especially
like to point you to "Choose your forum carefully" where this
particular email violates at least 3 (and possibly 4 based on
perspective) of the first 4 bullet points. There's no need for this to
be cross-listed to 3 mailing lists, a corporate support account, and 2
individuals. Also, this e-mail has nothing to do with GNU Radio.
Second, I have no idea why your mouse doesn't work. If it used to
work, you did something, and now it doesn't work then whatever you did
probably had a side affect of breaking your mouse.
Finally, based on your previous mailing list posts and irc chats you
seem overwhelmed. My only real comment here is that you probably need
more help/support than anyone can give over a mailing list. Perhaps
you would be better off backing up from your final goal and learning
more about GNU Radio on a standard PC and then try porting your work
to an embedded device. Alternatively maybe you could also take some
time to learn more about embedded systems (there's lots of classes
on-line and every university should have a couple). It might also help
if you hired someone to come in and do some work for you and you could
learn from them on the job.
Nathan
------------------------------
Message: 30
Date: Wed, 28 May 2014 19:28:27 +0530
From: gsmandvoip <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] spectrum chunk
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
dear list,
I am digging to find out how to record a frequency bandwidth e.g.
1100-1125MHz;
I already have USRP1 with DBRX, which I suppose able to capture 25MHz
frequency bandwidth as per their specification.
I played around ursp_rx_cfile but with single frequency, now I want to
record a frequency spectrum then later wish to divide it into several
frequency parts (which I presume can be done by channelizing, but any other
idea most welcome).
Taking above idea in my mind I am confused as if DDC of URSP (any
combination of rbf files) is able to process this much data??
if yes, please guide me where to strike first??
is GRC good way to go ahead??
guidance is highly appreciated
Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/b34e1761/attachment.html>
------------------------------
Message: 31
Date: Wed, 28 May 2014 16:15:55 +0200
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] spectrum chunk
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On a USRP1, you can get 8 MHz across the wire (16 MHz if you go to 8 bit
samples). This is a matter of USB2.0 not being able to transport more data.
Once you have a chunk, channelization is the way to go, and GRC is
generally a good tool to use.
M
On 28.05.2014 15:58, gsmandvoip wrote:
> dear list,
> I am digging to find out how to record a frequency bandwidth e.g.
> 1100-1125MHz;
> I already have USRP1 with DBRX, which I suppose able to capture 25MHz
> frequency bandwidth as per their specification.
> I played around ursp_rx_cfile but with single frequency, now I want to
> record a frequency spectrum then later wish to divide it into several
> frequency parts (which I presume can be done by channelizing, but any
> other idea most welcome).
> Taking above idea in my mind I am confused as if DDC of URSP (any
> combination of rbf files) is able to process this much data??
> if yes, please guide me where to strike first??
> is GRC good way to go ahead??
> guidance is highly appreciated
> Thanks in advance
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 32
Date: Wed, 28 May 2014 23:14:43 +0800
From: Activecat <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] assertion error beyond 4096 output
items
Message-ID:
<CANfBnZ6DA8zQNYKJjrvbLPq=XFC9-EsivrkAmTyDpJ9cP0=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Karan,
You keep Marcus very busy, let me help to offload him.
On Wed, May 28, 2014 at 8:36 PM, Karan Talasila <address@hidden> wrote:
> Hi Marcus,
> Thank you for evaluating our code and help debugging it. what we
> understand from your reply is that work function at a time processes
> noutput_items and this can be lesser than or more than the fft_length. As
> an example in our code when we give the fft length as 8192, but the
> noutput_items is still 4096, so does that mean it has to execute work
> function twice to process 4096*2=8192 items?
>
When the desirable fft_length is 8192, could you accept to perform FFT at
only 4096 elements?
If yes, perform FFT on this 4096 elements, and return 4096.
If not, make sure you use set_output_multiple(fft_length) or at least
set_min_noutput_items(fft_length), in this case the scheduler will not call
work() function with insufficient number of elements.
> Regarding the first approach you suggested, we change the input signature
> and output signature to (sizeof (gr_complex)*fft_length) so that it is a
> single vector that is being processed. Then we return 1 as suggested. But
> it is throwing an itemsize mismatch error. I have attached the c++ file
> here ( http://pastebin.com/TKemtbxN ). The error says
>
The correct way is, in your work() function you should have 2 loops,
because now your in[0] is a vector but no longer solely a complex number.
Example:
for (int i=0; i < noutput_items; i++)
{
for (int j=0; j < fft_length; j++)
{
......
}
}
For the second method suggested should we write a general work function and
> a forecast function which would mean doing away with sync block that we are
> using with work function right now?
>
No need, because set_output_multiple() works with sync block as well.
Note:
Apologize in advance if my answer is incorrect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/21a0b00f/attachment.html>
------------------------------
Message: 33
Date: Wed, 28 May 2014 08:46:16 -0700
From: Nick Foster <address@hidden>
To: "address@hidden" <address@hidden>
Cc: Wafa Elhajhmida <address@hidden>, discuss-gnuradio
<address@hidden>
Subject: Re: [Discuss-gnuradio] Unable to log in usrpe 110 to get
access to gnuradio on screen?
Message-ID:
<CA+JMMq-FE52Lb3473P6SVfeqk4jH6_YQ_oDk=address@hidden>
Content-Type: text/plain; charset="utf-8"
Wafa,
Try using a USB hub for the mouse instead of plugging it directly into the
E100. E100 is picky about USB and doesn't support USB1.1 devices directly
connected to the ports. This is a Linux HCI driver issue related to OTG
support in the Overo.
It's mentioned in the E100 FAQ:
http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#What-kind-of-USB-devices-can-I-connect-to-the-my-E1x0-series
--n
On Wed, May 28, 2014 at 6:43 AM, West, Nathan
<address@hidden>wrote:
> On Wed, May 28, 2014 at 8:03 AM, Wafa Elhajhmida
> <address@hidden> wrote:
> > Please any suggestion is appreciated.
> >
> > Thanks in advance.
> >
> > Best regards,
> >
> > Wafa HAJ HMIDA
> >
> >
> >
> >
> > 2014-05-28 11:16 GMT+02:00 Wafa Elhajhmida <address@hidden>:
> >
> >> Hi,
> >>
> >> I made a reboot of the usrp e110. I got on the screen a button login.
> >>
> >> But I'm unable to login with a mouse. In fact, the mouse doesn't work on
> >> usrp. But the mouse works well on my laptop.
> >>
> >> In fact, I even connected the mouse directly to a usrp e100 with a cable
> >> which is provided by Ettus(on host port).
> >>
> >> According to you what can be the problem ?
> >>
> >> Best regards,
> >>
> >> Wafa HAJ HMIDA
> >>
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> First of all, your method of asking questions is ineffective. For a
> guide on how to get better help read this:
> http://www.catb.org/esr/faqs/smart-questions.html . I would especially
> like to point you to "Choose your forum carefully" where this
> particular email violates at least 3 (and possibly 4 based on
> perspective) of the first 4 bullet points. There's no need for this to
> be cross-listed to 3 mailing lists, a corporate support account, and 2
> individuals. Also, this e-mail has nothing to do with GNU Radio.
>
> Second, I have no idea why your mouse doesn't work. If it used to
> work, you did something, and now it doesn't work then whatever you did
> probably had a side affect of breaking your mouse.
>
> Finally, based on your previous mailing list posts and irc chats you
> seem overwhelmed. My only real comment here is that you probably need
> more help/support than anyone can give over a mailing list. Perhaps
> you would be better off backing up from your final goal and learning
> more about GNU Radio on a standard PC and then try porting your work
> to an embedded device. Alternatively maybe you could also take some
> time to learn more about embedded systems (there's lots of classes
> on-line and every university should have a couple). It might also help
> if you hired someone to come in and do some work for you and you could
> learn from them on the job.
>
> Nathan
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140528/7fbec2bb/attachment.html>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 138, Issue 39
*************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |