Hey everyone, I saw an e-mail exchange a while back regarding an issue
similar to the one I'm facing right now. Here's the link to the archive:
https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00481.html.
Unfortunately, there were no further replies to that thread but I did see
that
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. There
I reported this problem previously (July 2018 timeframe) and I am still
wrestling with it.
Running Fedora 28 on Dell laptop. Prior to updating laptop to Fed 28,
gnuradio worked fine.
I ran dnf remove uhd (which removed gnu radio as well) and then
reinstalled them using dnf install
And just like
Hi folks,
we do not often get the chance to break API; releases like 3.8 are such
opportunities.
Not so long ago, we (I think it was Stefan, in fact) replaced a bad
random generator with boost::mt19937 (a Mersenne Twister implementation
with both known sufficient statistical properties and known
Hi collection of information theorists with the highest entropy known
to SDRkind,
just a warning: I'm opening a PR that'll change the random generation
for the random interleaver. That means you can't decode data encoded
with the old code using the new code.
The reason is simple: the old code use