Brian, I think your idea does work. I think the tricky bit to doing this really
well is having a control loop that reacts quickly enough that we don’t have to
be stuck with a giant buffer that adds undesirable latency, but then conversely
a control loop that adapts at a slow enough rate and
As part of the goal to fix bugs for a 3.8, please consider this patch
against current gnuradio master.
A small patch for the build system.
It removes a few lines and a few variables of CMake,
and yields a better gnuradio-runtime.pc file.
Looking forward to 3.8,
-Maitland
enc:
Hi Arpit,
> Also, pygccxml parser code
> itself is easy to visualize. libclang in python does a pretty good
> job in parsing all the header files, but it parses all the include
> files, and also the standard C++ ones because of it's compiler level
> parsing, which is not required, at least in
Welcome!
If you want to run gr-radar on Windows, please try running this as part of
your application, and then provide some "proof" that you were able to do
this in your application. If you can't effectively edit and publish code,
you won't get very far, so please make sure you have that part
A nice design could also abstract the implementation of the code parsing
tool (clang vs. pygccxml) and use either one under the hood.
-- M
On Thu, Mar 7, 2019 at 7:07 AM Arpit Gupta wrote:
> Hi,
> As I'm working on block header parsing tool as my GSoC project, I would
> like to have an opinion
John,
have you tried building a "vanilla" RFNoC image? That might help narrow
things down. Run 'make X310_RFNOC_HG' from your usrp3/top/x300 directory
(after loading the environment, which uhd_image_builder does for you).
-- M
On Tue, Feb 19, 2019 at 1:49 PM John_w_g wrote:
> I am going
Hi Johannes,
Thank you for your detailed response.
I would look into the two approaches you suggested, and get back once I
have something concrete.
I also welcome any suggestions as to which approach might be more suitable.
-Cheers,
Mayank
On Thu, Mar 7, 2019 at 2:42 PM Johannes Demel
wrote:
On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller
wrote:
> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
>
Could message passing from
Hi,
As I'm working on block header parsing tool as my GSoC project, I would
like to have an opinion on pygccxml, which is another C++ file parsing tool
in python and is working quite well on parsing GNU Radio header files
because of their brilliant, elegant yet simple and most importantly their
Hi Brennan,
This is great. I am curious, has this been released or you are still
working on it?
Thanks
Milos
On Thu, 31 Jan 2019 at 20:35, Brennan Ashton
wrote:
> In addition to what Ron mentioned there is an FPGA implementation of the
> LDPC portion of DVB-S2 that I will be releasing late
Hi,
On Thu, 7 Mar 2019 09:27:50 +
"Müller, Marcus (CEL)" wrote:
> Very little… https://wiki.gnuradio.org/index.php/Android
> of which https://wiki.gnuradio.org/index.php/GRAndDeps is probably the
> most important, but it's pretty dated. I don't think modern GNU Radio
> has problems with
Very little… https://wiki.gnuradio.org/index.php/Android
of which https://wiki.gnuradio.org/index.php/GRAndDeps is probably the
most important, but it's pretty dated. I don't think modern GNU Radio
has problems with GCC 4.9 anymore, but it does not work with GCC before
4.8.4.
You'll notice the
Hi Mayank,
I'm glad you're interested in optimized codes.
There are quite a lot of comms standards out there. They all come with
their standardized codes. Unlike their general definition, standards use
a small subset of all possible configurations a code might have.
e.g. in general frozen bits
13 matches
Mail list logo
