Jason Matusiak | 27 Jul 21:18 2015

Re: Any way to make the working window larger in GRC?

> "Options" block, "Window Size" parameter :)

Sadly would have never thought to look there.  That did the trick,
thanks.
Jason Matusiak | 27 Jul 19:44 2015

Any way to make the working window larger in GRC?

As I've attempted to copy and past some TX and RX examples into a single
window, I've started to run out of room.  Is there a way to make the
visual area larger so that I can fit more blocks in?  I've seen some
examples that are larger than the window and scrollable, but I can't
seem to figure out how to do that with my own GRC apps.  Is there a
setting somewhere or a config file that needs to be set?
Marcus Müller | 27 Jul 18:45 2015

Re: First Post - Question - GRC Repeat Block

Hi Kevin,

On 27.07.2015 17:53, mcquiggi wrote:
Hi Marcus:

I’m just following up on my Repeat block question.  I figured that I would take this off-list but if you think it appropriate for all then feel free to cc it back on-list.
I'll do that :)

Thanks for the assistance, let me know if I am wasting your time.
Far from it, actually! I think discussions like these are immensely valuable for the community -- people with different backgrounds contributing is one of the strengths of the GNU Radio project, and you are freely investing your time in this; in fact, I think what you're addressing below will be of interest to a lot of mailing list archive readers later on!

I had a look at various source code modules yesterday.  I looked at 'repeat_impl.cc' and ‘repeat_impl.h’  What I understand so far is that the new version of the Repeat block may have to move to the “General” type of block from that of an “interpolator” block, as it will now be in the M:N samples realm, rather than 1:N.
That's halfway true; if I understand your intention correctly, the block would stay 1:N -- but that N would be subject to change over the lifetime of the block. As far as I know, the normal sync_interpolator mother class can deal with that.

I also think I see that there is a value ‘noutput_items’ that gets computed once, when the block/object is created.
oh, no, that's the amount of items that the scheduler allows you to produce, so it's different each time work() is called!
 What I need is for this value to be variable and re-calculated by a change in the parameter in the GRC block.
It's a parameter, not a result of your work -- what you in fact need to re-calculate is the ratio between number of items you consume and number of items a call to work() produced.
In fact, sync_interpolator just overrides general_work like you would in a general block, and calls work(..) from within there -- based on the items work produced (usually, that's just the number work() returns), it calculates the items consumed (by a simple division).
 As the work function (which is fairly simple) is just a for loop 1 to noutput_items, then this seems correct.
So what you need to do when changing the number of repititions is just
a) change the value of d_interp, so that repeat's work() does the "right thing" and
b) call the set_interpolation method [1] to change the factor that is used behind the scenes to keep the amount of samples flowing in and out correct.

I see repeat_impl and work functions.  I gather that the repeat_impl routine allocates a block of storage or a buffer or something based on the static value of noutput_items which has been pre-computed in a higher level block.  This (I think) is where the code has to change. 
repeat_impl is a subclass of repeat (which itself is a subclass of sync_interpolator, which is a sync_block subclass, which is a block subclass, which is a basic_block subclass; C++ inheritance :) ).

This is now a bit of a oversimplification of C++, but I think you can deal with this: here, think of these C++ classes as C structs, that inherit all the elements from their mother structs. Methods are basically function pointers in these structs, and when invoked they automatically (and hiddenly) set a parameter "this" to be a pointer to the indidual struct object. That way, you can work with methods that really only operate on a single object's state, and don't have to always carry around a handle to the object to modify (which is a very C thing to do). So, work is such a function, and d_interp is a member of the struct that automatically relates to the "this" parameter, ie. you could also use this->d_interp (which really is a valid alias for d_interp).

What happens is that C++ makes sure that when the GNU Radio scheduler calls the general_work of any block, the respective block's implementation's general_work is called (in this case, sync_interpolator has that implementation of general_work). In the case of sync_interpolator, that general_work computes the right in- and output item numbers, and calls its work(), which is overridden by repeat_impl::work.

Now that's more software design theory than the average GNU Radio user has. What you need to know is: you implement a work() method; GNU Radio calls that when there's new data available or when there's still data on the input but new output space has become available.

There's one caveat that we'll have to address later: GNU Radio is multithreaded, and heavily so. Imagine the segfaults that would happen if you were to change d_interp from 1 to 10^9 in the middle of the for loop in work() running, but there was only output space for input_items[0]*1! C++, boost and GNU Radio have methods of dealing with that problem, and I'll gladly help with it.

Would re-calculation of noutput_items imply that the object created for the delay block has to be destroyed and get re-created?  I do not know anything about the internal structure of gnuradio so I am obviously in the dark.  I was unsuccessful in locating the place where noutput_items is calculated, I am guessing that it is in a higher-level block.

I’ve grabbed the source code and am building gnuradio (via the build-gnuradio script), so once I have all the source locally it will be easier to locate stuff.  I will look for where noutput_items is initially calculated.
It's calculated again, again and again, every time before calling your work() method.
The idea is that every block has it's (general_)work method, and GNU radio calls them, whenever the circumstances make that sensible, ie. when there is opportunity to generate/process items:
Assume you connect block A, B, C:
A->B->C
when the work method of B returns, the consumed input samples in its input buffer can be overwritten (GNU Radio implements circular buffers), since they already have been processed. Hence, in a different thread A's work() is called, with the info that noutput_items is now larger by exactly that amount of samples.
The same happens for C: B::work() returns, and GNU Radio calls C's work() with the info that there's new input available. When C::work() returns, B is notified again that there's output space available, and everything keeps flowing.


It may be a matter of you telling me how wrong I am, but otherwise I would ask if I am anywhere near the correct track?
You're pretty close to the real thing! The C coder is speaking through your questions, but that's absolutely not a bad thing; young "C++ folks" (I might consider myself that) often struggle with things like dealing with memory, pointer casting etc, where that's bread and butter techniques and patterns for C devs.
Have I pointed you to the guided tutorials?
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
Especially chapter 4 will be of interest to you. It does assume that you're somewhat proficient with C++, but 4.3.2.4 / Interpolation
illustrates what we're dealing with pretty nicely, I think.

Best regards,
Marcus

[1] https://gnuradio.org/doc/doxygen/classgr_1_1sync__interpolator.html#ae4daef83760cfe1951c9cf8a83520352


On Jul 26, 2015, at 2:54 AM, Marcus Müller <marcus.mueller <at> ettus.com> wrote:

Hi Kevin,

this is everything but a dumb newbie question! In fact, it explains quite well what you want to do, you illustrate with a screenshot of the relevant things, and you describe what happens instead. That makes this a well-researched, well-presented and thought through question.

So the point is that the GRC repeat block is but a graphical alias for the gr::blocks::repeat block[1]. As the docs show, that doesn't allow dynamic setting of the interpolation.

So, this email thread could now address different things:

(0. You kind of reported a bug. Or at least a feature request. If you want to do this the right way, open a issue on gnuradio.org's issue tracker.)
1. Do you really need repeat functionality, or are you in fact trying to adjustably interpolate a band-limited signal, in which case interpolation with a filter might be the right thing to do? There's a block that just wraps that nicely (fractional interpolator).
2. Do you want us to help you add that functionality to the repeat block? I had a look, it's not that hard, and it could get you on the contributor's list by helping an awesome free software project :) ; I haven't added that functionality yet, so there might be some surprises while doing this, but it should work.

Best regards,
Marcus

[1]https://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1repeat.html

On 26.07.2015 06:07, Kevin McQuiggin wrote:
I should have added that I am running gnuradio version 3.7.7.1 under OSX 10.10.4.
On Jul 25, 2015, at 8:26 PM, Kevin McQuiggin <mcquiggi <at> sfu.ca> wrote: Hi All: I would like to use a repeat block to stretch the duration of vectored input dynamically. For example, (0,1,0,1,…) input should become (0,0,0,1,1,1,0,0,0,…), the repeat count under control of a variable. In this example the Interpolation parameter would be 3. I observe that the “Interpolation” value in the Repeat block appears to be set initially, but does not respond to dynamic changes. Here is a minimalist flowgraph that shows this behaviour: <PastedGraphic-2.png> I would like to be able to use the QT GUI Chooser to select other vales for variable “test1” and have this dynamically adjust the Repeat block “Interpolation” value. This doesn’t work. In the example flowgraph, “Interpolation” is initialized and remains at 2, despite selecting other values for “test1” when the flowgraph is run. It is likely a dumb, newbie question, but how can I achieve the desired behaviour? I have scoured the Wiki, docs, Google, etc, and having not found an answer, I thought I’d make my first post and ask. Thanks in advance, Kevin _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio <at> gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

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


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Jose Perez | 27 Jul 17:56 2015
Picon

Power output RFX2400 and OFDM example

Hi all,

I am trying to obtain or know how much power output my hardware device is
transmitting. For this, I am running the example "tx_ofdm.grc" with a USRP1
and RFX2400 daughterboard. The RFX2400 provides a typical power output of 50
mW => ~ 17dBm. 
The block "Multiply const" can increase or decrease my transmitted signal
and I am also using a Spectrum Analyzer to measure the received signal
according the distance. 
Actually, I need understand how the "Multiply const" block relates with the
power output ... and what is the exact power that my hardware is
transmitting. 
If I put 0,5 in "Multiply const" block this means the I am transmitting half
of my all power output?

Thank you in advance.

Cheers,
José

--
View this message in context: http://gnuradio.4.n7.nabble.com/Power-output-RFX2400-and-OFDM-example-tp55049.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Simone Ciccia S210664 | 27 Jul 13:59 2015
Picon

file source with gr-ieee802.11 tx

Is there a way to make a continuous transmission with the gr-ieee802.11 
transmitter?
For example, reading a file (file sink), how to send the byte stream to 
the transmitter processing chain?
Tian Alvin | 27 Jul 12:28 2015
Picon

Error when build GNU Radio using cywin64

Dear list,

I have met some errors when I installed GNU Radio, I have followed the below instructions to installed GNU Radio:

I installed all the packages that needed, then I start to build GNU Radio, I have no problem to run the below commands:
$ cd gnuradio-3.7.2 $ mkdir build $ cd build $ cmake -DENABLE_DEFAULT=False -DENABLE_VOLK=True -DENABLE_GNURADIO_RUNTIME=True \ -DENABLE_GR_BLOCKS=True -DENABLE_GR_FFT=True -DENABLE_GR_FILTER=True \ -DENABLE_GR_ANALOG=True -DENABLE_GR_AUDIO=True ../

But when I do the next: "make", I encountered the below error:




 Could you please help? 


Best,
A


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Nathan Coppersmith | 26 Jul 23:05 2015
Picon

Analyze Waveform with GnuRadio

Hey all, (long post)

I'm trying to solve a cyber security challenge using GnuRadio, so I'm very new, and very lost.  I've spent the last few days reading, playing, experimenting, and trying to decipher the data contained within, but I'm at a loss, so I'm turning to ask for specific help, as the interwebz has not provided a clear path to the solution.  I'm not looking for an outright answer, but rather an analytical process that could be applied via lateral thinking to other challenges later on. (teach me to fish, don't give me a fish outright)

Here's what I know:  I have an .OGG file that sounds like a data transmission that needs to be demodulated.  A clue left behind in another challenge indicated that gnuradio with default blocks could be used to solve this one.  If you use a spectrum analyser (like sonic visualiser) and apply a spectrogram filter, you can see the following words embedded in the file: "Demodul me! 2400 bauds challange - Basic RZ with no preamble". You can also see this in Gnuradio by converting the OGG to WAV and viewing a GUI Waterfall sink. (fyi challange is spelled that way in the file, not sure if it's a typo or a hint)

Not knowing anything about radio, or frequencies, or GNUradio, how can I go about finding out what's inside this file?  I've been able to get file output from gnuradio, but I'm not doing it right as it's just jumbled data.  I've done significant reading on various modulation/demodulation schemes, but nothing seems to work the way I'm applying it.  It looks like the frequency is in the 400-650Hz range, but I don't think it's an RF signal, the embedded clue makes me think it's a packet stream from a dial-up modem.  Examining the waveform leads me to believe it's a frequency shift key type modulation.  I've tried to setup a flow in GRC of Wav File Source -> Throttle -> Float to Complex -> (various demodulators) -> Packet Decoder -> File Sink.

I don't think I need to modulate the input first, as I believe it's the raw modulated sound to begin with.  Not being versed in this area and feeling I've exhausted what's available via Google, I'm hoping someone can point me in the right direction.  I'm attaching the OGG file I'm using as input after converting to wav because it's smaller and I can't seem to get GNUradio to take OGG as a file input for some reason. (hopefully that doesn't break a TOS I didn't see)
Attachment (gnuradio.ogg): video/ogg, 651 KiB
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Andy Walls | 26 Jul 19:47 2015
Picon

Re: GNURadio CMake module/files for Google Protocol Buffers file generation?

On Sun, 2015-07-26 at 12:00 -0400, discuss-gnuradio-request <at> gnu.org
wrote:
> Message: 8
> Date: Sun, 26 Jul 2015 15:13:07 +0200
> From: Marcus M?ller <marcus.mueller <at> ettus.com>
> To: discuss-gnuradio <at> gnu.org
> Subject: Re: [Discuss-gnuradio] GNURadio CMake module/files for Google
>         Protocol Buffers file generation?

> Hi Andy,
> 
> without knowing for sure, I'd assume there'd be a bit of reinventing 
> wheels that will be unavoidable.
> 
> However, CMake does distribute a FindProtobuf.cmake [1], which 
> conveniently contains a command
> 
> protobuf_generate_cpp (<SRCS> <HDRS> [<ARGN>...])
> 
> 
> Now, I'd say you'd just do the same as for the source files in 
> lib/CMakeLists.txt, i.e. add a list variable that contains your proto 
> files, like
> 
> 
> list(APPEND gr_andys_module_proto_defs
> bufdef1.proto
> bufdef2.proto
> )
> 
> and then
> 
> protobuf_generate_cpp(PROTO_SRCS  PROTO_HDRS
> ${gr_andys_module_proto_defs})
> 
> and where you define the sources of your module, have that include 
> ${PROTO_SRCS}.
> 
> 
> You might run into some include path strangenesses, and I've found
> that 
> adding ${CMAKE_BINARY_DIR}/lib (or similar) to the
> include_directories() 
> directive might help
> 
> Cheers,
> Marcus
> 
> [1]
> http://www.cmake.org/cmake/help/git-master/module/FindProtobuf.html

Thanks, Marcus!

That ia the sort of running start I was looking for.

R,
Andy

> On 26.07.2015 14:57, Andy Walls wrote:
> > Hi:
> >
> > Can anyone point me to a CMake module or files that call the Google
> > Protocol Buffers compiler to generate *.pb.h and *.pb.cc before
> building
> > object files?
> >
> > Something already integrated with the GNURadio build system would be
> > ideal.
> >
> > I don't want to reinvent the wheel.  Thanks.
> >
> > Regards,
> > Andy
> >
Andy Walls | 26 Jul 14:57 2015
Picon

GNURadio CMake module/files for Google Protocol Buffers file generation?

Hi:

Can anyone point me to a CMake module or files that call the Google
Protocol Buffers compiler to generate *.pb.h and *.pb.cc before building
object files?

Something already integrated with the GNURadio build system would be
ideal.

I don't want to reinvent the wheel.  Thanks.

Regards,
Andy
Kevin McQuiggin | 26 Jul 06:07 2015
Picon
Picon

Re: First Post - Question - GRC Repeat Block

I should have added that I am running gnuradio version 3.7.7.1 under OSX 10.10.4.

> On Jul 25, 2015, at 8:26 PM, Kevin McQuiggin <mcquiggi <at> sfu.ca> wrote:
> 
> Hi All:
> 
> I would like to use a repeat block to stretch the duration of vectored input dynamically.  For example,
(0,1,0,1,…) input should become (0,0,0,1,1,1,0,0,0,…), the repeat count under control of a
variable.  In this example the Interpolation parameter would be 3.
> 
> I observe that the “Interpolation” value in the Repeat block appears to be set initially, but does not
respond to dynamic changes.  Here is a minimalist flowgraph that shows this behaviour:
> 
> <PastedGraphic-2.png>
> 
> I would like to be able to use the QT GUI Chooser to select other vales for variable “test1” and have this
dynamically adjust the Repeat block “Interpolation” value.  This doesn’t work.  In the example
flowgraph, “Interpolation” is initialized and remains at 2, despite selecting other values for
“test1” when the flowgraph is run.
> 
> It is likely a dumb, newbie question, but how can I achieve the desired behaviour?  I have scoured the Wiki,
docs, Google, etc, and having not found an answer, I thought I’d make my first post and ask.
> 
> Thanks in advance,
> 
> Kevin
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Johnathan Corgan | 26 Jul 04:44 2015

GNU Radio 3.7.8 Release Candidate 1, Call For Testers, and Live SDR Environment Snapshot Update

Feature Freeze and Release Candidate

The merge window for new features for GNU Radio 3.7.8 has closed, release candidate 3.7.8rc1 has been tagged, and only bug fixes will be accepted into the tree prior to release.  The planned release date is August 8.  If you have any pending fixes to submit, please create pull requests as soon as possible.

Tarball:


MD5:

e26d478e7ad51b7f889abb38f76d7aa1  gnuradio-3.7.8rc1.tar.gz

Call For Testers

If you have installed GNU Radio via git but don't routinely upgrade your GNU Radio installation, now is an opportunity to do so and test out what will eventually be released as 3.7.8.  Please remember to execute git pull --recurse-submodules in order to get the latest VOLK updates as well.

Since we lack automated tests for the GNU Radio Companion, we're asking people to emphasize testing your existing GRC applications for proper operation.

Live SDR Environment

We have updated the snapshot release of the GNU Radio Live SDR Environment image.  In addition to having the release candidate version of GNU Radio, there are new software releases for hardware support from Ettus Research (UHD 3.8.5), Nuand (2015.07), GreatScottGadgets (v2015.07.2), and Analog Devices (libiio/gr-iio v0.5).  Many of the third-party GNU Radio-based libraries and application software have been updated as well.  

Please see http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD for details about how to obtain and use the Live SDR Environment.

--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD
Intro to SDR Class - Sep. 3-4, Santa Clara, CA
http://corganlabs.com
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio <at> gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Gmane