GNU Radio, One Step at a Time: July 2016

Saturday, July 30, 2016

Re: [Discuss-gnuradio] compiling OOT module gr-dsd

Most likely you need to install the dev package

apt-get install gnuradio-dev

-- Cinaed

On 07/30/2016 07:17 AM, Brandon Lester wrote:
> I installed gnuradio 3.7.5 through the Debian package manager. I cloned
> the git repository for gr-dsd. I began the process of using cmake, but
> it fails giving the following error:
>
> CMake Error at CMakeLists.txt:104 (find_package):
> By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this
> project has
> asked CMake to find a package configuration file provided by "Gnuradio",
> but CMake did not find one.
>
> Could not find a package configuration file provided by "Gnuradio"
> (requested version 3.7.2) with any of the following names:
>
> GnuradioConfig.cmake
> gnuradio-config.cmake
>
> Add the installation prefix of "Gnuradio" to CMAKE_PREFIX_PATH or set
> "Gnuradio_DIR" to a directory containing one of the above files. If
> "Gnuradio" provides a separate development package or SDK, be sure it has
> been installed.
>
>
> In the readme file for the gr-dsd package, it said I could specify the
> location of the gnuradio installation with DCMAKE_INSTALL_PREFIX, but
> this fails as well. Does anybody have any idea what I'm doing wrong?
>
> --
> Brandon Lester
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

[Discuss-gnuradio] PyBOMBS: Error installing package python-zmq

Hi,

this is my first time with PyBOMBS.

Do you have any idea what is the problem with:
"PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package python-zmq"

Best regards.

Cyrille DERORY

************************************************************

[cderory@cyrille-E6540 ~]$
[cderory@cyrille-E6540 ~]$ pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git
PyBOMBS - INFO - PyBOMBS Version 2.1.0
Cloning:     (100%) [===========================================================================================================================]
PyBOMBS.ConfigManager - INFO - Creating new config file /home/cderory/.pybombs/config.yml
[cderory@cyrille-E6540 ~]$ pybombs recipes add gr-etcetera git+https://github.com/gnuradio/gr-etcetera.git
PyBOMBS - INFO - PyBOMBS Version 2.1.0
Cloning:     (100%) [===========================================================================================================================]
[cderory@cyrille-E6540 ~]$ mkdir gnuradio-prefix
[cderory@cyrille-E6540 ~]$ pybombs prefix init -a default gnuradio-prefix/default/ -R gnuradio-default
PyBOMBS - INFO - PyBOMBS Version 2.1.0
PyBOMBS.prefix - INFO - Creating directory `/home/cderory/gnuradio-prefix/default'
PyBOMBS.ConfigManager - INFO - Creating new config file /home/cderory/gnuradio-prefix/default/.pybombs/config.yml
PyBOMBS.prefix - INFO - Installing default packages for prefix...
PyBOMBS.prefix - INFO -
- gnuradio
- gr-osmosdr
Install tree:
|
\- gr-osmosdr
   |
   +- bladeRF
   |
   +- uhd
   |
   +- rtl-sdr
   |
   +- airspy
   |
   +- gr-iqbal
   | |
   | +- libosmo-dsp
   | |
   | \- gnuradio
   |     |
   |     +- python-zmq
   |     |
   |     \- uhd
   |
   +- osmo-sdr
   |
   +- hackrf
   |
   \- gnuradio
      |
      +- python-zmq
      |
      \- uhd
PyBOMBS.install_manager - INFO - Installing package: uhd
Cloning:     (100%) [===========================================================================================================================]
Configuring: (100%) [===========================================================================================================================]
Building:    (100%) [===========================================================================================================================]]
Installing: (100%) [===========================================================================================================================]
PyBOMBS.install_manager - INFO - Installation successful.
PyBOMBS.install_manager - INFO - Installing package: python-zmq
PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package python-zmq
PyBOMBS.install_manager - ERROR - Error installing package python-zmq. Aborting.
[cderory@cyrille-E6540 ~]$

[Discuss-gnuradio] compiling OOT module gr-dsd

I installed gnuradio 3.7.5 through the Debian package manager. I cloned the git repository for gr-dsd. I began the process of using cmake, but it fails giving the following error:

CMake Error at CMakeLists.txt:104 (find_package):
By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Gnuradio",
but CMake did not find one.

Could not find a package configuration file provided by "Gnuradio"
(requested version 3.7.2) with any of the following names:

GnuradioConfig.cmake
gnuradio-config.cmake

Add the installation prefix of "Gnuradio" to CMAKE_PREFIX_PATH or set
"Gnuradio_DIR" to a directory containing one of the above files. If
"Gnuradio" provides a separate development package or SDK, be sure it has
been installed.

In the readme file for the gr-dsd package, it said I could specify the location of the gnuradio installation with DCMAKE_INSTALL_PREFIX, but this fails as well. Does anybody have any idea what I'm doing wrong?

Brandon Lester

Re: [Discuss-gnuradio] Generate python file from GRC file

Klick the "generate" button (highlighted in red); the path where your python file has been written will be visible in the console window (highlighted in green), and you can set the ID and with that, the file name in the Options block (highlighted in blue):

This shouldn't be news to you if you've gone through the official GNU Radio tutorials on http://tutorials.gnuradio.org ; If you haven't yet read them, they are an excellent and quick introduction to using GNU Radio and the GNU Radio companion, and you should definitely read them in order, starting at the introduction.

Best regards,
Marcus

On 30.07.2016 11:28, Ahmad Zainudin wrote:

Dear All.

How to generate python file from GRC file ?

Best Regards,

--

Ahmad Zainudin

Lab. Digital Signal Processing E-206

Politeknik Elektronika Negeri Surabaya

Kampus PENS, Sukolilo, Surabaya 60111

Mobile : 085733409869 / ext. 2504
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

[Discuss-gnuradio] Generate python file from GRC file

Dear All.

How to generate python file from GRC file ?

Best Regards,

Ahmad Zainudin

Lab. Digital Signal Processing E-206

Politeknik Elektronika Negeri Surabaya

Kampus PENS, Sukolilo, Surabaya 60111

Mobile : 085733409869 / ext. 2504

Friday, July 29, 2016

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

On Fri, 2016-07-29 at 11:49 -0400, Michael Dickens wrote:

> I'm looking for an OOT to do the REP /REQ way that GR does -not-
> provide, or will just create one myself. I don't anticipate adding it to
> the core gr-zeromq component. I agree that it would add unnecessary
> complexity to those already-existing blocks. - MLD

I don't care if new blocks are added to gr-zmq to cover the other
combinations.

I just think its a bad idea to code a super-flexible gr-zeromq block
with "multiple-personalities" into a single C++ block and have its
functionality change between REQ/REP/PUB/SUB/PUSH/PULL based on an input
parameter.

BTW, I know of no OOT that has the functionality you need. Sorry.

Regards,
Andy

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

Re: [Discuss-gnuradio] Is there any way to export Qt GUI Sink?

Hello Shilei Tian!

When you middle-mouse-button-click on a Qt GUI, you get a menu, and that contains a "Save" entry. (You can definitely call that same functionality programmatically, too, but I'd have to look up how – I'd expect you'd have to send the right Qt signal to the right Qt slot to trigger the action, or you can grab the same data as that save function saves to disk).

However, that won't have a better quality than the screenshot, normally – the image is rendered as pixels, not as vector graphics, normally.

But you're on the right track:

> some data that I can use to plot with Matlab

If you want offline analysis, having something like the file sink might be the easiest approach.

Best regards,
Marcus

On 29.07.2016 18:29, Shilei Tian wrote:

Hello, everyone.

I need the plot of Qt GUI Sink result, but I don't find any way to export it except using system sceenshot, but it is poor quality. I want to ask is there any way to export a vector figure, like *.eps or something else, or some data that I can use to plot with Matlab? Thanks!

----------

Sincerely yours,

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

[Discuss-gnuradio] Is there any way to export Qt GUI Sink?

Hello, everyone.

I need the plot of Qt GUI Sink result, but I don't find any way to export it except using system sceenshot, but it is poor quality. I want to ask is there any way to export a vector figure, like *.eps or something else, or some data that I can use to plot with Matlab? Thanks!

----------

Sincerely yours,

Shilei Tian

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

Hi Andy - Thanks for your detailed thoughts on the subject matter.

I think we're all in general agreement that there are 2 ways to do REP /
REQ with respect to which is client and which is server. GR implements
one of those ways, but could easily provide the other, too. It's just
another way of looking at which is server and which is client. Neither
is more or less correct; they are just different implementations.

I'm looking for an OOT to do the REP /REQ way that GR does -not-
provide, or will just create one myself. I don't anticipate adding it to
the core gr-zeromq component. I agree that it would add unnecessary
complexity to those already-existing blocks. - MLD

> I think this would make the gr-zmq C++ block code unnecessarily complex
> and harder to maintain. The block requirements for each combination of
> parameters grow in different directions.
>
> Some things you'd have to deal with:
> 1. REP blocks have a receive then send main loop;
> REQ blocks have a send then receive main loop.
>
> 2. REQ/REP can never drop messages/samples and so the tag propagation
> code can be simple;
> PUB/SUB can drop messages/samples and tag propagation code needs to
> account for that in tag offsets
>
> 3. GNURadio messages are usually small enough that they can be handled
> in one call to work(). GNURadio sample stream payloads can have a great
> many samples that need to be handled across several calls to work().

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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

Great work!

On Fri, Jul 29, 2016 at 10:36 AM, Sebastian Müller <gsenpo@gmail.com> wrote:

Hi all,

week 10 of GSoC is over and I managed to implement an OFDM sync block:
https://grinspector.wordpress.com/2016/07/29/week-10-sync/

Since I make good time, I will try to add a FM demod block to the toolbox. Target is to have one example workflow from Ether to demod data (= sound).

Cheers,
Sebastian

2016-07-22 16:11 GMT+02:00 Sebastian Müller <gsenpo@gmail.com>:
Hi list,

in week 9 of my GSoC I finally managed to implement a working OFDM parameter estimation block. Read here about it:
https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/

Next up is a frequency and timing synchronization block.

Cheers
Sebastian

2016-07-18 9:57 GMT+02:00 Sebastian Müller <gsenpo@gmail.com>:
Hi Martin,

I have no problem with keeping the 'old' algo in the toolbox. But still I'm not sure if it is usable in real-world scenarios with sampling offsets. Maybe someone can improve it if interested.

Cheers, Sebastian

2016-07-15 19:22 GMT+02:00 Martin Braun <martin.braun@ettus.com>:
To clarify, if Koslowski's algorithm (since you already coined the
term...) is *as* good as your original one, but also faster, you should
not have duplicates. But if you did all the work to create software that
actually outperforms the fast algorithm in some other aspect, there's no
harm in keeping it around.

Cheers,
M

On 07/15/2016 10:20 AM, Martin Braun wrote:
> Sebastian,
>
> thanks for sharing, and your awesome work! I would suggest if you have
> an algorithm with great detection characteristics, you should keep it.
> If you want another suboptimal but fast one, create a second block (or
> whatever it is). The first algorithm did cost you time, and its superior
> detection performance might be interesting to other people.
>
> Cheers,
> Martin
>
> On 07/15/2016 08:10 AM, Sebastian Müller wrote:
>> Hi list,
>>
>> week 8 of GSoC is over and the latest news on gr-inspector are online:
>> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
>>
>> This week was a bit disappointing because the algorithm for the OFDM
>> estimation, which did show nice estimation results, and which I dealt
>> with 2 weeks now, had to be replaced because of performance issues. Now
>> I'll try a more straight-forward algorithm and hope to get started with
>> synchronization in two weeks.
>>
>> Cheers,
>> Sebastian
>>
>> Sebastian Müller <gsenpo@gmail.com <mailto:gsenpo@gmail.com>> schrieb am
>> Fr., 8. Juli 2016 um 13:48 Uhr:
>>
>> Hi all,
>>
>> week 7 of GSoC is over and I have written a blog post about what
>> I've been up to:
>> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
>>
>> I started implementing an OFDM parameter estimation block in python.
>> Also, I did some performance tests, which look quite good. Next, I
>> will implement this algorithm in C++. Stay tuned!
>>
>> Cheers,
>> Sebastian
>>
>> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
>>> Hi all,
>>>
>>> this week's GSoC blog post is ready! Check it out here:
>>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>>>
>>> I have finished the GUI so far and improved the Signal Separator.
>>> In the next time I will start with an OFDM parameter estimation,
>>> so stay tuned.
>>>
>>> Cheers,
>>> Sebastian
>>>
>>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gsenpo@gmail.com
>>> <mailto:gsenpo@gmail.com>>:
>>>
>>> Hi Ben,
>>>
>>> thanks for your interest. The manual signal selection is like
>>> the demod function in gqrx. You can move and resize an overlay
>>> that will determine the signal information that gets passed
>>> downstream. I have not dealt with AMC for now, but based on my
>>> own experience with manual modulation recognition I don't see
>>> a problem when not exactly hitting the signal edges. If your
>>> concern is too narrow selection, there is an oversampling
>>> factor parameter in the Signal Separator block, that will
>>> allow filtering wider than actually from the GUI specified, to
>>> compensate the naturally underestimated bandwidth when using
>>> energy detection. Also, the GUI now supports zooming so a user
>>> can work really precise if needed :)
>>>
>>> Thanks again for the feedback!
>>> Cheers,
>>> Sebastian
>>>
>>> 2016-06-27 16:41 GMT+02:00 Ben Hilburn
>>> <<mailto:bhilburn@gnuradio.org>bhilburn@gnuradio.org
>>> <mailto:bhilburn@gnuradio.org>>:
>>>
>>> Hi Sebastian -
>>>
>>> Thanks for the great update!
>>>
>>> I'm curious how the "manual selection with the mouse" will
>>> work? For some of the back-end processing that is going
>>> on, like Chris's AMC work, not selecting all of the bins
>>> of the signal seems like it could seriously impact the
>>> success of those functions. If the the FFT is, for
>>> example, 1024 bins, it seems like it may be hard for a
>>> user to accurately select the bins that are important.
>>> Will there be some sort of "intelligent auto-aim", for
>>> lack of a better word, for this?
>>>
>>> Thanks for the great work so far! The GUI screenshots are
>>> looking great, by the way.
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller
>>> <gsenpo@gmail.com <mailto:gsenpo@gmail.com>> wrote:
>>>
>>> Hi all,
>>>
>>> it's GSoC midterms time! For that purpose, I wrote a
>>> new blog post with what I've been up to and with a
>>> review of what I've done so far:
>>> <https://grinspector.wordpress.com/2016/06/26/week-5-midterms/>https://grinspector.wordpress.com/2016/06/26/week-5-midterms/
>>>
>>> I have managed to accomplish all of my midterm
>>> milestones and am looking forward for the next 8 weeks
>>> of GSoC.
>>>
>>> Cheers
>>> Sebastian
>>>
>>>
>>> Am 18. Juni 2016 um 15:06:11, Sebastian Müller
>>> (<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>> <mailto:gsenpo@gmail.com>) schrieb:
>>>
>>>> Hi all,
>>>>
>>>> my GSoC update came a bit later this week, because I
>>>> was abroad. The GUI came to life this week, read here
>>>> about it:
>>>> <https://grinspector.wordpress.com/2016/06/18/week-4-gui/>https://grinspector.wordpress.com/2016/06/18/week-4-gui/
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller
>>>> (<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>> <mailto:gsenpo@gmail.com>) schrieb:
>>>>
>>>>> Hi all,
>>>>>
>>>>> like every week I want to give a short update about
>>>>> my GSoC project. For details, check the blog post at
>>>>> <https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/>https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/
>>>>>
>>>>> Most of the week was used to debug the Signal
>>>>> Separator block, which did not pass my QA test. In
>>>>> consultation with my mentors I changed the structure
>>>>> under the hood and now the behavior is exactly like
>>>>> expected (same as Xlating FIR filter). Also I
>>>>> improved the Signal Detector with callbacks and an
>>>>> averaging function and started with the GUI.
>>>>>
>>>>> Cheers,
>>>>> Sebastian
>>>>>
>>>>> 2016-06-03 18:49 GMT+02:00 Sebastian Müller
>>>>> <<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>>> <mailto:gsenpo@gmail.com>>:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> the second GSoC week is over and I have updated
>>>>> my blog with the latest news:
>>>>> <https://grinspector.wordpress.com/2016/06/03/week-2-compiling/>https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>>>>>
>>>>> Mainly I did C++ implementation of the Signal
>>>>> Detector and Signal Separator blocks and started
>>>>> with the Signal Extractor block. Next week I
>>>>> plan to improve these blocks and start with the GUI.
>>>>>
>>>>> Cheers,
>>>>> Sebastian
>>>>>
>>>>> Am 28. Mai 2016 um 14:55:45, Sebastian Müller
>>>>> (<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>>> <mailto:gsenpo@gmail.com>) schrieb:
>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> thanks for the feedback!
>>>>>> PFBs are a topic I discussed with my mentors
>>>>>> and we decided to not use them because of the
>>>>>> following reasons. When using PFBs, there is a
>>>>>> trade-off between band resolution and
>>>>>> calculation effort (few filters lead to low
>>>>>> number of possible frequency bands, many
>>>>>> filters may have a high cpu usage). Since the
>>>>>> band separation is not dependend on the input
>>>>>> siganls, I think I can have a more efficient
>>>>>> solution with „customized" FIR filters for each
>>>>>> signal. The second reason is the implementation
>>>>>> effort that needs to be done (not only for the
>>>>>> PFB but also for recombining the bands again to
>>>>>> reconstruct the signals) is quite higher than
>>>>>> for using FIR filters. We were afraid that time
>>>>>> would be too short for implementing this (since
>>>>>> all this should work until the midterms in four
>>>>>> weeks).
>>>>>> We assume to have a moderate number of signals
>>>>>> in the input spectrum (let's say less than 5)
>>>>>> and I think the FIR filter approach is more
>>>>>> attractive here. But of course cpu usage is a
>>>>>> topic which I have to deal with. Therefore I
>>>>>> plan to use a lookup-table with precalculated
>>>>>> taps for different bandwidths and steepnesses.
>>>>>> Also, steepness (or something similiar) should
>>>>>> be a parameter of the block, so the user can
>>>>>> can somehow control the cpu usage with that.
>>>>>>
>>>>>> I hope that answers your question!
>>>>>>
>>>>>> Regards,
>>>>>> Sebastian
>>>>>>
>>>>>> Am 28. Mai 2016 um 12:45:49, Jan Krämer
>>>>>> (<mailto:kraemer.jn@gmail.com>kraemer.jn@gmail.com
>>>>>> <mailto:kraemer.jn@gmail.com>) schrieb:
>>>>>>
>>>>>>> Hey Sebastian,
>>>>>>>
>>>>>>> great work in your first week. Looking pretty
>>>>>>> good.
>>>>>>> One question though. At the end you propose to
>>>>>>> seperate the signals with a filterbank of
>>>>>>> xlating FIRs. Is there a use case or a way to
>>>>>>> do that with a polyphase filterbank? Cause
>>>>>>> multiple FIRs are going to become a major
>>>>>>> burden for the CPU if their number rises,
>>>>>>> especially if the filterorder gets pretty high
>>>>>>> e.g. for narrowband signals.
>>>>>>>
>>>>>>> Anyway keep up the good work.
>>>>>>> Cheers,
>>>>>>> Jan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2016-05-27 14:51 GMT+02:00 Sebastian Müller
>>>>>>> <<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>>>>> <mailto:gsenpo@gmail.com>>:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> there is a new blog post concerning the
>>>>>>> gr-inspector toolbox:
>>>>>>> <https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/>https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>>>>>>>
>>>>>>> There I describe what I have done in my
>>>>>>> first week of GSoC. Mainly I have
>>>>>>> prototyped a signal detection block and
>>>>>>> started planning the signal separator
>>>>>>> block (which is used to pass the detected
>>>>>>> signals serialized).
>>>>>>>
>>>>>>> As always, comments are very welcome :)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sebastian
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Discuss-gnuradio mailing list
>>>>>>> <mailto:Discuss-gnuradio@gnu.org>Discuss-gnuradio@gnu.org
>>>>>>> <mailto:Discuss-gnuradio@gnu.org>
>>>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>
>>>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>

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

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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

> From:
> Francisco Albani
> Subject:
> Re: [Discuss-gnuradio] ZMQ REQ /
> REP naming Swap?
> Date:
> Thu, 28 Jul 2016 23:21:25 -0300
>
> ______________________________________________________________________
> Michael, I found the need to do the same for some applications. I also
> needed to choose between bind and connect (I made this a parameter of
> my block).
>
>
> Wouldn't be better to have just one sink and one source with
> selectable options, like:
> * socket_type: REP/REQ/SUB/PUB/PUSH/PULL
>
> * method: bind / connect
>
> * interface: stream / message
>

I think this would make the gr-zmq C++ block code unnecessarily complex
and harder to maintain. The block requirements for each combination of
parameters grow in different directions.

Some things you'd have to deal with:
1. REP blocks have a receive then send main loop;
REQ blocks have a send then receive main loop.

2. REQ/REP can never drop messages/samples and so the tag propagation
code can be simple;
PUB/SUB can drop messages/samples and tag propagation code needs to
account for that in tag offsets

3. GNURadio messages are usually small enough that they can be handled
in one call to work(). GNURadio sample stream payloads can have a great
many samples that need to be handled across several calls to work().

It's just not worth it at the C++ level. Maybe at the GRC block XML
file level, it might be worth it.

My $0.02

Regards,
Andy

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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

Hi all,

week 10 of GSoC is over and I managed to implement an OFDM sync block:
https://grinspector.wordpress.com/2016/07/29/week-10-sync/

Since I make good time, I will try to add a FM demod block to the toolbox. Target is to have one example workflow from Ether to demod data (= sound).

Cheers,

Sebastian

2016-07-22 16:11 GMT+02:00 Sebastian Müller <gsenpo@gmail.com>:

Hi list,

in week 9 of my GSoC I finally managed to implement a working OFDM parameter estimation block. Read here about it:
https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/

Next up is a frequency and timing synchronization block.

Cheers
Sebastian

2016-07-18 9:57 GMT+02:00 Sebastian Müller <gsenpo@gmail.com>:
Hi Martin,

I have no problem with keeping the 'old' algo in the toolbox. But still I'm not sure if it is usable in real-world scenarios with sampling offsets. Maybe someone can improve it if interested.

Cheers, Sebastian

2016-07-15 19:22 GMT+02:00 Martin Braun <martin.braun@ettus.com>:
To clarify, if Koslowski's algorithm (since you already coined the
term...) is *as* good as your original one, but also faster, you should
not have duplicates. But if you did all the work to create software that
actually outperforms the fast algorithm in some other aspect, there's no
harm in keeping it around.

Cheers,
M

On 07/15/2016 10:20 AM, Martin Braun wrote:
> Sebastian,
>
> thanks for sharing, and your awesome work! I would suggest if you have
> an algorithm with great detection characteristics, you should keep it.
> If you want another suboptimal but fast one, create a second block (or
> whatever it is). The first algorithm did cost you time, and its superior
> detection performance might be interesting to other people.
>
> Cheers,
> Martin
>
> On 07/15/2016 08:10 AM, Sebastian Müller wrote:
>> Hi list,
>>
>> week 8 of GSoC is over and the latest news on gr-inspector are online:
>> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
>>
>> This week was a bit disappointing because the algorithm for the OFDM
>> estimation, which did show nice estimation results, and which I dealt
>> with 2 weeks now, had to be replaced because of performance issues. Now
>> I'll try a more straight-forward algorithm and hope to get started with
>> synchronization in two weeks.
>>
>> Cheers,
>> Sebastian
>>
>> Sebastian Müller <gsenpo@gmail.com <mailto:gsenpo@gmail.com>> schrieb am
>> Fr., 8. Juli 2016 um 13:48 Uhr:
>>
>> Hi all,
>>
>> week 7 of GSoC is over and I have written a blog post about what
>> I've been up to:
>> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
>>
>> I started implementing an OFDM parameter estimation block in python.
>> Also, I did some performance tests, which look quite good. Next, I
>> will implement this algorithm in C++. Stay tuned!
>>
>> Cheers,
>> Sebastian
>>
>> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
>>> Hi all,
>>>
>>> this week's GSoC blog post is ready! Check it out here:
>>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>>>
>>> I have finished the GUI so far and improved the Signal Separator.
>>> In the next time I will start with an OFDM parameter estimation,
>>> so stay tuned.
>>>
>>> Cheers,
>>> Sebastian
>>>
>>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gsenpo@gmail.com
>>> <mailto:gsenpo@gmail.com>>:
>>>
>>> Hi Ben,
>>>
>>> thanks for your interest. The manual signal selection is like
>>> the demod function in gqrx. You can move and resize an overlay
>>> that will determine the signal information that gets passed
>>> downstream. I have not dealt with AMC for now, but based on my
>>> own experience with manual modulation recognition I don't see
>>> a problem when not exactly hitting the signal edges. If your
>>> concern is too narrow selection, there is an oversampling
>>> factor parameter in the Signal Separator block, that will
>>> allow filtering wider than actually from the GUI specified, to
>>> compensate the naturally underestimated bandwidth when using
>>> energy detection. Also, the GUI now supports zooming so a user
>>> can work really precise if needed :)
>>>
>>> Thanks again for the feedback!
>>> Cheers,
>>> Sebastian
>>>
>>> 2016-06-27 16:41 GMT+02:00 Ben Hilburn
>>> <<mailto:bhilburn@gnuradio.org>bhilburn@gnuradio.org
>>> <mailto:bhilburn@gnuradio.org>>:
>>>
>>> Hi Sebastian -
>>>
>>> Thanks for the great update!
>>>
>>> I'm curious how the "manual selection with the mouse" will
>>> work? For some of the back-end processing that is going
>>> on, like Chris's AMC work, not selecting all of the bins
>>> of the signal seems like it could seriously impact the
>>> success of those functions. If the the FFT is, for
>>> example, 1024 bins, it seems like it may be hard for a
>>> user to accurately select the bins that are important.
>>> Will there be some sort of "intelligent auto-aim", for
>>> lack of a better word, for this?
>>>
>>> Thanks for the great work so far! The GUI screenshots are
>>> looking great, by the way.
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller
>>> <gsenpo@gmail.com <mailto:gsenpo@gmail.com>> wrote:
>>>
>>> Hi all,
>>>
>>> it's GSoC midterms time! For that purpose, I wrote a
>>> new blog post with what I've been up to and with a
>>> review of what I've done so far:
>>> <https://grinspector.wordpress.com/2016/06/26/week-5-midterms/>https://grinspector.wordpress.com/2016/06/26/week-5-midterms/
>>>
>>> I have managed to accomplish all of my midterm
>>> milestones and am looking forward for the next 8 weeks
>>> of GSoC.
>>>
>>> Cheers
>>> Sebastian
>>>
>>>
>>> Am 18. Juni 2016 um 15:06:11, Sebastian Müller
>>> (<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>> <mailto:gsenpo@gmail.com>) schrieb:
>>>
>>>> Hi all,
>>>>
>>>> my GSoC update came a bit later this week, because I
>>>> was abroad. The GUI came to life this week, read here
>>>> about it:
>>>> <https://grinspector.wordpress.com/2016/06/18/week-4-gui/>https://grinspector.wordpress.com/2016/06/18/week-4-gui/
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller
>>>> (<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>> <mailto:gsenpo@gmail.com>) schrieb:
>>>>
>>>>> Hi all,
>>>>>
>>>>> like every week I want to give a short update about
>>>>> my GSoC project. For details, check the blog post at
>>>>> <https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/>https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/
>>>>>
>>>>> Most of the week was used to debug the Signal
>>>>> Separator block, which did not pass my QA test. In
>>>>> consultation with my mentors I changed the structure
>>>>> under the hood and now the behavior is exactly like
>>>>> expected (same as Xlating FIR filter). Also I
>>>>> improved the Signal Detector with callbacks and an
>>>>> averaging function and started with the GUI.
>>>>>
>>>>> Cheers,
>>>>> Sebastian
>>>>>
>>>>> 2016-06-03 18:49 GMT+02:00 Sebastian Müller
>>>>> <<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>>> <mailto:gsenpo@gmail.com>>:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> the second GSoC week is over and I have updated
>>>>> my blog with the latest news:
>>>>> <https://grinspector.wordpress.com/2016/06/03/week-2-compiling/>https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>>>>>
>>>>> Mainly I did C++ implementation of the Signal
>>>>> Detector and Signal Separator blocks and started
>>>>> with the Signal Extractor block. Next week I
>>>>> plan to improve these blocks and start with the GUI.
>>>>>
>>>>> Cheers,
>>>>> Sebastian
>>>>>
>>>>> Am 28. Mai 2016 um 14:55:45, Sebastian Müller
>>>>> (<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>>> <mailto:gsenpo@gmail.com>) schrieb:
>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> thanks for the feedback!
>>>>>> PFBs are a topic I discussed with my mentors
>>>>>> and we decided to not use them because of the
>>>>>> following reasons. When using PFBs, there is a
>>>>>> trade-off between band resolution and
>>>>>> calculation effort (few filters lead to low
>>>>>> number of possible frequency bands, many
>>>>>> filters may have a high cpu usage). Since the
>>>>>> band separation is not dependend on the input
>>>>>> siganls, I think I can have a more efficient
>>>>>> solution with „customized" FIR filters for each
>>>>>> signal. The second reason is the implementation
>>>>>> effort that needs to be done (not only for the
>>>>>> PFB but also for recombining the bands again to
>>>>>> reconstruct the signals) is quite higher than
>>>>>> for using FIR filters. We were afraid that time
>>>>>> would be too short for implementing this (since
>>>>>> all this should work until the midterms in four
>>>>>> weeks).
>>>>>> We assume to have a moderate number of signals
>>>>>> in the input spectrum (let's say less than 5)
>>>>>> and I think the FIR filter approach is more
>>>>>> attractive here. But of course cpu usage is a
>>>>>> topic which I have to deal with. Therefore I
>>>>>> plan to use a lookup-table with precalculated
>>>>>> taps for different bandwidths and steepnesses.
>>>>>> Also, steepness (or something similiar) should
>>>>>> be a parameter of the block, so the user can
>>>>>> can somehow control the cpu usage with that.
>>>>>>
>>>>>> I hope that answers your question!
>>>>>>
>>>>>> Regards,
>>>>>> Sebastian
>>>>>>
>>>>>> Am 28. Mai 2016 um 12:45:49, Jan Krämer
>>>>>> (<mailto:kraemer.jn@gmail.com>kraemer.jn@gmail.com
>>>>>> <mailto:kraemer.jn@gmail.com>) schrieb:
>>>>>>
>>>>>>> Hey Sebastian,
>>>>>>>
>>>>>>> great work in your first week. Looking pretty
>>>>>>> good.
>>>>>>> One question though. At the end you propose to
>>>>>>> seperate the signals with a filterbank of
>>>>>>> xlating FIRs. Is there a use case or a way to
>>>>>>> do that with a polyphase filterbank? Cause
>>>>>>> multiple FIRs are going to become a major
>>>>>>> burden for the CPU if their number rises,
>>>>>>> especially if the filterorder gets pretty high
>>>>>>> e.g. for narrowband signals.
>>>>>>>
>>>>>>> Anyway keep up the good work.
>>>>>>> Cheers,
>>>>>>> Jan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2016-05-27 14:51 GMT+02:00 Sebastian Müller
>>>>>>> <<mailto:gsenpo@gmail.com>gsenpo@gmail.com
>>>>>>> <mailto:gsenpo@gmail.com>>:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> there is a new blog post concerning the
>>>>>>> gr-inspector toolbox:
>>>>>>> <https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/>https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>>>>>>>
>>>>>>> There I describe what I have done in my
>>>>>>> first week of GSoC. Mainly I have
>>>>>>> prototyped a signal detection block and
>>>>>>> started planning the signal separator
>>>>>>> block (which is used to pass the detected
>>>>>>> signals serialized).
>>>>>>>
>>>>>>> As always, comments are very welcome :)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sebastian
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Discuss-gnuradio mailing list
>>>>>>> <mailto:Discuss-gnuradio@gnu.org>Discuss-gnuradio@gnu.org
>>>>>>> <mailto:Discuss-gnuradio@gnu.org>
>>>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>
>>>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>

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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

From: Michael Dickens
Date: Thu, 28 Jul 2016 20:23:36 -0400
> On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote:
>> The ZMQ REQ/REP dataflow has the receiving end REQuest data from the
sending end when needed, which REPlies with a packet. It's a form of
flow control.
>>
>> From the GNU Radio perspective, streams flow into GNU Radio sinks to
exit the flowgraph, and data is sourced into a flowgraph from a GNU
Radio source block.
>>
>> Thus, the correct model is GR Stream | GR REP Sink | ZMQ REP | ZMQ
Transport | ZMQ REQ | GR REQ source | GR stream

[snip]

>My argument here is that it's equally valid to do the ZMQ REP/REQ
>transport either way, and if other projects are doing it the opposite
>way from GNU Radio, why aren't we providing an option to support that
>way?

[snip]

The ZMQ Guide is pretty clear that the core REQ/REP pattern is intended
to have the following usage:

REQuests are sent by Clients
REPlies are sent by Servers

Likewise in GNURadio it is clear that

Sinks send data out of a GNURadio instance
Sources send data into a GNURadio instance

Server vs. client and Source vs. Sink are orthogonal. So any of the
following is valid:
REQ source
REQ sink
REP source
REP sink
REQ msg source
REQ msg sink
REP msg source
REP msg sink

But what you actually should use depends on the functional context.

In the context of using REQ/REP, here are some use cases where I would
likely use a GNURadio instance as a server or a client. This is for
GNURadio instances communicating with programs which are not GNURadio
instances:

GNURadio as a client:
---------------------
(C1) Accepting medium to high rate sample data from an external source
for RX processing (REQ source)
(C2) After Rx processing, providing medium to low rate PDUs/messages to
an external source. (REQ msg sink)
(C3) Providing low rate status messages (REQ msg sink)
(C4) Accepting low rate sample data from an external source for further
Tx processing (REQ source)

GNURadio as a server:
---------------------
(S1) Tx processing output providing medium to high sample rate data to
an external source (REP sink)
(S2) Accepting medium to low rate PDUs/messages for Tx processing (REP
msg source)
(S3) Accepting low rate command and control messages (REP msg source)
(S4) After some Rx processing providing low rate sample data to an
external source (REP sink)

Of course other developers can have other design preferences than those
above.

In the above, I would actually never use REQ/REP for cases C1 and S1.
REQ/REP is too high overhead and provides a reliability guarantee way
beyond what is the norm for SDR. (libuhd/USRP source will drop data on
the floor if your GNURadio instance can't keep up; REQ/REP will not.)

REQ/REP is not the right pattern to use for high rate data. From the
ZeroMQ Guide:
"Request-reply, which connects a set of clients to a set of services.
This is a remote procedure call and task distribution pattern."

TL;DR:
REQ is for clients, REP is for servers.
ZeroMQ REP/REQ is orthogonal to GNURadio source/sink.
Some (REQ/REP, stream/msg, source/sink) block functional combinations
are missing from gr-zmq.
The current gr-zmq REQ/REP source/sink block combinations are not wrong
or incorrect, but they might not fit the usage pattern one may need or
envision in a particular context.
Don't use REQ/REP for medium to high sample rate sample streams.

Regards,
Andy

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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

Hi Francisco - Yes, I think having a generic ZMQ block would be awesome. Do you have an OOT module or block that does what you listed: a generic ZMQ block? If so, how do I gain access to it? This would save me lots of time! Thanks! - MLD

On Thu, Jul 28, 2016, at 10:21 PM, Francisco Albani wrote:

Michael, I found the need to do the same for some applications. I also needed to choose between bind and connect (I made this a parameter of my block).

Wouldn't be better to have just one sink and one source with selectable options, like:

* socket_type: REP/REQ/SUB/PUB/PUSH/PULL

* method: bind / connect

* interface: stream / message

Re: [Discuss-gnuradio] [USRP-users] N210s MIMO feature testing as in the Application Note Synchronization and MIMO updated kb

Hi Naceur,

I think this question has more to do with GNU Radio and GRC than with USRPs per say, so I added the GNU Radio mailing list.

I'll try and answer some of your questions.

1/ Your WX GUI looks old and ugly indeed. I've never had this issue before.

But WX widgets are "deprecated" and not recommended for use. You should be using the QT GUI widgets which look much nicer :D

2/ You can do a phase shift with the Multiply const block.

Just set the constant to cos(phi) + 1j * sin(phi) where phi is your phase shift.

You can even put the phase "phi" in a QT range (I believe that's the correct name) so you can change your phase shit from a slider on the GUI.

(One caveat here, you need to import cos and sin to use them. Just add an import block and put "import numpy as np" then in your Multiply const block set the constant to np.cos(phi) + 1j * np.sin(phi))

3/ I'm not sure what you mean or if I have the answer to this one.

Hope this helps,

Jawad

2016-07-29 0:31 GMT+02:00 El Ouni, Naceur (IntlAssoc) via USRP-users <usrp-users@lists.ettus.com>:

Hello usrp-users,

I am trying to test the MIMO capability of two N210s connected. I kept the 2 N210s connected through Ethernet to my Ubuntu 14.04 machine.

Following the Application Note on synchronization and MIMO, I generated two GNU Radio flowgraphs: non-MIMO.grc

and MIMO.grc:

Some questions arise here: 1/ did the WX GUI Scope Sink changed or what ? the document shows something like

However I am getting I guess an "uglier" version

2/ I am not able to find a phase shift block in the gnu radio palette. Does delay or Freq. Selective IQ Correction do the same function ?

Or is there any other block that may allow me to phase correct thw two uhd_sources signals.

3/ Apart from a consideration of Host-Radio data rate, how does connecting both MIMO-connectd USRPs with Ethernet cables or not affect my data paths, alignments of streams.

My ultimate goal is to be to show a pair of coherent receivers as show in the note

Thanks and Regards,

Naceur El Ouni

NIST - Wireless Networks Division (673)

100 Bureau Dr. Building 222-A218

Gaithersburg, MD 20899

(301) 975-3353

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [Discuss-gnuradio] gr-radar make issue

Hi,

Please run ctest -V and give the verbose error output. You give too
little information to guess what went wrong!

Greetings,
Stefan

On 07/29/2016 01:04 AM, Abhinav Jadon wrote:
> Hi ,
> I use an Ubuntu 14.04 machine. 64 bit processor.
> UHD version 003.010 | QWT version 6.0.0 | Boost version 1.54
>
> When i run the cmake command, everything gets built just fine (no
> errors). But when I open the flowgraphs in the examples folder, there
> are some gr-radar blocks that are not identified by grc ( probably they
> were not built properly). Also, 21 out of the 27 ctests are failures.
>
> Any help would be appreciated.
>
> Regards
> Abhinav Jadon
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Thursday, July 28, 2016

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

Michael, I found the need to do the same for some applications. I also needed to choose between bind and connect (I made this a parameter of my block).

Wouldn't be better to have just one sink and one source with selectable options, like:
* socket_type: REP/REQ/SUB/PUB/PUSH/PULL

* method: bind / connect

* interface: stream / message

2016-07-28 21:23 GMT-03:00 Michael Dickens <michael.dickens@ettus.com>:

On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote:

The ZMQ REQ/REP dataflow has the receiving end REQuest data from the sending end when needed, which REPlies with a packet. It's a form of flow control.

From the GNU Radio perspective, streams flow into GNU Radio sinks to exit the flowgraph, and data is sourced into a flowgraph from a GNU Radio source block.

Thus, the correct model is GR Stream | GR REP Sink | ZMQ REP | ZMQ Transport | ZMQ REQ | GR REQ source | GR stream

The GR stream is no longer the "pull" model that it was back in the day. If anything, it's more the "push" model: data is created at sources and moved downstream, processed & moved again until it reaches sinks.

It's just as valid to say that the sending end generates data, sends it via ZMQ, & REQuests a reply; the receiving end gets the data via ZMQ then REPlies; hence REQ/sink -> REP/source instead of the other way around. That's the model the ZMQ folks use in their Figure 2 from http://zguide.zeromq.org/page:all .

I'm not saying it's the only way to do things; what I am saying is that in a quick internet search this REQ/sink -> REP/source is how some other projects do their transport. I can't review all projects, so I can't say "many" or "all"; I did not find any projects that didn't do it this way, except GNU Radio, though they do likely exist.

My argument here is that it's equally valid to do the ZMQ REP/REQ transport either way, and if other projects are doing it the opposite way from GNU Radio, why aren't we providing an option to support that way?

As I wrote: I'm just going to create my own OOT that swaps the REP/REQ names, so that it works with my project. - MLD

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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote:

The ZMQ REQ/REP dataflow has the receiving end REQuest data from the sending end when needed, which REPlies with a packet. It's a form of flow control.

From the GNU Radio perspective, streams flow into GNU Radio sinks to exit the flowgraph, and data is sourced into a flowgraph from a GNU Radio source block.

Thus, the correct model is GR Stream | GR REP Sink | ZMQ REP | ZMQ Transport | ZMQ REQ | GR REQ source | GR stream

The GR stream is no longer the "pull" model that it was back in the day. If anything, it's more the "push" model: data is created at sources and moved downstream, processed & moved again until it reaches sinks.

It's just as valid to say that the sending end generates data, sends it via ZMQ, & REQuests a reply; the receiving end gets the data via ZMQ then REPlies; hence REQ/sink -> REP/source instead of the other way around. That's the model the ZMQ folks use in their Figure 2 from http://zguide.zeromq.org/page:all .

I'm not saying it's the only way to do things; what I am saying is that in a quick internet search this REQ/sink -> REP/source is how some other projects do their transport. I can't review all projects, so I can't say "many" or "all"; I did not find any projects that didn't do it this way, except GNU Radio, though they do likely exist.

My argument here is that it's equally valid to do the ZMQ REP/REQ transport either way, and if other projects are doing it the opposite way from GNU Radio, why aren't we providing an option to support that way?

As I wrote: I'm just going to create my own OOT that swaps the REP/REQ names, so that it works with my project. - MLD

[Discuss-gnuradio] gr-radar make issue

Hi ,

I use an Ubuntu 14.04 machine. 64 bit processor.

UHD version 003.010 | QWT version 6.0.0 | Boost version 1.54

When i run the cmake command, everything gets built just fine (no errors). But when I open the flowgraphs in the examples folder, there are some gr-radar blocks that are not identified by grc ( probably they were not built properly). Also, 21 out of the 27 ctests are failures.

Any help would be appreciated.

Regards

Abhinav Jadon

[Discuss-gnuradio] setter of the OOT module parameters cannot access from the top block

Hi,

I am trying to create an OOT module using gr_modtools. I followed the gnuradio tutorials and gr_modtool guidelines and the basic functionality of the block work fine.

I need to change a variable of the OOT module from the top block. To do it I added a setter function. I modified the impl.cc and .h files to add the function. The code compiled without any problem (I did make, make install and ldconfig). The new OOT block works fine with GRC, however, when I use the setter function from the top block it complains that the function is not declared. Is there any more files that I need to modify to get the setter functions working. I really appreciate if you could help me.

Thank you,

Damindra

Damindra Savithri Bandara,

Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

On Thu, Jul 28, 2016 at 12:20 PM, Michael Dickens <michael.dickens@ettus.com> wrote:

OK. I think the issue is that's not how ZMQ is designed to work with
respect to REQ/REP. I think it's designed to do "sink -> REQ -> ZMQ ->
REP -> source", so that the REQ is a sink & REP is a source. In a quick
internet search, this model is what I turn up. GR's model is the name
swap of this model; it would work internally to GR, but I won't be able
to connect GR to the outside world (or, at least my application) because
of this swapping.

The ZMQ REQ/REP dataflow has the receiving end REQuest data from the sending end when needed, which REPlies with a packet. It's a form of flow control.

From the GNU Radio perspective, streams flow into GNU Radio sinks to exit the flowgraph, and data is sourced into a flowgraph from a GNU Radio source block.

-Johnathan