file 'cmake_out.txt'. - MLD
ps> < https://pastebin.com/ > . should be self-obvious.
On Sat, Jul 20, 2019, at 5:17 PM, Barry Duggan wrote:
> Hi Michael,
>
> I am attaching the file. I'm not familiar with the pastebin process.
>
> ---
> Barry Duggan
>
>
>
Hi Barry - The contents of the file "CMakeError.log" can be interesting, but
what we need to see first is the output of the "cmake" command itself. Maybe
drop it to pastebin (or equivalent) & post the link here? - MLD
On Sat, Jul 20, 2019, at 3:31 PM, Barry Duggan wrote:
> Today I tried to
Hi Sneha Vasan - That all sounds very interesting and so forth. I'd recommend
for the best chances of getting a reply from anyone regarding your specific
topic, that you include links to describe the work you're referencing for the
"Zadoff chu seq", whatever that is. Maybe there are some folks
I guess for your need so long as it works that's what matters, yes?
We'll work on fixing the issue you found anyway ... seems like it's legit &
undesirable LOL.
Good luck with your demo! - MLD
On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
> Well it worked after compiling old checkouts
Hmmm ... well the current UHD API for "set_auto_dc_offset" is "(bool, size_t)".
Looks like the generated Python from gr-ieee-80211 is "set_auto_dc_offset("",
0)", which isn't compatible with the current UHD API for this method.
Hmmm ... here's my best bet: gr-ieee802-11 uses the GR-provided GRC
I'm no expert on what to change here, but I'd guess there's another setting
that's the correct one for your specific OS & version, and that
"net.core.rmem_max" is the correct one for some other OS and/or version. Maybe
do a quick internet search for how to change the UDP buffer size on your OS
Hi Sumit - Just out of curiosity, have you tried the command the warning asks
you to execute?
{{{
sudo sysctl -w net.core.wmem_max=250
}}}
If not then please try it & see if that helps. - MLD
On Thu, Jun 27, 2019, at 12:27 PM, sumit kumar wrote:
> OS: Ubuntu 18.04
> Laptop: Dell Latitude
Hi Ramazan - The "tP" means that a timed transmit came too early. Say you want
to transmit exactly every second (via timed samples), but you provided UHD with
a burst of 2 seconds of data. You will have a new timed command before the
first burst is finished. Hence, UHD will print "tP". I'm
Hi Kevin - Thanks for the additional info. It seems that you've been doing some
serious work trying out various options; very good!
If you're using gr-uhd, then you can use the data tag "tx_freq": If it's at the
initial sample in the incoming buffer, then it indicates an immediate tune
request
Hi Ramazan - The "#f" generally indicates that you the Rx SNR isn't high enough
... nearly, but not quite. The sync symbols are being detected, but the header
itself can't be decoded cleanly (CRC fails).
In your "test" script, you don't have to worry so much about gains. When using
actual
Hi Ramazan - Hmmm ... I'm not coming up with anything greatly useful when using
a single OFDM block for Tx. Alternatively you could use a 2 channel PFB
synthesizer on Tx, with 2 separate OFDM Tx and feed them into the synthesizer.
On Rx use a PFB channelizer and take its 2 outputs to 2 separate
Hi Ramazan - My primary wondering about your specific OFDM setup is whether the
sync preambles are abiding by your carrier separation (256 carriers: -120:-1
for one Tx and 1:120 for the other). It certainly looks from the images that
the payload portion is working as you desire. Depending on
e already changed to the default
> parameters for now.
>
> El mié., 19 jun. 2019 a las 19:04, Michael Dickens
> () escribió:
>> __
>> Hi Jale -
>>
>> From translate.google.com
>> {{{
>> Best regards, apologies for not writing in English.
>> I'm doing a
Hi Jale - translate.google.com es su amigo ... siéntase libre de usarlo, pero
también tenga en cuenta en sus correos electrónicos que lo está usando.
Unos pocos pensamientos:
* obtener la señal Tx para estar más cerca de [-1, +1] ... [-0.6, +0.6] no es
escala completa, y la señal Tx será mucho
Hi Tushar - Is the error when compiling your "receiver.cpp", or when linking?
What is the complete error and command issued that generates this error? - MLD
On Sat, Jun 15, 2019, at 3:47 AM, tushar sharma wrote:
> /home/msi52/src/applications/newpackage/receiver.cpp:-1: error: undefined
>
Hi Kevin - Maybe use the tagged_stream or a PDU or vectorized data? There are
various ways to do what you want that will guarantee N samples that you could
then trigger a function call on. The better one to use really depends on what
you actually want to do once you have your N samples. - MLD
Hi Farid - I'll reply off list since this is pretty technical; we can summarize
back on list if appropriate. - MLD
On Sat, Jun 8, 2019, at 1:19 PM, farid mihoub wrote:
> Hello,
> I am trying to change the OFDM_tx_rx payload modulation by a custom 64kQAM,
> I implemented the block in several
Hi geraldfenkell -
On modern Ubuntu, you should be able to just issue "sudo apt install gnuradio"
and after some ado GNU Radio will be installed. See also <
https://wiki.gnuradio.org/index.php/InstallingGR#Linux >.
The HackRF software interface should be pretty easily installable on Ubuntu (or
Hi Sara - Can you give us something more to work with, for example a link to
the Youtube video and another to your code? I'm sure folks here can help, but
without more info the best we can offer is high-level suggestions on how to fix
sample rate differences. - MLD
On Thu, Jun 6, 2019, at
Hi Sneha - You need to take a look at the command being issued (from the
debugging traceback) in the file "/home/sneha/My_waveform/past
work/transmit.py", line 250. The code is clearly is not setting the filter
initialization parameters correctly! Without seeing your code I think nobody
here
Hi Jerry - The GNU Radio live SDR environment might do what you want: <
https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment >. Worth a
look, if nothing else. That's the only one that comes to my mind; maybe others
here have other ideas? - MLD
On Fri, May 31, 2019, at 11:19 AM,
Hi Tom - Glad to hear that reverting Boost did the trick! The list you note
doesn't really do anything these days; we might as well remove it, since we
then wouldn't need to pretend to maintain it. Hopefully next week I'll get a PR
in for GR to address the Boost 1.70.0 issue; I'm almost there,
Hi Tom - GR, UHD, and Volk will all build correctly using Boost 1.70.0 ...
except that Boost 1.70.0's cmake scripts are broken, and they are installed by
default. So, if you insist on using 1.70.0 then you'll want to find a creative
way around them -- my recommendation is to just not use 1.70.0
Hi Florian - My initial thoughts are: why 5e6 points (so many!), and how are
you accumulating that many points inside GR? In order to get that many points
accumulated, you'll need to set the I/O buffering on the FFT block to at least
that number of items, and probably more -- not impossible,
Hi Hans - GR Companion generates a Python script that you can run directly from
the commandline. You can set the name in the config box (upper left) in the GRC
flowgraph window. Guessing this is what you were looking for; if not, keep
asking! - MLD
On Fri, May 24, 2019, at 6:48 AM, Hans
Check out < https://github.com/igorauad/gr-osmosdr/tree/gr3.8 > and <
https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8 >. Both of these folks have
been trying to get gr-osmosdr working with GR3.8 fully; maybe one or both of
them have converted yml scipts? - MLD
On Thu, May 23, 2019, at 3:11
Hi farid mihoub - The GR-provided digital OFDM Tx -> Rx is prone to packet
losses as any real wireless system will be, but especially in the first packet
Tx'd for whatever reason. This OFDM is unsynchronized, so the Rx is continually
searching for the OFDM preambles, which with more noise
There should be a log4cpp library too. That's really odd that the headers
(typically "dev" pkg) are installed but the library isn't. Maybe try removing
the log4cpp pkg & install from source ... log4cpp is pretty straight forward to
build & install. - MLD
On Wed, May 22, 2019, at 11:49 AM, Hans
Hi mehtap - You can certainly do what you're asking for, but I'd wonder if
there isn't a better algorithm to do whatever it is you require. Here are my
thoughts based on personal experience implementing something like what you're
trying to do (and, thus, why I ask whether there might be a
My suggestion at this point is to take the -exact- "work" code from a block
that seems to be causing this memory issue and move it into a test program as a
subroutine. Then, from "main" create a replicated set of calls to this "work"
and see what happens. The goal here is to remove the GR part
FYI: After some work off-list, we think the issue is that Moses is using an
older release of GNU Radio (3.7.11.1). He's trying to get the version updated
to the most recent 3.7 release. When I execute his OOT scripts using a GR devel
version a little prior to the current release, I have no
Hi Dr Sayed - We can't help without knowing what the errors are you're getting.
It would also be useful to know which OS you're working on compiler, as
well as which step in the tutorial you're currently on. You might want to open
a Github issue on the matter and attach the following to it:
; I'm sorry! Sure, next time I will.
>> I'm building on Debian 9.8, and cmake is 3.7.2.
>> Thank you for reply.
>> Ivan
>> Il 04.04.2019 15:41 Michael Dickens ha scritto:
>>> Hi Ivan - PLEASE next time use < pastebin.com > or Google Drive or DropBox
>>&
When creating the debug build log, please remember to use "make VERBOSE=ON",
not just "make" ... the additional verbosity shows actual commands executed,
which is what we need to see to determine whether C++11 is being used or not. -
MLD
On Thu, Apr 4, 2019, at 9:42 AM, M
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> /usr/bin/cc:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> [lekha@Lekha-01:build]$
>
>
Hi Ivan - PLEASE next time use < pastebin.com > or Google Drive or DropBox or
whatever to hold your files & then post a link here; doing so requires less
bandwidth && is -much- easier for us to parse.
It looks like "Volk" didn't configure correctly ... what version of Debian are
you building
Hi Balaji - For this sort of debugging, please "reply to all" including the GR
list: more eyes might find your issue faster than just mine along!
I see you're on "Ubuntu 14.04.4 LTS". I'm thinking that's a little dated by now
... any way you can use a more recent Ubuntu version?
What does the
Hi Balaji - It would greatly help to see not just the build errors but also the
build commands being issued as well as the CMake configuration debug output ...
basically the whole configuration and build logs, along with the OS & its
version you're trying to do the build on. Please don't attach
Modern GR installs ... maybe it contains what this OOT block
needs? - MLD
On Thu, Mar 28, 2019, at 9:45 AM, Tawahaa Ahmed wrote:
> Hi
> I am trying to install a costas loop block in GNU Radio whose code was
> written in C++ by my professor back 2012. Now I have .cc .h .i and .xml files
> of
Use a polyphase filterbank. It's not runtime reconfigurable in GR, but if you
create the correct spacing with the max you'll ever need then you can always
optionally direct the output of some to a null sink. Hope this is useful! - MLD
On Tue, Mar 26, 2019, at 3:46 AM, on4...@telenet.be wrote:
>
gr-iio is in MacPorts ... and if you need something related to GR ping me & we
can work together to make it happen. - MLD
On Tue, Mar 12, 2019, at 3:05 PM, George Rykowski wrote:
> Hello,
>
> I have a need to install the FMComms2/3/4 source block in order to access my
> Zedboard/AD9361 SDR
I'll second what Marcus said: a little tidier GRC flowgraph would help.
That said, it looks like you're using nice and simple GR OFDM for Tx and then
you've expanded the GR OFDM Rx into its hier block equivalent form ... then
connected the output to PER and BER blocks and output those results
t am I wrong?
>
> https://imgur.com/a/sM9pk6h
>
>
> Regards,
>
> Ren Lie
>
>> Michael Dickens 於 2019年2月11日 下午10:44 寫道：>>
>> Hi Ren - See <
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2018-10/msg00086.html
>> >>> [[[
Hi Ren - See <
https://lists.gnu.org/archive/html/discuss-gnuradio/2018-10/msg00086.html >
[[[
The primary point of issue that I know of is that the default PyQt4 Qt4
rendering configuration is "raster", which for some reason results in the GUI
window flashing a lot & sometimes being
If Mako is installed, then maybe your shell environment’s PYTHONPATH isn’t set
correctly to find it?
Also looks like you need to set the various PYTHON CMake variables to have
consistency — meaning the library, includes, and executable that all point to
the same Python version. You can look up
Do you mean the "compiled" Python and GRC scripts? Look in
"~/.grc_gnuradio/" and find the correct .py and .xml or .yml files &
"rm" them. Not sure what else you might mean, so hopefully this
helps! - MLD
On Mon, Jan 21, 2019, at 3:14 PM, david vanhorn wrote:
> I've created some heir blocks, and
Are any of your hier blocks written in c++? If so, are you trying to intermix
in any of these such blocks both a flowgraph as well as ‘work’ of any kind?
Although one shouldn’t be able to create such a hier block — their intent is
just to encapsulate a flowgraph — the GR API allows one to
I -love- this idea, and agree that to the best of my knowledge such an import
feature does not exist anywhere; I'd love to see it as part of gr_modtool!
I cannot count how many times I've imported blocks from either GR or some
GR/OOT in order to tweak them -- to learn what makes the block tick
If I recall correctly, GR will build with Thrift 0.10.X, but doesn't
with any newer version. I'd guess there are API changes to Thrift that
will require GR's interface to be updated, but to the best of my
knowledge nobody has ever done this updating. This might be a good GSoC
project!? - MLD
On
Hi Rudolf - That's a very cool idea, but to the best of my knowledge GNU
Radio can't do stepping like you describe. I think it would be an -excellent-
feature to add; not sure how one would deal with the non-deterministic
nature of threads waking / sleeping / executing when using the thread-per-
I'll second what Jared wrote, and add the following: I'd like -any-
logging GR uses to provide protected printing, such that logged messages
do not interleave. [Obviously, unlogged messages might interleave /
intermix; all depends on the actual printing interface.] Trying to parse
such interleaved
Hi Albin - Thank you for all of your work here! I haven't tested it out, but
reading through it (and other PRs) you're really helping Volk along for NEON.
I'm not going to review this PR, just comment about PRs in general ... for now.
In general for GR / Volk PRs: Keep them targeted and simple;
Hi Prasoon - Welcome to the world of GNU Radio! A few questions to help
clarify your query:
What OS are you using? Guessing Windows but just checking.
How did you install GR? and its dependencies? ... from source, from an
archive, something else?
Cheers! - MLD
On Fri, Dec 28, 2018, at 6:13 AM,
Hi Prasoon - GNU radio 3.7.13.4 does not support Python 3. The
forthcoming GR 3.8 release will support Python 3. - MLD
On Mon, Dec 24, 2018, at 7:58 AM, Prasoon P wrote:
> Hi ,
> I have installed the latest windows version of GNU
> radio(3.7.13.4).Would like to know if Python 3 is supported as of
Unless your host computer's CPU is way underpowered, I'm with Derek
here: use polyphase filterbanks to channelize into 200 kHz bandwidth per
channel, then have a bank of FM demodulators, one per channel. Output to
files, or display, or whatever you need. - MLD
On Thu, Dec 6, 2018, at 12:17 PM,
-- just not update the "parent" variables; that's
done by the scheduler itself.
Glad this helped! - MLD
On Sat, Nov 10, 2018, at 4:21 PM, rear1019 wrote:
> On Fri, 09 Nov 2018 at 16:07:53 -0500, Michael Dickens wrote:
> > Depends on what you mean by "modify input buff
Depends on what you mean by "modify input buffers" ... You can read and write
to the buffers via the provided pointers. But the provided pointers do not
allow you to modify the actual gr::buffer in any way ... they just point to
where data is located. - MLD
On Fri, Nov 9, 2018, at 3:38 PM,
Apple's latest OSX, macOS Mojave 10.14, was officially released on September
24, 2018 -- just under a month ago. I've been running the public beta for a few
months on a separate partition to make sure GR / UHD / Volk work on this new
release ... and, the good news is that that they do!
There
Hi John_w_g - The error you're encountering indicates that the version of UHD
isn't compatible with the version of gr-uhd -- which is part of the overall GNU
Radio install. I'd guess that GNU Radio was installed, and then UHD was
updated. Generally the solution is to reinstall GNU Radio while
Hi Luis - Thank you for the feedback. Just to be clear: PyBOMBS worked
& you now have some usable version of GNU Radio installed? - MLD
On Tue, Oct 9, 2018, at 10:05 AM, Luis Felipe Albarracin Sanchez wrote:> Hello
all,
>
> I have tried to install GNuRadio, the way Michael explaines to me with
Hi Luis - The tag is probably "v3.7.14.3" (with the extra 'v' in
front); that's the way it looks like its listed on GitHub: <
https://github.com/gnuradio/gnuradio/tree/v3.7.13.4 >. Either way, this
script is outdated & PyBOMBS is a modern, kept-up-to-date way that's
the better alternative for
Hi Carles - Shortest answer: yes. Longer answer: 'next' was merged into
'master' ['next' is dead, long live 'next'!] ... 'master' now contains
the whole future of GR; there is not more 'maint' or 'next' (even if
they still exist, they are deprecated), just 'master'. - MLD
On Mon, Oct 8, 2018, at
OK; thanks Marcus. Good to know! Seems like maybe we should just remove
that section from the install guide altogether? That way folks will just
use PyBOMBS & we can just support that method. - MLD
On Mon, Oct 8, 2018, at 12:35 PM, Marcus D. Leech wrote:
> On 10/08/2018 12:11 PM, Michael
Yes, that's my belief based on reviewing the "build-gnuradio" script.
I think updating the install guide would be wise, assuming the flags
work as desired. Please give this a try & report back to the list.
Cheers! - MLD
On Mon, Oct 8, 2018, at 10:44 AM, Luis Felipe Albarracin Sanchez wrote:> Hello
Hi Luis - So the issue is that the installed version of Volk isn't API
compatible with that required by GR. I believe that GR is too old, and
you should use a more recent version. This script will try to build by
default from "3.7/Maint", which is obsolete though it might work. The
other "easy"
Hi Mike - Here's something to try that might provide some feedback
that's hidden by the standard "import" command:{{{
% cd /usr/local/lib64/python2.7/site-packages/gnuradio/uhd
% python2.7
>>> import importlib
>>> importlib.import_module('_uhd_swig')
}}}
and see what the last command returns.
Hi Sumit - Do you have your GR OOT in a public repo where we could
review all of the code & try the example ourselves? That's the most
reliable way to handle such potentially in-depth queries such as yours.
As a quick reply without knowing more specifics, are you using the
"hier_block2" for the
Hi Nick - From the description of your flowgraph, I think you'll have to write
your own custom block to handle the "consequent addition". In C/C++, you could
declare an array during instantiation that would be a class variable, once you
know the vector size of the addition (via an instantiation
Hi Cindy - It is true that the B200 can generally support 60 MSps
("60M") sustained throughput over USB3. That's -total combined-
throughput for all Rx and Tx streams. The example
"uhd_two_tone_loopback.grc" performs both Rx and Tx via the USRP, so if
you set the sample rate to 60M, then you're
Hi Cindy - Your query is a little off-topic, as this list is for GNU
Radio discussions, not Thrift discussions.
That said, as Thrift is related to building GNU Radio, and this seems
worth noting on this list every now and then: Hopefully you're following
"standard procedure" for these sorts of
OK; Ubuntu is usually pretty compatible with GNU Radio.
Now:
1) What computer are you running GNU Radio on [manufacturer & model]?
2) What does the following return: "gnuradio-config-info --enabled-
components"
On Fri, Sep 7, 2018, at 11:44 AM, Cindy Zhang wrote:
> Ubuntu18.4
Hi Cindy - Please remind us which OS you’re using. Also, what computer
too ... might be useful for figuring out what audio is available. - MLD
On Thu, Sep 6, 2018, at 7:18 PM, Cindy Zhang wrote:
> I couldn't hear the sound after gnu radio companion is installed from
> the source. However, I could
Thanks for the info, George. I guess since some USB controllers work
better or worse with UHD / USRP, these USB adapters will also be better
or worse. I bought my MBP touch 2017 USB-C to USB-3 adapters off of eBay
-- the least expensive they provided that didn't ship from China
(overseas etc) --
Hi George - I haven't seen this error yet, but of course I'm just one
Mac UHD / GR user; I'll try testing my B210 for longer. In the meantime,
how is UHD & GR installed? If MacPorts, have you tried the "uhd-devel"
port? Sometimes it has fixes to the release. - MLD
On Mon, Aug 27, 2018, at 3:46 PM,
Hi Volker - You're welcome & so glad that we got the issue figured out! Which
reminds me that I never put together a PR for the changes that would give
programmers a clue that a hier2 block isn't meant to do actual "work". I'll add
that to my queue & try to get it in before GRCon ... Cheers! -
At issue is a change in PyQt4. It fails importing in Python 2.7,
regardless of origin (MacPorts, 'Brew, Apple-provided, from source,
whatever). - MLD
On Tue, Aug 21, 2018, at 1:17 PM, George Rykowski wrote:
> Hi Adrian,
>
> I am using a MacBook Pro and assume am running the ‘standard’ Apple
Hi George - Yes this is a known issue that I'm working on; see also <
https://trac.macports.org/ticket/56993[1] >. On this ticket is provided
a way to revert back to the prior PyQt4 release that doesn't have this
issue. We'll get a fix in place as soon as we can. - MLD
On Tue, Aug 21, 2018, at
Hi Savino - The short answer is: no. That said, you -can- give hints to
the scheduler -- the part of GNU Radio runtime that determines how many
items are provided to "work" for any given block. For example, you can
set an I/O signature such that the item size is your desired vector
length (in
The GNU Radio Wiki is your friend. If you've already installed GNU Radio
via 'apt', then you can just following the basic GR install here: <
https://wiki.gnuradio.org/index.php/BuildGuide#III._Start_the_build_process
>. Hope this helps! - MLDOn Fri, Aug 3, 2018, at 10:59 AM, Linda20071 wrote:
> My
Could be that the gnuradio reinstall didn't get all of the files in
place. Could be that your modifications to the gr-howto do something
strange for SWIG purposes. Could be something entirely unexpected.
Really hard to know without source code, a logfile, and info about your
host computer: OS
Great; you're welcome! Thanks for reporting back your success, Edwin,
and good luck with your GR work/programming. - MLD
On Wed, Aug 1, 2018, at 5:45 PM, Edwin Li wrote:
> Hi Michael,
>
> Since you said you did not have the problem I mentioned, I guess the
> change is not written into the
suggestion.> I added
> chaotic_prefix_generator_template.grc[1] to my repository. I
> use it to test.> Inside there is a vector source. I tried to set the data as
> the output
> of Logistic_map(). You will see an error: 'chaotic_prefix_bc_sptr'
> object has no attribute
Hi Edwin - Is there a test or example in your repo that's failing? I have built
it successfully; "make test" fails for a couple reasons but not for the
specific issue you're having. I don't see any specific use of the method you're
having issues with; hence my query. - MLD
On Wed, Aug 1, 2018,
Hi Edwin - Your C++ coding looks fine (to me).
If you added this method -after- building SWIG for the first time, you
generally need to "clean" the SWIG build (or, just "make clean" in the
top-level build directory; maybe this is the "clean trick" you
mention?), since oftentimes CMake doesn't
Hi Jebreel - From the import error, it looks like either you're not
linking against gr-digital library, or you're referencing some function
or method or variables that doesn't exist in (isn't being exported from)
the gr-digital library. Did you verify in your OOT's top-level
CMakeLists.txt that
On Fri, Jul 27, 2018, at 6:23 AM, Müller, Marcus (CEL) wrote:
> Awesome! Folks, this is the way I always hoped the community works.
> Cheers to you!
LOL thanks but maybe premature?!
This issue is somewhat more complicated than I thought, mostly because I'm
still learning how to actually use a
Hi Linda20071 - The error shows that either your Python code isn't
passed a 'bool' type, or the SWIG interface isn't providing the correct
API for Python. Without seeing your code it's pretty difficult to tell.
So if you have a public repo please post it along with your query. There
are plenty of
mp;
tag you on it, Volker, for testing. Cheers! - MLD
On Sat, Jul 21, 2018, at 12:41 PM, Michael Dickens wrote:
> Hi Volker - OK thanks for the update. After rechecking my OOT example, I
> agree that this issue requires inheritance from a hier2_block class.
> Maybe that will help track down
Hi Volker - OK thanks for the update. After rechecking my OOT example, I agree
that this issue requires inheritance from a hier2_block class. Maybe that will
help track down the issue... ? I know that the code for doing connections is
pretty gnarly, so who knows? Anyway, worth poking at ... and
Hi Volker - Just to clarify:
You've added an -optional- input async message port to a block that currently
does just streaming. If you -do not- try to connect to this new port, then
everything works as desired & as before. If you -do- try to connect to the port
then you get the runtime error
Hi Usama - I'm confident that if you searched back through the GR
discussion archives, you'd find discussions about this topic: <
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=header_payload_demux0=Search%21=discuss-gnuradio=20=normal=score
>.
The "Parser returned #f" means that the OFDM
FYI that for MacPorts users, I just updated the gnuradio-next port to "51c234b2
(20180626)" ... not quite the latest commit, but nearly. I'll update again next
week to whatever the latest commit is at the time & continue to do so roughly
weekly as changes are committed.
There are a bunch of
Hi Ale - Unfortunately the files & images don't really provide useful info on
the issue you're encountering. Much better would be to attach the output of the
"cmake" command, e.g., "cmake .. > cmake_out.txt 2>&1", including whatever
cmake arguments you issue. Please note the actual cmake
Hi Luis - You'll note in the install instructions <
https://wiki.gnuradio.org/index.php/OutOfTreeModules#Using_CMake > that
you don't issue the "cmake" command from directly in the top-level OOT
directory. Instead you do the following from the top-level OOT
directory:{{{
mkdir build
cd build
cmake
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Michael Dickens, Mac OS X Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ett
Is there error in your GR OOT module, or when you're building GR itself?
If the former, then you'll want to include the following in the top-
level CMakeLists.txt somewhere near the top:{{{
SET(CMAKE_CXX_STANDARD 11)
}}}
If the latter, then contact me off-list & I'll help you get gr-dev
Hi Cindy - Which operating system are you working on? - MLD
On Thu, May 17, 2018, at 11:34 AM, Cindy Zhang wrote:
> gnuradio - $ cmake -DCMAKE_INSTALL_PREFIX= ../ command - Stack
> Overflow body,.top-bar{margin-top:1.9em}> I am following the
> example square_ff at
>
Hi Vipin - Easiest way is to just install gnuradio-devel:
{{{
sudo port -f deactivate gnuradio
sudo port install gnuradio-devel
}}}
Assuming that the 2nd command works, then in your OOT when you "make"
for the first time since this GR change CMake will redo configuration &
you should be good to
Yes what you found is the case: any project when using CppUnit 1.14
requires C++11. Are you trying to build the "gnuradio" port? If so,
instead try the "gnuradio-devel", as it contains fixes for this issue
&& I don't recall if the release does yet. I'll look into it on my
end. - MLDOn Wed, May 16,
Hi Vipin - I'll second what Sebastian writes ... because ... I moved
CppUnit from a forced requirement to just a testing requirement a bit
ago. Which means it is not installed by default unless testing is
enabled ... which is not the case by default. So you currently have to
install it separately.
101 - 200 of 1164 matches
Mail list logo
