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

[Francisco Albani]

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 :

> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Michael Dickens]

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

[Discuss-gnuradio] gr-radar make issue

[Abhinav Jadon]

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] setter of the OOT module parameters cannot access from the top block

[Damindra Bandara]

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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Johnathan Corgan]

On Thu, Jul 28, 2016 at 12:20 PM, Michael Dickens  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.

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

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

[Discuss-gnuradio] OFDM sync word generator

[Suman Bhunia]

Hi!

I was wondering if there is any code block available to generate 
suitable sync words for OFDM transceivers. I want to use 512, 1024 and 
2048 as FFT length for OFDM.


Any help is much appreciated.

==
Thanks and Regards,
Suman Bhunia
PhD candidate in CSE
University of Nevada Reno
http://www.sbhunia.me




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

Re: [Discuss-gnuradio] Questions on StackOverflow

[Martin Braun]

Let me emphasize this. The mailing list is terrible for searching, and
stack overflow is highly optimized to show the correct results, *if* we
have enough Q's and A's on there.

This is also about the efficiency of this list. The aforementioned bad
indexing means we'll get a lot of repeated questions, and we can't
really blame people for that. Stack Overflow is simply a much better
forum for simple questions with simple answers, while the mailing list
is unbeatable for discussions.

Cheers,
Martin


On 07/27/2016 10:16 AM, Marcus Müller wrote:
> Hi People,
> 
> at Grcon'14 we decided to reach out to the GR community forming on
> StackOverflow. We did – and I really think this is a great thing.
> 
> However, this support has come to somewhat of a halt. There's a bunch of
> questions[1] on StackOverflow that I can't answer, mostly due to
> temporal restrictions. Most of these aren't really hard to answer at all
> – an easy way to get StackOverflow Reputation¹ as a "SO newb".
> 
> So, if anyone of you has got time on their hands to help a few users
> that are lost with a few problems, taking the time to look, maybe
> comment, or answer questions on StackOverflow on StackOverflow, I think
> that would be a valuable contribution to the whole community process.
> 
> Otherwise, we might as well call off the whole "let's help people on SO"
> deal – and rather point them directly to the mailing list in comments. I
> don't think the separation that mailing list vs SO is facing currently
> is a good thing, if only mailing list users get "premium" support :)
> 
> Cheers,
> 
> Marcus
> 
> 
> ¹ Yes. They officially came up with a unit to measure credibility of
> internet strangers.
> [1]
> http://stackoverflow.com/search?tab=active=%5bgnuradio%5d%20%20or%20%5bgnuradio-companion%5d%20answers%3a0
> 
> 
> ___
> 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?

[Michael Dickens]

On Thu, Jul 28, 2016, at 03:11 PM, Sylvain Munaut wrote:
> > But this model doesn't work for the REP / REQ in Figure 2
> > "Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead
> > if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it
> > is instead a sink.
> >
> > The internal coding is consistent with the external naming; I just
> > question whether the naming was swapped. Am I missing something? - MLD
> 
> Basically it's coded so that you REQuest some samples from a server.
> 
> So the REQ is the source (it sends a request for data and gets back
> some samples that are fed to GR).
> And REP obviously then has to be a sink since it waits for a REQuest
> and when it gets one, sends some data out of GR in the REPlies.

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.

I'll write my own OOT that does ZMQ REP/REQ the way I need.

Thanks! - 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?

[Sylvain Munaut]

> But this model doesn't work for the REP / REQ in Figure 2
> "Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead
> if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it
> is instead a sink.
>
> The internal coding is consistent with the external naming; I just
> question whether the naming was swapped. Am I missing something? - MLD

Basically it's coded so that you REQuest some samples from a server.

So the REQ is the source (it sends a request for data and gets back
some samples that are fed to GR).
And REP obviously then has to be a sink since it waits for a REQuest
and when it gets one, sends some data out of GR in the REPlies.

Cheers,

   Sylvain

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

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

[Michael Dickens]

I'm trying to work with the ZQM REQ / REP message blocks while learning
about ZMQ. From their overview guide < http://zguide.zeromq.org/page:all
>, they define various graphs where the interconnects are the ZMQ
connections.

Thus, for example, in Figure 4 "Publish-Subscribe", the PUB would be GR
sinks: taking in messages / data & publishing it to a ZMQ SUB; the ZPQ
SUB would be GR sources: receiving data from ZMQ SUB & pushing out
message. Looking in GRC, these blocks align with my expectations.

Ditto for Figure 5 "Parallel Pipeline" using ZMQ PUSH (GR sink) and ZMQ
PULL (GR source).

But this model doesn't work for the REP / REQ in Figure 2
"Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead
if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it
is instead a sink.

The internal coding is consistent with the external naming; I just
question whether the naming was swapped. Am I missing something? - MLD

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

[Discuss-gnuradio] SWIG std::vector issue

[Dave NotTelling]

I have a utility lib in C++ created with 'gr_modtool add noblock' that has
a function that returns a vector of pmt::pmt_t values.  I need to then be
able to access the elements of that vector via Python.  Right now I get the
following error when using a for loop to iterate over the vector:


TypeError: 'SwigPyObject' object is not iterable
swig/python detected a memory leak of type 'std::vector<
boost::intrusive_ptr< pmt::pmt_base >,std::allocator< boost::intrusive_ptr<
pmt::pmt_base > > > *', no destructor found.


How does one iterate over the elements of a std::vector in
Python?

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