Hi Alejandro,
um, this is the mailing list you are looking for.
Ask this here; don't ask to ask in private :)
Best regards,
Marcus
On Sat, 2018-05-05 at 14:44 +0200, ALEJANDRO RAMIRO MUNOZ wrote:
> Hey all!
>
> Someone has experience working with this block in GNU Radio?
> I'd like to ask
Hi Ali,
just like the console will tell you, 25 kS/s is simply impossible with
an X310; instead, the minimum possible rate was used.
You should probably just configure your X310 to get you e.g. 500 kS/s,
and then resample in digital domain. If you're hesitant to design your
own decimating
Hi Murray,
> background color … transparent
I wasn't aware of that, but I'd call it a bug in Kubuntu (or, the way
Kubuntu configures their KDE to configure GTK to show tooltips).
What do you mean with "toggle visibility button"?
Cheers,
Marcus
On Mon, 2018-05-14 at 12:56 +0100, Murray
Hello Yeo Jin Kuang Alvin,
that's probably because your Spectrum Analyzer has a sweep rate, and
you get something like a reduced probability of seeing the sweep at
all.
I think it's very likely you should read a tutorial on what a spectrum
analyzer is, and what the various settings on it mean,
Well, I think you and Ron basically recommend the same functionality,
but Ron is hesitant to reinvent the wheel:
For local transport, UDP between your flowgraph and VLC works just
fine. Also fine would be simply using a named pipe (FIFO, as in `man
mkfifo`, if you're on something vaguely
Hi Brad,
changing the pythonpath shouldn't change the path in which CMake looks
for include files and libraries, at all.
Can you check whether your /usr/include has some zmq.hpp ?
Debian just throws that C++ wrapper for C zeromq into the zeromq-devel
package (without any documentation which
Hi Brad,
to jump in and clarify what Phil probably could've said in a lot fewer
words, but for didn't ;) :
Philip is an OpenEmbedded Guru of ancient fame. Basically, OpenEmbedded
is a system to build your own linux distros, by defining what
compilers, libraries, and tools to include in the base
Dear Inkyu,
there's no guarantee that the phases of both TX are exactly identical.
In fact, you should expect an unknown offset.
Also, you'll notice that your two antennas are at two different
positions in the room. You're accidentally building a beamforming
system! So, these nulls will not be
Hi Mehtap
On Fri, 2018-04-27 at 15:57 +0300, mehtap özkan wrote:
> Based on your calculations, I have decided to get a LIMESDR-PCIe.
> The sampling rate will be 122,88 MSPS which will give 61.44 MHz I and 61.44
> MHz Q.
I think it is the other way around: The Sampling rates are 61.44 MHz on
I
Dear Prabhat,
the B210 doesn't support 120 dB of gain.
Ask uhd_uspr_probe about minimum and maximum gain, or simply don't use
"absolute gain" setting in the USRP block, but "relative" gain, and use
0 for minimum, and 1 for maximum gain.
Risking that I repeat what I said before: RSSI is a
better way for burst
> transmission?
>
> Does anyone know this?
>
> Thanks in advanced!
>
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu]
> Sent: Thursday, 10 May 2018 5:06 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio
Hi!
your receiver low pass filter is incorrectly parameterized, probably
(sampling rate isn't 32 MS/s). And so is the rest of your flow graph –
your USRP is using a sampling rate of 2 MS/s, but you act as if it's
running at 32 MS/s. Start with 2 MS/s and make it work with that – then
later scale
it every few
> seconds?
>
> Thank you in advanced!
>
> -Original Message-----
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu]
> Sent: Thursday, 10 May 2018 5:34 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Tx B
No, 15 kHz is not "very minimum", it's impossible. Your console will
contain information that the UHD picked a different, higher, sampling
rate.
Your "I picked 15 kS/s to get a clear audio file" doesn't make much
sense; this is not how digital communications work!
I'm afraid you'll have to be
Hi Brad!
Thanks for sharing your success! It's always valuable to hear what
works for people :)
Best regards,
Marcus
On Sat, 2018-05-12 at 09:01 -0400, Brad Hein wrote:
> Just a follow up to some of the issues I reported recently with the
> Socket PDU blocks.. Switching to ZeroMQ (ZMQ) based
k! Mr muller
> To be honest am new for this software but I tried my best to figure
> out this problem.if you can please send me the exact block
>
>
>
> On Sat, 12 May 2018, 12:11 Müller, Marcus (CEL), <muel...@kit.edu>
> wrote:
> > No, 15 kHz is not "very minimum&q
k to
> itself to the RX port. As a result, I have to send a pulse and stop
> for a moment while it is receiving and then transmit again.
>
> Thank you in advanced!
>
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu]
> Sent: Thursday, 10 May
Hi Marcus,
> Use digipots to set the R values, and use a fixed value for C, or
perhaps selectable C as well (probably only two or three values).
friends of mine tried to do variable attenuation for powerline
communication frontends using digipots, and: these can be very
frequency-selective, even
No.
Best regards,
Marcus
On Thu, 2018-05-24 at 09:22 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
>
> Am I able to change the value of the delay block automatically in GRC over
> time when the flowgraph is running?
>
> Thank you in advanced!
>
Hi!
Don't use random.h's `random()` in GNU Radio. It's not thread-safe and
mustn't be used in multithreaded applications, and GNU Radio is
inherently multithreaded.
> So I tried to use srand(time(0))
That is **explicitly** a way to get a different sequence every time, so
this is very
them)?
Best regards,
Marcus
On Thu, 2018-05-24 at 10:00 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
>
> Is there a way to implement control of delays over time? Type out own code?
>
> Thank you in advanced!
>
> -Original Message-
> From: Müller, Marcus (CEL)
Hi John,
GNU Radio versioning is totally independent from UHD versioning, and
that's what's defining the compatibility with the FPGA image.
So, you need to install the UHD that fits your FPGA image (or use an
FPGA image that fits your installed UHD).
Best regards,
Marcus
On Thu, 2018-05-24 at
Hi John,
On Fri, 2018-05-25 at 06:39 -0600, John Medrano wrote:
> Thank you for the response.
>
> The issue that we have is that the latest UHD RFNOC version is not compatible
> with latest version of GNU Radio.
That's simply not true. UHD, to GNU Radio, is just a library.
>
> So I must
Hi John,
no need to apologize; we're all learners of some kind!
So, let me annotate your terminology below, so that we are on the same
page :)
On Fri, 2018-05-25 at 07:20 -0600, John Medrano wrote:
> Hello,
>
> I apologize for my terminology, it is causing some confusion.
>
> If you download
a for 5 secs which means I need to calculate the slant
> range over time. In order for me to get the propagation delay 2R/c. As a
> result, I need to change the delays for 5 secs.
>
> Thank you in advanced!
>
> -Original Message-----
> From: Müller, Marcus (CEL)
means I need to calculate the slant
> range over time. In order for me to get the propagation delay 2R/c. As a
> result, I need to change the delays for 5 secs.
>
> Thank you in advanced!
>
> -Original Message-----
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu]
>
Hi Linda,
Why should the Ettus website contain GNU Radio examples?
Also, why should this specific example exist?
Anyway, all you need is the "vector insert" block.
Best regards,
Marcus
On Fri, 2018-05-25 at 21:05 -0400, Linda20071 wrote:
> There is an example on ettus website that uses a single
If possible, please track progress on
https://github.com/gnuradio/volk/issues/188
On Sat, 2018-06-09 at 15:30 +, Müller, Marcus (CEL) wrote:
> Hi Paul,
>
> hm, OK, considering the actual conversion is done in VOLK, can you
> tell
> us
>
> * whether ~/.volk/volk_config e
https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32f_s3
> 2f_convert_8i.h#L200
>
> I had not really looked into that before because having run the
> volk_profile seemed to make no difference.
>
> Regards, Paul Boven.
>
> On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wr
optimizations your machine
> happens to have available, so that's also quite bad.
>
> Possibly there is also an optimization opportunity of never using
> 'generic' even at the block edge when acceleration is available by
> choosing the right size of blocks, but that's probably a small
_sse2
>
> Regards, Paul Boven.
>
> On 06/09/2018 05:30 PM, Müller, Marcus (CEL) wrote:
> > Hi Paul,
> >
> > hm, OK, considering the actual conversion is done in VOLK, can you
> > tell
> > us
> >
> > * whether ~/.volk/volk_config exists (and if s
Hello Eugene,
Thanks! I.. uh. wat?! There's a lot of interesting things in the code
of that block. d_8 being a constant with value 8 not being the largest
surprise; I see that this should be a derivative-approximating filter,
right, which inherently needs to have high-pass characteristics, and
Hi Paul,
hm, OK, considering the actual conversion is done in VOLK, can you tell
us
* whether ~/.volk/volk_config exists (and if so, its contents regarding
volk_32f_s32f_convert_8i )
* what the output of `volk-config-info --machine` is?
Thanks,
Marcus
On Sat, 2018-06-09 at 17:13 +0200, Paul
Oh wait, it gets better: while the float->int16 does indeed use rintf,
float->int32 doesn't… now we don't have a majority situation pro-
rounding anymore… argh.
On Sat, 2018-06-09 at 19:24 +, Müller, Marcus (CEL) wrote:
> Hi Paul,
>
> I agree with everything you say. Float
As Marcus said, 3.0.4 is somewhere between "ancient" and "archaic". Is
there a specific reason you consider that version?
On Tue, 2018-06-12 at 03:01 -0400, Marcus D. Leech wrote:
> On 06/12/2018 02:49 AM, Luis Felipe Albarracin Sanchez wrote:
> > Hello to all,
> >
> > i just did, what the
that one
> was one of the closest to the top.
>
> I will checkout the others.
>
> Is there any stable Version you would recommend?
>
> Kind regards.
>
> On Tue, Jun 12, 2018 at 10:06 AM, Müller, Marcus (CEL) du> wrote:
> > As Marcus said, 3.0.
Hi Jaco,
this is really a reasonable thing to want, but to be honest, GNU
Radio's visualizations are very much oriented along the streaming
nature of GNU Radio – and scrollback doesn't fit all to well.
I recommend https://github.com/miek/inspectrum , which is relatively
new, and relatively cool
Hi Tom,
got a bit of worries about this one:
On Fri, 2018-06-08 at 09:17 -0700, Tom McDermott wrote:
> modified: volk (new commits)
Which basically means that the Volk submodule isn't in the state the
main module's branch expects it to be, and that's exactly what's going
wrong there.
Sorry, I replied with an empty mail just now, confusion of keys. I
added more coffee to solve the issue with the author.
Steve,
assuming your set_mag() is in C++: if you have control over the
set_mag() method, write it so that it accepts vectors, for example.
Then, you can just use Python lists
On Thu, 2018-06-07 at 08:45 +0300, shachar J. brown wrote:
> Hi Everyone,
>
> I'm sure someone has encountered one of the following questions. Please help
> me figure this out:
> At certain points in my flow graph I have different scenarios, each demanding
> a set of different parameters. I now
Hi Tal,
3.7 is the maint-3.7 branch, master works towards 3.8, and a milestone
of that will be when next is merged into it. You can expect a 3.8
release when next is merged, and all the serious kinks that came with
it are contained enough for us to risk a release :)
Best regards,
Marcus
On Fri,
Hi Luis,
I hope you're using an attenuator with a cable or antennas in your
feedback, not to risk damaging your receiver!
What you need to do to get a similar constellation is the whole dance
that is taught in your average digital communication basics lecture:
Synchronization in time, and phase
Hi Luis,
On Thu, 2018-06-14 at 12:29 +0200, Luis Felipe Albarracin Sanchez
wrote:
> Hello Marcus,
>
> Thanks for the response,
>
> I am not using an attenuator, because i font have one , i am only with my
> cable, but i have meassured the Power before connecting to the RX in my USRP,
> so it
gt;
> Kind regards.
>
> On Thu, Jun 14, 2018 at 12:46 PM, Müller, Marcus (CEL)
> wrote:
> > Hi Luis,
> > On Thu, 2018-06-14 at 12:29 +0200, Luis Felipe Albarracin Sanchez
> > wrote:
> > > Hello Marcus,
> > >
> > > Thanks for the response,
&g
Dear Maria,
no, GNU Radio is a pure software framework; it doesn't directly talk to
any hardware, but has a gr-uhd component which uses UHD, Ettus' own
driver, to talk to your USRP.
Anyway, you can't simply reprogram the FPGA to give you higher clock
rates. 61.44 MHz is physically the most that
Hi Amrit,
Well, usrp_spectrum_sense is a hopping observer, and GSM is a hopping
system: your probability of intercept is rather low.
Your probability of intercept is in fact, really zero, if your phone
doesn't do GSM (2G), but uses 3G (UMTS) or 4G (LTE): these use other
frequencies altogether.
chuk wrote:
> I need to rebuild the frequency, do fft and then transfer the whole array
> from 70 to 6GHz to the host machine. I do not quite imagine how you can do
> this with standard blocks in gnuradio.
>
>
> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
> > Dear I
Dear Ivan,
you don't pass data to a block yourself.
You write a block that does a clearly-limited signal processing job,
and use GNU Radio to connect that to other blocks:
https://tutorials.gnuradio.org
In your case, instantiating a USRP source in your block makes
absolutely no sense, for
and then transfer the whole
> > > > > array from 70 to 6GHz to the host machine. I do not quite imagine how
> > > > > you can do this with standard blocks in gnuradio.
> > > > >
> > > > >
> > > > > 2018-06-1
Hello Jason and Derek!
What Derek wrote very much sums up what is going on in my head; I
should probably write that down.
So, knowing fully this is everything but an official announcement, 3.8
will need C++11. Just wanted to confirm that.
On the way to 3.8, we'll thus need to "weed out" the
Hello Dewan!
On Mon, 2018-05-28 at 16:09 -0400, Dewan Arif wrote:
> 1. In FEC_extended_encoder, What is the Encoder Objective ?? How to put the
> value in Encoder Objective ??
Small typo: it's "encoder object", not "objective" :)
What you want there is to put the ID of a "Encoder Definition"
Hi Linda,
for debugging *programmatic* things (i.e. crashes, program doesn't
calculate what I think it should), you'd use a debugger:
https://wiki.gnuradio.org/index.php/TutorialsDebugging
https://wiki.gnuradio.org/index.php/TutorialsGDB
for debugging *algorithmic* things (i.e. I don't know why
e breaks in the continuous signal)
>
> Regards.
>
> On 29 May 2018 at 23:19, Müller, Marcus (CEL)
> wrote:
> > Hi Carlo,
> >
> > if you're using GNU Radio's rational resampler, you're already
> > using
> > that method!
> >
> > Really, at yo
Hi Carlo, hi Linda:
as Linda said,the RR approach works really well and is numerically
relatively stable until you hit really ugly ratios (after, of course,
cancelling the fraction as far as possible).
But what is "ugly" here?
In theory, rational resampling by M/N (note: M,N coprime!) would
ares.
> Regards.
>
> On 29 May 2018 at 19:34, Müller, Marcus (CEL) wrote:
> > Hi Carlo, hi Linda:
> >
> > as Linda said,the RR approach works really well and is numerically
> > relatively stable until you hit really ugly ratios (after, of course,
> > cancelling the fra
Dear best community of an SDR project known to mankind!
It took me longer than I'd like to admit, but we've finally come to a
release of GNU Radio's maintenance branch 3.7. I'm very thankful for
the contributors we've had this time, especially because the amount of
first-time code contributions
Hi Carlo,
not quite sure I get what you mean with "bandlimiting"? What with
"transposing"?
Regarding "padding": do you mean interpolation? Again, you'd use a
resampler, and in your case, the rational resampler with decimation=1,
interpolation = 48 would do the trick.
Best regards,
Marcus
On
Hello!
If you've modified it, I guess you already have the GNU Radio source
code.
So, you must make sure that you're using the GNU Radio that you have
built from source:
https://www.gnuradio.org/doc/doxygen/build_guide.html
Simply build your modified GNU Radio and install it :)
How that
I messed up, and v3.7.13.1 was tagged off-branch, whereas I pushed a
commit that incorrectly changed the version number to the maint-3.7
branch.
I ask you to not use 3.7.13.1 but 3.7.13.2. Thank you!
Best regards,
Marcus
On Thu, 2018-05-31 at 19:30 +, Müller, Marcus (CEL) wrote:
> Dear b
Then the answer is really, very likely, to use a container of sorts.
Docker seems to be the choice for that these days.
Best regards,
Marcus
On Tue, 2018-06-05 at 08:08 -0700, Jason Matusiak wrote:
> I wasn't worried about my gnuradio builds as much as my system as a whole
> when I was mucking
Hi Jason,
to not hose my system every day, I simply work in prefixes. Basically,
find my shell's RC file below. With options like `-
DCMAKE_INSTALL_PREFIX=$GRPREFIX` (for CMake) or `export`ing
PREFIX=$GRPREFIX (before running ./configure scripts) one can set the
installation directory so that
The whole purpose of using PyBOMBS is to work in PREFIXes, so no need
to do that – PyBOMBS does that automatically.
On Tue, 2018-06-05 at 10:38 -0400, Dave NotTelling wrote:
> Check out
> https://github.com/gnuradio/pybombs#configuring-a-prefix-environment-eg-for-cross-compiling.
> You might be
Hello Ji-yeon,
I think the best way to help you forward here is point out that the
description of the block is very close to actually being an
algorithmical description of what you need to do!
So, maybe you're just missing the tools to build your own blocks and
use the existing blocks; in that
Hi!
Linda, you **must not** use rand(). It's not thread-safe, and GNU Radio
is inherently multithreaded. For reference, I've pointed that out in a
recent mail exchange [-1]; the recommendation was the same as Dave's:
use C++11's std:: random generators; that email even has a small code
example :)
Also, while you're at it: If you have parameters (like potentially your
scaling) that you'd like to update externally, for example from a
different block, it's not that bad an idea to add a "command" message
port, with a message handler that does the setting.
I mention this because messages are
Hi Alvin,
you've already gotten plenty of info on this list from where over- and
underflows come.
We've really addressed all this before[1,2,3,4,5,6,7,8,9,10,11,12,etc],
and you've gotten sufficient recommendations. Please do avoid to spam
the mailing list with redundant questions.
Let me
Hi!
So, I'm really not sure how to help you here: I have to expect you to
be able to call a function in C++ to give you value. The level of
understanding necessary to transfer my example to replace your usage of
rand() in your code isn't really high.
Maybe you'd want to read a good C++
Hi Carlo!
On Wed, 2018-05-30 at 23:04 +1000, Carlo Manfredini wrote:
> My hardware arrangement is fairly demanding, I think ?
> I wish to resample between a Red Pitaya connected via ethernet running at
> 100kSps and a USB-audio unit (UCA-202) running at 48kSps.
That's not "much signal to
Hi Linda,
Do you mean "sending 0 in between" or do you mean "switch transmission
on some SDR device on and off"?
First case: multiply with a (threshold(sawtooth from signal source))
Second case: see the gr-uhd examples on how to do bursty transmissions,
if a USRP is what we're talking about!
The history is really just the same ring-alike buffer. Setting the
history really does nothing but tell the scheduler that although you
consumed N samples, it may only declare (N-history) as "done with", and
will present you the last (history) samples as beginning of your new
input item buffer on
Hi Ali,
I went into the GRC file (in gnuradio/gr-filter/grc) and looked that
up: It calls block::declare_sample_delay
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#acad5d6e62ea
885cb77d19f72451581c2
(this documentation isn't great and doesn't really say what
declare_sample_delay
Hello greatest SDR community to roam the earth,
as we're progressing towards a merge of the next branch into master,
which will actually bring us new features and challenges like Python3,
QT5, YAML instead of XML in GRC and many, many specific improvements,
I'll announce that we're switching over
Hi Jim,
Can you share the full console output of your flow graph?
Also note that the most "fragile" dependency of GNU Radio right now is
Thrift, if you can check whether your CMake output says that Thrift was
used, it would be helpful. Thrift is the RPC middleware that ctrlport
uses to expose
Dear Priyanka,
um, the whole point of that article is that you need to give the third
parameter, the kind of date (Matlab docs erroneously call this
precision, it's really the data type):
fopen(your_filename_here, 'rb', 'float')
The fact that you're even asking about quotes around the file name
t helps us get forward,
Best regards,
Marcus
On Sat, 2018-06-23 at 16:50 -0700, Jim Larsen wrote:
> Marcus,
>
> Thank you for your reply.
>
> > On Jun 23, 2018, at 4:00 AM, Müller, Marcus (CEL)
> > wrote:
> >
> > Can you share the full console output of your f
Hi Trueblues,
the packet encoder and decoder blocks are known to be broken – that's
why they are in the "deprecated" category! It'll be gone with the next
minor release of GNU Radio, even. (same will happen to WX GUI, so
switch to Qt now!)
So, please don't use them; I don't expect them to work.
Hi Tom!
Hm, no, I wouldn't be aware of any limitations, and even if such exist,
things shouldn't die with a std::bad_alloc!
Ok, so I'm wondering how we can move forward with this. Let us try
this:
* Can you share a proof of failure flow graph with us? That way,
everyone's definitely talking
gsym`
I was wrong, at that point it's totally OK to complain about missing
symbol. Just say it's OK to set the breakpoint on future library load.
On Tue, 2018-06-26 at 10:47 +, Müller, Marcus (CEL) wrote:
> Hi Tom!
>
> Hm, no, I wouldn't be aware of any limitations, and even if such
>
Hi LJ Eads,
I'm a bit confused: What has your sound card to do with GNU Radio, or
the USRP? And how is your sound card comparable to a GPU?
GNU Radio runs on CPUs.
Best regards,
Marcus
On Wed, 2018-05-02 at 13:23 +, Eads, LJ D. wrote:
> Hello,
> I just setup a USRP X310 that I plan on
Hi Geoff,
might be a good idea to ask this on usrp-us...@lists.ettus.com, because
these CICs are not part of GNU Radio :)
Anyway: There's nothing much to interpret about CIC responses; they are
well-known. The length (and potentially order, as in exponent) of the
CIC used depends on your
That certainly works, too!
If you're using C++11, you can also
static std::vector get_input_sizes(){
std::vector input_sizes = {
sizeof(gr_complex),
sizeof(gr_complex),
sizeof(gr_complex),
sizeof(gr_complex),
sizeof(float)
};
return
Hi Jordan,
nice! But: what exactly do you need help with? What's that source?
Best regards,
Marcus
On Tue, 2018-04-10 at 10:53 -0400, Jordan Nnabugwu wrote:
>
> I want to be able to create a block that will sent a message to change my
> source once it senses a certain amount of power coming
Hi Snehasish,
since this is defitnitely not your complete code, there's nothing we
can do to help you :(
Best regards,
Marcus
On Mon, 2018-04-02 at 19:13 +, Snehasish Kar wrote:
> Hello
>
> I was trying to generate a flow graph using file source descriptor and a file
> sink. But after
Hi Marvin,
sorry to have been so late to react:
Don't use the Packet Decoder. It has a bug and doesn't work reliably!
That's why it's in the "deprecated" category.
Best regards,
Marcus
On Thu, 2018-04-05 at 19:28 +, Marvin Biedermann wrote:
> Hello,
>
> I am new to Gnuradio and I have a
Hi Jacob,
sorry, I wasn't around to react to this:
Wow! Thank you for sharing this.
Would this be functionality that you'd like to see upstreamed into
mainline GNU Radio? That might ease future usage for you, as then "GNU
Radio" as a whole project would notice if something we do breaks the
unit
Dear Kailash,
there's very much that can go wrong for over-the-air transmissions, and
you'll simply have to apply your digital wireless communications
knowledge to narrow this down.
Furthermore, the Packet encoder and decoder blocks are *heavily*
deprecated, and you mustn't use them. Use the
f your GDB knows the python
debug symbols, and maybe even has the scripting in place to interleave
Python state with the back trace (since we then would even see which
Python line was being executed, as well as the state of the python
interpreter).
Best regards,
Marcus
On Mon, 2018-04-30 at 17:1
Huh, no, barring great undiscovered bugs, the delay involved shouldn't
have anything to do with the data, and the error pretty certainly has
something to do with invalid input data.
Are you sure the data is always the same?
Best regards,
Marcus
On Thu, 2018-04-12 at 11:03 -0400, Brad Hein wrote:
Hi Brad,
Sorry that I missed your mail for so long!
So, I'm pretty certain I've fixed a potential race condition when
accessing the data vector in vector sink lately:
https://github.com/gnuradio/gnuradio/pull/1445
But that should be included in the 3.7.11.1 release you're using... hm.
We
but that might be as simple as XOR with
10101010...).
Best regards,
Marcus
>
> Thank you.
> Regards,
>
> Inkyu
>
>
>
> > 2018. 4. 27. 오후 10:13, Müller, Marcus (CEL) <muel...@kit.edu> 작성:
> >
> > Dear Inkyu,
> >
> > there's no guaran
Hi Ogün,
this might be many things – generally, your Pi might just be running
out of memory during the build, for example (in that case, you'll often
find a hint about the OOM (out-of-memory) killer in `dmesg`; I suspect
memory limits because SWIG is especially hungry for RAM).
make VERBOSE=1
Hi Brian,
this came up today already, and seems solved by a patch:
http://lists.gnu.org/archive/html/discuss-gnuradio/2018-01/msg00108.htm
l
Maybe this helps,
best regards,
Marcus
On Wed, 2018-01-17 at 19:00 +, Brian Clark wrote:
> Good evening all,
>
> I have recently updated my kali
Hello everyone,
I'm currently debugging a strange spinlooping issue in GRC, which
happened just while I was entering the number of output streams in a
PFB channelizer's property dialog; I've not pressed enter or closed the
dialog.
However, as far as my htop and gdb debugging goes, the code path
Hi Volker,
you're definitely scratching something I've been thinking about for
quite some time.
The direction in which I'd like to steer this whole would be twofold:
* a high degree of quality assurance (that includes naming consistency)
of in-tree code
* a high degree of reward for developers
Hi John,
my experience, indeed, is that USB passthrough support in VMs is
suboptimal. So, this could very well be a virtual USB host controller
problem.
I'd actually recommend circumventing the issue, e.g. by running rtl_tcp
on the host machine, and using the appropriate source string in the gr-
Ah, and: Choppy audio from low-buffer streaming applications within VMs
is another common issue with many VM hypervisors.
On Tue, 2018-01-23 at 12:44 +, Müller, Marcus (CEL) wrote:
> Hi John,
>
> my experience, indeed, is that USB passthrough support in VMs is
> suboptimal. So
You'll find instructions at
https://osmocom.org/projects/sdr/wiki/rtl-sdr#rtl_tcp
On Tue, 2018-01-23 at 12:50 +, john cooper wrote:
> Hello Marcus, good idea, I will research how to do this and report back.
> Many thanks. John
>
> On Tue, 23 Jan 2018, 12:47 Müller, Marcus
; it's somewhere in that logic.
>
> On Tue, Jan 23, 2018 at 5:37 AM, Müller, Marcus (CEL) <muel...@kit.edu> wrote:
> > Hello everyone,
> >
> > I'm currently debugging a strange spinlooping issue in GRC, which
> > happened just while I was entering the number of
Hello Markus,
just to add to the things said:
The (non-fast) noise source in GR has experienced a bit of bugfixing
(but more on a mathematical level: turns out that the built-in random
function GNU Radio used wasn't all that random if one looked for about
10^8 samples)...
I'm currently reading
Hi Tellrell,
>def forecast(self, noutput_items, ninput_items_required):
>#setup size of input_items[i] for work call
>for i in range(len(ninput_items_required)):
>ninput_items_required[i] = noutput_items
what your forecast does: it tells the GNU Radio runtime that
1 - 100 of 1113 matches
Mail list logo
