Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?
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 a lot of log messages that are only of
interest within the GNU Radio "part" of an application that uses GNU
Radio as library (for example: Info that a buffer of a certain size was
allocated during flow graph startup), and others that are relevant to
some "business logic" of an application (e.g. network connection
dropped).
So, I think GNU Radio does need an internal logging mechanism, BUT:
That needs to be something that the application using GNU Radio can
selectively "subscribe" to.
So, what I'd say is we should get the following:
* Good GNU Radio-centralized logging, because it's such a common
requirement
* Easy ways to attach a callback to a filter on that centralized
logging instance.
The way to do that filtering could indeed be through some kind of enum
categorization. Logging frameworks do that – typically, there's
categories of severity (trace, debug, info, warning, critical, fatal or
similar). I think a string "component" and a matching filter wouldn't
be so bad a choice for a callback subscriber?
Needn't be a callback, by the way. Could also be a ZMQ sub socket.
Best regards,
Marcus
On Thu, 2019-08-29 at 00:11 +0200, Vadim Yanitskiy wrote:
> Hello Marcus and GNU Radio community,
>
> 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).
>
> That developer shared an interesting opinion that GNU Radio
> should be considered as a library, thus it should not do any
> logging itself. And then I came up with the following idea:
>
> What if a GNU Radio block could have a set of events that are
> being generated in some situations? Let's just look at the
> Audio Source and Sink (ALSA) blocks. In case of a buffer
> overrun / underrun, we do print magic 'aO' / 'aU' symbols.
> That's how we currently signal that something has happened.
>
> Instead of printing directly to stderr (or anywhere else),
> we can define a value-string array of possible events:
>
> enum gr_audio_event_t {
> GR_AUDIO_EV_OVERRUN,
> GR_AUDIO_EV_UNDERRUN,
> GR_AUDIO_EV_FOO_BAR,
> /* other events... */
> };
>
> struct value_string {
> unsigned int value;
> const char *string;
> } gr_audio_events[] = {
> { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
> { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
> { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
> /* other events... */
> { 0, NULL }
> };
>
> and give a possibility to the API user to subscribe either to
> some of the events, or to all of them, so logging can be done
> by the user itself, if needed. For GUI applications, the
> corresponding part of UI can be updated instead.
>
> Other blocks, such as TCP Source and Sink, could also generate
> some potentially interesting events, such as connection status
> (server got a new connection, client has lost connection, etc.).
>
> I am not going to work on it, this is just an idea, which may
> probably look interesting to some developers / users too.
>
> With best regards,
> Vadim Yanitskiy.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
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 are constrained by the I/O buffer sizes. Sorry to be a little vague, but the answer is that the value of the variable "consumed" in your description is context dependent. Hope this is useful! - MLD On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona wrote: > Hello GNURadio community, > > Does anyone know what is the maximum number of input items that an Out Of > Tree block can consume on each input stream? > > consume_each(consumed) --> what is the maximum value that the variable > consumed can take? > > Thank you very much. > > > -- > *Laura Arjona * > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > *Paul G. Allen School of Computer Science & Engineering* > 185 E Stevens Way NE > University of Washington > Seattle, WA 98195-2350 > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?
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.
> > Instead of printing directly to stderr (or anywhere else),
> > we can define a value-string array of possible events:
> >
> > enum gr_audio_event_t {
> > GR_AUDIO_EV_OVERRUN,
> > GR_AUDIO_EV_UNDERRUN,
> > GR_AUDIO_EV_FOO_BAR,
> > /* other events... */
> > };
> >
> > struct value_string {
> > unsigned int value;
> > const char *string;
> > } gr_audio_events[] = {
> > { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
> > { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
> > { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
> > /* other events... */
> > { 0, NULL }
> > };
> >
> > and give a possibility to the API user to subscribe either to
> > some of the events, or to all of them, so logging can be done
> > by the user itself, if needed. For GUI applications, the
> > corresponding part of UI can be updated instead.
This idea was especially valuable as blocks/objects/modules could keep
the logging messages in a binary format. Meaning that for each
event/block there could be a struct which contains information and
instead of serializing/stringifying every event logged the information
could stay in a binary/original format until it really needs to be
converted to a string. (Which is actually how the python logging
library handles string formating as well).
I thought about something like passing a
"event_severity, event_component, event_data_t, event_data_fmt" with
the last argument being a function pointer which can convert
event_data_t to string. For simple logging messages with static content
this could just be a static string, but for dynamic content this could
convert all sorts of information to a printable string (if needed).
Obviously I'm not going to implement this, just my 2 cents where this
idea originated.
Cheers
Andrej
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
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 *)
output_items[0]; *
/*
* The private constructor */
decoder_impl::frame_decoder_impl(int sample_rate,std::vector
output_sizes) : gr::block("decoder",
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::makev(2, 2, output_sizes)),
s_rate(sample_rate){
On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens
wrote:
> 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 are constrained by the I/O buffer sizes. Sorry to be a little
> vague, but the answer is that the value of the variable "consumed" in your
> description is context dependent. Hope this is useful! - MLD
>
> On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona wrote:
>
>> Hello GNURadio community,
>>
>> Does anyone know what is the maximum number of input items that an Out Of
>> Tree block can consume on each input stream?
>>
>> consume_each(consumed) --> what is the maximum value that the variable
>> consumed can take?
>>
>> Thank you very much.
>>
>>
>> --
>> *Laura Arjona *
>> Washington Research Foundation Innovation Postdoctoral Fellow in
>> Neuroengineering
>>
>> *Paul G. Allen School of Computer Science & Engineering*
>> 185 E Stevens Way NE
>> University of Washington
>> Seattle, WA 98195-2350
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> --
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>
--
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering
*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hiring Radio Enthusiasts at Astranis
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.com/ A few things we're *currently *using gnuradio for: 1. custom waveform and modem design for a low throughput, high reliability radio (for spacecraft control, telemetry, and ranging). The radio is custom, software defined hardware platform. 2. ultra wide band channelization, equalization, etc. for a high throughput, high reliability radio. The radio is also a fully custom, software defined hardware platform. 3. network modelling, optimization, and planning to maximize network capacity for a range of use cases around the globe. A few things we're *going to *use gnuradio for in the slightly longer term (12+ months out), 1. ultra high-rate DVB-S2x modem design 3. significantly expand and evolve our SDRs processing bandwidth and architecture And much more...plenty of digital communications and signal processing work going forward! If this sounds interesting to you, shoot me an email and apply online: https://www.astranis.com/ Thanks, Steve Joseph Astranis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
