Hi all,
For developing python and C++ OOT modules and maybe working on GNURadio itself
I am looking for a good combination of development environments. OS could be
Linux, currently I am tending towards Debian 10. Windows 10 is also available
with Visual Studio, but I think this doesn't go well
Hi Sumit,
this is not an installation error. Your configuration is wrong. The
argument `enb` must be of type bool but it is a string in your case.
I assume you use GRC to generate this flowgraph.
Open your USRP source block. Go to the `FE Corrections` tab and put in
`False` in both fields. No `,
Hi Johannes,
Thanks, it works now, but the input will be without quotes, i.e., False not
`False`.
Regards
Sumit
On Thu, Jul 25, 2019 at 10:22 AM Johannes Demel
wrote:
> Hi Sumit,
>
> this is not an installation error. Your configuration is wrong. The
> argument `enb` must be of type bool but it
Hi Chris,
Thank you for that. I'm still a newbie with git.
That process worked as far as cloning, but I am still getting the same
error:
"""
CMake Error at CMakeLists.txt:102 (message):
GnuRadio Runtime required to compile display
"""
from CMakeLists.txt:
find_package(Gnuradio "3.8" REQUIR
That OOT is just not up to date with GNU Radio 3.8. It needs to be
redone with the current gr_modtool.
Ron
On 7/25/19 04:36, Barry Duggan wrote:
Hi Chris,
Thank you for that. I'm still a newbie with git.
That process worked as far as cloning, but I am still getting the same
error:
"""
CMa
Sorry I forgot: This is a outdated version as it was setup before
gnuradio switched to modern cmake. I have to publish my latest
gr-display version, but first I want to test it against the latest gnuradio.
Am 25.07.19 um 13:56 schrieb Ron Economos:
That OOT is just not up to date with GNU Radi
Now the gr-display master branch builds against gnuradio 3.8.0.0-rc2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Marcus, Derek,
Thank you both so much for your feedback and for all of your suggestions on
this, I really appreciate it. My apologies for the delayed response -- I
have been out of town for several days.
Based on feedback from you all and some experimentation, I came up with a
workaround for t
Also, I'd recommend not to rely on TCP sink/source, it's python-only
and it is indeed quite fiddly – the constructors can deadlock each
other.
On Wed, 2019-07-10 at 17:51 -0400, Marcus D. Leech wrote:
> On 07/10/2019 02:54 PM, Ellie White wrote:
> > Hello!
> >
> > I am working on a radio astronomy
Hi Volker,
Yes, it works now :)
Thank you very much for fixing that. I will be making use of it today
with my RTTY Terminal Unit.
Best regards,
--
Barry Duggan KV4FV
--
Message: 13
Date: Thu, 25 Jul 2019 17:43:32 +0200
From: Volker Schroer
To: discuss-gnuradio@g
Hi all,
Hope you are doing well! I have been working on a flowgraph (attached) that
will allow me to process and save data samples from an Ettus SDR (which is
plugged in to a different computer -- the data is streamed over via a TCP
socket). I am using a metadata filesink for this, and am curious
Arbitrary counts, relative to what your Device and the attached DSP you
or the device are doing considers full scale.
Best regards,
Marcus
On Thu, 2019-07-25 at 13:09 -0400, Ellie White wrote:
> Hi all,
>
> Hope you are doing well! I have been working on a flowgraph (attached) that
> will allow
Forgot to cc the list the first time...
On Thu, Jul 25, 2019 at 1:16 PM Ellie White
wrote:
> Hi Marcus,
>
> Thanks for the suggestion, much appreciated. Do you have an alternative to
> recommend? The nature of the equipment I am working with requires that the
> SDR be plugged in to a different
Hi Marcus,
Good to know. So how would you recommend I should convert these values to,
say, watts? (I guess perhaps it would be watts squared due to the mag to
mag squared block). I assume I would first have to determine what the SDR
considers full scale -- do you have any suggestions on how to do
Hi Ellie,
> The nature of the equipment I am working with requires that the SDR
be plugged in to a different computer from the one which is storing the
data,
The problem is not that it's not on the same computer – the problem is
that the samples coming from a USRP are just that: samples, not volt
On Thu, 2019-07-25 at 13:24 -0400, Ellie White wrote:
> Hi Marcus,
>
> Good to know. So how would you recommend I should convert these values to,
> say, watts?
I described exactly that in my other email.
> (I guess perhaps it would be watts squared due to the mag to mag squared
> block).
No.
Yeah, I'm on Linux Mint 18 aka Ubuntu 16.04 (xenial). I've been meaning to
upgrade. I'm not familiar with check_topology, I basically just copied the
gr-dtv reed Solomon decoder implementation and tried to extend the
io_signature. I probably copied pasted things into my OOT module in a way
that its
On 07/25/2019 01:24 PM, Ellie White wrote:
Hi Marcus,
Good to know. So how would you recommend I should convert these values
to, say, watts? (I guess perhaps it would be watts squared due to the
mag to mag squared block). I assume I would first have to determine
what the SDR considers full sc
On Tue, 23 Jul 2019, Kevin Reid wrote:
On Tue, Jul 23, 2019 at 8:33 PM Tom Crane wrote:
Can anyone explain how to use the File Descriptor Source module in
gnuradio-companion?
I am trying to write a flow-graph to read data from an arbitrary file,
chosen via the GUI at ru
19 matches
Mail list logo
