QT GUI buttons not updating

[Martin Hübner]

Hello Guys,

I've a question concerning the gui-push-msg-button in conjunction with 
the gui-chooser.


If I understood it right, the chooser will set a variable called like 
its ID with the value I've chosen. In my flowgraph, I then try to read 
that variable and pack it into a message, whenever I push the message 
button.


There emits a message, whenever I push the button, but it will always 
have the standard value of the chooser, it never changes with the option 
chosen from. :/


Probably I misunderstand something here, but currently reading the docs 
does not help me further, as they read for me, like it should work as 
described.


Any hints on this would be highly appreciated. :) I've attached a 
minimal flowgraph below.


Best,
Martin



GUI-Test_min.grc
Description: application/gnuradio-grc

Re: Adding C++ Code generation support for c++ implemented blocks

[Martin Hübner]

Hi Marcus and Daniel,

sorry that I didn't respond fast in the last days. I am quite busy at 
the moment.


Thank you very much for the thoughts and ideas you shared with us. They 
are very valuable for our work and helped us a lot to get more context 
on our project.


As we are obliged to fulfil a working package description from our 
supervisors, we still discuss, how to incorporate your ideas into the 
project goals exactly.


I will hopefully get some time to keep you updated on this.

Best,
Martin

Am 21.05.23 um 10:00 schrieb Daniel Estévez:

Hi Martin and Marcus,

Just seen this thread.

I would suggest that you base the demodulator part of the flowgraph on 
the current FSK demodulator that gr-satellites uses:


https://github.com/daniestevez/gr-satellites/blob/main/python/components/demodulators/fsk_demodulator.py 



This is a Python hier block that can handle several different cases, 
but you can make a simpler C++ version adapted to S-NET.


This uses the Symbol Sync block with a Gardner TED instead of Mueller 
and Müller (mainly because I heard fred harris say that Mueller and 
Müller is not very good, though he didn't say which are the TEDs he 
prefers), and in general it is a better and more modern approach at 
FSK demodulation than the flowgraph for GNU Radio 3.7.


The Sync to PDU block is a Python hier block, but it uses only C++ 
blocks, so it would be really easy to port it to C++.


https://github.com/daniestevez/gr-satellites/blob/main/python/hier/sync_to_pdu.py 



Regarding the S-NET deframer, as Marcus pointed out, this is Python 
(it makes heavy use of numpy) and it uses a BCH decoder in Python. The 
reason why this is done in Python (as all the other Python code in 
gr-satellites) is primarily because of the faster development, and 
also partly better maintainability due to the smaller and simpler code.


Performance-wise, the implementation of the BCH decoder in Python is a 
joke, but for these satellites that transmit at a few kpbs, 
performance is not a problem unless decoding on a really constrained 
embedded platform.


I would be happy to see C++ implementations of the BCH decoder and the 
S-NET deframer being upstreamed and replace the Python implementations 
in gr-satellites. Marcus was right on the money with his comment about 
giving away free puppies, but if the code quality is good and there 
are unit tests, I have no regrets about taking over maintaining the 
code when it is upstreamed.


I would definitely encourage upstreaming the resulting code. Specially 
with university student projects, otherwise it is very difficult to 
ensure the long-term maintenance of the software, since projects end 
and students go. The code then bit rots. As an example, I can mention 
the BEESAT GNU Radio out-of-tree module, which I think is still only 
available for GNU Radio <= 3.8 (this was also a TU-Berlin project).


Finally, I agree with Marcus on whether porting all this stuff to C++ 
is the best approach if the goal is just improving how the software is 
shipped and installed. The idea to build everything into a single 
static binary might sound appealing, but to me it seems more similar 
to how applications are bundled for embedded platforms than for the 
desktop, and I can tell you that it can be full of issues.


Would you link statically the GNU Radio libraries in the binary as 
well? This is definitely possible, and you can produce a binary that 
only requires libc, libstdc++ and friends (libpthread, libm, etc.). 
However, you'll face problems with libc and libstdc++ versions across 
different distributions, unless you build against an version of these 
that is older than the ones in all the distributions you want to support.


How about multi-platform support? Building just one of these static 
binaries is a bit of a pain (for embedded I tend to set up a Docker 
container that builds everything from scratch as required). If you 
want to support Linux x86_64, Linux arm, Linux aarch64, Windows 
x86_64, Mac x86_64 and Mac aarch64, then things start to look 
daunting. And don't forget that if you want people to be able to 
modify and rebuild the software, the build system needs to be easy to 
use and not break when software versions change (this is why I use a 
Docker container for building).


Also, coming back to what I said about bit rot, it's quite likely that 
no one will maintain this static binary build system long-term, so 
your binary will end up bundling an old version of GNU Radio and other 
dependencies. It will work in the same way as it did on release day, 
but it won't benefit from improvements in new versions of the 
dependencies.


All I'm saying with this is that building and shipping software is 
complicated. Marcus' suggestion of using conda is great because it 
already saves you much of the work and complications.


Some words about user friendliness. Unless you're going to embed the 
decoder in a G

Re: Resource issues when trying to record 2 FM broadcast

[Martin Lefkowitz]

Here is the screen capture of the Marcus Leech version of the two FM 
demodulate as described here


https://wiki.gnuradio.org/index.php?title=Frequency_Xlating_FIR_Filter

https://github.com/patchvonbraun/wfm_stuff

With a samplerate of 2.4M it uses about 60% of the 4 core I5 I am using 
for this project


If anybody wants the grc pm me.

The other email contains the Zans version of stereo demod.


2fmtopblock.pdf
Description: Adobe PDF document


wfm_stereo-heir.pdf
Description: Adobe PDF document

Re: Resource issues when trying to record 2 FM broadcast

[Martin Lefkowitz]

Trying screen capture.  This email will contain the zans FM demod 
version of receiving 2 broadcast radio stations.  based on the project 
referenced here


http://zansprojects.blogspot.com/2019/05/stereo-fm-receiving-with-rtl-sdr-and_23.html

https://forums.radioreference.com/threads/multiple-fm-station-receiver.341340/#lg=_xfUid-2-1556650274&slide=0

At 1024Mhz sample rate I was getting about 89% on my 4 core I5. If I 
went much higher both the wav file and the audio out would glitch.


The other message will contain the Marcus Leech version


FM_Demod_heir.pdf
Description: Adobe PDF document


TwoFMDemod.pdf
Description: Adobe PDF document

Re: Resource issues when trying to record 2 FM broadcast

[Martin Lefkowitz]

It looks like the list doesn't handle .jpg.  i tried to post the images 
of my 2FM project to the list, but no images.  Is there a spot  to drop 
(image) files that is generally accepted on the list?



Marty


On 5/17/2023 5:23 PM, Gary Schafer wrote:

"I can post the block diagrams if someone is interested."

Yes, if you would, please. I'd be interested to see them and 
understand what it is you're trying to do.


Thanks!

Adding C++ Code generation support for c++ implemented blocks

[Martin Hübner]

Dear GNU Radio Community,

for a university project we want to use GNU Radio / gr-satellites to 
decode some signals of S-NET satellites. The goal for this semester will 
be, to provide a software that enables easy communication with them for 
HAMs, either by using traditional transceiver or SDR.


As the software will potentially be used by a broad group of differently 
experienced persons, we want to keep the deployment as easy as possible: 
A single statically linked binary would be ideal.


We already managed to setup a receiving pipeline in GRC like shown by 
DK3WN and EA4GPZ here:
https://www.dk3wn.info/wp/satelliten/s-net/ (GRC-Screenshot quite 
below). Next, we want to try to invert the flowgraph, to tackle signal 
generation and later on transmission too.


Unfortunately there are 4 blocks in the flowgraph, that don't support 
C++ code generation:


- Frequency Xlating FIR Filter
- Quadrature Demod
- Sync and create PDU
- S-NET deframer

For the first two blocks, it looks like they are implemented completely 
in C++. So I hoped adding support for them would be rather easy. I 
oriented for that on Håkon Vågsether work done here:

https://github.com/haakov/gnuradio/commit/18cbe62c27c3dc8006b707a172da80300e2adfa8

Similarily, the C++ support for the rather easy quadrature demod block 
should look like this then, right?

https://github.com/Akira25/gnuradio/tree/add\_cpp\_generation-quadmod

We would love to upstream these changes too, if you find them useful.

Kind regards,

Martin

Re: Resource issues when trying to record 2 FM broadcast

[Martin Lefkowitz]

After reviewing your email, Marcus, I decided to go back to my original 
project with the Marcus Leech FM heir.  I saw that ultimately the reason 
I stopped was that the Osomocom block (from the gunradio 3.7 project) 
was not sending signal.  I could see this because the FFT graph directly 
connected to that output  was blank. I was able to get the original 
project working by creating a new project adding a osomocom block then 
copying the rest of the blocks from the original project and it began 
working.  At 2.4M sample rate it uses 50% of the CPU.  The project with 
the FMDemod heir block is at 89% CPU usage at 1024M.  Don't quite 
understand why but the old one works now and is more efficient.  I can 
post the block diagrams if someone is interested.

Resource issues when trying to record 2 FM broadcast stations

[Martin Lefkowitz]

I  haven't spent a whole lot of time working with gnuradio.  I'm not a 
DSP engineer.  I am however a software engineer that has dealt with 
signals so not completely a laymen, but I am out of my comfort zone.


I  had successfully created this project about 4 years ago using Marcus 
Leech's Stereo FM Radio implementation and grafting it into the front 
design of this  the multiple station receiver design. Described here


https://forums.radioreference.com/threads/multiple-fm-station-receiver.341340/#lg=_xfUid-2-1556650274&slide=0 



I recorded 2 pirate radio stations at a 4 day music festival. Started 
the recording on Thursday.  Stopped it on Sunday.  The sample rate was 
2.4M.  I created an Heir block that had the appropriate parts of Marcus 
Leech's Stereo FM radio in it.  and replaced everything from the xlating 
FIR to the multiply const in the second block figure above with the heir 
block, and added some WXQT blocks to handle the gui for 2 stations like 
wav sinks, file names, etc.  It was successful, but one thing that did 
happen was I needed to go from a Acer 720 (celeron) with Gallium 
installation to an (older) I5 laptop.


I let that project sit for a couple of years.  The first thing I did 
when I got back to it was upgrade everything.  Big mistake... Nothing 
worked after that.  I got grc 3.10 running with radioconda.  I swapped 
Marcus's implementation out for Zan's fm_stereo_demod_clean


https://forums.radioreference.com/threads/multiple-fm-station-receiver.341340/#lg=_xfUid-2-1556650274&slide=0

http://zansprojects.blogspot.com/2019/05/stereo-fm-receiving-with-rtl-sdr-and.html

In this new implementation I needed to create a series of variables to 
handle the design issue of having the signal be a multiple of 48k for 
the audio sink to be the correct speed.  In particular the decimations 
in the rational resampler.This worked, but when I changed the sample 
rate to widen the bandwidth to receive 2 stations further apart on the 
FM band than 1Mhz I ran into performance issues.  Basically with my 
setup the CPU load is about 90% with a sample rate of 1.24 Mhz.


I was able to do this because of the great work done by the people 
mentioned above, but figuring out how to deal with the performance 
issues is kind of beyond the disciplines I am familiar with.  I am 
wondering if anybody has any suggestions on how to get 
fm_stereo_demod_clean to have better performance.  I did not see an 
updated version of the Marcus Leech design so I figured there was 
something blocking that update, but maybe that is incorrect. I am also 
wondering if I could get a more powerful laptop/NUC and make it work 
with brute force by throwing money at the project.  I would love to hear 
any suggestions from people with more grc and dsp experience, or which 
path I should take now.



Thanks in advance


Marty

Re: Problems with the Frequency Xlating FIR Filter

[Martin Braun]

Can you try running this in a REPL to see what the return value of
firdes.lowpass(...) is?

--M

On Tue, Jan 25, 2022 at 2:03 AM Michelle  wrote:

> hello,
>
> I'm using a FIR filter and I have the error : "Param - Taps(taps):
> Expression None is invalid for type'complex_vector'."
>
> my taps is : firdes.low_pass ( 1, samp_rate, frec_carrier,
> 25000,firdes.WIN_HAMMING )
>
> samp_rate and  frec_carrier are both variables in my graph.
>
> I don't understand why I have an error. Please could you tell me what I
> am doing wrong?
>
>
> Thank you.
>
>

Re: Building packages for GnuRadio 3.8 and UHD 4.1.0: Circular dependency?

[Martin Braun]

Hi Katja,

I was trying to figure out where that comes from. Maybe this is the key:
https://packages.ubuntu.com/jammy/libuhd-dev

This page is telling me that libuhd-dev recommends gnuradio-dev (not that
it depends on it). Maybe your script is also working on recommended
dependencies? Have you tried --no-install-recommends (in step 4)?

--M

On Fri, Jan 21, 2022 at 5:42 PM Schütz, Katja <
katja.schu...@iis.fraunhofer.de> wrote:

> Hello there,
>
>
>
> I’m building packages for internal use:  GnuRadio 3.8.5 and UHD 4.1.0.5
> and noticed that each seems to have the other as dependency. Is this
> correct? How to deal with that? Build and install them alternating?
>
>
>
> Background: We have a fairly complicated flowgraph which we don’t want to
> convert to GnuRadio3.9. On the other hand we enjoy and use features and bug
> fixed from UHD 4.1.0.5. Our server runs Ubuntu 20.04 (Focal) and that won’t
> change soon. Until now we used a script to download both, GnuRadio and UHD,
> as archives and build them directly on the machine. The package is meant to
> save time when installing a new server and guarantee the specific versions.
> Also we could then directly work on the code.
>
>
>
> What I did:
>
> 1.   Download sources with apt. For UHD I used the jammy repo as
> focal only provides 3.15
>
> 2.   Install UHD build dependencies (sudo apt-get build-dep) for uhd
>
> 3.   Build UHD package (dpkg-buildpackage –b)
>
> 4.   Try to install:
>
> a.   libuhd4.1.0 installs fine including dependencies
>
> b.   libuhd-dev_4.1.0.5 depends on gnuradio, gnuradio-dev and several
> libgnuradio packages
>
> 5.   Try to install gnuradio build dependencies
> -> build depends on libuhd-dev
>
>
>
> Does this really mean to install libuhd-dev I need to install gnuradio,
> but to build gnuadio (with UHD support) I need to install libuhd-dev?
>
> Again my question: Where do I even start? Is this intended?
>
>
>
> Thanks for looking into this!
>
> Best Regards,
>
> Katja
>

Re: [USRP-users] time division duplexing (TDD) with USRP B2xx

[Martin Braun]

Ali,

most of the time, these types of applications require the RX to be on
permanently (unless you know exactly when you're expecting packets), and
the TX only when you're transmitting packets.

In GNU Radio, this is simply achieved by using a USRP Sink and Source,
respectively. The USRP Source (RX) will be permanently receiving into your
custom DSP blocks. The USRP Sink (TX) will only transmit when it gets data,
so all you need to do is send it data when you have some. Important: You
need to add the "tx_eob" tag. See the manual:
https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html#a244302d311f9232dc0634ebb920508c7
(look for "bursty transmission").

Note: The TX signal will leak into RX and will appear as a really strong
signal. You need to filter those out.

If you're doing vanilla UHD, it's pretty much the same. Except now, you
need to pass in the tx_eob tag as metadata (see here:
https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html).

--M

On Sat, Jan 15, 2022 at 11:22 AM Ali G. Dezfuli  wrote:

> I am going to implement a real-time TDD link (in the order of
> one-millisecond burst durations) using two laptops and two USRP B2xx (in
> either single antenna or dual-antenna ways). I searched a lot on the net
> especially GNU Radio's mailing list but could not find any clear techniques
> or tutorials to deal with it. So, I wonder if someone helps me manage that
> in a step-by-step way. Thank you!
> ___
> USRP-users mailing list -- usrp-us...@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>

Re: RfnocError: OpTimeout: Control operation timed out waiting for space in command buffer

[Martin Braun]

Christoph,

we have occasionally heard about this issue. Can you please open an issue
on https://github.com/EttusResearch/uhd/issues. The more data we have on
this, the better. It's possible this may affect other USRPs, too.

--M

On Fri, Nov 26, 2021 at 9:10 AM Christoph Schultz (Riedel) <
christoph.schu...@riedel.net> wrote:

> Dear Gnuradio Users,
>
>
>
> I am facing a crash when repeatedly receiving data on a X300 using
> Gnuradio.
>
> To run into this issue, I load a top_block with a usrp_source, a head and
> a file_sink initially.
>
> Then a sequence of start()-wait()-stop()-wait()-reconfigure is run for
> e.g. 200 times.
>
> After a deterministic number of cycles the following error will appear:
>
>
>
> thread[thread-per-block[0] ]: RfnocError: OpTimeout:
> Control operation timed out waiting for space in command buffer
>
> Similar to the issue discussed here:
>
> https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11413.html
>
> my first idea was, that the command buffer is getting filled faster than
> it is sent to the USRP device, but artificial sleeps between the loop
> cycles do not change the behavior at all.
>
>
>
> I was also not successful in reloading the usrp_source object on Python
> level (without stopping the full python process, and restarting it again
> manually).
>
>
>
> So it looks like the gnuradio functions leave something in the command
> buffer which I couldn’t clear so far without reloading the whole library by
> restarting Python.
>
> Is this a known issue? Are there any ways to manually release the command
> buffer, or is it a potential bug, which should go to the bug tracker of gr?
>
>
>
> Many thanks in advance and
>
> Best regards
>
> Christoph
>
>
>
> Christoph Schultz
> RF System Architect
>
>
> [image: RIEDEL at Social Media]
> <https://www.riedel.net/en/social-media-links/>
> 
>
> RIEDEL
> Communications GmbH & Co. KG
> Uellendahler Str. 353
> 42109 Wuppertal
> Deutschland
>
> phone: +49 202 292-9150
>
> christoph.schu...@riedel.net
> www.riedel.net
> 
> RIEDEL Communications GmbH & Co. KG
> Registergericht: Amtsgericht Wuppertal HRA 22390
> Umsatzsteuer-Identifikationsnummer: DE 814906984
> Komplementärin: RIEDEL Communications International GmbH, Wuppertal
> Registergericht: Amtsgericht Wuppertal HRB 17038
> Geschäftsführer: Thomas Riedel, Frank Eischet, Martin Berger
>
>
>
>

Re: Error with two versions of GNU Radio: 3.7.13.4 and 3.8.0.0

[Martin Braun]

Isaac,

we've sunsetted GNU Radio 3.7, so any issues with that version of GNU Radio
will remain where they are, unfortunately.

--M

On Mon, Nov 29, 2021 at 3:41 PM isaac mario tupac davila <
isacct...@gmail.com> wrote:

> Hello
>
> I'm Isaac. I've installed GNU Radio 3.8.0.0, my second version of GNU
> Radio for one pc, following the steps of this website:
>
> https://kb.ettus.com/Building_and_Installing_UHD_and_GNU_Radio_to_a_Custom_Prefix
>
> I could run GRC, but some errors appear regarding qtgui:
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_bercurve_sink')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_const_sink_x')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_edit_box_msg')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_freq_sink_x')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_histogram_sink_x')
> Warning: docstring loader crashed too often
>
> My GRC also closes immediately if I try to open any QT block.
>
> How could I solve this error?
> Is it possible to solve this mistake without eliminating my old version of
> GR (3.7.13.4)?
>
> Please any help will be appreciated.
>
> Regards
> Isaac T.
>
>

Re: How to Change the modulation mode of "constellation decoder" in real time?

[Martin Braun]

Hey,

I don't see a conceptual reason why you can't change the equalizer at
runtime, but you have to be careful to not get into concurrency issues. You
should hold onto a reference to your new equalizer until some condition is
met, and then replace d_eq at "the right time", whatever that is (before
the frame processing starts, but after some condition is met, like the
timestamp you want to change it at or something like that).

>From your linker errors, it looks like you have some conceptual problem
though (unrelated to equalizers). I recommend you read some other blocks'
code first to see how callbacks are added, then try adding some empty
callbacks until the linker is happy, and then proceed.

--M

On Mon, Dec 27, 2021 at 2:46 AM maolin liu  wrote:

> Hello everyone，
>
> I'm sorry to bother you here，I wasn't sure whether my previous email
> was sent, but I was eager to know the answer to this question, so I sent it
> again. I would like to ask if there is any method or suggestion for me to
> control the modulation mode of "OFDM frame equalizer" module and
> "constellation decoder" through "QT GUI chooser" or other widgets. I know
> that they cannot be changed. Because they do not have "callback" function,
> they will be fixed once the flow graph runs. I try to write "callback"
> function myself, But my C + + level is really limited. There are some
> errors here. I don't know how to solve them.
>
>
>
> /usr/bin/ld: libgnuradio-digital.so.v3.8.2.0-111-g6aad98a6: undefined
> reference to
> `gr::digital::ofdm_frame_equalizer_vcvc::set_equalizer(boost::shared_ptr)'
>
> /usr/bin/ld: libgnuradio-digital.so.v3.8.2.0-111-g6aad98a6: undefined
> reference to `typeinfo for gr::digital::ofdm_frame_equalizer_vcvc'
>
> collect2: error: ld returned 1 exit status
>
> make[2]: *** [gr-digital/lib/CMakeFiles/digital_qa_header_
> buffer.cc.dir/build.make:104：gr-digital/lib/digital_qa_header_buffer.cc
> ]
> error 1
>
> make[1]: *** [CMakeFiles/Makefile2:8900：
> gr-digital/lib/CMakeFiles/digital_qa_header_buffer.cc.dir/all] error 2
>
>
>
> I refer to the writing method of callback in other modules, but there
> are still errors, and I think it is not good to change the source code,
> which may cause many unknown errors, so I want to know whether there are
> other ways for me to change the modulation mode at any time? Or is it
> feasible to add the callback function directly?
>
> Any suggestion would be appreciated！
>
> Bset Regrads,
>
> linge93
>
>
>
>
>
>
>

Re: Rate matching between host and SDR

[Martin Braun]

Moses,

software doesn't run at fixed rates. Instead, you keep track of how many
samples you've transmitted. If you're underrunning, then your software
design is slower than the hardware clock of your USRP. In your case, you're
also not signaling an "end of burst" (also you're copying fcpxIQ instead of
passing a reference, and the clear() call at the end seems misplaced).

I recommend you familiarize yourself with the UHD examples, such as
tx_waveforms. They will get you started. From there, you can take your
lessons learned and integrate them into your software.

Cheers,
M

On Thu, Jan 6, 2022 at 4:17 PM Moses Browne Mwakyanjala 
wrote:

> Hi everyone,
> I'm experimenting with a C++ standalone USRP transmitter using the
> function shown below. The data is generated by another function called
> Modulate() which "posts" the modulated IQ samples to this function. The
> transmitter works very well for burst transmissions (individual packets). I
> was wondering how to do transmission in a continuous way. I mean, the
> Modulate() function depends on the CPU clock while the actual transmission
> is dictated by the rate of the USRP. I did try to send blocks of samples
> (10,000) continuously and the USRP was reporting underruns. How do I make
> sure my functions run at the same rate as the USRP?
>
> voidUSRPDriver::TransmitIQ(std::vector > fcpxIQ){
> //assert(1 ==0);
> if(m_bDeviceUp){
> if(DEBUG)
> std::cout << "USRPDriver::" << __func__ << "Transmitting IQ Frame 
> Size = " << fcpxIQ.size() << std::endl;
> // setup metadata for the first packet
> uhd::tx_metadata_t md;
> md.start_of_burst = false;
> md.end_of_burst   = false;
> md.has_time_spec  = false;
> md.time_spec  = uhd::time_spec_t(1.5);
> // the first call to send() will block this many seconds before 
> sending:
> double timeout =  10.0; // timeout (delay before transmit + padding)
> tx_stream->send(&fcpxIQ[0], fcpxIQ.size(), md, timeout);
> fcpxIQ.clear();
> }
> }
>
>
> Regards,
>
>
> Moses.
>

Re: Peaks when increasing the FFT lenght ofdm example

[Martin Braun]

Did you repost this accidentally, or is this a new question?

On Thu, Jan 6, 2022 at 12:15 PM Pedro Viegas  wrote:

> Hi everyone,
>
> I'm having a problem when I increase the number of carriers from 64 to 512
> in the gnuradio OFDM example. When the number of carriers is 512, the
> complex envelope of the signal in the time domain has some peaks, which I
> can not have for the test I'm trying to make. Can anyone tell why there are
> those peaks and how I get rid of them?
> A possible cause for the peaks, in my opinion, can be the fixed frame len
> of the header, that is filled with zeros when the FFT size increases,
> resulting in a peak in the beginning of each frame because of the ifft
> block. If this is the problem, how can I change that frame len?
> To better show what I'm saying, there is an image on the attachments of
> the complex envelope with the peaks, and a .txt file with the
> specifications of the ofdm parameters.
>
> Thanks in advance,
> Pedro Viegas
>

Re: Regarding open source

[Martin Braun]

Gunesh,

if you decide that you do want to contribute to GNU Radio (which we would
be happy about), make sure that you first go through most of the GNU Radio
tutorials, and make sure that you can build and install GNU Radio from
source without requiring external help. These are things that you need to
have down before you can start doing actual contributions. Next, start
playing with something that interests you personally, like receiving
specific waveforms. When you get into the thick of it, you will
automatically find things to improve, or you will learn to understand what
the issue tracker is talking about.

--M

On Mon, Jan 3, 2022 at 7:48 PM Josh Morman  wrote:

> Gunesh,
>
> If you are generally interested in open source, find a project that you
> would like to contribute to - maybe that is GNU Radio, maybe something else
> you find along the way.  Familiarize yourself with the software and reach
> out on the chat asking for ways you can get involved.  This might be at
> first improving documentation or fixing minor issues.  There is a tag in
> the github which is "good first issue" which can be good to tackle.  Once
> you are ready to submit a pull request (contributing your code back to the
> main repository), myself or others can help guide on some of the
> particulars.
>
> Josh
>
> On Mon, Jan 3, 2022 at 11:57 AM Gunesh  wrote:
>
>> hello sir,
>> thank you for having me on board.
>> As I am new to open source could you help me with getting started.
>> and i have done only c++ language so could you help me by guiding me
>> about where should i contribute.
>>
>>
>>
>> Regards
>> Gunesh munjal
>>
>>
>> On Mon, Jan 3, 2022 at 9:19 PM Josh Morman  wrote:
>>
>>> Hi Gunesh,
>>>
>>> Glad to hear you would like to contribute.  This is a great starting
>>> point:
>>> https://wiki.gnuradio.org/index.php/Development
>>>
>>> And also, it can be useful to join the conversation at chat.gnuradio.org
>>> to ask questions
>>>
>>> Looking forward to seeing you get involved - it can be a great
>>> experience and it is an excellent community to work with!
>>>
>>> Josh
>>>
>>> On Mon, Jan 3, 2022 at 10:02 AM Gunesh  wrote:
>>>
   Hello sir,
 I am Gunesh Munjal currently in 1st year. I am new to open source and
 want to contribute. As, I don't know how to get started with open source it
 would be great if you could help me out sir. I am having the knowledge of
 c++.Hoping to hear from you soon.


 regards
 gunesh munjal

Re: Headless Airspy operation on Raspberry Pi

[Martin Braun]

Glen,

thanks a lot for sharing this!

--M

On Mon, Jan 3, 2022 at 7:06 PM Glen Langston 
wrote:

> Hello and Happy New Year to all,
>
> We’ve just released a version of the Raspberry PI OS that works with
> Airspy R2 and Airspy Mini,
> as well as SDRPlay RSP1A, PlutoSdr and RTL-SDR.
>
> It is rather specifically configured for Radio Astronomy, but anyone could
> build other designs
> in it using Gnuradio 3.10 (first release candidate).
>
> It is available for download (3.1 GB) at:
>
> https://drive.google.com/file/d/1N0bX20tUO_IyRBlp06aAXGMwbx-ykomz/view?usp=sharing
>
> The installation guide (pdf) is here:
>
>
> https://drive.google.com/file/d/1ssS_zBQWDEXMENc2_aqqPGxGkEEU5Ea3/view?usp=sharing
>
> Hope this is useful to you.
>
> Best regards
>
> Glen
>
>
> > On Jan 2, 2022, at 9:23 PM, Dale Farnsworth  wrote:
> >
> > I recall seeing 3 of your posts in the past 2 days.
> >
> > On Sun, Jan 2, 2022 at 12:30 PM __jmp  wrote:
> > Is anyone seeing my replies?  I cant' seem to get a response from
> anything I post.
> >
> >
> > _._,_._,_
> > Groups.io Links:
> > You receive all messages sent to this group.
> >
> > View/Reply Online (#42077) | Reply To Group | Reply To Sender | Mute
> This Topic | New Topic
> > Your Subscription | Contact Group Owner | Unsubscribe [
> glen.i.langs...@gmail.com]
> >
> > _._,_._,_
>
>
>

Re: Does complex conjugate invert IQ ?

[Martin Luelf]

Dear Rachida,

in order to do that, use the "complex to float" and "float to complex" 
blocks and connect the re output to the im input and the im output to 
the re input.


Yours
Martin


On 13.12.21 16:31, Rachida SAROUI wrote:
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau <mailto:fab...@opencode.eu>> a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
 > Hi everyone,
 >
 > I need to invert the I and Q of a complex signal. Does the block
complex
 > conjugate do the job?
 >
 > Thank you
 >

Re: Questions On GNU Radio FFT Data logging

[Martin Luelf]

Dear Zen Chen,

to subscribe to the mailing list you need to follow this link: 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I think the account on the GNURadio website is for editing the Wiki etc.

You are sampling your signal at 10 MSamples per second. Since you use a 
complex signal (blue input to the file sink) that means each sample is 
two 32 bit floating point numbers). Thus your generated binary file has 
a size of 80 MByte per second of recording.


If you convert that into a CSV file the default formater for 
numpy.savetxt() is .18e, meaning that each real and imaginary part will 
be written as 24 characters (one place before the decimal, the decimal 
point, the 18 places after the decimal and 4 chars for the exponential). 
These need to be delimited by a comma and finally a new line character. 
That makes 50 characters per measurement. For a regular ASCII file each 
char is 1 Byte so you are writing 50 Byte/sample * 10 MSample/s = 500 
MByte per second of recording.


That is a lot of data. For a 5 second recording for example you are 
asking Excel to import a 5GB file (!). I don't know Excel too much but 
that sounds like it might be to much. Possible remedies are: try to 
reduce the sampling rate (which will reduce the monitored bandwidth) or 
try to record very short bursts, or (my personal opinion) try to analyze 
your signal in a program that is more suitable to signal analysis than 
Excel. You most definitely want something that can work directly with 
the binary files from GNURadio's file sink rather than having to use a 
CSV file. GNURadio itself, python/numpy, Matlab/octave, C++ are all good 
choices for the analysis (and certainly many more).


Yours
Martin



On 10.12.21 09:59, Zen Chen wrote:
Yes933_10_12_20212nd.csv 
<https://drive.google.com/file/d/1tEaxr9bQICfDm-Uu6nIfGcLSQd6Rfb1Z/view?usp=drive_web>
HI all,My name is Zen Chen , a GNU radio Novice and I tried to create an 
account on the GNU Radio .org website to post my questions on the 
mailing list however I could not . I am using GNU radio and Hack RF 1 to 
design a power spectrum analyser and I am using the attached flowgraph 
to and python script to give me the attached CSV file however , the 
results (FFT connect to file sink) is to large to be contained in a 
single excel file . Is there a problem in my GNU Radio Flowgraph?


Regards,
Chong Zhi

Re: RF signals are pure noise in Python implementation

[Martin Braun]

Verónica,

have you maybe mismatched data types? Like, the real signals are fixpoint,
but your Python is doing floating point?

--M

On Thu, Nov 25, 2021 at 2:59 PM Verónica Toro Betancur 
wrote:

> Hi,
>
> I am trying to detect and decode WiFi and ZigBee signals in GNURadio. For
> the detection, I have implemented my own blocks in Python. It all works
> well with simulated signals but the problem comes when I use radios to
> acquire real signals. I'm using Pluto SDR and it works perfectly when I use
> it in workflow examples but not in my own implementation. I mean, I plot
> the data that comes directly from the radio and it looks good in the given
> examples but, in mine, it looks like noise.
>
> I am using the exact same parameters in both cases. The only difference I
> see is that the blocks in the example are all in C++ while mine are in
> Python. Could this be the problem? If so, is there a way to solve it other
> than writing the blocks in C++?
>
> Thanks in advance.
>
>
> Best regards,
> Verónica
>

Re: Is there a Gnu Radio block to compute the power of a signal?

[Martin Spears]

This is good to know. After reading this I was going to ask a similar question 
about RSSI. I will look further into this as well

Get Outlook for Android

From: Discuss-gnuradio  on 
behalf of Marcus Müller 
Sent: Thursday, November 18, 2021 7:37:08 AM
To: discuss-gnuradio@gnu.org 
Subject: Re: Is there a Gnu Radio block to compute the power of a signal?

That's almost certainly not an answer to the question you're posing, namely 
"How do I
measure the power of a specific class of signals".
A function probe is just a method of getting some data out of a flowgraph, and 
it's almost
never the appropriate solution (function probes are really more for debugging, 
or very
sporadically/randomly updated GUIs and such, not for signal processing).

First of all, it's important to note that basically none of the SDRs you'd 
attach to GNU
Radio come calibrated by default – so the numbers you see in GNU Radio are only
proportional to some amplitude of electrical field. So, digital powers are only
proportional to the powers on the air, but can easily be calculated taking the 
squared
magnitude of your complex samples.

Best regards,
Marcus

On 18.11.21 11:45, Rachida SAROUI wrote:
> Thank you very much!
>
> Le jeu. 18 nov. 2021 à 11:40, Van-Dung PHAM  > a écrit :
>
> Hi, you can use the Function Probe in GNU Radio to measure the Power in 
> dBm
>
> Vào Th 5, 18 thg 11, 2021 vào lúc 11:23 Rachida SAROUI 
>  > đã viết:
>
> Hello everyone,
>
> I'm looking for a gnuradio block or a method to determine the power 
> of a received
> LORA signal from an arduino. Can anyone help me please?
>
> Thank you
>
>
>
> --
> ---
> Van-Dung,PHAM
>

Re: Sending a file through a LimeSDR mini with a loopback cable using PSK modulation

[Paul Martin]

Oh sorry for the confusion, I'm NOT running gnuradio from the pycharm
venv, I just put the folder there so pycharm handles the version
control.
Just in case, I did what you suggested, but the same as before
happened (new log attached).

I've just finished setting up a VM and both flowgraphs work, so it
must be something to do with my install. On the VM I only get a
warning on the transmitter: "Warning: failed to XInitThreads()", but
as far as I can tell it doesn't change anything.

I tried Evgeny's simplified flowgraph with a LimeSDR mini and it also works.

Tomorrow I'll experiment a little more and let you know if I find
anything interesting.

Again, thanks a lot to both of you!

Paul


On Thu, 11 Nov 2021 at 15:37, Paul Atreides  wrote:
>
> Glad to hear you didn’t give up!
> H. I haven’t seen this one on my machines. I see you’re using pycharm 
> (which is what i use). I think I had to setup pycharm to find GNURadio. IIRC 
> Pycharm typically sets up its own environment, so it might be missing a 
> module? That may not be valid, just my first thought.
>
> Try getting pycharm out of the equation temporarily by creating your own 
> embedded block (name it something different) and use the default editor 
> (gedit on my machine). Then copy past the code from the wiki into that, see 
> if the error persists. Again, just first thoughts to simplify the problem.
>
> I’ll see if there’s anything on my end I can see that’s obvious.
>
> 
>
> > On Nov 11, 2021, at 12:38, Paul Martin  wrote:
> > Evgeny, Paul:
> > Thanks so much for replying! I was actually about to give up after all.
> >
> > I've tried to use the updated flowgraphs from the wiki, but got an
> > error message while running the transmitter (log attached). Google
> > didn't help to figure out what was wrong, besides the fact that it's
> > the python embedded block.
> >
> > The receiver seems to work fine, although it has no data to receive at
> > the moment.
> >
> > Paul
> >
> > On Thu, 11 Nov 2021 at 13:50, Paul Atreides  wrote:
> >>
> >> Answers below.
> >> Barry, can you fill in where my understanding is weak here?
> >>
> >> 
> >>
> >> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  wrote:
> >>
> >> 
> >> Indeed it works great out of the box :) Thanks Paul for fixing this!
> >>
> >> My pleasure, thanks for testing it!
> >>
> >>
> >> But when I upgraded the setup by replacing the ZMQ with LimeSDR (Tx on one 
> >> LimeSDR is transmitting to an Rx of another LimeSDR through an 
> >> attenuator), the Rx wasn't able to recover the message. I simplified the 
> >> flow by removing the resamplers and using a single sampling rate and added 
> >> a squelch block to the Rx to stop the idle signals and it's working well 
> >> this way. My Tx and Rx flowcharts are attached.
> >>
> >> Any time you introduce the “real world” of hardware there are many new 
> >> variables. Things like DC offset, dynamic range, etc. can really effect 
> >> your outcome.
> >> Sounds like you stripped it down pretty aggressively. I think you need to 
> >> get more familiar with your analog environment and play with it a bit. 
> >> This part is not as “drag and drop” as some of the digital parts.
> >>
> >>
> >> There are some questions that are still open...
> >> 1. There is an access code for Rx. Where was it created? Do I need it?
> >>
> >> The access code is created in the embedded Python block. The code is 
> >> commented, copy and paste the values into a Python IDE and display them as 
> >> bits, you’ll see the sync word there. As to whether or not you need it, I 
> >> think that’s up to you and your implementation. Generally I’d say yes, but 
> >> you should read up on the use of sync words/access codes to understand 
> >> their uses better.
> >>
> >> 2. The Tx should send some sync header before the data, that would be used 
> >> by the Rx while locking on the clock frequency and this data won't be 
> >> recovered. I don't see such sync data here, am I correct?
> >>
> >> Answered above. I think it’s a difference of terminology. Again, the 
> >> embedded block is commented and answers this question.
> >>
> >> I increased the delay between every 2 messages to 5 sec and timed the 
> >> detected messages, it seems that part of them are not detected. Actually, 
> >> I am surprised that anything at all gets detected! How is the clock 
> &g

Re: Sending a file through a LimeSDR mini with a loopback cable using PSK modulation

[Paul Martin]

Evgeny, Paul:
Thanks so much for replying! I was actually about to give up after all.

I've tried to use the updated flowgraphs from the wiki, but got an
error message while running the transmitter (log attached). Google
didn't help to figure out what was wrong, besides the fact that it's
the python embedded block.

The receiver seems to work fine, although it has no data to receive at
the moment.

Paul

On Thu, 11 Nov 2021 at 13:50, Paul Atreides  wrote:
>
> Answers below.
> Barry, can you fill in where my understanding is weak here?
>
> 
>
> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  wrote:
>
> 
> Indeed it works great out of the box :) Thanks Paul for fixing this!
>
> My pleasure, thanks for testing it!
>
>
> But when I upgraded the setup by replacing the ZMQ with LimeSDR (Tx on one 
> LimeSDR is transmitting to an Rx of another LimeSDR through an attenuator), 
> the Rx wasn't able to recover the message. I simplified the flow by removing 
> the resamplers and using a single sampling rate and added a squelch block to 
> the Rx to stop the idle signals and it's working well this way. My Tx and Rx 
> flowcharts are attached.
>
> Any time you introduce the “real world” of hardware there are many new 
> variables. Things like DC offset, dynamic range, etc. can really effect your 
> outcome.
> Sounds like you stripped it down pretty aggressively. I think you need to get 
> more familiar with your analog environment and play with it a bit. This part 
> is not as “drag and drop” as some of the digital parts.
>
>
> There are some questions that are still open...
> 1. There is an access code for Rx. Where was it created? Do I need it?
>
> The access code is created in the embedded Python block. The code is 
> commented, copy and paste the values into a Python IDE and display them as 
> bits, you’ll see the sync word there. As to whether or not you need it, I 
> think that’s up to you and your implementation. Generally I’d say yes, but 
> you should read up on the use of sync words/access codes to understand their 
> uses better.
>
> 2. The Tx should send some sync header before the data, that would be used by 
> the Rx while locking on the clock frequency and this data won't be recovered. 
> I don't see such sync data here, am I correct?
>
> Answered above. I think it’s a difference of terminology. Again, the embedded 
> block is commented and answers this question.
>
> I increased the delay between every 2 messages to 5 sec and timed the 
> detected messages, it seems that part of them are not detected. Actually, I 
> am surprised that anything at all gets detected! How is the clock locking so 
> fast?!
>
> I think this speaks to the “conclusions” section on the wiki that Barry wrote 
> up extremely well. Read that, it will explain what your seeing.
>
> 3. (a side question) Why do you multiply the signal by 1/2 before 
> transmitting? Are you aiming to get to +-1 levels to avoid clipping?
>
> I didn’t write the flowgraph, but I know what your talking about. There is 
> probably a fundamental DSP principle here that eludes me at the moment as I 
> don’t have it in front of me, but avoiding clipping sounds correct, maybe 
> Barry can answer this?
>
>
>
> Evgeny
>
>
> On Thu, Nov 11, 2021 at 11:54 AM Paul Atreides  wrote:
>>
>> Evgeny:
>> I just updated the wiki. If you are willing to test them out, please try the 
>> new GR3.8 tutorials under the subsection
>> "Using BPSK with Hardware Simulation (version 3.8)"
>> https://wiki.gnuradio.org/index.php/Packet_Communications
>>
>> On Wed, Nov 10, 2021 at 12:07 PM Evgeny Hahamovich  
>> wrote:
>>>
>>> Hi Paul,
>>>
>>> I tried to perform a similar experiment and unfortunately after investing a 
>>> significant effort, still haven't figured out how the packets method works 
>>> :(
>>> For now, I pack the data in python, send the packed data to GNURadio and 
>>> LimeSDR_Tx. and on the Rx side, I detect by LimeSDR_Rx, perform all the 
>>> clock recovery procedure in GNURadio and then send the extracted bits to 
>>> python via ZeroMQ where I do the unpacking with my code. It's definitely 
>>> not optimal, but it works.
>>>
>>> Evgeny
>>>
>>>
>>> On Wed, Nov 10, 2021 at 5:16 PM Paul Martin  wrote:
>>>>
>>>> Hi!
>>>>
>>>> I'm trying to send a file through a LimeSDR mini with a loopback cable 
>>>> using PSK modulation.
>>>>
>>>>
>>>> The gr-limesdr plugin only works with gnuradio 3.8, so I'm on that versio

Re: Adding custom function in OOT module

[Martin Luelf]

Dear Wei,
which GNURadio version are you using?

On 3.9 you need to update the python bindings for your block (assuming 
you have a python flowgraph).


Before 3.8 you need to make sure that the SWIG bindings that GNURadio 
generates are updated (which should happen automatically, but for me 
they get stuck sometimes). Try deleting the build folder and build your 
OOT again from scratch.


Yours
Martin


On 10.10.21 23:30, Huang Wei wrote:

Hi group,

It could be a simple question, but I could not find the solution. I am 
writing my own OOT C++ module, I want to add a function get_value() in 
the block, so I can use Function Probe to read value in the block 
through this function.

so in the lib/my_block_impl.cc, I added:
double my_block_impl::get_value()
{
    return value_global;
}
int my_block_impl::work(...)
{
    ...
}

in lib/my_block_impl.h, I added:
Public:
   double get_value() override;

and in include/tootl/my_block.h, I added:
Public:
   virtual double get_value() = 0;

Then I did: make, sudo make install and sudo ldconfig.
But when I run the flowgraph, it keeps saying that "my_block_sptr" 
object has no attribute "get_value". where I made the mistake?

Thank you very much for your help!

Regards,
Wei

Hacktoberfest 2021

[Martin Braun]

Hi all,

and yes, whoops, it's already a week into October. But it's not too late
to remind folks that this month is Hacktoberfest
(https://hacktoberfest.digitalocean.com/)!

Hacktoberfest is an event organized by a third party whom we have no
relationships with. Nevertheless, it's a fun event, and if you
participate, you can either get a t-shirt, or donate to having a tree
planted.

In order to participate, you need to sign up (see website link above),
and submit 4 valid pull requests. While we will make sure to dunk on
invalid/spam PRs, we will also make sure to either tag PRs as valid, or
make sure they get merged during this month. You can submit PRs against
any repository that has the 'hacktoberfest' tag to make them count
towards your score.

Of course, we encourage and welcome pull requests all year round, but if
you have any kind of improvement for GNU Radio and have been holding
back, now really is the time to submit them!

It doesn't matter if you submit small documentation updates, or major
bugfixes. Any contribution is welcome.
If you're looking for things to fix, then our issue tracker might give
you inspiration. For example, you can look for issues tagged "good first
issue":
https://github.com/gnuradio/gnuradio/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

Cheers all, and happy hacking!

--M

Re: Questions on B200 PPS

[Martin Braun]

Marcus is right, "_external_" is a B200- and N2x0-only feature.

I also think 8 ms should be fine, but just as an FYI, "our" PPS signals
have a 25% duty cycle (so, 250 ms). Since we only register the pos. edge,
anything in the ms-range should be working. When you say "occasionally", do
you mean within a single session? I.e., you init the device, set the time,
and then don't touch the device any more?
As an experiment, can you try a time that's not on the PPS edge (like. .5
seconds off)?

Really, the PPS shouldn't be the issue here, since it's only used once (to
set the time).

--M

On Fri, Sep 10, 2021 at 8:49 PM Marcus D. Leech 
wrote:

> On 2021-09-10 2:35 p.m., Mike wrote:
>
> Hello,
>
> We are using an external GPSDO to provide 10 MHz and PPS into a B200.
>
> Our application collects a fixed number of samples at 50 MSPS using a
> stream command (UHD_STREAM_MODE_NUM_SAMPS_AND_DONE and the timespec for the
> next PPS).  In this way we rely on the USRP to provide samples that begin
> at the instant of PPS arrival.
>
> This works almost all the time.  Occasionally, it appears we miss one
> sample (20 ns) and thus our timing is off.  We suspect this is due some
> behavior in the B200 related to the PPS.
>
> We are using a Stanford Research FS740 for our GPSDO and have it set to
> provide a 5 volt PPS pulse with a duration of 8 microseconds.
>
> Questions:
>
> 1.  Is 8 milliseconds long enough for a PPS signal?  If not, what value
> would be appropriate?
>
> That should be plenty.
>
> 2.  Documentation shows an alternate for the
>
> usrp->set_time_source("external");
>
> command that uses underscores on either side of the word, as
>
> usrp->set_time_source("_external_");
>
> What exactly does this command do relative to the leading edge of the PPS
> signal?
>
> My recollection is that this is a leading-vs-trailing option in PPS
> processing--I'm not even certain that the B2xx family supports that
> flexibility.
>
> It may be that what you're seeing is a sampling anomaly with respect to
> the PPS.  If the PPS is *sampled* by the FPGA at 50MHz, you would expect
> there
>   to be occasional anomalies of 1 sample time.  But I am not intimately
> familiar with the FPGA code, so I'm not sure.
>
>
> To the extent it matters, we are operating under Ubuntu 20.04 with UHD
> 3.15.
>
>
> Thanks!
>
>
>

Re: 3D plots or image display in GR

[Martin Braun]

Marcin,

gr-specest (https://github.com/kit-cel/gr-specest/) has some
cyclostationary code, as well as some matplotlib-based plotting thereof.
The code was written in the Py2k era and might be out-of-date. But it might
be an inspiration!
--M

On Mon, Sep 13, 2021 at 9:57 PM Marcin Wachowiak <
marcin.r.wachow...@gmail.com> wrote:

> Hello,
>
> I would like to experiment with some cyclostationary signal detection in
> GNU Radio.
> In order to visualize the results, I need some kind of 3D plot or 2D
> image plot (to visualize matrix values). Having searched for similar
> topics on the internet and mailing lists I decided to ask here.
>
> What could be the best approach to obtain such plots in GR? Should I try
> to introduce a new Qt block or use an embedded python block with matplotlib
> (create a sequence of plots, animation)? I can also do simple
> postprocessing after collecting the data but live visualization or one with
> tolerable latency would be most desirable. Maybe I can utilize some of
> the existing blocks like constellation sink and change the colours of
> points accordingly to values in the matrix?
> Please let me know your thoughts.
>
> Kind regards,
> Marcin Wachowiak
>

Re: UHD function to determine USB version?

[Martin Braun]

Mike,

this is available since UHD 4.0, so maybe that's the issue. You can dump
the tree with uhd_usrp_probe --tree, and see what nodes you have.

--M

On Thu, Sep 9, 2021 at 8:43 PM Mike  wrote:

> Hi Martin,
>
> Thanks for your response.  I tried the command you provided but received
> this:
>
> Error: LookupError: Path not found in tree: /mboards/0/usb_version
>
>
> I see the trace statement
>
> [INFO][B200] Operating over USB 3.
>
> but was hoping for a UHD API call rather than using the system() function,
> but if I can get the tree location correct it should work.
>
>
> Thanks again.
>
>
>
> On 9/9/2021 3:34 AM, Martin Braun wrote:
>
> (log statements removed)
>
> $ uhd_usrp_probe --args type=b200 --int /mboards/0/usb_version
> 3
>
> --M
>
> On Fri, Aug 27, 2021 at 8:51 PM Mike  wrote:
>
>> Hello,
>>
>> I apologize if I missed it in the documentation, but is there a UHD
>> function that will return the USB version (e.g. USB 2 or USB 3) that the
>> USRP is using?
>>
>> I'm using a B200 in a custom C++ program and would like to
>> programmatically verify the USB connection speed before attempting high
>> rate sampling.
>>
>>
>> Thanks!
>>
>>
>>
>>

Re: Using an E310 in place of a B200

[Martin Braun]

UHD 4.0 has a network mode, too, which comes out-of-the-box (it does not
require an extra executable). You can use it like a B200, but as Marcus
says, with less streaming performance.

--M

On Tue, Jul 20, 2021 at 10:41 PM Marcus D. Leech 
wrote:

> On 07/20/2021 03:52 PM, Mike wrote:
>
> Hello,
>
> We are working with the srsRAN software package (www.srslte.com).  Our
> hardware configuration is a laptop running the srsRAN application under
> Ubuntu, connected via USB to a USRP.  It runs well with B200s, however we
> do not have access to B200s at the location where our testing will take
> place.
>
> What we do have are E310s.  The srsRAN application expects a UHD-based
> front end, as is standard when using a B200.  What we are looking for is a
> way to make an E310s look like a B200 to the laptop, accessible via UHD.
>
> Is there an easy way to do this, like some kind of bypass mode to give
> direct access to the radio?  MATLAB appears to support this type of
> operation but we're not clear how.
>
>
> Thanks!
>
>
> E310 have something called "network mode", so you don't have to use them
> as a not-very-well-endowed embedded platform.  Unfortunately it's
>   very limited in the bandwidth it can deliver and really isn't
> recommended.   The last LTS release for E310 that even supported network
> mode was
>   UHD 3.9.
>
> The E310 was really intended as a small embedded platform where if you're
> clever you can split functionality between the on-board FPGA, and
>   the embedded ARM dual-core CPU.
>
>
>

Re: UHD function to determine USB version?

[Martin Braun]

(log statements removed)

$ uhd_usrp_probe --args type=b200 --int /mboards/0/usb_version
3

--M

On Fri, Aug 27, 2021 at 8:51 PM Mike  wrote:

> Hello,
>
> I apologize if I missed it in the documentation, but is there a UHD
> function that will return the USB version (e.g. USB 2 or USB 3) that the
> USRP is using?
>
> I'm using a B200 in a custom C++ program and would like to
> programmatically verify the USB connection speed before attempting high
> rate sampling.
>
>
> Thanks!
>
>
>
>

Re: How to debug GNU Radio's C++ program from source code?

[Martin Luelf]

Hi,

in case you don't have VS code, you can also run GDB directly 
https://wiki.gnuradio.org/index.php/TutorialsDebugging#Tutorial:_Using_gdb_with_Pythonic_GR_applications


Yours
Martin


On 03/08/2021 15:48, Josh Morman wrote:

Hello!

Even though GNU Radio has python bindings with swig or pybind11, the 
underlying code c++ symbols are still accessible with GDB. Using Visual 
Studio Code and GNU Radio compiled from source with Debug Symbols this 
is pretty straightforward:

1) Open up the source tree of gnuradio in visual studio code
2) edit the launch.json and add a C++/GDB configuration where program is 
python and args is the output of the GRC rendering

         {
             "name": "(gdb) Launch",
             "type": "cppdbg",
             "request": "launch",
             "program": "/usr/bin/python3",
             "args": ["/path/to/grc_output.py"],
             "stopAtEntry": false,
             "cwd": "${workspaceFolder}",
             "environment": [],
             "externalConsole": false,
             "MIMode": "gdb",
             "setupCommands": [
                 {
                     "description": "Enable pretty-printing for gdb",
                     "text": "-enable-pretty-printing",
                     "ignoreFailures": true
                 }
             ]
         },
3) put the breakpoint where you want to hit - note that GR will have 
been compiled with optimizations, so the breakpoints might be a bit funky

4) F5 to run the application

If you are debugging your own OOT, this makes it even simpler because 
you can compile as "-DCMAKE_BUILD_TYPE=Debug" and then your breakpoints 
will be very predictable - in this case you just open up VS code from 
the root of your project and follow the same steps.


Hope this helps.

Josh



On Tue, Aug 3, 2021 at 8:41 AM 能书能言 <2127629...@qq.com 
<mailto:2127629...@qq.com>> wrote:


Hi guys!
I want to know how to debug c++ code in gnuradio. As far as I know,
after we run GRC, a Python file will be generated. The Python file
connects various blocks, but if I debug this Python file directly, I
cannot observe the internal operations of the C++ block. I want to
know if there is any way to let me Can I see the contents of the
c++work function when I run the python file? It's like executing a
pure Python or pure C++ program.
If this is not possible because of the swig connection method, how
can I observe the work of a C++ block's work function? If I look at
the code directly, it is definitely not accurate enough. Can I write
a demo by myself? Or other ways.
In addition, how to edit an existing block? I just want to modify
its function slightly. Do I have to use gr_modtool to create a new
OOT module and rewrite it based on the contents of the original
block? You must also use debugging methods when writing, but I don't
know how to do it.
in addition. I have tried the tutorials on the official website, but
none of them worked. I also checked the previous mailing list, but
it was not very helpful. I think anyone has a better solution?
Sincerely

Re: Having problems using forecast method

[Martin Luelf]

Dear George,

please always reply to the mailing list (or have the list in CC), rather 
than only to the person you are replying to. This way other people that 
will find your original question in the future can benefit from the 
discussion as well.


From your example I see that you are using python rather than C++. 
Python will automatically convert the ratio between two integers to a 
floating point number if that is required, so you can ignore my comment 
on casting everything to float.


For your small example with just 12 samples the way GNURadio works might 
seem overly convoluted and complicated, but GNURadio can't know whether 
this flowgraph will run for just 12 samples, or for hours with millions 
and millions of samples. In the latter case it is impossible to process 
everything in one go, so GNURadio is processing everything in smaller 
chunks. Your code assumes it will process the entire data set within one 
call of general_work, rather than processing just the part that GNURadio 
currently wants processed. Or at least it assumes that GNURadio will 
always feed you input data and output buffer size in the correct ratio. 
But that is not correct. GNURadio will provide you as much input data as 
it has right now, even if that is more than you asked for.


It will ask a block beforehand, "Hey block, how much samples do you need 
from me to give me a certain number of output samples" (this is done in 
the forecast method). It might actually call forecast multiple times 
with a different number of outputs until it arrives at a situation where 
the requested number of input samples are actually available in a buffer 
from a previous block (it might also run the previous block a couple of 
times before coming back to the current block to make sure there is now 
enough input).


Then it calls the general_work function and tells it, here are 
len(input_items) inputs and here is a buffer where you can write your 
output to. Since this buffer needs to be allocated first you cannot 
write an arbitrary amount of data into that buffer. general_work must 
produce *at most* as many output samples, as output_items[0] is large. 
general_work can chose to produce exactly that amount of outputs, less, 
or none at all (even though it told GNURadio something else in forecast).


Then the scheduler will run another time. Usually by first calling 
forecast (maybe multiple times) and eventually general_work where you 
can produce additional output. This will repeat until you have processed 
all the data.


The bug in your code is that you determine the number of loop iterations 
only based on the number of input samples, not on the available output 
buffer size. To better understand this behavior I suggest you add a 
print statement into the forecast method that prints the requested 
number of output samples and your computed number of input samples and a 
print statement in the general_work method that prints the length of the 
input_items[0] and output_items[0] arrays (before you change any of 
them). With these prints you should be able to follow my description of 
the scheduler and understand what you need in your code to fix the error.


Yours
Martin


On 06.07.21 14:00, George Edwards wrote:

Hi Martin,

Thank you very much for the detailed response. Like I indicated, I 
experimented and found a work around by leaving out the forecast method 
and in the general_work method, I simply get the value of the number of 
input samples and scale it to get the precise number of outputs and 
reset Gnuradio noutput_items[0] to match and it works. But I would love 
to learn how to also use the forecast method and have the same OOT work.


Here is a simplified version of my OOT code using the forecast method 
and it works sometimes in the QA test which is not good. In this OOT I 
am feeding in a stream of data and output a stream. In this exampleI I 
choose M=4 and N=2 to be small numbers and M/N =2 was an integer (my 
true algorithm has M and N in the hundreds and M/N is not an 
integer, but would be a decimal value). This simple algorithm, reads the 
input in group of 4 values and output the first two values in the group. 
I will list my results when I run the QA test!  Here is the Python code:


In the general_work method I have:
in = input_items[0]
out = output_items[0]
jj =0
for n in range(0, len(in)-4, 4):   # read in 4 samples at a time so M=4
      input = in[n:n+4]
      for k in range(0,2)
           out[jj] = reg[k]                # write to output to the 
first 2 input samples, N=2

           jj = jj+1
self.consume(0, len(input_items[0]))
return len(output_items[0]) ,

In the forecast method for loop, I set input_items_required[i] = 
noutput_items*M/N   where M=4 and N =2


I ran the QA test with input vectors [0,1,2,3], then [0,1,2,3,4,5,6,7] 
and the outputs were [0,1] and [0,1,4,5], respectively which are correct.
When I changed the QA input vector to [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 

Re: Having problems using forecast method

[Martin Luelf]

Dear George,

what specifically does not work with your test? Any error messages, or 
is it not producing the result you are expecting. And if so, what is 
your block input, what is the output and what output are you expecting?


Keep in mind that the forecast method tells the scheduler how much input 
you *likely* need. This is not binding, meaning the general_work method 
does not have to produce this number of outputs, nor does GNURadio have 
to give you that exact amount of input data. In the general_work method 
you need to tell the scheduler how many samples you used (using the 
consume method) and how many samples you created (by returning that number).


Also be aware of the data types in C++. noutput_items is an int. If M 
and N are integer types as well, C++ will round M/N to the nearest 
integer before multiplying it to noutput_items and you have effectively 
created an integer decimating block. To avoid that you want to cast M, N 
and noutput_items to a floating point number type (if you know the C++ 
specifics you can probably get away with just casting one type and have 
the compiler cast the others, but just to be sure I would cast them all 
to float). With that you will get a floating point number of samples 
that your block needs. Since GNURadio can only deal with an integer 
number of samples, it is up to you and your algorithm to bring that to a 
sensible integer number. Most likely you will want to round that number 
up or down and feed this integer number of samples back into 
ninput_items_required[0].


Yours
Martin


On 05.07.21 22:51, George Edwards wrote:

Hello,

I played with it and got it to work. I left out the forecast method and 
forced my will on the scheduler in terms of the input to output 
sample relationship.


However, I am still open to hearing from anyone who has used the general 
block with the forecast method to solve this problem, so as to have the 
perspective on how to use the forecast method.


Thanks!

George

On Mon, Jul 5, 2021 at 2:44 PM George Edwards <mailto:gedwards@gmail.com>> wrote:


Good afternoon GNURadio community!

I am having a problem using the forecast method in my OOT model.

In my model, I have one input port and one output port with
streaming data. My signal processing algorithm converts every M
input samples into N output samples where the ratio of M to N is a
floating point number, soI cannot use the sync  block (if M=N) nor
the interpolator or decimator OOT blocks.

I am forced to use the general or basic block which has theforecast
method where one has to inform the Scheduler of the relationship
between the input and output samples.

In the forecast method, I set up the relationship as:
ninput_items_required[i] = noutput_items*M/N
which is the precise relationship. However, on running the QA test I
cannot get the OOT module to work properly.

Will appreciate any suggestions!

Regards,
George

Re: Virtual GNU Radio Hackfest

[Martin Braun]

On 29/03/2021 21:38, Martin Braun wrote:
It's been about a year since the pandemic started, making this a pretty 
late thing. Better late than never though: We would like to organize 
another hackfest, but this time, we want to do it online.

> [...]


Personally, I would like to stretch the HF to accommodate multiple

time zones comfortably. Not sure if Ozzies/Asians/Russians (<- in their
native countries, of course) would like to join, but they could start
off the hackfest, handing it over to Europeans and Africans, who then
pass the baton to the Americans. We've usually had most contributors
from EU and Americas join, so it seems likely that such an event would
start early afternoon EU time. Again, your feedback is appreciated.


Any dates that are preferred? Please let us know!



I accidentally hit Ctrl-Enter as I was finishing that last sentence, but 
that was most of what I wanted to write. You can use this thread to 
respond, or start a discussion in our Matrix.


My preference would be to get this going within a few weeks.

Cheers all,

M

Virtual GNU Radio Hackfest

[Martin Braun]

It's been about a year since the pandemic started, making this a pretty 
late thing. Better late than never though: We would like to organize 
another hackfest, but this time, we want to do it online.


We have a main theme for the HF, which is to reduce the number of open 
issues on the issue tracker: https://github.com/gnuradio/gnuradio/issues


As I write this, we have 387 open issues. Which is almost a 100 issues 
better than a few weeks ago, but still. After we attacked the pull 
request queue a few months ago (down to 17 open pull requests, only one 
of which is older than 3 weeks!), we want to try and achieve the same 
with the issue tracker.


We also have a vague idea how we want to do this. A main Jitsi call 
shall be one of the places the hackfest will happen, paired with a 
Twitch stream. That means that part of the hackfest will happen in 
public. Of course, we want to leverage our Matrix chat to coordinate 
groups. Other than that, we are not sure ourselves how we want to run 
the hackfest, and this email is for you to provide some feedback.



** How do we want to do the hackfest exactly? **

We have some vague notions:

- As mentioned before, we'll have a main stream (on Twitch) and a Jitsi 
call associated with that, which shall be public (we might have to add a 
lobby and an admin just to avoid malicious stream snipers, but it shall 
be otherwise easy to join). A small group of people can be active in 
this call, and their activities will be public. I'm hoping there'll be a 
coming-and-going of people who want to showcase something.


- Others can freely organize via chat and their own video/screensharing 
calls. NO ONE is forced to be on camera on Twitch.


- Content of the hackfest can be people actually fixing the bugs on the 
tracker (they can livecode this), or newbies being taught things by more 
experienced GNU Radio hackers, or people from the project (plus whoever 
cares) going through the issue tracker and adding tags, or [insert your 
idea here].


- If you don't care about the issue tracker, but still want to join, 
that's of course fine too! We know from the past that having a theme 
helps such hackfests though, and makes it easier for people with less 
experience to join.


We'll be honest: None of this takes much organizing, but maybe it'll be 
effective. We honestly have no idea how this could turn out.


** When are doing this? **

Again, this is open and we await some feedback. We don't think a 
multi-day online hackfest will attract a lot of people who might 
otherwise travel to such an event. Or maybe it might-- please let us know!


If it's a single-day, the day of the week is also up for debate. 
"Saturday" has been thrown around a lot, although that might be tough 
for people with kids who are looking forward to a computer-free weekend.


Personally, I would like to stretch the HF to accommodate multiple time 
zones comfortably. Not sure if Ozzies/Asians/Russians (<- in their 
native countries, of course) would like to join, but they could start 
off the hackfest, handing it over to Europeans and Africans, who then 
pass the baton to the Americans. We've usually had most contributors 
from EU and Americas join, so it seems likely that such an event would 
start early afternoon EU time. Again, your feedback is appreciated.


Any dates that are preferred? Please let us know!

Re: USRP N210 Synchronization

[Martin Braun]

USRPs typically operate with a 25% duty cycle PPS (i.e., 250 ms on, 750 ms
off). But they will work with pretty much any duty cycle.

Check the levels are within limits (I don't have them off the top of my
head). I would suggest you connect your PPS/10 MHz generator directly to
the USRP, and see if that works. Then, the splitter to see if that's
ruining your levels.

Note that we sell such a splitter:
https://www.ettus.com/all-products/octoclock/
I might be more than your budget, which I understand, but it's what we
usually use for these types of applications.

--M

On Wed, Mar 10, 2021 at 8:35 AM Vadym Sushko  wrote:

> Hello. I am using USRP N210 devices in my work. I have the necessity to
> synchronize three USRP N 210 devices in order to implement coherent
> receiving for these devices. I would like to know if it is possible to
> synchronize the USRPs by using the splitted into three 10MHz and splitted
> into three PPS signals from one generator and connected correspondingly to
> each of the USRPs. Currently I have an error that my board "may not be
> getting a PPS signal, no PPS detected with the time interval".  What pulse
> duration should I use for PPS signal and how setup time interval for PPS
> detection? Maybe the problem is something else.
>
> Thank you in advance.
>

[Announcement] Even More Shift in Maintainership

[Martin Braun]

Hi all,

and also thanks to Marcus from our side for taking over this huge role 
the last few years. Many of us have been giving Marcus our best wishes 
over in chat (in case you were wondering why this thread was quiet), and 
you can join in there as well if you like.


But that's not why I'm writing this email! In fact, my tenure as interim 
maintainer has already ended.

We have not one, but two people stepping up into these big shoes:

Josh Morman will become the new master branch maintainer. That means the 
buck stops with him on all decisions regarding the future development of 
GNU Radio. This is particularly fortunate, since Josh is also the lead 
developer on the future GNU Radio runtime (see his talk with Basti B. at 
FOSDEM, or our newsched repository).


Jeff Long (you might know him as willcode4) will become the maintainer 
for our stable branches (maint-3.8 and maint-3.9). This is another 
evolution for us, since we've never had a dedicated stable branch 
maintainer. The role of stable branch maintainer is different from the 
master branch maintainer, since on those branches, we need to make sure 
we don't break anyone's software, rather than incorporating all the new 
features.


I am very happy about to welcome Josh and Jeff in these roles, and I 
hope everyone else here will join me in doing so. Please give them all 
ther respect and help they need to keep pushing our great project forward!


Cheers,
Martin

On 2/18/21 7:13 PM, Marcus Müller wrote:

Dear GNU Radio community,

at FOSDEM 2018, I was asked whether I'd be happy to take over maintainership of 
the GNU
Radio project, something I've been very eager to do; by then, I had known the 
community
for a little more than 8 years, and the project had grown to be an important 
factor in
what I did on a day-to-day scale. It's been basically become family, anyways, 
and I was
asked to play a decisive role in that.

That maintainership came with a role as an software, and what's more important, 
ecosystem
architect. That's something I quite enjoyed, as it means that as long as 
there's direction
and progress towards that, I got to shape what my favourite software project 
looks like.
Pair that with the incredible amount of talent and resources that go into the 
most
prolific SDR framework in the solar system, and you've got really quite a grand 
thing
going on there! It's really been more akin to asking giants to move hills in a 
way that
suits the scenery than wielding a hoe to shape one's own garden. And it's 
really been a
fun, rewarding, and hopefully productive time:

In these three years, we've managed to finally move from the 3.7 era to a 
modern 3.8 era,
by which we succeeded to get the GNU Radio cart out stasis, and we've even went 
another
step and started the 3.9 era, where I hope modern tools and perspectives on 
software
development allow GNU Radio to move at a high speed.

This might be a good time to give the authority to be the one to make calls 
back to the
project. This means the General Assembly and the GNU Radio board will figure 
out how to
find a successor for my former position. For the meantime, Derek Kozel and 
Martin Braun
will take that power and use it for the best of the project for the near future.

I'll of course still be involved with GNU Radio (wouldn't know which other 
project could
stand me...), but will be able to focus on concrete aspects, which might both 
be on the
community side, as well as on technical projects. It's just that we're shifting 
away from
me being a bottleneck to development!

I'm very grateful that Martin and Derek found the time to take over this 
responsibility,
especially since I know they share my enthusiasm for the project, SDR and its 
users.

Best regards,
Marcus

Re: Issue reporting and Pull Request rules?

[Martin Braun]

I think it might help if we rename those labels. Maybe something like
"PleasePortThisTo3.9". A less verbose label would also work as long as it
conveys the intent.

On Sun, Feb 21, 2021 at 2:33 PM Jeff Long  wrote:

> The backport-3.8 label would mean "this PR is against a non-3.8 branch and
> needs to be ported to 3.8", though it hasn't been used that way
> consistently. A PR for 3.8 would already be targeted at that branch, so
> there's no need to also tag it that way. There will also be forward ports.
> It's likely that, since 3.8 is going to be usable for a while, people will
> submit bug fixes for it. A PR could be tagged (3.10,3.9,port-3.8)
> potentially.
>
> Here are some ideas about the process, to get a discussion started:
>
>- TBD: clearly define the meaning of version numbers, with respect to
>API, ABI and even GRC changes/compatibility.
>- Decide whether the PR is eligible for backporting, and to what
>branch. This is kind of rough due to the number of different ways changes
>can affect compilation/linking/runtime.
>   - Simple fixes with no API or runtime behavior change can go in the
>   next a.b.c.d version. These version can be tagged often. An example is 
> an
>   internal fix to a calculation.
>   - Changes that do not affect the API (except addition of blocks),
>   but that change runtime behavior for the better would go in the next 
> a.b.c
>   version. Block yml may change, causing the need to regenerate a 
> flowgraph,
>   though this would be avoided if possible. Autogenerated code messes up 
> nice
>   versioning rules, so this may continue to be a grey area.
>   - API changes (except maybe serious bug fixes?) go in the next
>   minor (a.b) version.
>   - Things that cause OOTs a lot of work go in next major version.
>- For smaller, easily understandable changes, a PR could be marked
>"Backport-a.b", implying that it would be easier for a maintainer to figure
>out the correct backport. Maintainers can then say "sorry, need more help
>from the author" if it's a bigger deal than the PR author though it was, it
>requires testing, etc.
>- For larger changes, the PR author would make separate PRs and work
>with maintainers to get everything settled. This implies that the PR author
>builds/tests against each each targeted branch.
>- Issues can be tagged with version numbers. The issue should contain
>the version (and other info) in text, explaining the environment where the
>issue was found. The minor versions (a.b) known to be affected would appear
>as tags.
>
> Any ideas from other projects that have complex dependencies and a small
> crew of maintainers?
>
> On Sat, Feb 20, 2021 at 6:01 PM Christophe Seguinot <
> christophe.segui...@orange.fr> wrote:
>
>> Hi
>>
>> As a regular user of GNURadio, I sometime trying to improve the code and
>> made some PR. I came to these questions and observations :
>>
>> I think It would be a good practice to encourage those reporting issues
>> (and also posting email on this list) to clearly indicates which GR
>> version(s) is (are) concerned. I don't remember having seen such
>> recommendations on GNURadio Github.
>>
>> And for those making PR, may be we need to propose or expose some rules.
>>
>> I made a PR for another issue this evening, and was not really aware of
>> what should be done since it concerned 3.8 3.9 and master. So I made 3 PR.
>>
>>- Is this the right method ?
>>- How to avoid fixing a bug on one branch while forgetting that other
>>branches could have the same bug not fixed (which seems to be the case in
>>#4251 )
>>- What is the best method to reduce maintainer work ?
>>
>> A related question: what is the real meaning of issue label
>> "backport-3.8" ? does it means we must check if this issue is present in GR
>> 3.8, or, something similar?
>>
>> In case code modifications are light and identical or similar for both
>> branches, is there a simpler methods than sending 3 PR ?
>>
>> Once again, many thanks to the maintainers and Marcus for his (passed)
>> Mainternership. Gnuradio is really becoming a great tool for SDR and
>> radiocommunications
>>
>> Regards, Christophe
>>
>

Re: Project Call January 2021

[Martin Braun]

Recording available here: https://youtu.be/U2nZDdOZVy0

On 18.02.21 18:08, Martin Braun wrote:
> Hi all,
> 
> our project call will be in less than one hour, at UTC 1800 (19:00 CET).
> Join us on twitch.tv/gnuradio, or join us on chat!
> 
> --M
> 

Re: shared_ptr does not name a template type in Cross-compile of GR 3.7 with UHD 3.15 SDK

[Martin Braun]

On 2/18/21 5:26 PM, dtra...@tampabay.rr.com wrote:
The build I am using is maint-3.7 from git. I would like to try 
maint-3.8, but I am told that UHD 3.15 does not work with maint-3.8.


UHD 3.15 works with all version of GNU Radio that I know of (say, from 
the last 3 years or so). It most definitely works with 3.8, 3.9, and 
master branch.


--M

Project Call January 2021

[Martin Braun]

Hi all,

our project call will be in less than one hour, at UTC 1800 (19:00 CET).
Join us on twitch.tv/gnuradio, or join us on chat!

--M

Re: GSoc-2021

[Martin Braun]

On 2/9/21 8:21 PM, Kabir Kedia wrote:

Respected Developers,
My name is Kabir Kedia. I'm currently studying at IIT Roorkee in India. 
I was going through GNU Radio and I found it quite interesting. I would 
like to start contributing to it. However, I don't know where to start.

It would be great if someone can help me how to start.


Check out our issue tracker: https://github.com/gnuradio/gnuradio/issues.

If you can help fixing some of those, that would be a fantastic start!

--M

Re: Performing a USRP Packet Loopback

[Martin Braun]

Jada,

I haven't read up on all the threads in which you've been asking stuff, so
this is lacking a bit of context. I still hope it's helpful:

   - I don't think you should downgrade UHD. There has been a lot of change
   in UHD, but not in the B210 driver.
   - UHD provides some tools, such an example called "benchmark_rate",
   which let you test the streaming rates. Those can be helpful to rule out
   issues. If you can exchange data in those tools fast enough between USRP
   and computer (in your case the RPi) then that's a good indicator of things
   working.
   - SMA cables are not strictly necessary, and I think in your particular
   case they might not provide any benefit. They are generally considered a
   very useful tool though:
  - You don't need to worry about receiving stray RF, or polluting the
  RF environment in your lab
  - They provide a good way of controlling the transmission of RF,
  meaning you have more influence over how the Rx spectrum will look like.
  Important: You need attenuators as well as cables, because USRPs are
  designed to receive tiny levels of RF power, and SMA cables will
basically
  carry the full Tx power.
   - This might be old news to new, but you should tune the gain settings
   of your Tx and Rx before attempting to transmit data. I recommend running
   an app like uhd_fft on your Rx and see if the spectrum looks "good". If
   you're clipping or distorting, you'll probably notice in the spectrum, and
   you'll have no chance of transmitting bits.


--M

On Thu, Jan 21, 2021 at 10:30 PM Jada Mariano Berenguer 
wrote:

> Hi, I think I also forgot to mention that I'm very new at working with
> GNURadio, the boards, and UHD, so I have some follow up questions.
>
> Regarding Aditya's reply, why would I need to downgrade the version of
> UHD? And by 'check it', do you mean run the benchmark, transmitting, and
> receiving examples to see if there's overruns or underruns? Also, what
> benefit does attaching SMA cables before attaching antennas have? Because I
> don't have any SMA cables, but if there's some significant benefit I'll
> look into getting some.
>
> Regarding Marcus's reply, I've attached a picture of the flowgraph for the
> packet-tx block so we can determine if it uses start-of-burst/end-of-burst
> tagging, because I'm not sure how to tell. I think it uses start-of-burst
> tagging because of the PDU to Tagged Stream blocks at the beginning of the
> flowgraph but am unsure. Also, if it is the case that it doesn't use
> start-of-burst/end-of-burst tagging, I found a property of the packet_tx
> and packet_rx blocks called 'Maxoutbuf'. Could I use these properties to
> set a buffering policy? And what size buffer would I need?
>
> Again, what I'm trying to do is follow what was said in this message
> thread
> .
> It says that the packet_loopback example is a transceiver, and I can
> replace the Channel Model blocks with USRP source and USRP sink blocks to
> try to send a message over the air. I did that, but I'm running into
> overruns and underrruns and want to know how to fix that.
>
> Thanks everybody for speedy replies and the help so far! It's much
> appreciated!!
>
> On Wed, Jan 20, 2021 at 9:11 AM Marcus D. Leech 
> wrote:
>
>> On 01/20/2021 12:12 AM, Jada Mariano Berenguer wrote:
>> > Hi, I realized that in my packet loopback example, I didn't connect
>> > any of the QT GUI sinks after the USRP source. The updated flow graph
>> > is attached in screenshot0. After I connected them, I ran the packet
>> > loopback example on my MacBook Air using one B210 board with TX/RX and
>> > RX2 antennas attached and got the results attached in screenshot1, but
>> > still received underruns as printed out in the terminal in the bottom
>> > left corner. I also ran the example with two B210 boards with a TX/RX
>> > antenna on one and a RX2 antenna on the other and got slightly
>> > different results. Instead, the third graph was just a straight
>> > horizontal line and still ran into underruns. I also ran the same
>> > program with a Raspberry Pi 4 with one B210 board and got
>> > similar results. So I don't think it's an issue concerning computer
>> > power.
>> >
>> > Also, I was wondering what you meant by "for a loopback flow at low
>> > rates you may need to alter the internal buffer sizes in your
>> > flow-graph to prevent TX starving for samples because the RX buffers
>> > are still filling. But this is not a distinctly USRP problem and has
>> > more to do with GnuRadio". How would I alter the internal buffer sizes
>> > and what would I need to change it to?
>> >
>> > Are there any other suggestions you have for me to successfully get
>> > this loopback example running?
>> >
>> > Thanks!
>> >
>> My comments on buffer sizes were driven by an incomplete understanding
>> of what you were doing--however, having said that,
>>at low sample rates, the default bu

Re: Migration from 3.7 to 3.8 OOT - module 'howto' has no attribute 'square_ff'

[Martin Braun]

Criss,

a good debugging method is to go into the build dir, where you should find
a DLL called _howto_swig.so (or something like that). Try importing that:

>>> import _howto_swig

It will probably fail, and will likely give you a better clue of what's
going on.

--M

On Sat, Jan 23, 2021 at 12:51 AM Criss Swaim  wrote:

> I am upgrading from gnuradio 3.7.2 to 3.8.2 and have run into a couple
> of issues with my OOT modules not showing up in the python module.  So I
> went back and walked through the HowTo tutorial to see it the tutorial
> would work.  It fails also.
>
> OS: Fedora 33
>
>
> > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> > '/tmp/runtime-sensor'
> > Traceback (most recent call last):
> >   File "/home/sensor/gr-howto/HowTo.py", line 175, in 
> > main()
> >   File "/home/sensor/gr-howto/HowTo.py", line 151, in main
> > tb = top_block_cls()
> >   File "/home/sensor/gr-howto/HowTo.py", line 112, in __init__
> > self.howto_square_ff_0 = howto.square_ff()
> > AttributeError: module 'howto' has no attribute 'square_ff'
>
> The libgnuradio-howto.so lib is in /usr/local/lib64
>
> I have added the /usr/local/lib64 directory to ld.so.conf and ran the
> sudo ldconfig to reload the lib paths, followed by make/make install.
>
> When the python howto module is created it does not have the square_ff
> entry point:
>
> > dir(howto)
> > ['__builtins__', '__cached__', '__doc__', '__file__', '__loader__',
> > '__name__', '__package__', '__path__', '__spec__', 'unicode_literals']
> Any ideas on where to look next?  I am not sure if this is a path-ing
> issue or is something wrong in the building of the python module.
>
> --
> Criss Swaim
> csw...@tpginc.net
> cell: 505.301.5701
>
>
>

Re: Cross compile gnuradio in E312 error

[Martin Braun]

Hi,

you didn't paste an error message.

--M

On Mon, Jan 25, 2021 at 7:02 AM --- via GNU Radio, the Free & Open-Source
Toolkit for Software Radio  wrote:

> Dear friends:
>  I'm installing rfnoc on E312, when I cross compile gnu radio, I
> execute this command：cmake -Wno-dev
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
>
>  It prompts the following error：
> zcm@zcm-XPS-8500:~/rfnoc/src/gnuradio/build-arm$ cmake -Wno-dev
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Extracting version information from git describe...
> -- Compiler Version: arm-oe-linux-gnueabi-gcc (GCC) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for
>

Re: Jamming the WiFi channel

[Martin Spears]

Building a jammer is one thing. For the sake of just academics building a 
jammer against a specific mac address on a specific channel.

This would help in demodulation techniques, device identification, and tx out 
controls.

I am not saying this is even ethical, but in the case of purely academics. This 
could be an educational exercise.





Martin Spears

From: Discuss-gnuradio  on 
behalf of Aditya Arun Kumar 
Sent: Sunday, January 17, 2021 10:27:11 AM
To: Doug McGarrett 
Cc: GNURadio Discussion List 
Subject: Re: Jamming the WiFi channel

On a serious note, I know that all of us know how to build a jammer, in case of 
questions like this how do we deal with it?
I mean I can do both sides, in the spirit of sharing the knowledge I think that 
someone should tell the person who is doing it on how to build a jammer (in 
this case) or should we not help the person?
Or should we condemn these acts?

On Sun, Jan 17, 2021 at 10:15 AM Doug McGarrett 
mailto:dmcgarr...@optonline.net>> wrote:


On 1/16/21 10:58 PM, paulles...@mailo.com<mailto:paulles...@mailo.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   Mailo   *1 fichier disponible au téléchargement*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   * hackrf2.png (35 Ko)
>
> Vous pouvez télécharger ce fichier en cliquant sur ce lien ou en le
> copiant dans la barre d'adresse de votre navigateur
> <https://www.mailo.com/attachlinks.php?id=MTg2NDQuPGVhLW1pbWUtNjAwM2I1Y2ItMTRjNS0yN2Q0OGNlZUB3d3ctMS5tYWlsby5jb20%2b>
>
> https://www.mailo.com/attachlinks.php?id=MTg2NDQuPGVhLW1pbWUtNjAwM2I1Y2ItMTRjNS0yN2Q0OGNlZUB3d3ctMS5tYWlsby5jb20%2b
>
> Ce lien restera valable pendant 30 jours.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello, I have build a VCO jammer using gnuradio and I would like to
> emit the jamming signal on a Wi-Fi channel but nothing is being emitted.
>
> Can anyone please help me ?
>
> I am newbie to signal processing.
>
> PL
>
>
Probably even in France it is illegal to jam radio signals. I sure hope
that NOBODY helps you!
--doug



--
S. Aditya Arun Kumar
Security Researcher, Comms
+919123517465

Re: Block with overlapping window - consume_each() in regard to set_history()

[Martin Braun]

This might be helpful:
https://github.com/kit-cel/gr-specest/blob/master/lib/stream_to_vector_overlap_impl.cc

Might answer your question on history with a very simple block.

--M

On Sat, Dec 19, 2020 at 7:18 PM Marcus Müller  wrote:

> Either that source of yours is incorrect, or you have a buggy block in
> there somewhere.
>
> Throttle really should *never* do anything to the result of your signal
> processing. All it does is copy its exact input to its output, and in
> between doing so, going to sleep to literally just throttle its throughput.
>
> On 19.12.20 14:14, Marcin Wachowiak wrote:
> > This can be fixed by placing throttle blocks before autocorrelate with
> > arbitrary set sample rate - according to source.
>
>

Project Call December 2020

[Martin Braun]

Hi all,

as usual, we will do our project call on this third Thursday of the
month. You can join us on twitch.tv/gnuradio, via Matrix
(https://chat.gnuradio.org), or IRC.

The call starts in 4 minutes.

Cheers,
Martin

Changes to contribution guidelines

[Martin Braun]

Hi all,

before we finish this year, we do want to announce one more change in
how we accept contributions into the GNU Radio code base.

One thing that we take very seriously is the whole business of license
compliance. GNU Radio is GPLv3-licensed, and that's not going to change.
But also, we have to make sure that code upstreamed is legally OK to go
into our branches (that usually means it's not copyrighted elsewhere,
etc.). Since we can't do a thorough check for every submission (even if
we wanted to, we don't know and can't know the origin of all the code),
we put the burden onto the developer. So far, they agree to this by
signing the CLA that so many of you have signed.

The CLA signing process has been criticized as being overly complex and
a barrier for entry to contributing to GNU Radio. We agree with this
statement.

Moving forward, we will no longer require users to have a CLA filed.
Instead, we will require signing a DCO (Developer's Certificate of
Origin). You can do that by using the `git commit -s` command line
argument. Our updated contributing guide has more details
(https://github.com/gnuradio/gnuradio/blob/master/CONTRIBUTING.md#dco-signed).

Since there is no copyright assignment in the DCO, this means that new
components of GNU Radio can be upstreamed without copyright assignment.
The copyright remains with the author or their company.

We hope this means that new contributors are more likely to upstream
their code to GNU Radio, while existing contributors hopefully won't be
upset by amending '-s' to their git commits.

We're happy to discuss this change, but I suggest reading a blog article
by Bradley Kuhn on the subject (Bradley is unrelated to GNU Radio, but
this particular article happens to also express the opinions of the GNU
Radio leadership):
https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

Maybe this will motivate folks to do some Christmas hacking!

Cheers,
Martin

Re: RPC Timeout with USRP N321

[Martin Braun]

It looks like the device is not properly initialized. Things to make sure:
- You're running UHD 3 on your host. Are you running UHD 3 on your device?
- It's not clear if there is a specific issue with get_num_xbars(), or if
there's a general RPC problem. Does uhd_usrp_probe work?

--M

On Fri, Dec 11, 2020 at 11:06 PM Dylan Baros  wrote:

> Good afternoon,
>
> Sent a message yesterday but I realize that it was not complete so I
> apologize. The issue is that I am getting the following error message when
> doing the spectrum analyzer tutorial on the gnuradio website.
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
> Guided Tutorial Hardware Considerations - GNU Radio
> 
> Introduction []. One of the more basic (and also incredibly useful) things
> you can do in GNU Radio with a receiver is to create a software radio
> spectrum analyzer.
> wiki.gnuradio.org
>
>
> Generating: '/home/dylan/Documents/sa1.py'
>
> Executing: /usr/bin/python3 -u /home/dylan/Documents/sa1.py
>
> [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100;
> UHD_3.15.0.0-2build5
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=n3xx,product=n320,serial=31EDB79,claimed=False,addr=192.168.10.2
> Traceback (most recent call last):
>   File "/home/dylan/Documents/sa1.py", line 199, in 
> main()
>   File "/home/dylan/Documents/sa1.py", line 175, in main
> tb = top_block_cls()
>   File "/home/dylan/Documents/sa1.py", line 92, in __init__
> self.uhd_usrp_source_0 = uhd.usrp_source(
>   File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line
> 125, in constructor_interceptor
> return old_constructor(*args)
>   File "/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 2787, in make
> return _uhd_swig.usrp_source_make(device_addr, stream_args,
> issue_stream_cmd_on_start)
> RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
> 'get_num_xbars'
>
> >>> Done (return code 1)
>
> I am using a USRP N321 and N320.
>
>
> Any ideas? Thanks.
>

Re: How to print Socket PDU messages on the terminal?

[Martin Luelf]

Hi Shumin,

netcat (nc) uses TCP by default, but your Socket PDU is set to UDP. So 
you are sending and listening to two different sockets.


There are two ways to fix that (but don't apply both at the same time or 
it won't work again):
1. Switch the PDU Socket type to TCP Server (like it is done it the 
reference you linked).
2. Use the command "nc -u 127.0.0.1 52001" where the -u option will make 
netcat use UDP instead.


Yours
Martin

On 09.12.20 09:47, Shumin Yao wrote:

Hi,

I am working on a straightforward project. In the project, there is a 
Vector Source transmits a vector to a Socket PDU module. I am trying to 
print the vector received by the Socket PDU module on the terminal but 
fail to do that.


My settings are as follows. The transmitted vector is full of "1"s. The 
host of the Socket PDU module is set to "127.0.0.1", and the port of the 
Socket PDU module is set to "52001".


On the terminal window, I type a command "nc 127.0.0.1 52001" (according 
to Section 3 in [1]) but obtain nothing.


Am I missing something?

Note: the screenshot of my flowgraph is attached.

[1] http://joshuaedgcombe.com/getting-started-with-gnu-radio/

Thank you for reading this mail,

Shumin Yao.

Re: Passing real data from a thread to the next block

[Martin Lülf]

Dear Isaac,

you can overwrite the start method of gr::block 
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f


This function will be called once the processing starts.

Yours
Martin


On 2020-11-18 02:35, isaac mario tupac davila wrote:

Hi Marcus

Thanks for your answer. I am restructuring the design of my OOT block.

I'd like to ask a last question about it...I am trying to send some 
commands (array of bytes) to an external hardware only ONCE before 
starting with my real time data acquisition . The problem is that if I 
implement the sending of the commands in the general work of my block, 
the commands will be sent each time the general work finishes and starts 
again. My solution proposed is to begin the execution of my flowgraph 
and send an external signal (specificallykill -SIGIO PID) from terminal 
to call the implemented method which sends the commands, so that my 
general work will only focus on the data acquisition and I will send the 
commands only once.


My question is: Is there a facility or tool that GNU Radio gives me to 
solve this situation? There should be a more suitable solution.


Any help or recommendation would be appreciated.
Thanks

Regards
Isaac.



El dom., 15 nov. 2020 a las 13:50, Marcus Müller (<mailto:mmuel...@gnuradio.org>>) escribió:


Hello,

On 15.11.20 06:26, isaac mario tupac davila wrote:
 > Hello
 >
 > I'm Isaac.

Hi Isaac, nice having you.

 > I have a question about threads. I've created three
 > threads and I want to pass real data from one thread to the next
block
 > directly without returning to the general work method.

That sounds like a misguided design approach. Please don't do that.

The work function is meant to be seen as atomically processing a bit of
data from its input to its output.

If you need asynchronous messaging, then use the msg_passing facilities.
These make sure you don't change the state of the block while its
general_work is executing.

 > I could give
 > value to the out array in the thread but for some reason the data
 > doesn't pass to the next block. I am not sure if it's because I
didn't
 > put: return noutput_items in the thread,

What you describe as thread makes no sense – the way GNU Radio is,
there's exactly one thread executing a block's general_work at a time,
and that's the thread of the block_executor. And `return` ends that
execution; that's how C++ works.

 > as normally this is in the
 > general work method... I also add that the function is defined in the
 > thread as void*function and I defined the out array as a
complex*.
 >
 > Any help would be appreciated.

I'm afraid there's something not GNU Radio-compatible in the way you've
architected your system, but we sadly don't know your system well enough
to comment on what to change.

Best regards,
Marcus

GNU Radio Organization Updates

[Martin Braun]

Hi all,

we're a bit behind in updating the mailing list on the latest
organizational update. At GRCon, we talked about the changes we were
planning to do within the GNU Radio organization
(https://www.youtube.com/watch?v=FRGwxPBG1wM).

In the meantime, we have implemented most of these changes.
The people who were previously officers of the project congregated on
8-Oct-2020 to have our first General Assembly. Here, we decided to
reorganize the GNU Radio Project under new articles of association.

The new articles, and the minutes of the General Assembly can be found
on a new repository we've been using to capture all important
organizational documents: https://github.com/gnuradio/gr-governance

We'll also document assembly meeting minutes and other decisions here,
so if you care about the organization, you can monitor that repository
for updates.

Other than agreeing on the new organization format, the assembly also
elected a new board. The board now consists of Derek Kozel, Marc
Lichtman, and myself. After the assembly, the board met internally to
decide on who would be the new president of the project, and we are very
happy to have Derek Kozel fill that role.

Ben Hilburn, our previous president, did not run for the office of the
board, but remains part of the General Assembly. We are very grateful
for all his work during the years of his presidency, in particular, the
work he did to set up the GNU Radio organization in a more sustainable
way, ultimately leading to the organization we have now.

Finally, we elected two more members into the General Assembly: Barry
Duggan (our documentation lead) and Sam Palazzolo (who was a key member
of the GRCon committee). We will be adding more members to the GA in the
coming months.

We had a bit of an audio snafu during the last project call, but we did
also talk about the new org structure in the October call:
https://youtu.be/HS4F2Z60NUU

I want to thank all volunteers in the project, on the assembly or
otherwise, for their contributions to the project, and hope that the new
org structure will continue to bring success to the project.

Cheers,
Martin

Re: clang formating

[Martin Braun]

Most IDEs have clang-format support built in and can tell you what's wrong
(like a word processor spellchecker). I use vim + ALE, for example. VS Code
also has plugins.

--M

On Wed, Nov 11, 2020 at 11:25 AM Volker Schroer  wrote:

> Hi,
>
> I just made a pr and got the message that the pr formatting check
> failed. But looking at the output I don't understand, what's wrong.
>
> Even more I'd like to know how I can do the formatting check locally.
> The coding guide in the wiki is empty.
>
> Thanks in advance
>
> -- Volker
>
>
>
>
>
>

Re: Regarding ofdm mod in gnu radio

[Martin Braun]

Check the tx_ofdm.grc and rx_ofdm.grc examples in the gr-digital module.

This page will help if you want to access the C++ API:
https://www.gnuradio.org/doc/doxygen/group__ofdm__blk.html

Also, this: https://wiki.gnuradio.org/index.php/Basic_OFDM_Tutorial

--M

On Tue, Nov 10, 2020 at 2:53 PM Rozana Alam  wrote:

> Hello community,
> I have currently started using gnu radio for some signal measurement
> purpose. I want to transmit ofdm signal with the help of gnu through
> SDR(bladeRF). I got an idea from some tutorials that ofdm mod is needed for
> transmitting ofdm signal.but I don't have any ofdm mod block on my gnu
> platform but I have all the other ofdm components like ofdm tx,Rx, channel
> allocator etc.i am using gnu radio 3.8 version in Ubuntu 18.04 and it's
> compiled from source. Can anyone please assist me how to download ofdm mod
> in my current platform.or is there any supplement that I can simply use
> ofdm transmitter and receiver to transmit and receive ofdm signal through
> the SDR. I would highly appreciate your help.
> Sincerely,
> Rozana
>

Re: gr 3.8, uhd4.0 and rfnoc

[Martin Braun]

The Block#0 issue is a known one, the problem is that it doesn't pick up
the name until it invokes the DLL/.so from your custom code. It's being
worked on. They should work, however, in GNU Radio where the DLL/.so *is*
linked in.

You do, however, need to create block.yaml files to describe your blocks to
UHD.

--M

On Sun, Nov 8, 2020 at 8:04 AM Dario Pennisi  wrote:

> Hi,
> I've been trying to create and use a rfnoc block for n310 within gnuradio
> 3.8 and uhd4.0. I first tried with pybombs but this doesn't not seem to
> work very well and there is no default recipe that works. I then moved to
> manual install from source and got something up using the maint-3.8 and
> uhd-4.0 branches however none of the rfnoc blocks in uhd 4.0 seem to be
> usable directly in gnuradio companion as the yaml files in uhd are not
> compatible with the yaml block files required by grc.
>
> I then moved to master branch of both repositories and this installs with
> gnuradio, some yaml files for some of the blocks in uhd, so I tired
> compiling a fpga with fft block as instructed in the tutorial but the fft
> would not produce output data.
>
> Finally I tried compiling the gain example block out of tree and installed
> its control block both with maint 3.8 branch (that uses swig) and master
> branches (that uses pybind11) but in both cases the block doesn't get
> recognized when i issue uhd_usrp_probe and it gets listed as block#0
> regardless of Ldconfig.
> I get it listed in grc after I created a second yaml file compatible with
> grc but of course running a graph will fail as it doesn't find the block
> control class, likely because in the installation process I don't see
> python bindings being generated for it, regardless of the binding creation
> mechanism.
>
> So my questions are:
> 1) is there any way to use rfnoc in grc as of today that doesn't need
> manual creation of the block.yaml files?
> 2) why the fft block using the block.yaml definition from gr-uhd doesn't
> seem to work?
> 3) how do I make oot blocks recognized by probe and grc?
>
> Thanks,
>
>
> Dario Pennisi
>

Re:

[Martin Braun]

What's wrong with the layout?

You can probably ignore the GTK warnings. The flowgraph itself is run in QT.

--M

On Fri, Nov 6, 2020 at 8:07 PM  wrote:

> Hello,
>
> I am new to gnu radio. I installed it in Ubuntu 20.04 through PPA (
> http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu). The version
> installed is 3.8.2.0 (Python 3.8.5).
>
> Every time I execute a flow graph I receive the following warnings in the
> grc terminal.
>
> # Start of the grc log #
>
> <<< Welcome to GNU Radio Companion 3.8.2.0 >>>
>
> Block paths:
> /usr/share/gnuradio/grc/blocks
>
> Loading: "/home/joao/Downloads/gnuradio/tutorial_two_3.grc"
> >>> Done
>
> Generating: '/home/joao/Downloads/gnuradio/tutorial_two_3.py'
>
> Executing: /usr/bin/python3 -u
> /home/joao/Downloads/gnuradio/tutorial_two_3.py
>
>
> (python3:22390): Gtk-WARNING **: 11:09:32.062: GTK+ module
> /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libgail.so cannot be loaded.
> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process
> is not supported.
> Gtk-Message: 11:09:32.062: Not loading module "atk-bridge": The
> functionality is provided by GTK natively. Please try to not load it.
>
> (python3:22390): Gtk-WARNING **: 11:09:32.174: GTK+ module
> /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libcanberra-gtk-module.so cannot
> be loaded.
> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process
> is not supported.
> Gtk-Message: 11:09:32.174: Failed to load module "canberra-gtk-module"
>
> (python3:22390): Gtk-WARNING **: 11:09:32.174: GTK+ module
> /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libgail.so cannot be loaded.
> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process
> is not supported.
> Gtk-Message: 11:09:32.174: Not loading module "atk-bridge": The
> functionality is provided by GTK natively. Please try to not load it.
>
> (python3:22390): Gtk-WARNING **: 11:09:32.175: GTK+ module
> /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libcanberra-gtk-module.so cannot
> be loaded.
> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process
> is not supported.
> Gtk-Message: 11:09:32.175: Failed to load module "canberra-gtk-module"
>
> (python3:22390): Gtk-WARNING **: 11:09:32.175: GTK+ module
> /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libgail.so cannot be loaded.
> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process
> is not supported.
> Gtk-Message: 11:09:32.175: Not loading module "atk-bridge": The
> functionality is provided by GTK natively. Please try to not load it.
>
> # End of the grc log #
>
> The print screen of the flow graph is in the tutorial_two_3.png file. It
> is the example that exists in the "A More Complex Flowgraph" section in
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GRC.
>
> The tutorial_two.png file shows the gui obtained when the flow graph is
> run. The GUI layout is not correct and I think it could be related to the
> above warnings.
>
> Is there something I can do to solve this issue? or is this a bug?
>
> Thanks a lot!
>
> João
>

Re: Project Call: Live Next Thursday!

[Martin Braun]

Trust me to do timezones? No? Good!

Because of course I messed this up, as people have pointed out. As Marcus
wrote earlier, the call is 1700 UTC, which means 19:00 CET  / 1 PM Eastern
/ 10 AM Pacific, not what I wrote.

--M

On Tue, Oct 20, 2020 at 5:38 PM Martin Braun  wrote:

> Two days from now, our next Project call will be live on
> twitch.tv/gnuradio. The call will be 19:00 CET, but keep in mind, right
> now, that means 2 PM Eastern / 1 PM Central / 11 AM Pacific!
>
> Cheers,
> Martin
>

Project Call: Live Next Thursday!

[Martin Braun]

Two days from now, our next Project call will be live on twitch.tv/gnuradio.
The call will be 19:00 CET, but keep in mind, right now, that means 2 PM
Eastern / 1 PM Central / 11 AM Pacific!

Cheers,
Martin

RE: GR-inspector

[Martin Spears]

Sudo apt-get install libqwtplot3d-qt5-dev python3-qwt3d-qt5

Martin Spears
Chief Technical Officer
Ingenious Countermeasures Technologies Inc.
705-885-1990
mspe...@icmt.ca

From: ahmad ALmousa<mailto:ahmadakram1...@hotmail.com>
Sent: Monday, October 19, 2020 11:12 AM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: GR-inspector


Dear Sir,

I'm ahmad almousa from jordan.

I need a help in installing GR-inspector for GNURADIO 3.8 on ubuntu 20.04 , I'm 
trying all suggested solution on google but still give me Package has no 
install method: qwtplot3d
please how I can solve this error.

Thank you

Re: oscilloscope suggestions

[Martin Striegel]

Hi Daniel,
Jean-Michel Friedt has worked on this:
* https://github.com/jmfriedt/gr-oscilloscope38
* 
https://archive.fosdem.org/2020/schedule/event/fsr_software_defined_radio_based_scientific_instrumentation/attachments/slides/3895/export/events/attachments/fsr_software_defined_radio_based_scientific_instrumentation/slides/3895/fosdem2020_instrumentation.pdf.


Regards,
Martin




On 12.10.20 13:33, Fabian Schwartau wrote:

Hi Daniel,

You can probably do that with GNURadio, I mean you can use the basic
processing and display blocks in any Python/C++ (and probably others)
program. But as far as I know there is not much software in GNURadio to
interface the multitude of devices out there.
You should check out (lib)sigrok and Pulseview. This is a library and a
GUI exactly for this purpose (and others) and they support a ton of
devices. Interestingly there seems to be (20 second google search) no
direct interface between sigrok and GNURadio (except for pipes/files I
guess) - this could make a nice project which would add a lot of value
to GNURadio (I imagine a sigrok block in GNURadio, which can be
configured to capture stuff from all the supported devices or send a
data stream to them - sigrok can also control instruments like frequency
generators, ...).
However, I think you can do it, but GNURadio is not the right tool for that.

Regards,
Fabian

Am 12.10.20 um 13:20 schrieb Daniel Pocock:


Oscilloscopes have changed a lot in recent years

Has anybody used GNU Radio to make a basic oscilloscope?

There are many generic ADC to USB devices now, some are purpose-built
for use as an oscilloscope.  Has anybody tried any of them in a pure
free software environment, either with GNU Radio or other software?
Examples[1] on eBay.

There have also been some open hardware projects like ScopeFun[2], has
anybody tried it?  They sell[3] it for $750 and the software is all
free, open source.

This area is probably quite interesting for hams, hobbyists and students
who don't have money or space for full size lab equipment.

Please note I'm not only interested in RF-oriented analysis here, some
people may simply want to analyze their audio signals, Arduino PWM
outputs or some other things below RF.

This could also be a useful topic for one of the proposed GNU Radio
amateur radio workshops.

Regards,

Daniel


1. https://www.ebay.co.uk/sch/i.html?_nkw=usb+oscilloscope
2. https://www.scopefun.com/
3. https://www.crowdsupply.com/scopefun/open-source-instrumentation






--
Martin Striegel, M.Sc.
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC

Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 121
Fax +49 89 32299 86 299

martin.strie...@aisec.fraunhofer.de

http://www.aisec.fraunhofer.de

Hacktoberfest 2020

[Martin Braun]

Hi all,

like the last years, GitHub and Digital Ocean are doing Hacktoberfest.
To participate, you sign up with your GitHub account, and submit four or
more pull requests against public repositories. Of course, we'd be very
happy if you submit some of them against the GNU Radio repositories!

Please don't think there's a high bar for submitting pull requests. If
you find a typo in the documentation (not the wiki docs, but stuff
that's in the tree), submit a typo-fix as a PR, and boom, that's your
first PR. If there's a compiler warning that annoys you, that might be a
quick second PR.

Of course, if you have bigger changes, we're also happy about those. If
you have *really big* changes, please submit a GREP first -- PRs against
the greps repository also count! Or any other repo. So, you can also fix
typos on our website, for example.

I do have one request though. We have a lot of PRs open already on the
GNU Radio repo, and we're having trouble keeping up with code reviews.
You can help us with code reviews to get PRs merged faster. That said,
merging is not a requirement for PRs to count for Hacktoberfest, and we
appreciate all PRs, even if you don't help with code reviews. It would
just be even more helpful.

Some links:
- Hacktoberfest: https://hacktoberfest.digitalocean.com/
- GNU Radio PR queue: https://github.com/gnuradio/gnuradio/pulls
- Need ideas to fix something? Look here:
https://github.com/gnuradio/gnuradio/issues

Cheers,
Martin

Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[Martin Spears]

I would love to join this

Martin Spears
VE3AGS

Sent from my BlackBerry — the most secure mobile device — via the Bell Network
From: krist...@skypro.be
Sent: September 22, 2020 4:26 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

Hi Barry,



Concerning the separate GR-ham mailing-list, I don't know if it really
needs to be a "GR ham-radio" list,  but what I think would be useful is
a separate mailing-list to discuss signal-processing (that happen to use
GNU Radio), separate of the 'discuss-gnuradio' list that is more related
to questions on GNU Radio itself.

I am also still learning SDR, and I have a number of question on how to
decode signals (e.g. "I want to decode RTTY with 1.5 stop-bits, what's
the best way to handle that half a bit at the end without impacting the
clock-recovery block?") here I have been hesitant to post here in the GR
list as it's more about signal-process then about GNU Radio.
When talking to fellow hams who tried GNU Radio, a lot of them have the
same problem: how to create a working flowgraph? What blocks to use?
What do all the parameters of that block really do and what do I value
should I put in there?

So, yes, a separate list would be nice. .. but I don't know if a "GR Ham
Radio"  is  the best combination.

- Why only Ham radio?
SDR and GNU Radio seams to me one of the best tools to promotion
amateur-radio, especially if you target people from the open-source /
hackerspace / maker scene. Focussing to much on amateur-radio will -I
think- might mean you lose this opportunity.


- For the amateur-radio community, focussing to much on GNU Radio might
not be ideal neither. For me, the main topic here is SDR,
signal-processing, DSP and data-communication, ... GNU Radio is only
part (be it, a very big and important part) of that.
Most hams start out with a simple RTL-SDR dongle and just *use* it for
some project: APRS receiver, beacon receiver, to track HABs to listen to
weather-satellites, listen to QO100, ...
It's usually only in a later stage that they move to GNU Radio, when
they are comfortable with using SDR and are interesting going the next
step: learn how SDR works internally and develop SDR applications
themselves.




73
kristoff - ON1ARF



On 22/09/2020 14:30, Barry Duggan wrote:
> Thank you for your feedback! It looks like we have a viable idea.
>
> Here are some additional items to consider:
>
> ** use BigBlueButton or Zoom
>
> ** have a host / moderator present a topic with a demonstration
>
> ** limit to one hour (especially if using BigBlueButton)
>
> ** a time on the weekend might be better - something like 20:00 UTC?
>
> ** I will put out a news entry on the gnuradio.org homepage as soon as
> a kickoff seems feasible. Marcus will help "as much as he can"
>
> ** possibly start a GR Ham Radio mailing list like discuss-gnuradio
>
> Thank you for your continued interest and ideas.
>
> 73 and stay safe,
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
>
> On Mon, 21 Sep 2020 11:13:29 +0200, Marcus Müller wrote:
>
> Hello Barry, hi everyone,
>
> I just wanted to say I was very impressed with all the activity in the
> breakout session, and how productive everything was.
>
> I'd find it super interesting if aside from the social benefit of
> ragchewing (no matter whether that happens on a video conference, via
> pure voice comms, or in a text chat), people had would also take the
> chance to give a short "impulse" presentation on what they think would
> be interesting for the rest; for example, I think Barry's digital
> modulations tutorials would be extremely interesting for a lot of people.
>
> But also, a bit on stuff like (brainstorming here) "how to make use of
> the new digital predistortion module to get the most out of my system",
> "I've invented a digital mode, and you'll never guess what happened
> next", "how it took me a month to figure out why I wasn't seeing any
> satellites and why I hate storks", "SDR in club education settings", ….
>
> Nothing that takes 2 hours, but something to get discussion off the
> ground, and then if discussion shows people like where things are going,
> go deeper into it.
>
> Cheers,
> Marcus
>

Re: gr-dsd help needed

[Martin Spears]

I have tested this again and again. I cannot get audio out of the did block. I 
will post the .py in the morning. I just need a direction

Sent from my BlackBerry — the most secure mobile device — via the Bell Network
From: mspe...@icmt.ca
Sent: September 22, 2020 7:21 AM
To: mmuel...@gnuradio.org; discuss-gnuradio@gnu.org
Subject: Re: gr-dsd help needed

I will add a sink between the did and rational resampler and test again. Other 
then that does the flow graph look correct.

I am using a B210 UHD

Sent from my BlackBerry — the most secure mobile device — via the Bell Network
From: mmuel...@gnuradio.org
Sent: September 22, 2020 7:14 AM
To: discuss-gnuradio@gnu.org
Subject: Re: gr-dsd help needed

Is it possible the output rate of your DSD block isn't actually as high
as you think it is?

On 21.09.20 20:03, Martin Spears wrote:
> I am attempting to use gr-dsd for dmr audio. Can someone please tell me what 
> I am doing wrong. This sounds like a chipmunk with a speech impediment
>
> Martin Spears
>
>

Re: gr-dsd help needed

[Martin Spears]

I will add a sink between the did and rational resampler and test again. Other 
then that does the flow graph look correct.

I am using a B210 UHD

Sent from my BlackBerry — the most secure mobile device — via the Bell Network
From: mmuel...@gnuradio.org
Sent: September 22, 2020 7:14 AM
To: discuss-gnuradio@gnu.org
Subject: Re: gr-dsd help needed

Is it possible the output rate of your DSD block isn't actually as high
as you think it is?

On 21.09.20 20:03, Martin Spears wrote:
> I am attempting to use gr-dsd for dmr audio. Can someone please tell me what 
> I am doing wrong. This sounds like a chipmunk with a speech impediment
>
> Martin Spears
>
>

Sending out messages on block shutdown

[Martin Luelf]

Dear list,

I have a custom frame sync block that takes a stream of complex samples 
as inputs (output signature is 0,0) and outputs PDU messages if frames 
were found. When the upstream block is done I would still like to send 
out a few messages (flushing an internal buffer), before shutting down 
the block and signaling the subscribed block that we are done.


With GNURadio 3.7 I sent out these messages in the stop() method 
followed by an PMT EOF object, which worked great.


Now I finally ported my block to 3.8 and noticed that the messages send 
out during the stop() call are no longer received by the subscribed block.


Is there a way to find out that the call to the work function is going 
to be the last call, or is there another way of learning that the block 
is being stopped at a time where the subscribed block is still listening 
for messages?


Yours
Martin

Gr-dsd and ran codes

[Martin Spears]

Let's start this off.

Ubuntu 20.04
GNURadio 3.8.1.0
GR-DSD

This is running exactly as it should, all except the ability to decode RAN 
codes for the NXDN radio network I am listening too. Is there a block available 
that has the RAN tables in it?

Thank you all
Martin Spears - VE3AGS


Sent from my BlackBerry — the most secure mobile device — via the Bell Network

Re: Having trouble with C++ OOT block in restricting output to those input values I wish to pass

[Martin Luelf]

Dear George,

please keep the list in CC so other people can read this discussion in 
the future.


general_work can be called with any number of input parameters. This 
could be just 5, or 500 because it can buffer the repeated result from 
your repeating source. You can somewhat steer this with the forecast 
method by telling GNURadio that you need 100 inputs. In that case 
GNURadio will not call general_work with less than 100 inputs, but it 
might still call it with more than 100. Also for unittests that do not 
repeat keep in mind that GNURadio will silently drop any excess inputs 
that are less than the requested size.


I suggest you put a print statement both in forecast and general_work to 
and then run your code multiple times (also under different loads) to 
get a better idea of what GNURadio is doing under the hood.


Yours
Martin

On 15.09.20 06:28, George Edwards wrote:

Hi Martin,

I was out of town for the weekend, so I am just getting at my email.

Thanks for your detailed reply as usual. I really appreciate your help 
and I know it is a lot of effort and time on your part so I really 
appreciate it.

:
  The param cnt works well and is used to synch up the indices for the 
in and out arrays. For example, suppose the input data was 
{1,2,3,0,1,3,2,5,6} and the preamble pattern is {3,0,1,3,2}.
Then after initialization, cnt = 7 and i = 7 and of course the number of 
sync bytes = buf_size = 5. Before leaving the initialization loop I 
memcpy the 5 preamble bytes to the out array, which means the next index in
"out" to write on the next input data sample is out[5], however, this 
sample comes from in[i] = in[7]. Immediately after initialization, hence 
the relationship:
out[i-cnt+buf_size] = in[i] is correct because out[5] = in[7] and as i 
increases, we get out[6] = in[8], etc.


However, I see one big problem that will cause my logic to fail and it 
is based on your explanation that each time the general_work method is 
called it brings in a new set of data and i starts over in the "for loop".
I will need to change my logic, but please allow me to ask another 
question. Let's say, I have a source which generates 100 bytes and it 
Repeats. In Gnuradio, does this mean that each time the general_work 
method is called it receives a block of100 bytes of data? Thus, in the C 
logic test "for (int i = 0; i < ninput_items[0]; i++)", can I assume the 
Gnuradio parameter ninput_items[0] is equal to 100 and each function call?


Thanks for the help.

Best Regards,
George


On Sun, Sep 13, 2020 at 2:51 AM Martin Luelf <mailto:m...@mluelf.de>> wrote:


Hi George,

noutput_items is a number given to you by GNURadio. I would not
overwrite this variable, otherwise you no longer know how many items
you
can write into the output buffer. Create a new variable nitems_written
or similar to track how many items you have written.

Also have a look at what each variable is tracking exactly. cnt
seems to
be the number of input bytes you have checked for the preamble. But you
also use it to compute the position in the out array, which does not
make sense to me. cnt would increase with more spurious bytes in front
of the preamble, but the output position should not depend on the
number
of spurious bytes. From the code you showed me cnt also seems to
persist
between multiple calls to general_work, but the out array is always
clean when general_work is called again (meaning that on every
general_work call you should always start writing to element 0).

You loop over your entire input array and if the preamble was found you
copy the entire preamble and then you copy every following byte one by
one. That means you copy the entire preamble again (without the first
byte) and if your input buffer is longer than your message size you
also
copy more bytes to the output than your message is long which could
result in missing the next preamble. Also you are potentially writing
more items into the out array than GNURadio has space for, which is why
I recommend you not to overwrite noutput_items and while you are still
learning check that your computed indices for out and in are within the
allowed bounds before every single write and read (i.e. by using
assertions).

What messages are you using in your unittest and what kind of spurious
bytes? Is is all zeros, or all ones? I would recommend you use
different
bytes, e.g. an increasing counter for your message and a decreasing
counter starting from 255 for your spurious bytes so you can quickly
spot if your messages are cropped, or off in some other way. Because
the
way you describe your results it seems like one message is copied
twice.
I could not find any obvious bug in your code that would output a
message exactly twice, so I suppose it copies some data that 

Re: Having trouble with C++ OOT block in restricting output to those input values I wish to pass

[Martin Luelf]

Hi George,

noutput_items is a number given to you by GNURadio. I would not 
overwrite this variable, otherwise you no longer know how many items you 
can write into the output buffer. Create a new variable nitems_written 
or similar to track how many items you have written.


Also have a look at what each variable is tracking exactly. cnt seems to 
be the number of input bytes you have checked for the preamble. But you 
also use it to compute the position in the out array, which does not 
make sense to me. cnt would increase with more spurious bytes in front 
of the preamble, but the output position should not depend on the number 
of spurious bytes. From the code you showed me cnt also seems to persist 
between multiple calls to general_work, but the out array is always 
clean when general_work is called again (meaning that on every 
general_work call you should always start writing to element 0).


You loop over your entire input array and if the preamble was found you 
copy the entire preamble and then you copy every following byte one by 
one. That means you copy the entire preamble again (without the first 
byte) and if your input buffer is longer than your message size you also 
copy more bytes to the output than your message is long which could 
result in missing the next preamble. Also you are potentially writing 
more items into the out array than GNURadio has space for, which is why 
I recommend you not to overwrite noutput_items and while you are still 
learning check that your computed indices for out and in are within the 
allowed bounds before every single write and read (i.e. by using 
assertions).


What messages are you using in your unittest and what kind of spurious 
bytes? Is is all zeros, or all ones? I would recommend you use different 
bytes, e.g. an increasing counter for your message and a decreasing 
counter starting from 255 for your spurious bytes so you can quickly 
spot if your messages are cropped, or off in some other way. Because the 
way you describe your results it seems like one message is copied twice. 
I could not find any obvious bug in your code that would output a 
message exactly twice, so I suppose it copies some data that look like a 
message on the first glance.


Yours
Martin


On 11.09.20 03:06, George Edwards wrote:

Hi Martin,

Thanks for your detailed answer. I really appreciate the great effort 
you put into explaining how things work. I am still on the learning curve.


I used your suggestions to the best of my understanding and it worked 
beautifully for the one sync pattern test vector in the QA test.


Then, I took your suggestion for repeated sync patterns using an init 
flag which I reset to 0 to restart the process. For the QA test, I 
repeated the original input data twice (now I have 2 sync patterns), so 
the expected QA output should be the original output repeated twice. I 
modified the C code by adding an if statement at the end to check if 
noutput_items == Buf_size+message_size (buf_size is the length of the 
pattern, which I call preamble) and if it is, I reset the init flag to 
zero as well as other params used in the initialization section of the 
code. The QA test failed by producing an output with 3 repeated copies 
of the original output rather than the expected 2 copies. I do not 
expect you to send too much time looking at my code below, however, I 
would appreciate it very much, if you would glance at it to see if you 
can spot what I am doing wrong. The test to un-initialize (setting init 
to 0) was done towards the end of the code block after the consume method.


       int kk = 0;

   for (int i = 0; i < ninput_items[0]; i++)

   {

  if(!init){__

     cnt += 1;   // cnt number of passing bytes

     kk = initialize(in[i]);

     if (kk == 0){

     noutput_items =  cnt;

     }else{

     memcpy((void*)out, (const void*)preamble, buf_size);

     noutput_items = cnt;

     }

  } else {

    out[i-cnt+buf_size] = in[i];

    noutput_items = buf_size + message_size;

  }

   } 

   consume_each (noutput_items);

   if (noutput_items == buf_size + message_size){

  init = 0;  // re-initialize all

  cnt = 0;

  kk = 0;

   }

   return noutput_items;

     }


Thanks very much for the help.

Regards,
George

On Thu, Sep 10, 2020 at 12:06 AM Martin Luelf <mailto:m...@mluelf.de>> wrote:


Dear George,

this also caused me a lot of headache when I started with GNURadio, so
here is what I learned about it.

Let's start with the forecast method. This tells GNURadio how many
input
samples you need on each input stream to generate the requested number
of output items. Usually GNURadio will run your forecast function a
  

Re: GNU Radio SDR Project

[Martin Braun]

On 9/10/20 4:03 AM, Elmore's wrote:
> I am currently working on a GNU radio project using my Softrock/MOBO
> SDR. I have a functioning receiver and transmitter. I now want to
> incorporate an interface to the Softrock in the GNU Radio flowgraph. I
> have not been able to find any info on how to do this.
>  
> I am using a command line application called usbsoftrock to control PTT
> and frequency. This is written in C. Ideally I would like to call
> usbsoftrock from the flowgraph but I don’t see any way to do that. I
> have looked at creating a new block and using a Function Probe block but
> this doesn’t seem possible. The blocks need to be written in C++ or
> Python and Function Probe can’t make a single function call.
>  
> My platform is a Raspberry Pi. GNU Radio has presented a stiff learning
> curve for me and I’m sure I still have a lack of understanding of many
> aspects of it.
>  
> Note that I have used quisk on the RPi and PowerSDR on a Windows machine
> with the Softrock.
>  
> Any suggestions? Thanks for any help you can provide.

Have you done the tutorials on how to write a block? Thanks to our docs
team, they're pretty good. I would recommend using GNU Radio 3.8 as a
basis. Once you've done the tutorial, creating hardware sources or sinks
should not be hard if you're familiar with C/C++. There's plenty of
other driver interface blocks (like gr-uhd) to use as inspiration.

--M

Re: Having trouble with C++ OOT block in restricting output to those input values I wish to pass

[Martin Luelf]

Dear George,

this also caused me a lot of headache when I started with GNURadio, so 
here is what I learned about it.


Let's start with the forecast method. This tells GNURadio how many input 
samples you need on each input stream to generate the requested number 
of output items. Usually GNURadio will run your forecast function a 
couple of times with different output numbers to find a good data chunk 
size to give to the general work function. Keep in mind that the number 
of required input items you give here is a minimum number and GNURadio 
might decide to give you more input data than you requested. It is also 
important to know that the number of samples you request here is just an 
estimate. You are not forced to actually process that much data.


Now to the general_work function. noutput_items tells you how many 
samples GNURadio would like you to produce (this is a maximum number you 
may produce less). It also tells you how much memory is allocated in 
every array in the output_items vector. If you have only one output and 
you used the default  *out = ( *) output_items[0]; 
definition this tells you how many items you can place (at most) into 
the out array.


The ninput_items[] array tells you how many input items are available in 
the input arrays. Again if you just have one input and you use const type> *in = (const  *) input_items[0]; ninput_items[0] is the 
number of inputs available in the in array. You may not read more items 
than that from the array.


Within the given input symbols you can start looking for your sync 
pattern. If you generate output you have to write (in your case copy) it 
to the out array. At the end of general_work you call consume(0, K) with 
the number of input items K that you have consumed on input 0. That is 
how many of the input items you have used and do not need to see again. 
If you consume 0 symbols the next call to general_work will show you the 
exact same input samples again. If you consume ninput_items[0] you will 
see completely new input samples on the first input the next time 
general_work is called. And then you return the number of samples you 
generated (i.e. how much samples you put into the out array). This 
number must be smaller or equal noutput_items, because otherwise you 
would have written out of the allocated memory which might result in a 
segfault/core dump. Note that you don't have to call consume at the very 
end of work and there is also another way of telling GNURadio how many 
samples you have produced, but let's leave that for another day.


So a very easy (but not the most efficient) setup for your problem could be:
Add a boolean flag to your _impl class that both forecast and 
general_work can read/write to. This flag will indicate whether or not 
you have found the sync pattern or not. You initialize this flag with false.
Assume you have a sync pattern of length L and a message with M data 
symbols afterwards.


In forecast if the flag is set (meaning you have found the sync pattern) 
you need L+M symbols of input. If the flag is not set you need L input 
samples, regardless of how many output samples GNURadio wants you to 
generate.


In general work if the flag is false you search the input for the sync 
pattern. If you found it at position i (counting from 0) you set the 
flag to true, consume i samples (i.e. everything before the sync 
marker). If the sync marker is not found you keep the flag to false and 
consume the inputs that you have searched so far. In both cases you 
return 0 since you have not generated any output yet.


If the flag is true you copy the first L+M samples from the input to the 
output, you set the flag to false (because after the data you have to 
start searching for the sync marker again) you consume L+M samples and 
return L+M samples.


Note: This is a very easy to understand scheme, but unfortunately not 
very efficient. You only process a single block of either unwanted 
spurious symbols, or one sync marker and data at a time. So once you 
have a good understanding of how this works you should tweak that block 
to be able to process multiple blocks of spurious symbols and sync 
patterns/data within once call to general_work. It uses the same kind of 
logic, but requires more housekeeping of counters and indices.


If your input is symbols rather than bits/bytes you should also look at 
the paper from J. Massey "Optimum Frame Synchronization" from 1972 on 
how to perform optimum sync marker detection, which performs better than 
the intuitive correlation search.


Hope that gets you started.

Yours
Martin


On 10.09.20 04:34, George Edwards wrote:

Hello,

I am writing an OOT block in C++ that receives a sequence of numbers and 
searches through for a sync pattern and passes to its output the sync 
pattern and the  bytes of data which follows it. The QA test shows the 
block recognizes the pattern and will pass the pattern along with the 
data that follow it,

Re: How to write Gnuradion OOT C++ method as a stand alone .cc file?

[Martin Braun]

George,

all the usual linking and compilation rules of C++ apply. There are plenty
of blocks that call other functions from general_work() or work(). If
you're compiling a-OK, then you're probably halfway there. Your QA code
should tell you what's missing, if it's a missing symbol (i.e. linker
error) or something more profane.

--M

On Thu, Aug 20, 2020 at 5:56 AM George Edwards 
wrote:

> Hello,
>
> I am experimenting with writing an OOT method in a separate .cc file to be
> called by the general_work method that Gnuradio automatically generates
> when one uses the gr_modtool to create an OOT module. In general if the
> method is short, it is convenient to write its definition about the
> general_work method which called it. However, if the signal processing
> makes the method long with too many lines of code, then it is better to
> create a separate .cc file for the function. I made the additional .cc file
> and wrapped the method in a similar manner to how the gr_modtool  wraps the
> .cc file My_ProgramName.cc. The new .cc file shows no errors and I compiled
> the entire OOT module with: cmake ../ and make. However, when I run the QA
> test, it breaks the  system. Below is a template showing how I wrote the
> additional file named, my_function_name.cc:
>
> *#include  *
> *#include "My_ProgramName.h"  // created by gr_modtool*
> *namespace gr {*
> *namespace tutorial {*
> *gr_complex*
> * My_ProgramName_impl::my_function_name(param)*
> *   {*
> *   // my signal processing algorithm goes here*
> *}*
> *   }  //namespace tutorial*
> *} //namespace gr*
>
> I will appreciate your feedback or help, so I can get my method to work
> and not break the system when I run the QA test.
>
> Thank you!
>
> George
>

Re: USRP b200mini initial behavior

[Martin Braun]

Try an LO offset. You might be dealing with the AD9361-based calibrations,
they work better if you're not sending DC (if that's what you're doing).

On Tue, Aug 18, 2020 at 8:53 AM Ali G. Dezfuli  wrote:

> Hi all,
> In USRP B200mini, when I start off sending, for example, a tone from TX/RX
> port and receive it from RX2 port, there is an increasing amplitude signal
> at the receiver that could take a pretty long time to converge (e.g. at 4
> MHz sample rate, it is as long as 50 to 100 milliseconds.)
> I wonder if it is because of the transmitter's initialization or the
> receiver's AGC.
>
> I also test a binary OOK-like signal (on-off keying) to check if it
> happens during the transmission and found out that it just happens at the
> start of transmission.
> I would be appreciated if anyone helps me with this.
>
> regards,
> Ali G. Dezfuli
>

GNU Radio Project Mission Statement -- Looking for Your Thoughts!

[Martin Braun]

GNU Radioers,

as the GNU Radio project matures, we're going to spend some time evolving
the actual organization behind it. We'll keep you posted on updates on
that, but as a first step, we'd like to define the mission statement of the
GNU Radio organization.

When people think of GNU Radio, they usually think of the code itself. And
that's OK, our code is our prime asset, our crown jewel. Our own website
describes it as such:

"""

GNU Radio is a free & open-source software development toolkit that
provides signal processing blocks to implement software radios. It can be
used with readily-available low-cost external RF hardware to create
software-defined radios, or without hardware in a simulation-like
environment. It is widely used in research, industry, academia, government,
and hobbyist environments to support both wireless communications research
and real-world radio systems.

"""

The GNU Radio project is more than that, though. We run a conference, we
work with industry, academia, students, hobbyists, governments to do
all sorts of things: Be part of SDR research, be part of education, do
education ourselves. and so on.

As opposed to the GNU Radio code, we are looking to formulate a succinct
mission statement for the GNU Radio Organization itself. Basically a
paragraph or two that describes our purpose.

We have some thoughts, but we would like to ask this open-ended question to
everyone here to hear your input.

If you would like to see other organization's mission statements, the KDE
e.V. is a similar organization (albeit much bigger). You can find their
purpose in their statutes: https://ev.kde.org/corporate/statutes/ (however,
I deliberately didn't paste it here for those who want to think about it.

Why are we doing this?

Well, as I said, we're trying to grow the organization itself. A mission
statement is a very useful tool when engaging in partners (e.g., when we're
trying to insert GNU Radio into a publicly funded project), sponsors, or
educational institutions. And maybe we'll create an actual organization, or
e.V. of our own where we'll need this anyway.


We're interested to hear your thoughts and ideas!


Cheers,

Martin

Re: gr-modtool does not seem to work in gnuradio 3.8.1 package in ubuntu 20.04

[Martin]

I already found out I had to remove all CC qa code.
This is a different issue. (python qa code).
I found a patch for this issue in anouther message (see my other email 
from e few minites ago).


I need to patch the installed gr_modtool add.py code from the gnuradio 
package.


Would be nice to fix the broken ubuntu package, but I don't know how to 
initiate that.


Best regards,

Martin


On 28-07-2020 16:52, Tom McDermott wrote:

 >Message: 3
 >Date: Tue, 28 Jul 2020 16:07:06 +0200
 >From: Martin <mailto:gnuradiom...@olifantasia.com>>

 >To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
 >Subject: gr-modtool does not seem to work in gnuradio 3.8.1 package in
 >        ubuntu 20.04
 >Message-ID: <2df7bef0-8270-750f-7bb4-73a112914...@olifantasia.com 
<mailto:2df7bef0-8270-750f-7bb4-73a112914...@olifantasia.com>>

 >Content-Type: text/plain; charset=utf-8; format=flowed
 >
 >Hi,
 >I am trying to get my out of tree module to build and work on ubuntu
 >20.04 with the default gnuradio package gnuradio 3.8.1.0-rc1-2build2
 >
 >
 >When I use gr_modtool to create an out of tree module with an empty
 >source block then cmake gives an error.
 >
 >CMake Error at lib/CMakeLists.txt:85:
 >   Parse error.  Expected a command name, got unquoted argument with text
 >   "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".

I've had the same problem.   gr_modtool is generating broken cmake for 
.cc qa tests.
It was necessary to strip out all cc qa tests and files for an OOT 
project I ported to 3.8 to get it to build.
By looking at the cmake code, it's not clear what it should have 
generated, someone skilled

in cmake would probably quickly know what was meant.

The .py qa generated cmake file is correct and builds fine, so the error 
is likely in

a small area.

-- Tom, N5EG

Re: gr-modtool does not seem to work in gnuradio 3.8.1 package in ubuntu 20.04

[Martin]

I found this on the list:

Fixed by this commit:

https://github.com/gnuradio/gnuradio/commit/79ae0042ff0ec3c20f67820c11adae5442236274

That commit is included in GNU Radio 3.8.1.0

Ron 



This seems to fix the problem.
Note that the  gnuradio release 3.8.1.0-rc1-2build2 distributed in 
ubuntu does not yet have this fix, even though it has 3.8.1.0 in its 
version.



With best regards,

Martin



On 28-07-2020 16:07, Martin wrote:

Hi,
I am trying to get my out of tree module to build and work on ubuntu 
20.04 with the default gnuradio package gnuradio 3.8.1.0-rc1-2build2



When I use gr_modtool to create an out of tree module with an empty 
source block then cmake gives an error.


CMake Error at lib/CMakeLists.txt:85:
   Parse error.  Expected a command name, got unquoted argument with text
   "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".



Does anybody have gr_modtool working on ubuntu 20.04 with the 
distributions gnuradio package.



See below for details of what I did.


install gnuradio and dependencies

apt-get install gnuradio
apt-get install gnuradio-dev
apt-get install build-dep gnuradio


Use gr-modtool to try to create new module with name testmod with a 
source block named testsource


gr_modtool newmod testmod

gr_modtool add -t source --add-python-qa --add-cpp-qdistributionsa -l cpp

GNU Radio module name identified: testmod
Language: C++
Enter name of block/code (without module name prefix): testsource
Block/code identifier: testsource
Please specify the copyright holder: Martin Dudok van Heel
Enter valid argument list, including default arguments:
Adding file 'lib/testsource_impl.h'...
Adding file 'lib/testsource_impl.cc'...
Adding file 'include/testmod/testsource.h'...
Adding file 'lib/qa_testsource.cc'...
Adding file 'lib/qa_testsource.h'...
Can't add C++ QA files.
Editing swig/testmod_swig.i...
Adding file 'python/qa_testsource.py'...
Editing python/CMakeLists.txt...
Adding file 'grc/testmod_testsource.block.yml'...
Editing grc/CMakeLists.txt...

mkdir build2
cd build2
cmake ..


- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found LOG4CPP: /usr/lib/x86_64-linux-gnu/liblog4cpp.so
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'gmp'
--   Found gmp, version 6.2.0
-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY 
MPIR_INCLUDE_DIR)

-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Found Boost: 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found 
suitable version "1.71.0", minimum required is "1.71.0") found 
components: date_time program_options filesystem system regex thread 
unit_test_framework

-- Found VOLK: Volk::volk
-- User set python executable /usr/bin/python3
-- Found PythonInterp: /usr/bin/python3 (found version "3.8.2")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found 
suitable exact version "3.8.2")

-- Found Git: /usr/bin/git
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found 
components: doxygen dot

CMake Error at lib/CMakeLists.txt:85:
   Parse error.  Expected a command name, got unquoted argument with text
   "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".


-- Configuring incomplete, errors occurred!
See also "build2/CMakeFiles/CMakeOutput.log".
See also "build2/CMakeFiles/CMakeError.log".






cat CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the 
following output:

Change Dir: gr-testmod/build2/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make cmTC_60538/fast && /usr/bin/make -f 
CMakeFiles/cmTC_60538.dir/build.make CMakeFiles/cmTC_60538.dir/build

make[1]: Entering directory 'gr-testmod/build2/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_60538.dir/src.c.o
/usr/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD   -std=gnu11 -o 
CMakeFiles/cmTC_60538.dir/src.c.o   -c 
gr-testmod/build2/CMakeFiles/CMakeTmp/src.c

Linking C executable cmTC_60538
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_60538.dir/link.txt 
--verbose=1
/usr/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD 
CMakeFi

gr-modtool does not seem to work in gnuradio 3.8.1 package in ubuntu 20.04

[Martin]

Hi,
I am trying to get my out of tree module to build and work on ubuntu 
20.04 with the default gnuradio package gnuradio 3.8.1.0-rc1-2build2



When I use gr_modtool to create an out of tree module with an empty 
source block then cmake gives an error.


CMake Error at lib/CMakeLists.txt:85:
  Parse error.  Expected a command name, got unquoted argument with text
  "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".



Does anybody have gr_modtool working on ubuntu 20.04 with the 
distributions gnuradio package.



See below for details of what I did.


install gnuradio and dependencies

apt-get install gnuradio
apt-get install gnuradio-dev
apt-get install build-dep gnuradio


Use gr-modtool to try to create new module with name testmod with a 
source block named testsource


gr_modtool newmod testmod

gr_modtool add -t source --add-python-qa --add-cpp-qdistributionsa -l cpp

GNU Radio module name identified: testmod
Language: C++
Enter name of block/code (without module name prefix): testsource
Block/code identifier: testsource
Please specify the copyright holder: Martin Dudok van Heel
Enter valid argument list, including default arguments:
Adding file 'lib/testsource_impl.h'...
Adding file 'lib/testsource_impl.cc'...
Adding file 'include/testmod/testsource.h'...
Adding file 'lib/qa_testsource.cc'...
Adding file 'lib/qa_testsource.h'...
Can't add C++ QA files.
Editing swig/testmod_swig.i...
Adding file 'python/qa_testsource.py'...
Editing python/CMakeLists.txt...
Adding file 'grc/testmod_testsource.block.yml'...
Editing grc/CMakeLists.txt...

mkdir build2
cd build2
cmake ..


- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found LOG4CPP: /usr/lib/x86_64-linux-gnu/liblog4cpp.so
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'gmp'
--   Found gmp, version 6.2.0
-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY 
MPIR_INCLUDE_DIR)

-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Found Boost: 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found 
suitable version "1.71.0", minimum required is "1.71.0") found 
components: date_time program_options filesystem system regex thread 
unit_test_framework

-- Found VOLK: Volk::volk
-- User set python executable /usr/bin/python3
-- Found PythonInterp: /usr/bin/python3 (found version "3.8.2")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found 
suitable exact version "3.8.2")

-- Found Git: /usr/bin/git
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found 
components: doxygen dot

CMake Error at lib/CMakeLists.txt:85:
  Parse error.  Expected a command name, got unquoted argument with text
  "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".


-- Configuring incomplete, errors occurred!
See also "build2/CMakeFiles/CMakeOutput.log".
See also "build2/CMakeFiles/CMakeError.log".






cat CMakeFiles/CMakeError.log
Performing C SOURCE FILE Test CMAKE_HAVE_LIBC_PTHREAD failed with the 
following output:

Change Dir: gr-testmod/build2/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make cmTC_60538/fast && /usr/bin/make -f 
CMakeFiles/cmTC_60538.dir/build.make CMakeFiles/cmTC_60538.dir/build

make[1]: Entering directory 'gr-testmod/build2/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_60538.dir/src.c.o
/usr/bin/cc   -DCMAKE_HAVE_LIBC_PTHREAD   -std=gnu11 -o 
CMakeFiles/cmTC_60538.dir/src.c.o   -c 
gr-testmod/build2/CMakeFiles/CMakeTmp/src.c

Linking C executable cmTC_60538
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_60538.dir/link.txt 
--verbose=1
/usr/bin/cc  -DCMAKE_HAVE_LIBC_PTHREAD 
CMakeFiles/cmTC_60538.dir/src.c.o  -o cmTC_60538

/usr/bin/ld: CMakeFiles/cmTC_60538.dir/src.c.o: in function `main':
src.c:(.text+0x46): undefined reference to `pthread_create'
/usr/bin/ld: src.c:(.text+0x52): undefined reference to `pthread_detach'
/usr/bin/ld: src.c:(.text+0x63): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_60538.dir/build.make:87: cmTC_6053

gr-foo , gr-Bluetooth

[Martin Spears]

I have been working with gr-bluetooth and things have been working out fine. I 
was wondering if there is a wireshark connector similar to the gr-foo 
ZigBee/wifi case. I can see a lot of the hex data but since I cannot format it 
correctly as a pcap file wireshark cannot provide me with any further 
information except that of a malformed eth

Martin Spears

Project Call June 2020 Today!

[Martin Braun]

Hi all,

as usual, it's the third Thursday of the month, and we're doing our project
call. Join us on IRC, Matrix, or via the Twitch stream:
https://twitch.tv/gnuradio

The call starts 10 AM Pacific, 1 PM Eastern, 19:00 CEST.

Cheers,
Martin

Looking for a maintainer for PyBOMBS

[Martin Braun]

Hi all,

I'm currently -- nominally -- the maintainer for PyBOMBS, but it's not
something I have actively done in the past. Since PyBOMBS is a useful
tool, it would be a disservice to this community to not continue its
development, and we're looking for someone who wants to do that.

We have tried to put more focus on packages for GNU Radio, making an
additional tool like PyBOMBS less important for installing GNU Radio
itself. However, for obtaining out-of-tree modules, it's still very,
very useful.

If you're interested in maintaining this tool, please let me know. Prior
experience is highly appreciated -- people who have been submitting PRs
and been active on the issue tracker would be preferred.

Cheers,
Martin

Re: fastest way to interpolate

[Martin Spears]

Frederico

I am not certain about this but could it be the USB bus. I know with my 
Fairwaves XTRX which connects through 2x miniPCI-e the transfer rate is close 
to 8Gbps, and the SDR can do 120Msps is SISO mode

Martin Spears
Chief Technical Officer
Ingenious Countermeasures Technologies Inc.
mspe...@icmt.ca
705-885-1990


From: Discuss-gnuradio  on 
behalf of Federico 'Larroca' La Rocca 
Sent: Thursday, May 28, 2020 4:11:01 PM
To: GNURadio Discussion List 
Subject: fastest way to interpolate

Hi everyone,

I've finally been testing gr-tempest with some SDR hardware and the following 
problem arised: sampling correction takes way too much CPU. In my (relatively 
new) laptop I get dropped samples at a sampling rate above 15 MSps. I'm 
currently using the Fractional Resampler block, and I would need at least 
30MSps to get a decent image.

The question is then: is there any other faster possibility to interpolate and 
correct the incoming's signal sampling rate? Right now, I'm thinking about 
sending messages to the USRP Source block, but it would not work with other 
hardware. Note that recording the signal and passing it through the provided 
flowgraph still works, but it would be much more interesting to have a 
real-time system.

best
Federico

GNU Radio Project Call May on Now!

[Martin Braun]

Hi all!

A very last minute announcement for our monthly project call! As usual,
every third Thursday of the month, we're going to talk about what's going
on in the project. You can watch us at

twitch.tv/gnuradio

or you can even join the call if you like: https://meet.jit.si/gr-prj-may
(it's the same content).

See you in a bit!

--Martin and the GR leads team

Re: GNU Radio 3.7 on Ubuntu 20.04

[Martin Luelf]

Hi,

I just updated my Kubuntu today without thinking about GNURadio (and due 
to my OOT not being ported to 3.8 yet I am still stuck on 3.7). I still 
have python2 running like a charm. But I could not get the QT bindings 
running, since my KDE is using QT5 and trying to install Qt4 looks like 
it is going to skrew up my entire system.


So GNURadio 3.7 itself is running fine on 20.4, but gnuradio-companion 
and gr-qtgui seem to be tricky (at least when running KDE).


Yours
Martin


On 14.05.20 17:29, Alex Humberstone wrote:
The new Ubuntu 20.04 does not include Python 2 anymore. But GNU Radio 
3.7 requires Python 2. So then can you run GNU Radio 3.7 on Ubuntu 
20.04? I think there's still a package that you can instal to add Python 
2 support in Ubuntu 20.04. I found a bunch of websites that make it 
sound like this should be possible. So I'm thinking it should still 
actually be possible to run GNU Radio 3.7 on Ubuntu 20.04. Has anyone 
actually tried this before? Does this work? Is there anything special 
that you have to do? Any help here would be super appreciated. Thanks in 
advance for your help everyone!


https://linuxconfig.org/install-python-2-on-ubuntu-20-04-focal-fossa-linux

https://linuxize.com/post/how-to-install-pip-on-ubuntu-20.04/

https://www.vultr.com/docs/how-to-install-python-2-on-ubuntu-20-04

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.04-Clear-Python2

--
Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University
Las Cruces, New Mexico

Re: Coding standard: AllowShortFunctionsOnASingleLine?

[Martin Braun]

In case this adds clarification: Before committing, just run clang-format
-i on your code. That way, you can write code however you like, and then
have a computer fix the formatting for you.
Many editors also let you clang-format inside the IDE. Personally, I
reformat in vim on demand (I prefer not to have vim auto-correct while I'm
typing), and I have a pre-commit hook to warn me if I'm checking in badly
formatted code. If it slips through the cracks, don't worry: GitHub will
tell you, and you just need to fix and force-push your branch. No harm done!

--M

On Sun, May 10, 2020 at 4:37 AM Ron Economos  wrote:

> You're not doing anything wrong. The comments you received are incorrect.
> If you clang-format your files, you'll be fine.
>
> Ron
> On 5/10/20 04:08, Christophe Seguinot wrote:
>
> Hi
>
> I recently submitted an "add eye_sink" PR. (as I'm not familiar with PR, I
> made several attempts/close :  correct coding standard and new line at
> EOF)
>
> I'm sucked on a request to use the following format for short function
> 
>
> function()
> {
> code;
> }
>
> However  using   GNURadio coding standard
> 
> clang-format  uses the directive:
>
> AllowShortFunctionsOnASingleLine: All
>
> which format short function on a single line.
>
> What am I doing wrong?
>
> Please could someone guide me to the right direction so that my next PR
> will be the good one?
>
> Regards
>
>

Re: [USRP-users] How to set channel B reception with rfnoc USRP E310?

[Martin Braun]

It does; the channel parameter on E310 is used to address the A- or B-side.

On Mon, May 4, 2020 at 1:39 PM Rob Kossler  wrote:

> Does the 2nd argument to set_rx_antenna() indicate which radio port?  If
> so, try setting it to 1.
> Rob
>
> On Mon, May 4, 2020 at 2:02 PM Ivan Zahartchuk via USRP-users <
> usrp-us...@lists.ettus.com> wrote:
>
>> Hello, I'm trying to switch between all four USRP E310 inputs. For this,
>> I use the command self.uhd_rfnoc_streamer_radio_0.set_rx_antenna ("TX /
>> RX", 0) but I can only switch in channel A. RFNoC Radio does not have the
>> set_rx_subdev_spec command. Tell me how can I switch across all 4 channels?
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

Switching Chat Services: From Slack to Matrix

[Martin Braun]

Hi all,

for a while now, we've been discussing what to do about our Slack chat
service. It was very clear that we needed to do something: Our free plan
only kept a very short history, the non-free plan was pricey, and Slack
itself came with a lot of baggage (mostly related to privacy issues, and
the fact that the chat logs, even though we we couldn't see them, were
hosted on a server we don't own).

With the upcoming virtual GRCon, we wanted to get our chat solution
sorted out pretty quickly, which is one reason why we made an effort to
speed up the process and push out a replacement service ASAP.The bottom
line is that we will be moving to a Matrix-based solution. Go to
https://chat.gnuradio.org to join our Matrix server.

On https://www.gnuradio.org/blog/2020-04-27-moving-to-the-matrix/, you
can find the full announcement, and how we came to the conclusion of
choosing Matrix, as well as some details of how we're set up.

A personal note from a community standpoint: We have received some
criticism about how we made this decision without much community
involvement. And yes, that's true, we could have done this better. The
root cause, I would wager a guess, was procrastinating on the decision
until we really needed to sort this out. I would like to ask everyone
who wants to participate in the GNU Radio chat to give it a shot, and
provide constructive feedback other than "can we have giphys".

All things considered, Matrix brings a lot to the table: We can host it
ourselves (meaning, we have control over chat logs and the data), it is
an open standard, and thus supports many different clients, including
web and mobile, which help support people's different preferences and
personal requirements.

Again, for more details check out the blog post.

Cheers!

Martin

Re: Late messages after a tx_time tagged message

[Martin Braun]

Anthony,

the USRP doesn't keep the time, but there is only a single FIFO. If you
schedule 3 messages for sending, they need to be sent in order. Once they
are on the device, they are in a FIFO and will be released in that order.

For example, if have 3 messages A, B, and C. You first send A to be sent at
time T0. Then you send B to be send ASAP. Then you send C to be sent at
time T1 > T0.

A will be sent at T0, but B has to wait for A to clear the FIFO. That means
B will go out at T0 + (length of B).

All our devices have a single FIFO for data, so there's no way around that.
You could try and track the device time in software, and send them to the
device as late as possible, but that's tricky of course.

--M

On Mon, Apr 27, 2020 at 8:58 AM Anthony B.  wrote:

> Hello all,
>
> I am using timed commands to send messages at a specific time, using GNU
> Radio 3.7.14.
> To achieve that, I add a tx_time tag to my message just before the USRP
> Sink, slightly in the future, and it works fine.
> What I'd like to achieve now is to only send specific messages using the
> tx_time tag, in an asynchronous way.
> I just want the other messages to be sent as soon as possible, without
> timed commands.
>
> What happens currently is the following behaviour:
> - the message n is sent successfully, with a tx_time tag
> - the message n+1, without a tx_time tag, is considered late by UHD
> (printing "LL") when it is about to be sent
>
> My interpretation is that the USRP Sink keeps the tx_time tag of the
> message n for all the messages following it.
> Is it possible to clean the tags on the USRP bloc between the messsages n
> and n+1 ?
> Or UHD is only expecting an implementation that updates the tx_time tag
> for the next burst, and so all the messages have to be tagged before being
> sent ?
> Is it possible to mix messages that are timed with the tx_time tag, and in
> the same flow send others that are not ?
>
> Any suggestion would be appreciated.
>
> Best regards,
>
> Anthony
>

Re: Project Call April On Now!

[Martin Braun]

The recording is available here: https://youtu.be/4xRWRNmR5as

On Thu, Apr 16, 2020 at 10:07 AM Martin Braun  wrote:

> ...well, in a few minutes.
>
> We'll be streaming again on twitch.tv/gnuradio in  few minutes, just
> fixing the agenda. Join us in IRC, Slack, or Twitch chat and let us know
> immediately if the audio is not working (and continue to let us know until
> someone has acknowledged it).
>
> Cheers,
> Martin
>

Project Call April On Now!

[Martin Braun]

...well, in a few minutes.

We'll be streaming again on twitch.tv/gnuradio in  few minutes, just fixing
the agenda. Join us in IRC, Slack, or Twitch chat and let us know
immediately if the audio is not working (and continue to let us know until
someone has acknowledged it).

Cheers,
Martin

Project Call March 2020: Cancelled

[Martin Braun]

Hi all,

we don't have a lot of agenda items for today's call, so the project
call is cancelled today. We're still on IRC and Slack -- come chat with
us there if you need GNU Radio Company!

Cheers,
Martin

Re: MPSK SNR Estimation block shifts input by one

[Martin Luelf]

Dear Marcus,

thank you very much for your reply. Please see my comments inline.

On 24.03.20 16:38, Marcus Müller wrote:

Really quick answer:

 // at least 1 estimator has to look back
 set_history(2);
I totally forgot about the history feature. That makes a lot of sense 
and explains the leading zero. Plus it helps to restore my sanity :)




i.e. "works as designed"; whether that is "works as intended" is up for
discussion.


I would argue that the SNR Estimation block should skip the first 
history()-1 input samples, such that the blocks output becomes exactly 
the input without any shift.


The corresponding doc comment in 
https://github.com/gnuradio/gnuradio/blob/07741c1e5c7693a2a240bacfc5828f455fe20482/gr-digital/include/gnuradio/digital/mpsk_snr_est_cc.h#L28 
says


"It [...] passes all incoming data along to its output"

While that does not explicitly says 1:1 copy I think it is fair to say 
that a shift might come as a surprise to a user.


Is there any benefit to keeping the additional zero in the output, or 
was this simply not considered when writing the block? If the latter is 
true, I'd be happy to write a patch for it.



However, you'll see the last symbol as the first symbol of
your coming call to work!
I am not entirely sure what you mean by that. Are you explaining what a 
history of 2 does to a block? In that case this is clear to me.


But I am wondering what happened to my last input symbol.

Input: ((1+0j), (-1+0j), (1+0j), (1+0j))
I got: (0j, (1+0j), (-1+0j), (1+0j))
I would expect: (0j, (1+0j), (-1+0j), (1+0j), (1+0j))

Could it be that the last history()-1 number of samples are cut away 
from a blocks input?


Or asked in a different way: Will a block that has a history of 5 that 
gets 10 input samples (in total, might be over different calls to work) 
see 10, 14 or 15 unique (as in not counting them twice) symbols?


Yours
Martin


From the example


Best regards,
Marcus

On 24.03.20 10:33, Martin Luelf wrote:

Hi everybody,

I stumbled over a strange behavior while writing unittests for a frame
synchronization block.

The MPSK SNR Estimation block from GNURadio will output a complex zero
sample before outputting the (shifted by one) input samples.

To show this problem I use a Vector source with a sequence of BPSK
symbols and connect this source to a vector sink and the MPSK SNR
estimation block. The SNR estimation block is connected to a second sink
(the python script for this is attached at the bottom of this email).
After the flowgraph completes I print out the input data and the data
collected by the two sinks and it looks like this:

Original input data:. ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from source (SNR Est input): ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from SNR Est:... (0j, (1+0j), (-1+0j), (1+0j))

Note that the data from the SNR estimator has an additional 0j at the
front before the input sequence and the last symbol from the input data
is dropped.

However looking at the source code of the SNR Estimation block the first
line of the work function
(https://github.com/gnuradio/gnuradio/blob/351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70/gr-digital/lib/mpsk_snr_est_cc_impl.cc#L77)
reads:

memcpy(output_items[0], input_items[0], noutput_items *
sizeof(gr_complex));

which looks perfectly correct to me. So what is happening here? Am I
missing something? I tried searching the mailing list for shifted
samples but the results all resolve around actually wanting to shift
samples around.

Any help/hint would be greatly appreciated.

Yours
Martin



Example code to reproduce the problem (tested on maint-3.7 branch
currently at commit 351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70):

#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from gnuradio import blocks
from gnuradio import digital
from gnuradio import gr

tb = gr.top_block("Test MPSK SNR Estimation")

##
# Variables
##
data_in = (1.0+0j, -1.0+0j, 1.0+0j, 1.0+0j)

##
# Blocks
##
blocks_vector_source = blocks.vector_source_c(data_in, False, 1, [])
digital_mpsk_snr_est_cc = digital.mpsk_snr_est_cc(0, 1, 0.001)
blocks_vector_sink1 = blocks.vector_sink_c(1, 1024)
blocks_vector_sink2 = blocks.vector_sink_c(1, 1024)

##
# Connections
##

# Source -> Sink 1
tb.connect((blocks_vector_source, 0), (blocks_vector_sink1, 0))

# Source -> MPSK SNR Est -> Sink 2
tb.connect((blocks_vector_source, 0), (digital_mpsk_snr_est_cc, 0))
tb.connect((digital_mpsk_snr_est_cc, 0), (blocks_vector_sink2, 0))

tb.run()

print('Original input data:. {}'.format(data_in))
print('Data from source (SNR Est input):
{}'.format(blocks_vector_sink1.data()))
print('Data from SNR Est:...
{}'.format(blocks_vector_sink2.data()))

MPSK SNR Estimation block shifts input by one

[Martin Luelf]

Hi everybody,

I stumbled over a strange behavior while writing unittests for a frame 
synchronization block.


The MPSK SNR Estimation block from GNURadio will output a complex zero 
sample before outputting the (shifted by one) input samples.


To show this problem I use a Vector source with a sequence of BPSK 
symbols and connect this source to a vector sink and the MPSK SNR 
estimation block. The SNR estimation block is connected to a second sink 
(the python script for this is attached at the bottom of this email). 
After the flowgraph completes I print out the input data and the data 
collected by the two sinks and it looks like this:


Original input data:. ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from source (SNR Est input): ((1+0j), (-1+0j), (1+0j), (1+0j))
Data from SNR Est:... (0j, (1+0j), (-1+0j), (1+0j))

Note that the data from the SNR estimator has an additional 0j at the 
front before the input sequence and the last symbol from the input data 
is dropped.


However looking at the source code of the SNR Estimation block the first 
line of the work function 
(https://github.com/gnuradio/gnuradio/blob/351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70/gr-digital/lib/mpsk_snr_est_cc_impl.cc#L77) 
reads:


memcpy(output_items[0], input_items[0], noutput_items * sizeof(gr_complex));

which looks perfectly correct to me. So what is happening here? Am I 
missing something? I tried searching the mailing list for shifted 
samples but the results all resolve around actually wanting to shift 
samples around.


Any help/hint would be greatly appreciated.

Yours
Martin



Example code to reproduce the problem (tested on maint-3.7 branch 
currently at commit 351a22cc0e2fc05f4ca6ccb08de6ca1e83b62a70):


#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from gnuradio import blocks
from gnuradio import digital
from gnuradio import gr

tb = gr.top_block("Test MPSK SNR Estimation")

##
# Variables
##
data_in = (1.0+0j, -1.0+0j, 1.0+0j, 1.0+0j)

##
# Blocks
##
blocks_vector_source = blocks.vector_source_c(data_in, False, 1, [])
digital_mpsk_snr_est_cc = digital.mpsk_snr_est_cc(0, 1, 0.001)
blocks_vector_sink1 = blocks.vector_sink_c(1, 1024)
blocks_vector_sink2 = blocks.vector_sink_c(1, 1024)

##
# Connections
##

# Source -> Sink 1
tb.connect((blocks_vector_source, 0), (blocks_vector_sink1, 0))

# Source -> MPSK SNR Est -> Sink 2
tb.connect((blocks_vector_source, 0), (digital_mpsk_snr_est_cc, 0))
tb.connect((digital_mpsk_snr_est_cc, 0), (blocks_vector_sink2, 0))

tb.run()

print('Original input data:. {}'.format(data_in))
print('Data from source (SNR Est input): 
{}'.format(blocks_vector_sink1.data()))
print('Data from SNR Est:... 
{}'.format(blocks_vector_sink2.data()))

Re: Accurate GPIO Clock

[Martin Braun]

Your hardware might have some hardware timers and programmable interrupts.
Otherwise, what Jean-Michel said... Time to bring out the FPGAs!

M

On Sun, 1 Mar 2020, 05:10 jean-michel.fri...@femto-st.fr, <
jean-michel.fri...@femto-st.fr> wrote:

> welcome to the field of real time operating systems. There are a few
> thousand
> pages about the latencies introduced by the scheduler in non-real time OS,
> the
> first google hit being
> https://www.veterobot.org/2012/04/precise-pwms-with-gpio-using-xenomai.html
> A few microseconds is not too bad actually. Unless you shift the hard real
> time
> task to hardware (FPGA), I am not sure you can get any better.
>
> JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
>
> March 1, 2020 12:57 PM, "Till Hülder"  wrote:
>
> > Hello,
> >
> > i want to build a accurate GPIO Clock . I wrote a wait function :
> >
> > void sleepus(int n)
> > {
> > clock_t end=clock()+n*CLOCKS_PER_SEC/100;
> > while(clock() < end) continue;
> > }
> >
> > And wait until the value of the bits change .I recognized that the time
> of these wait time is not
> > constant. It differs by a few microseconds.
> >
> > Is there are another way to get a more accurate clock ?
> >
> > Best regards ,
> >
> > Till
>
>

Re: gr-uhd: Switching DSP frequency of *RX* over stream tags in TX (USRP Sink)

[Martin Braun]

Lukas,

There's a pull request being discussed right now on GitHub (on my phone, so
you'll have to find it yourself) that might do what you need.

Please head over there and join the conversation.

M

On Tue, 3 Mar 2020, 14:38 Lukas Haase,  wrote:

> Hi,
>
> I need to (synchronously) switch the DUC/DDC frequency at certain sample
> intervals.
>
> I previously used the message ports for that and created timed commands.
> This worked nicely for the RX (USRP Source) and with analog retuning.
> However, it turned out that this does not work for the transmitter with
> DUC-only retuning since the DUC/DDC does not have access to the MB clock.
> On the other hand, gr-uhd does not add the sample timing information
> needed. See our discussion in
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2020-March/061615.html
> .
>
> It was suggested to try stream tags and bounce this question on this
> mailing list.
>
> I now use stream tags with USRP Sink with the module below.
> Now the DSP retuning seems to work nicely but ONLY for TX.
> How can I re-tune RX as well?
>
> My approach with the message ports would have allowed me to do both.
> However, stream tags I can only use for "USRP Sink".
>
> Any suggestions are highly appreciated.
>
>
> Best,
> Lukas
>
>
>
>
>
>
>
> PS: This is the code which adds stream tags to retune DUC for USRP Sink:
>
> import numpy as np
> import pmt
> from gnuradio import gr
> from gnuradio import uhd
>
> class blk(gr.sync_block):
> def __init__(self, hop_interval_samples=1000, hop_frequencies=[ 0 1e6
> ]):
> gr.sync_block.__init__(
> self,
> name='Controller',
> in_sig=[np.complex64],
> out_sig=[np.complex64]
> )
> self.hop_frequencies = hop_frequencies
> self.hop_interval_samples = int(hop_interval_samples)
> # state
> self.next_hop = self.hop_interval_samples
> self.current_freq_idx = 0
>
> def work(self, input_items, output_items):
> output_items[0][:] = input_items[0]
>
> window_start = self.nitems_read(0)
> window_end = window_start + len(input_items[0])
>
> while(self.next_hop > window_start and self.next_hop < window_end):
> fcenter = self.hop_frequencies[self.current_freq_idx]
>
> key = pmt.intern("tx_command")
> value = pmt.make_dict()
> value = pmt.dict_add(value, pmt.to_pmt("lo_freq"),
> pmt.to_pmt(900e6))
> value = pmt.dict_add(value, pmt.to_pmt("dsp_freq"),
> pmt.to_pmt(-fcenter))
> self.add_item_tag(0, self.next_hop, key, value)
> self.next_hop = self.next_hop + self.hop_interval_samples
> self.current_freq_idx = (self.current_freq_idx + 1) %
> len(self.hop_frequencies)
>
> return len(output_items[0])
>
>
>

Project Call this Thursday, 10 AM Pacific, 19:00 CET

[Martin Braun]

Hi all,

our monthly project call is this Thursday, 10 AM Pacific Time, 19:00 CET, 1
PM Eastern Time.
Please head over to IRC or Slack for the coordinates. Like last time, we
intend to stream the call on Twitch, but you can still join the call
directly. Note we're still getting used to Twitch chat as yet another chat
medium, maybe eventually we'll figure out how to sync chats. Bear with us
as we catch up with 2020 technology (twitch.tv/gnuradio).

Cheers,
Martin

Re: Kurtosis estimator

[Martin Braun]

There's also kurtotic_equalizer_cc, if that's what you're looking for.

On Mon, Feb 10, 2020 at 2:11 AM Müller, Marcus (CEL) 
wrote:

> Maybe you can abuse the mpsk_snr_est for your purposes?
>
> On Sun, 2020-02-09 at 22:16 -0500, Marcus D. Leech wrote:
> > Has anyone implemented a Kurtosis estimator in GR?  Maybe a convenient
> OOT?
> >
> >
> >
>

Re: make error with gr3.8

[Martin Spears]

Marcus

I see where I went wrong. I am using ettus because I have an Ettus B210 SDR. as 
for setting up the rest I will upgrade to ubuntu 19.10. For my project I 
require gr3.8. I am noticing that with several dependencies for 3.7 based 
applications are no longer available. so upgrading everything to 3.8 is 
becoming my better choice. I want to see if I can combine a lot of the 
different applications from cgran into one menu driven front end, but with so 
many variations in dependency compatibility I am having difficulties.

I will upgrade to 19.10 and proceed from there

Martin

From: Müller, Marcus (CEL)
Sent: Friday, February 14, 2020 2:27 PM
To: Martin Spears; discuss-gnuradio@gnu.org
Subject: Re: make error with gr3.8

Hi Martin,

1. you're using a guide meant for Ubuntu 19.10, but you are running a
Ubuntu 18.04. So, yeah, that probably works, but really, not what you'd
normally do.
2. UNLESS you really need the Ettus version of UHD, and can't work with
the one supplied with your Ubuntu installation, building anything from
source is a bad idea.

**Do you REALLY need UHD 3.15 on Ubuntu 18.04**?
It'd be usually easier to just upgrade to Ubuntu 19.10. That has UHD
3.15 in its default installation sources, so no need to build UHD from
source, and you can install GNU Radio linking to that version of UHD
for that without having to compile anything from source.

Please do not compile software from source unless you really need to;
that's just complications without benefits. We're supplying current GNU
Radio packages for Ubuntu [1] that are way easier to install. But, as
said, you can only work with  a *really* old UHD if you stay on Ubuntu
18.04. Updating your Ubuntu is my recommendation. (Please uninstall all
things you've built from source before updating your Ubuntu: cd
uhd/build; sudo make uninstall)

If you can live with the old version of UHD that Ubuntu 18.04 ships
(e.g. if you have no USRP, or a USRP N210, or so), it's better to not
install UHD from source (i.e. uninstall what you've built from source),
and just follow [1], even on Ubuntu 18.04.

Regarding your problem: the fact that building breaks when linking gr-
blocks points to insufficient RAM. Back when I started with GNU Radio
about 10 years ago, that was a very common sight. Today, it's rare to
find a PC that has insufficient RAM and not enough Swap, but you seem
to be in the unlucky situation that you're running out of it.
This again stresses the unnecessary amount of complications building
from source brings.

Best regards,
Marcus

[1]
sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio

This automatically installs the version of UHD your Ubuntu brings (old
UHD 3.10 on Ubuntu 18.04, new Ubuntu 3.15 on Ubuntu 19.10), and
installs GNU Radio. Should take less than 3 Minutes.

Below, a bit of commentary:

On Fri, 2020-02-14 at 18:50 +, Martin Spears wrote:
> following this doc ---> 
> https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit#heading=h.ocyosag08tha
>
!!! > Ubuntu 19.04 != Ubuntu 18.04
>
> GNU Radio 3.8, Ettus UHD and Ubuntu 19.10

<---

> ~/source/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ../

Dangerous, you're installing into directories usually managed by your
Linux distro (i.e. Ubuntu). I do not recommend that.

> […]
> after make -j4
>
> […]
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_c_impl.cc.o
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_f_impl.cc.o
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_s_impl.cc.o
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_i_impl.cc.o
> [ 48%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_b_impl.cc.o
> [ 48%] Linking CXX shared library libgnuradio-blocks.so

This is the most RAM-intense step in the whole GNU Radio build.

> [ 48%] Built target gnuradio-blocks

... Hence my suspicion that you run out of RAM. It might be something
else. The fact that there's no compiler error printed, however,
suggests my suspicion is right. You can usually check using `dmesg`,
whether there's a OOM (out-of-memory) kill log entry somewhere.

> Makefile:140: recipe for target 'all' failed
> make: *** [all] Error 2

:(

make error with gr3.8

[Martin Spears]

good afternoon

following this doc ---> 
https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit#heading=h.ocyosag08tha
[https://lh6.googleusercontent.com/NpLjzlqjSnbxqXvWzufp6eebVI2b_nl3zh8nLiVVmDudyD_GsQaH2k4xM11qW3GJhoFav7JEew=w1200-h630-p]
GNU Radio 3.8, Ettus UHD and Ubuntu 
19.10
Install Ubuntu 19.10 Used the network installer on a USB stick, downloads on 
demand. Selected kubuntu-desktop and openssh-server Ignore encfs warning 
Install Ettus UHD Drivers For The B210 (and others) We roughly follow this 
guide, with some modifications for python 3 and the newer package names...
docs.google.com


everything goes perfectly until I do make -j4


~/source/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ../
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Build type set to Release.
--
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
--
-- Configuring testing-support support...
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
-- Found Git: /usr/bin/git
-- Extracting version information from git describe...
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_WARN_SIGN_COMPARE
-- Performing Test HAVE_WARN_SIGN_COMPARE - Success
-- Performing Test HAVE_WARN_ALL
-- Performing Test HAVE_WARN_ALL - Success
-- Performing Test HAVE_WARN_NO_UNINITIALIZED
-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
-- Compiler Version: cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall 
-Wno-uninitialized
-- ADDING PERF COUNTERS
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   regex
--   thread
--   unit_test_framework
--   chrono
--   atomic
-- PYTHON_EXECUTABLE not set - using default python3
-- Use -DPYTHON_EXECUTABLE=/path/to/python2 to build for python2.
-- Found PythonInterp: /usr/bin/python3.6 (found suitable version "3.6.9", 
minimum required is "3.6.5")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found suitable 
exact version "3.6.9")
-- Python checking for six - python 2 and 3 compatibility library - found
--
-- Checking for module SWIG
-- Found SWIG version 3.0.12.
-- Found SWIG: /usr/bin/swig3.0
--
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Dependency SIX_FOUND = TRUE
--   Enabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
--
-- Configuring VOLK support...
-- Build type set to Release.
-- Extracting version information from git describe...
--
-- Python checking for python >= 2.7
-- Python checking for python >= 2.7 - found
--
-- Python checking for mako >= 0.4.2
-- Python checking for mako >= 0.4.2 - found
--
-- Python checking for six - python 2 and 3 compatibility library
-- Python checking for six - python 2 and 3 compatibility library - found
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'orc-0.4 > 0.4.11'
--   Found orc-0.4 > 0.4.11, version 0.4.28
-- Found ORC: /usr/lib/x86_64-linux-gnu/liborc-0.4.so
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") found components:  
doxygen dot
-- QA Testing is enabled.
--   Modify us

Re: FBMC

[Martin Braun]

There's also this: https://github.com/kit-cel/gr-fbmc

But please, STOP SHOUTING. Thank you.

--M

On Sun, Feb 2, 2020 at 7:39 AM Madhan TJ 
wrote:

> CAN WE IMPLEMENT FBMC (filter bank multi carrier ) IN GNU RADIO ,
> IF YES,
> ANYONE PLEASE HELP ME
>