To implement WiMAX with GnuRadio or not?

GNU Radio
1

Hi community,

Our WiMAX Scanner project (Google Code Archive - Long-term storage for Google Code Project Hosting.)
approaches the moment when we should start writing C/C++ code - our
Matlab model decodes broadcast messages from all recordings we have on
hands.

At this point we have to make a choice - rely on GnuRadio or create
our own framework. Until recently I was sure would create our own
framework, but recent discussions on this list made me think GnuRadio
may be an option. So, I’m looking for the community help with the the
following questions:

  1. How well is GnuRadio suited for packet data processing? WiMAX is
    essentially a packet-oriented system.

  2. We don’t want to use Python. Is there anything we can’t do without
    it? And where can we find examples of C+±only flowgraphs?

  3. Right now all our code is open-source, but we must leave an option
    for proprietary plugins. How can we make this possible?

  4. Related to (3) - how can we make sure our protocol stack can be
    embedded into a closed-source application/system?

PS I have heavy travel schedule these days and a lot of other duties,
so please excuse me is I respond slow.

–
Regards,
Alexander C…

2

On Tue, May 24, 2011 at 7:04 AM, Martin B. [email protected]
wrote:

That’s great. I think GNU Radio would benefit from having big, cool

essentially a packet-oriented system.

What you’re writing is receiver-only, right? In that case, GNU Radio
will be able to handle all your data just fine. It gets tricky when you
have a transceiver with timing-sensitive operations, but it seems your
project would work well. GNU Radio is pretty agnostic of the data moved
between blocks.

I know I might be slightly biased here, but, yes, I think you’d be fine
handling the receiver code in GNU Radio. You are going to have to work a
bit
on the receiver side packet handling, though, because I know WiMax has
the
concept of the downlink map that you have to properly separate. I’d look
into the stream tagging infrastructure that we have now to handling
passing
around the necessary information.

Python for unit tests. Also, this gives you the opportunity to quickly
click together tests using GRC. This will make development a lot
easier.
Side note: Porting from Matlab to Python is much simpler than going from
Matlab to C++ (for porting your unit tests).

What Martin said. C++ is definitely doable, but you might want to start
in
Python, anyway. I’ve done a handful of C+±based flowgraphs, and it’s
relatively trivial to take a flowgraph in Python and convert it to C++,
as
long as you recognize anything that you did that is Pythonic in nature.

Tom

3

On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander C. wrote:

Hi community,

Hi Alex,

Our WiMAX Scanner project (Google Code Archive - Long-term storage for Google Code Project Hosting.)
approaches the moment when we should start writing C/C++ code - our
Matlab model decodes broadcast messages from all recordings we have on
hands.

That’s great. I think GNU Radio would benefit from having big, cool
projects.
Here’s my thoughts and experiences:

At this point we have to make a choice - rely on GnuRadio or create
our own framework. Until recently I was sure would create our own
framework, but recent discussions on this list made me think GnuRadio
may be an option. So, I’m looking for the community help with the the
following questions:

  1. How well is GnuRadio suited for packet data processing? WiMAX is
    essentially a packet-oriented system.

What you’re writing is receiver-only, right? In that case, GNU Radio
will be able to handle all your data just fine. It gets tricky when you
have a transceiver with timing-sensitive operations, but it seems your
project would work well. GNU Radio is pretty agnostic of the data moved
between blocks.

  1. We don’t want to use Python. Is there anything we can’t do without
    it? And where can we find examples of C+±only flowgraphs?

There are some examples in gnuradio-examples/c++. It’s really not that
hard, and I’ve done some C+±only projects with great success.

However, let me ask why you don’t want to use Python. Is it because you
want a final product that works without Python, or do you have a real
‘allergy’?
Because I recommend that even for a C+±only project, you still use
Python for unit tests. Also, this gives you the opportunity to quickly
click together tests using GRC. This will make development a lot
easier.
Side note: Porting from Matlab to Python is much simpler than going from
Matlab to C++ (for porting your unit tests).

  1. Right now all our code is open-source, but we must leave an option
    for proprietary plugins. How can we make this possible?

  2. Related to (3) - how can we make sure our protocol stack can be
    embedded into a closed-source application/system?

IANAL, TINLA. I’m guessing your best bet would be to separate the
actual DSP code from the GNU Radio bindings and have very lean GNU Radio
blocks (being GPL) which only call your module. Still, I don’t know how
or if you may link code across licenses.
You will have to get legal help here, I would not rely on anything said
on this list.

Good luck with your project!

MB

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

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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

4

Michael-

source or binary becomes part of a “greater work” and
closed source for your needs when
(1) Do not distribute a product or service that uses
GNU Radio’s headers, Python scripts, or compiled
libraries: Use currently available GNU Radio blocks
as much as you can (or, those written and released
by others), and then create a pipe or socket
connection to your specific code. Because your
code does not rely -directly- on GNU Radio’s
codebase / libraries, it forms an independent work
& thus you can license it as you choose. That said,
this method is certainly a nuisance and, depending
what blocks are available versus what you need, it
might also be impractical (never impossible :).

This is where I think licensing discussions tend to go off track. Legal
precedents have clearly established
requirements for interoperability. In that context, the key point is
not what code “links to”, but where it resides
and what shape it takes. “Linking based” arguments are fuzzy and argued
ad infinitum until at least one such case
reaches the Supreme Court – not likely any time soon. If code resides
across a network, across a bus (i.e. on a PCIe
card inside the GNU radio host server), or some other clearly non-GNU
radio location then interoperability becomes the
metric. It doesn’t matter what header files or libraries (or whether
the libraries are static or shared object, etc)
were used to create an interface to the code that is physically separate
– in that case, the code is clearly out of
the scope of the license.

I’ve mentioned on the forum before the need for ways to insert
proprietary code within the GNU radio framework, as
have others. For example, is it possible for GNU radio users to insert
code blocks into the FPGA data flow, for
instance if FPGA Verilog code contained “user defined” stubs or simple
reference examples to serve as a starting
point? Could an Nvidia accelerator be used? To me, it’s a matter of
imagination, creativity, and persistence – if
GNU radio developers believe in the need for proprietary IP within their
framework, then it can be done. So far,
evidently, they don’t believe.

Alexander is asking excellent questions and I’m surprised at the tepid
response – he’s got like 4 replies so far?
He’s the prototype GNU radio user who needs to maintain his group’s IP,
he should be receiving “how to’s”, not
“INALs”.

-Jeff

5

Hi Alexander - I think Martin & Tom covered that GNU Radio is quite
capable of being programmed for the basic receiver processing. You
might need to play around a bit with your DSP blocks, but otherwise I
think GNU Radio’s data processing is up to the task.

On May 23, 2011, at 3:50 PM, Alexander C. wrote:

  1. Right now all our code is open-source, but we must leave an option
    for proprietary plugins. How can we make this possible?

  2. Related to (3) - how can we make sure our protocol stack can be
    embedded into a closed-source application/system?

IANAL and TINAL. I think, as has been said, you’ll really want to
consult a lawyer to figure out how to best meet your needs.

GNU Radio is licensed solely under the GPLv3, which is written with the
intent that -anything directly- using source or binary becomes part of a
“greater work” and hence would also fall under this or an equivalent
license (e.g., if used in a sold product). In the case of GNU Radio,
that means any C++ code that links with GNU Radio’s libraries, or Python
script that makes use of GNU Radio’s Python / SWIG files / libraries.
To the best of my knowledge, because GNU Radio is not dual-licensed,
neither can “greater works” derived from it. Ettus’ UHD code is (will
be?) an example of a dual license (GPL for the primary source, or some
other license allowing you to do closed source for your needs when you
pay to license the code from Ettus); Qt tries to do this dual-license
as well – I don’t know how well they succeed, but they do try.

IMHO, you have 3 primary choices for keeping your code closed source:

(0) Do not use GNU Radio; use some other project that has a less
restrictive license.

(1) Do not distribute a product or service that uses the code: Nobody
will care how you license your code so long as you / your company does
not sell or distribute your product – e.g., if you use it just in house
for testing and evaluation, then you can license it however you want.
However, I doubt that this is what you’re looking for: why develop such
a product, but not sell or distribute it? That brings us to:

(2) Make sure your code does not -directly- rely on GNU Radio’s headers,
Python scripts, or compiled libraries: Use currently available GNU Radio
blocks as much as you can (or, those written and released by others),
and then create a pipe or socket connection to your specific code.
Because your code does not rely -directly- on GNU Radio’s codebase /
libraries, it forms an independent work & thus you can license it as you
choose. That said, this method is certainly a nuisance and, depending
what blocks are available versus what you need, it might also be
impractical (never impossible :).

I don’t know of another way to look at this issue – maybe someone on
this list is more enlightened?

That said: Unless you feel strongly that your work truly needs to be
proprietary, then why not just create a project on the CGRAN or your
preferred area (e.g., github) & make your work public – it will benefit
many others in the SDR / DSP world (and, likely, beyond).

Good luck, and please do keep the list informed on your project – it
sounds quite interesting! - MLD

6

On May 25, 2011, at 6:23 PM, Marcus D. Leech wrote:

Actually, IANAL is a perfectly-valid response. IP licensing arrangements are
complicated and studded with sinkholes and minefields.

Yes; exactly. Think of it this way: If we don’t put “IANAL, TINLA” then
one could possibly, if IMHO unreasonably, interpret what we write as
legal advice and thus we could possibly even be held liable for the
advice. Although putting in that text does not entirely protect us, it
makes the context clear that -this is not legal advice- and should not
be interpreted to be so; it is just a discussion of legal issues, and
may simply be people’s opinions that wouldn’t hold water in a court of
law. It’s sort of like the “CONFIDENTIALITY NOTICE” many professional
organizations require their employees to use when sending emails – it
cannot legally be enforced, but without it the organization could
actually be liable for its contents (IIRC, WIRED did a piece on this
issue in the last year, and this was their conclusion). And, no, I’m
not kidding: in the litigious US society, these non-legally binding
annoyances are actually necessary to CYOA.

I’ve avoided the issue (I hope!) in my proprietary “stuff” that uses Gnu Radio
by doing two things:

o minimizing the "stuff" that I do inside the flow-graph if I can

conveniently do it outside

o speaking to the flowgraph via named pipes and moving the proprietary and

user-goop into non Gnu Radio compiled

   code.

That sounds like the correct way to go in order to keep your code
separate from GNU Radio’s, but, of course, TINLA etc. :wink:

It would be great if you could share with the list example code snippets
of how you do the pipes. For example: Where in an online repository one
can find such code.

I think that’s what Jeff was getting at: that “we” are providing IANAL
advice rather than code examples. I, for one, have never actually tried
the pipes – I’ve just heard that they are possible and that using them
does not form a “greater work” in the GPL sense. - MLD

7

Alexander is asking excellent questions and I’m surprised at the tepid
response – he’s got like 4 replies so far? He’s the prototype GNU
radio user who needs to maintain his group’s IP, he should be
receiving “how to’s”, not “INALs”. -Jeff
Actually, IANAL is a perfectly-valid response. IP licensing
arrangements are complicated and studded with sinkholes and minefields.

I’ve avoided the issue (I hope!) in my proprietary “stuff” that uses Gnu
Radio by doing two things:

  o minimizing the "stuff" that I do inside the flow-graph if I can

conveniently do it outside
o speaking to the flowgraph via named pipes and moving the
proprietary and user-goop into non Gnu Radio compiled
code.

This is probably the safest thing that somebody who isn’t a lawyer can
do without consulting an (expensive) IPR lawyer.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

8

On 26/05/2011 9:55 AM, Michael D. wrote:

It would be great if you could share with the list example code snippets of how
you do the pipes. For example: Where in an online repository one can find such
code.

I think that’s what Jeff was getting at: that “we” are providing IANAL advice
rather than code examples. I, for one, have never actually tried the pipes –
I’ve just heard that they are possible and that using them does not form a
“greater work” in the GPL sense. - MLD

Actually, my SIDSuite code uses this a little bit, in that data
recording is handled outside of Gnu Radio. The basic idea is that
there’s
a shell script that sets up the environment (creates the FIFO files,
starts the external programs in the background, etc), then the
Gnu Radio flow-graph is called. The flow-graphs just use “File
Source” and “File Sink” with buffering turned off–as far as Gnu Radio
is concerned, it’s writing to a file, but in fact, it’s a FIFO file
or “named pipe”.

See:

http://www.sbrac.org/files/sidsuite.tar.gz

It doesn’t do it as much as other code that I’ve written, but it gives
one a flavour for how the pipes are used.

The other “trick” that I use is to use the XMLRPC server stuff that Josh
put in GRC–it allows you to set flowgraph variables from an
outside program, which is really great!

9

Marcus-

  o minimizing the "stuff" that I do inside the flow-graph if I can

conveniently do it outside
o speaking to the flowgraph via named pipes and moving the
proprietary and user-goop into non Gnu Radio compiled
code.

This is probably the safest thing that somebody who isn’t a lawyer can
do without consulting an (expensive) IPR lawyer.

I agree this is a good approach with clear intent. Especially if you
can show things would work the same way if the
pipes connected over Ethernet to another server that did not have GNU
radio installed.

Maybe if GRC had some blocks for this purpose…

-Jeff

10

On Fri, May 27, 2011 at 2:31 PM, Jeff B. [email protected]
wrote:

Radio by doing two things:
I agree this is a good approach with clear intent. Especially if you can show
things would work the same way if the
Discuss-gnuradio Info Page

How do the companies write closed-source drivers for the Linux Kernel
without running into GPL2 issues? I can only recall that there is a
“user-land” and a “kernel-land” driver, where the “kernel-land” is the
only part that is open source. Is this correct?

Perhaps that method could work well?

11

How do the companies write closed-source drivers for the Linux Kernel
without running into GPL2 issues? I can only recall that there is a
“user-land” and a “kernel-land” driver, where the “kernel-land” is the
only part that is open source. Is this correct?

Perhaps that method could work well?

I thought GPLV2 was less onerous in this regard, and that case-law had
established that a loadable kernel driver didn’t necessarily get
infected by the GPL virus. IANAL. TINLA. Etc.

The last kernel driver I worked on we were planning to open-source as a
way of encouraging people to buy our (very closed-source!) chips.
Project fell apart before we hit market. Sigh.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

12

Colby-

How do the companies write closed-source drivers for the Linux Kernel
without running into GPL2 issues? I can only recall that there is a
“user-land” and a “kernel-land” driver, where the “kernel-land” is the
only part that is open source. Is this correct?

Perhaps that method could work well?

You can find many opinions either way. But as you mention, “the reality
on the ground” is that commercial outfits
often distribute binary-only versions of libraries and drivers, whether
the license they’re under actually permits
that or not. Their argument that providing driver source would disclose
proprietary information about their hardware
is difficult to refute. Nvidia is one example.

I continue to think future legal rulings will invoke interoperability to
clarify this. Numerous people want to
interoperate with Linux and still maintain their sauce as secret.
Building cards that insert into servers is one
obvious example. A smaller group of people want to interoperate
similarly with GNU radio. Yes there are no lawyers
posting here, but my point is these users should be supported in some
formal, encouraged way.

-Jeff

I thought GPLV2 was less onerous in this regard, and that case-law had
established that a loadable kernel driver didn’t necessarily get
infected by the GPL virus. IANAL. TINLA. Etc.

The last kernel driver I worked on we were planning to open-source as a
way of encouraging people to buy our (very closed-source!) chips.
Project fell apart before we hit market. Sigh.

13

Hi Martin, hi all,

I’m sorry for delayed replies. That’s not because I don’t care - I
just have very tight schedule at this moment.

On Tue, May 24, 2011 at 10:04, Martin B. [email protected]
wrote:

That’s great. I think GNU Radio would benefit from having big, cool
projects.

I believe so too. But first, big cool projects should make sure
GnuRadio fits :slight_smile:

What you’re writing is receiver-only, right? In that case, GNU Radio
will be able to handle all your data just fine. It gets tricky when you
have a transceiver with timing-sensitive operations, but it seems your
project would work well. GNU Radio is pretty agnostic of the data moved
between blocks.

WiMAX receiver is our current goal, but we aim ultimately at creating
a full 4G modem. And want to create real working modem, not just an
offline model. We plan to port our code to some powerful DSP later to
make it run in real-time. That’s why we want to stay with C/C++ -
Python is not a common guest at DSP.

  1. We don’t want to use Python. Is there anything we can’t do without
    it? And where can we find examples of C+±only flowgraphs?

There are some examples in gnuradio-examples/c++. It’s really not that
hard, and I’ve done some C+±only projects with great success.

Thanks. I’ll look into them.

However, let me ask why you don’t want to use Python. Is it because you
want a final product that works without Python, or do you have a real
‘allergy’?

See explanation above about our intention to port to DSP.
Also I believe that it’s better to avoid such mixes, because it forces
people to learn language which they don’t know.

Because I recommend that even for a C+±only project, you still use
Python for unit tests. Also, this gives you the opportunity to quickly
click together tests using GRC. This will make development a lot
easier.
Side note: Porting from Matlab to Python is much simpler than going from
Matlab to C++ (for porting your unit tests).

Yes, using Python for unit tests may be a good idea. But it has a
downside - it means that people still have to learn Python.

  1. Right now all our code is open-source, but we must leave an option
    for proprietary plugins. How can we make this possible?

  2. Related to (3) - how can we make sure our protocol stack can be
    embedded into a closed-source application/system?

IANAL, TINLA. I’m guessing your best bet would be to separate the
actual DSP code from the GNU Radio bindings and have very lean GNU Radio
blocks (being GPL) which only call your module. Still, I don’t know how
or if you may link code across licenses.

That’s the question - how to link across licenses.

You will have to get legal help here, I would not rely on anything said
on this list.

In many cases opinion of the community leader plays no smaller role
then license itself. If Linus didn’t state that he think proprietary
modules are allowed, Linux would have a very different role now.

–
Regards,
Alexander C…

14

Isn’t the main difference between v2 and v3 the “Tivo Exception” as
the call it? Not sure.

I guess I should add IANAL. TINLA.

:stuck_out_tongue:

15

On Tue, May 24, 2011 at 13:55, Tom R. [email protected]
wrote:

hands.

handling the receiver code in GNU Radio.
What about transmitter side?
We should be sure that we can implement full 4G modem in GnuRadio.

You are going to have to work a bit
on the receiver side packet handling, though, because I know WiMax has the
concept of the downlink map that you have to properly separate. I’d look
into the stream tagging infrastructure that we have now to handling passing
around the necessary information.

Yes! DL-MAP is one of the nicest features of WiMAX, bu it makes packet
decoding highly non-linear process. I.e. you should decode header,
find out about encoding parameters of different zones and then decode
zone-by-zone. So we need a tight integration with MAC layer here,
which should command what to decode.

IIRC LTE has similar concept, so it’s a must for 4G systems.

BTW, Wireless Innovation Forum is about to kick off a project about
open-source implementation of LTE-Advanced. We’re discussing right now
whether we should join forces and create a reconfigurable WiMAX/LTE
implementation. It’s a project with wonderful complexity and it needs
a good platform to stay on.

Python for unit tests. Also, this gives you the opportunity to quickly
click together tests using GRC. This will make development a lot
easier.
Side note: Porting from Matlab to Python is much simpler than going from
Matlab to C++ (for porting your unit tests).

What Martin said. C++ is definitely doable, but you might want to start in
Python, anyway. I’ve done a handful of C+±based flowgraphs, and it’s
relatively trivial to take a flowgraph in Python and convert it to C++, as
long as you recognize anything that you did that is Pythonic in nature.

When I write in C++ I prefer to be C+±ish :wink:
(if I understood you comment correctly)

Tom, it would be great to hear your opinion about licensing issues.
You’re the leader of the community and your word is important here.
And if I understand correctly, you’re also a liaison to FSF?

–
Regards,
Alexander C…

16

On Wed, May 25, 2011 at 23:21, Jeff B. [email protected]
wrote:

leave an option
GNU Radio is licensed solely under the GPLv3, which is
an example of a dual license (GPL for the primary
has a less restrictive license.

what blocks are available versus what you need, it

I’ve mentioned on the forum before the need for ways to insert proprietary code
within the GNU radio framework, as
have others. For example, is it possible for GNU radio users to insert code
blocks into the FPGA data flow, for
instance if FPGA Verilog code contained “user defined” stubs or simple reference
examples to serve as a starting
point? Could an Nvidia accelerator be used? To me, it’s a matter of
imagination, creativity, and persistence – if
GNU radio developers believe in the need for proprietary IP within their
framework, then it can be done. So far,
evidently, they don’t believe.

Alexander is asking excellent questions and I’m surprised at the tepid response
– he’s got like 4 replies so far?
He’s the prototype GNU radio user who needs to maintain his group’s IP, he
should be receiving “how to’s”, not
“INALs”.

Jeff, thanks. Yes, I’m trying to solve a bigger problem then just my
personal case. And you’re right - if we want to see serious projects
to use GnuRadio, then there must be how-to’s and examples.

–
Regards,
Alexander C…

17

On Wed, May 25, 2011 at 22:29, Michael D. [email protected] wrote:

Hi Alexander - I think Martin & Tom covered that GNU Radio is quite capable
of being programmed for the basic receiver processing. You might need to play
around a bit with your DSP blocks, but otherwise I think GNU Radio’s data
processing is up to the task.

Yes, with an exception that we our receiver is not basic (e.g. see
comment about DL-MAP) and we also need transmitter, and integration
with MAC level, ugh.

IMHO, you have 3 primary choices for keeping your code closed source:

(0) Do not use GNU Radio; use some other project that has a less restrictive
license.

Yes, this is an option.

(1) Do not distribute a product or service that uses the code: Nobody will care
how you license your code so long as you / your company does not sell or
distribute your product – e.g., if you use it just in house for testing and
evaluation, then you can license it however you want. However, I doubt that this
is what you’re looking for: why develop such a product, but not sell or distribute
it? That brings us to:

Right.

(2) Make sure your code does not -directly- rely on GNU Radio’s headers, Python
scripts, or compiled libraries: Use currently available GNU Radio blocks as much
as you can (or, those written and released by others), and then create a pipe or
socket connection to your specific code. Because your code does not rely
-directly- on GNU Radio’s codebase / libraries, it forms an independent work &
thus you can license it as you choose. That said, this method is certainly a
nuisance and, depending what blocks are available versus what you need, it might
also be impractical (never impossible :).

Let me clarify.
We will publish our main source code as open-source (we already do for
our Matlab models). But we want (1) to allow other parties to replace
some parts of our open-source code with their proprietary blocks and
(2) more importantly - allow creation of proprietary solutions to be
based on this code. So far, (2) would require you to create a
socket/IPC based API and use it to embed into a larger system - though
this implies that you add latency in your processing path. Requirement
(1) may go the same way, as long as it’s only for some blocks, but
again - this may add latency. I’m not yet sure how bad is this added
latency, but in general, latency is an important characteristic for
4G.

Interesting thing is how Linux kernel allows proprietary modules. If I
understand this correctly (IANAL), it’s because kernel’s API is
clearly defined and kernel it’s considered, that it’s a kernel native
feature - to be able load and run modules, just like it’s for
applications. With this logic, it’s possible to allow modules with
GnuRadio if there are a clearly defined external API. But note, that
the kernel is licensed under GPLv2, and GnuRadio is under GPLv3 - I’m
not sure whether this trick works for the latter.

I don’t know of another way to look at this issue – maybe someone on this list
is more enlightened?

That said: Unless you feel strongly that your work truly needs to be
proprietary, then why not just create a project on the CGRAN or your preferred
area (e.g., github) & make your work public – it will benefit many others in the
SDR / DSP world (and, likely, beyond).

We’re more concerned about others to use our work. That’s what is
missing for many GnuRadio projects - we build software for ourselves.
We want to create a software which will be used by many.

Good luck, and please do keep the list informed on your project – it sounds
quite interesting! - MLD

Thanks! I’ll do my best keeping the community informed.

–
Regards,
Alexander C…

18

On Thu, May 26, 2011 at 18:10, Marcus D. Leech [email protected]
wrote:

“named pipe”.

See:

http://www.sbrac.org/files/sidsuite.tar.gz

It doesn’t do it as much as other code that I’ve written, but it gives one a
flavour for how the pipes are used.

Cool!
It would be truly great to see a simplified example of this in the
GnuRadio repository, and at least somehow mentioned on the wiki.

The other “trick” that I use is to use the XMLRPC server stuff that Josh put
in GRC–it allows you to set flowgraph variables from an
outside program, which is really great!

Hum. Any examples?

I also wonder - have you quantified overhead of those methods - in
latency, jitter, memory, etc?

–
Regards,
Alexander C…

19

Anti-tivoization is one of main differences (but not the only), but
it’s about a different issue.

On Sat, May 28, 2011 at 05:14, Colby B. [email protected]
wrote:

“user-land” and a “kernel-land” driver, where the “kernel-land” is the
of encouraging people to buy our (very closed-source!) chips.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
Regards,
Alexander C…

20

Cool! It would be truly great to see a simplified example of this in
the GnuRadio repository, and at least somehow mentioned on the wiki.
Yes, I suppose it would. I’ll put it on my list, but so many other
things to do :frowning:

The other “trick” that I use is to use the XMLRPC server stuff that Josh put
in GRC–it allows you to set flowgraph variables from an
outside program, which is really great!

Hum. Any examples?

I also wonder - have you quantified overhead of those methods - in
latency, jitter, memory, etc?

Well, in terms of the FIFO I/O, they’re pretty-darned efficient in
Linux, at least as efficient as disk I/O,
although since FIFOs (named pipes) are implemented in kernel memory,
they’re typically a lot
faster.

I’ve never needed the XMLRPC stuff to “go real fast”, since I typically
use it to modify flow-graph
parameters that change infrequently. One of the things I use it for
in one of my applications that I
did for a customer is for active RFI excision for a science
application. The flow-graph produces
a spectral estimate which is sent over a FIFO to an external program
that analyses the spectrum, and
then, if necessary, sends back parameters for a multi-notch filter
into the flow-graph.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium