Hey Vadim,
nice!
So, just writing without much of a filter:
1. Yes. GNU Radio should be a non-intrusive library. Stuff being
printed directly to stdout is a bad idea and we need to get away from
that.
2. Well, GNU Radio is used to construct pretty complex applications,
which leads to potentially
Hi Laura - In the "work" or "general_work" method, there are arguments that
contain the information you're looking for. These arguments are set
depending on what type of block you're creating (source, sink, sync,
tagged_stream, whatever), are influenced by what the "forecast()" method
returns, and
Hi,
> > during the last congress (35c3) we have been talking about
> > the logging in GNU Radio. I was not thinking about this much,
> > until the recent discussion with another GNU Radio developer
> > at the CCCamp 2019 (unfortunately, I forgot his name, sorry).
I plead guilty. It was me.
> >
Thank you very much Michael.
What are the I/O buffer sizes?
* My block is a general block
* In my forecast:* ninput_items_required[0] = noutput_items;*
* In the general_work: const gr_complex *in = (const gr_complex *)
input_items[0];
*float** *out = (float
Let me know if you're interested in building new radios for space! We're
looking for both full time and interns with a background in digital
communications. We actually flew an Ettus E310 about 18 months ago, but now
we're building a couple SDRs of our own. Here's our website:
https://www.astranis
