+ <id>8632</id>

+ <parentid>8605</parentid>

+ <timestamp>2021-05-31T14:39:04Z</timestamp>

+ <ip>172.18.0.3</ip>

+ <comment>/* Logging from Python */ small typo fix</comment>

+ <text xml:space="preserve" bytes="10203">[[Category:Usage Manual]]

+The logging configuration can be found in the '''<prefix>/etc/gnuradio/conf.d/gnuradio-runtime.conf''' file

+under the '''[LOG]''' section. This allows us fairly complete control over

+for the two loggers, the standard logger and the separate debug logger.

+specified in the log_config file. Here, we have turned on the standard logger

+If both an log_config configuration file is set and the "log_file" or

+through the log_config file while also still outputting to stdout or stderr.

+logger into the gr_block parent class to simplify access and make

+

+

+==== Current GNU Radio 3.9 March 2020 ====

+With the current ''master'' branch, logging got way easier. In your OOT module, just write:

+<syntaxhighlight lang="c++">

+GR_LOG_INFO(this->d_logger, "My INFO message");

+</syntaxhighlight>

+for logging to the standard logger with level 'INFO'. More generally, we'd use:

+<syntaxhighlight lang="c++">

+GR_LOG_<LOGLEVEL>(this->d_logger, "My <LOGLEVEL> message");

+</syntaxhighlight>

+

+It is not necessary to apply any CMake changes or to include additional headers.

+Be aware that

+<syntaxhighlight lang="c++" inline>

+this->d_logger

+</syntaxhighlight>

+implies that you call the logger within a class inherited from

+<syntaxhighlight lang="c++" inline>gr::block</syntaxhighlight>.

+

+The logging capability has been brought out python via swig (<=v3.8) or pybind11 (>=v3.9). The configuration

+You can instantiate this by the following. (Reference logger.h for list of methods)

+ <sha1>s1zlqhtu3momfl66ryql76uguo9567g</sha1>

+ <id>8794</id>

+ <parentid>8615</parentid>

+ <timestamp>2021-10-05T23:22:38Z</timestamp>

+ <username>777arc</username>

+ <id>632</id>

+ <comment>Added blurb about having to edit yaml</comment>

+ <text xml:space="preserve" bytes="20661">[[Category:Usage Manual]]

+[[File:Gnuradio_pdu_illustration.png|550px|Gnuradio_pdu_illustration.png]]

+

+must then bind this port to the message handler.

+Starting in GNU Radio 3.8¹ using C++11 we do that using a lambda function:

+ [this](const pmt::pmt_t& msg) { message_handler_function(msg); });

+function of the class designated to handle messages to this port.

+

+The prototype for all message handling functions

+ void block_class::message_handler_function(const pmt::pmt_t& msg);

+messages. Assume that the block '''src''' has an output message port named

+''pdus'' and the block '''dbg''' has an input port named ''print''. The message

+The following example uses a gr::blocks::pdu_to_tagged_stream block

+Note, in addition to the C++ or Python code below, if adding message passing to a block, you need to edit the block's YAML file as well. Add the corresponding input or output entries (ensuring the domain is set to "message"). You do not need to specify a dtype. You should also ensure that the label value corresponds to the registered port name. See [[YAML_GRC#Inputs_and_Outputs_.28optional.29 | here]] for more details.

+

+gr::blocks::message_debug and gr::blocks::tagged_stream_to_pdu below

+passing system. It describes two input message ports: ''print'' and

+''store''. The ''print'' port simply prints out all

+messages posted to it. The ''store'' port works in

+conjunction with a gr::blocks::message_debug::get_message(size_t i) call

+ [this](const pmt::pmt_t& msg) { print(msg); });

+ [this](const pmt::pmt_t& msg) { store(msg); });

+identify this particular port name with a callback function.

+

+So now

+gr::blocks::message_debug_impl::print and

+gr::blocks::message_debug_impl::store are assigned to handle

+ message_debug_impl::print(const pmt::pmt_t& msg)

+The gr::blocks::tagged_stream_to_pdu block only defines a single

+<syntaxhighlight lang="cpp">

+{

+}

+</syntaxhighlight>

+gr::blocks::tagged_stream_to_pdu_impl::send_message function that is

+There is similarly a gr::blocks::pdu_to_tagged_stream block that essentially

+flowgraph using the gr::blocks::pdu_to_tagged_stream block.

+</syntaxhighlight>

+

+== Flowgraph Example ==

+

+Here's a simple example of a flow graph using both streaming and messages:

+

+[[File:strobe.grc.png|550px|strobe.grc.png]]

+

+There are several interesting things to point out. First, there are two source blocks, which both output items at regular intervals, one every 1000 and one every 750 milliseconds. Dotted lines denote connected message ports, as opposed to solid lines, which denote connected streaming ports. In the top half of the flow graph, we can see that it is, in fact, possible to switch between message passing and streaming ports, but only if the type of the PMTs matches the type of the streaming ports (in this example, the pink color of the streaming ports denotes bytes, which means the PMT should be a u8vector if we want to stream the same data we sent as PMT).

+

+Another interesting fact is that we can connect more than one message output port to a single message input port, which is not possible with streaming ports. This is due to the '''asynchronous''' nature of messages: The receiving block will process all messages whenever it has a chance to do so, and not necessarily in any specific order. Receiving messages from multiple blocks simply means that there might be more messages to process.

+

+What happens to a message once it was posted to a block? This depends on the actual block implementation, but there are two possibilities:

+

+1) A message handler is called, which processes the message immediately.<br />

+2) The message is written to a FIFO buffer, and the block can make use of it whenever it likes, usually in the work function.

+

+For a block that has both message ports and streaming ports, any of these two options is OK, depending on the application. However, we strongly discourage the processing of messages inside of a work function and instead recommend the use of message handlers. Using messages in the work function encourages us to block in work waiting for a message to arrive. This is bad behavior for a work function, which should never block. If a block depends upon a message to operate, use the message handler concept to receive the message, which may then be used to inform the block's actions when the work function is called. Only on specially, well-identified occasions should we use method 2 above in a block.

+

+With a message passing interface, we can write blocks that don't have streaming ports, and then the work function becomes useless, since it's a function that is designed to work on streaming items. In fact, blocks that don't have streaming ports usually don't even have a work function.

+

+=== PDUs ===

+

+In the previous flow graph, we have a block called ''PDU to Tagged Stream''. A PDU (protocol data unit) in GNU Radio has a special PMT type, it is a pair of a dictionary (on CAR) and a uniform vector type. So, this would yield a valid PDU, with no metadata and 10 zeros as stream data:

+

+<pre>pdu = pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 0))</pre>

+The key/value pairs in the dictionary are then interpreted as key/value pairs of stream tags.

+

+== Flowgraph Example: Chat Application ==

+

+Let's build an application that uses message passing. A chat program is an ideal use case, since it waits for the user to type a message, and then sends it. Because of that, no [[Throttle]] block is needed.

+

+Create the following flowgraph and save it as 'chat_app2.grc':

+

+[[File:Chat_app2_fg.png]]

+

+The ZMQ Message blocks have an Address of 'tcp://127.0.0.1:50261'. Typing in the [[QT GUI Message Edit Box]] will send the text once the Enter key is pressed. Output is on the terminal screen where gnuradio-companion was started.

+

+If you want to talk to another user (instead of just yourself), you can create an additional flowgraph with a different name such as 'chat_app3.grc'. Then change the ZMQ port numbers as follows:

+* chat_app2

+** ZMQ PUSH Sink: tcp://127.0.0.1:50261

+** ZMQ PULL Source: tcp://127.0.0.1:50262

+

+* chat_app3

+** ZMQ PUSH Sink: tcp://127.0.0.1:50262

+** ZMQ PULL Source: tcp://127.0.0.1:50261

+

+When using GRC, doing a Generate and/or Run creates a Python file with the same name as the .grc file. You can execute the Python file without running GRC again.

+

+For testing this system we will use two processes, so we will need two terminal windows.

+

+Terminal 1:

+* since you just finished building the chat_app3 flowgraph, you can just do a Run.

+

+Terminal 2:

+Open another terminal window.

+* change to whatever directory you used to generate the flowgraph for chat_app2.

+* execute the following command:

+ python3 -u chat_app2.py

+

+Typing in the Message Edit Box for chat_app2 should be displayed on the Terminal 1 screen (chat_app3) and vice versa.

+

+To terminate each of the processes cleanly, click on the 'X' in the upper corner of the GUI rather than using Control-C.

+

+

+----

+

+¹ In old GNU Radio 3.7, we used Boost's 'bind' function:

+

+ set_msg_handler(pmt::pmt_t port_id,

+ boost::bind(&block_class::message_handler_function, this, _1));}}

+

+The 'this' and '_1' are standard ways of using the Boost bind function to

+pass the 'this' pointer as the first argument to the class (standard

+OOP practice) and the _1 is an indicator that the function expects 1

+additional argument.

+

+[[Category:Guided Tutorials]]</text>

+ <sha1>s8jjo2g4fgrlyymzfhuhti4v98hz2pj</sha1>

+</mediawiki> \ No newline at end of file

+ <id>7025</id>

+ <parentid>4867</parentid>

+ <timestamp>2020-05-11T23:07:18Z</timestamp>

+ <username>L0uisc</username>

+ <id>891</id>

+ <minor/>

+ <comment>fixed "extra_str" in call to blocks.file_meta_sink() in final code block to read "extras_str"</comment>

+ <text xml:space="preserve" bytes="14485">[[Category:Usage Manual]]

+ 1000000, extras_str, False)

+ <sha1>79bbsfgjz078sumck0ea80hkoe1kuow</sha1>

+ <id>8534</id>

+ <parentid>8533</parentid>

+ <timestamp>2021-05-08T15:28:22Z</timestamp>

+ <username>Solomonbstoner</username>

+ <id>892</id>

+ <minor/>

+ <comment>Fixed example code</comment>

+ <text xml:space="preserve" bytes="24944">[[Category:Usage Manual]]

+Polymorphic Types are used as the carrier of data from one block/thread to another such as stream tags and message passing interfaces.

+PMT data types can represent a variety of data ranging from the Booleans to dictionaries.

+They are heavily used in the stream tags and message passing interfaces.

+In a sense, PMTs are a way to extend C++' strict typing with something more flexible.

+The most complete list of PMT function is, of course, the source code, specifically the header file [https://gnuradio.org/doc/doxygen/pmt_8h.html pmt.h].

+This page summarizes the most important features and points of PMTs.

+

+Let's dive straight into some Python code and see how we can use PMTs:

+First, the <code>pmt</code> module is imported. We assign two values (<code>P</code> and <code>P2</code>) with PMTs using the <code>from_long()</code> and <code>from_complex()</code> calls, respectively. As we can see, they are both of the same type! This means we can pass these variables to C++ through SWIG, and C++ can handle this type accordingly.

+ pmt::pmt_t P2 = pmt::from_complex(gr_complex(0, 1));

+ // Alternatively: pmt::from_complex(0, 1)

+Two things stand out in both Python and C++: First, we can simply print the contents of a PMT. How is this possible? Well, the PMTs have in-built capability to cast their value to a string (this is not possible with all types, though). Second, PMTs must obviously know their type, so we can query that, e.g. by calling the <code>is_complex()</code> method.

+

+Note: When running the above as a standalone, the compiler command will look something like <code>g++ pmt_tutorial.cpp -I$(gnuradio-config-info --prefix)/include -lgnuradio-pmt -o pmt_tutorial</code>

+

+When assigning a non-PMT value to a PMT, we can use the <code>from_*</code> methods, and use the <code>to_*</code> methods to convert back:

+ pmt::pmt_t P_double = pmt::mp(0.2);

+

+The last row shows the [http://gnuradio.org/doc/doxygen/namespacepmt.html#a90faad6086ac00280e0cfd8bb541bd64 pmt::mp()] shorthand function. It basically saves some typing, as it infers the correct <code>from_</code> function from the given type.

+

+

+See the [https://www.gnuradio.org/doc/doxygen/namespacepmt.html PMT docs] and the header file [http://gnuradio.org/doc/doxygen/pmt_8h.html pmt.h] for a full list of conversion functions.

+

+

+

+

+

+

+

+<code>pmt.PMT_T</code> and <code>pmt.PMT_F</code> are boolean PMT types representing True and False, respectively. The PMT_NIL is like a NULL or None and can be used for default arguments or return values, often indicating an error has occurred.

+out the type from a PMT. The family of <code>is_*</code> methods helps us do that:

+

+

+We can compare PMTs without knowing their type by using the <code>pmt::equal()</code> function:

+

+

+There are more equality functions, which compare different things: [http://gnuradio.org/doc/doxygen/namespacepmt.html#a5c28635e14287cc0e2f762841c11032f <code>pmt::eq()</code>] and [http://gnuradio.org/doc/doxygen/namespacepmt.html#a25467c81e1c5f4619a9cabad7a88eed5 <code>pmt::eqv()</code>]. We won't need these for this tutorial.

+

+=== More Complex Types ===

+

+PMTs can hold a variety of types. Using the Python method <code>pmt.to_pmt()</code>, we can convert most of Pythons standard types out-of-the-box:

+

+<pre>P_tuple = pmt.to_pmt((1, 2, 3, 'spam', 'eggs'))

+P_dict = pmt.to_pmt({'spam': 42, 'eggs': 23})</pre>

+But what does this mean in the C++ domain? Well, there are PMT types that define [http://gnuradio.org/doc/doxygen/namespacepmt.html#a32895cc5a614a46b66b869c4a7bd283c tuples] and [http://gnuradio.org/doc/doxygen/namespacepmt.html#aba10563e3ab43b8d52f9cb13132047cf dictionaries], keys and values being PMTs, again.<br />

+So, to create the tuple from the Python example, the C++ code would look like this:

+

+<pre>pmt::pmt_t P_tuple = pmt::make_tuple(pmt::from_long(1), pmt::from_long(2), pmt::from_long(3), pmt::string_to_symbol(&quot;spam&quot;), pmt::string_to_symbol(&quot;eggs&quot;))</pre>

+For the dictionary, it's a bit more complex:

+

+<pre>pmt::pmt_t P_dict = pmt::make_dict();

+P_dict = pmt::dict_add(P_dict, pmt::string_to_symbol(&quot;spam&quot;), pmt::from_long(42));

+P_dict = pmt::dict_add(P_dict, pmt::string_to_symbol(&quot;eggs&quot;), pmt::from_long(23));</pre>

+As you can see, we first need to create a dictionary, then assign every key/value pair individually.

+

+A variant of tuples are ''vectors''. Like Python's tuples and lists, PMT vectors are mutable, whereas PMT tuples are not. In fact, PMT vectors are the only PMT data types that are mutable. When changing the value or adding an item to a dictionary, we are actually creating a new PMT.

+

+To create a vector, we can initialize it to a certain lengths, and fill all elements with an initial value. We can then change items or reference them:

+

+<pre>pmt::pmt_t P_vector = pmt::make_vector(5, pmt::from_long(23)); // Creates a vector with 5 23's as PMTs

+pmt::vector_set(P_vector, 0, pmt::from_long(42)); // Change the first element to a 42

+std::cout &lt;&lt; pmt::vector_ref(P_vector, 0); // Will print 42</pre>

+In Python, we can do all these steps (using <code>pmt.make_vector()</code> etc.), or convert a list:

+

+<pre>P_vector = pmt.to_pmt([42, 23, 23, 23, 23])</pre>

+Vectors are also different from tuples in a sense that we can '''directly''' load data types into the elements, which don't have to be PMTs.<br />

+Say we want to pass a series of 8 float values to another block (these might be characteristics of a filter, for example). It would be cumbersome to convert every single element to and from PMTs, since all elements of the vector are the same type.

+

+We can use special vector types for this case:

+

+<pre>pmt::pmt_t P_f32vector = pmt::make_f32vector(8, 5.0); // Creates a vector with 8 5.0s's as floats

+pmt::f32vector_set(P_f32vector, 0, 2.0); // Change the first element to a 2.0

+float f = f32vector_ref(P_f32vector, 0);

+std::cout &lt;&lt; f &lt;&lt; std::endl; // Prints 2.0

+size_t len;

+float *fp = pmt::f32vector_elements(P_f32vector, len);

+for (size_t i = 0; i &lt; len; i++)

+ std::cout &lt;&lt; fp[i] &lt;&lt; std::endl; // Prints all elements from P_f32vector, one after another</pre>

+Python has a similar concept: [http://docs.scipy.org/doc/numpy/reference/generated/numpy.array.html Numpy arrays]. As usual, the PMT library understands this and converts as expected:

+

+<pre>P_f32vector = pmt.to_pmt(numpy.array([2.0, 5.0, 5.0, 5.0, 5.0], dtype=numpy.float32))

+print pmt.is_f32vector(P_f32vector) # Prints 'True'</pre>

+Here, 'f32' stands for 'float, 32 bits'. PMTs know about most typical fixed-width data types, such as 'u8' (unsigned 8-bit character) or 'c32' (complex with 32-bit floats for each I and Q). Consult the [http://gnuradio.org/doc/doxygen/namespacepmt.html manual] for a full list of types.

+

+The most generic PMT type is probably the blob (binary large object). Use this with care - it allows us to pass around anything that can be represented in memory.

+

+ pmt::pmt_t pmt_a = pmt::make_rectangular(a.real(), a.imag());

+List of available pmt::is_(dtype)vector(pmt_t x) methods from <code>pmt.h</code>:<br>

+

+ bool pmt::is_uniform_vector()

+ bool pmt::is_u8vector()

+ bool pmt::is_s8vector()

+ bool pmt::is_u16vector()

+ bool pmt::is_s16vector()

+ bool pmt::is_u32vector()

+ bool pmt::is_s32vector()

+ bool pmt::is_u64vector()

+ bool pmt::is_s64vector()

+ bool pmt::is_f32vector()

+ bool pmt::is_f64vector()

+ bool pmt::is_c32vector()

+ bool pmt::is_c64vector()

+

+A concept that originates in Lisp dialects are [http://en.wikipedia.org/wiki/Cons ''pairs'' and ''cons'']. The simplest explanation is just that: If you combine two PMTs, they form a new PMT, which is a pair (or cons) of those two PMTs (don't worry about the weird name, a lot of things originating in Lisp have weird names. Think of a 'construct').

+

+Similarly to vectors or tuples, pairs are a useful way of packing several components of a message into a single PMT. Using the PMTs generated in the previous section, we can combine two of these to form a pair, here in Python:

+

+<pre>P_pair = pmt.cons(pmt.string_to_symbol(&quot;taps&quot;), P_f32vector)

+print pmt.is_pair(P_pair) # Prints 'true'</pre>

+You can combine PMTs as tuples, dictionaries, vectors, or pairs, it's just a matter of taste. This construct is well-established though, and as such used in GNU Radio quite often.

+

+So how do we deconstruct a pair? That's what the <code>car</code> and <code>cdr</code> functions do. Let's deconstruct that previous pair in C++:

+

+<pre>pmt::pmt_t P_key = pmt::car(P_pair);

+pmt::pmt_t P_f32vector2 = pmt::cdr(P_pair);

+std::cout &lt;&lt; P_key &lt;&lt; std::endl; // Will print 'taps' using the PMT automatic conversion to strings</pre>

+

+Here is a summary of the pairs-related functions in C++ and Python:

+For more advanced pair manipulation, refer to the [http://gnuradio.org/doc/doxygen/namespacepmt.html#a7ab95721db5cbda1852f13a92eee5362 documentation] and the [https://en.wikipedia.org/wiki/Car_and_cdr Wikipedia page for car and cdr].

+

+ pmt::pmt_t a = pmt::from_double(1.0);

+=== Collection Notation ===

+PMTs use a different bracket notation from what one might be use to in Python.

+

+<syntaxhighlight lang="plaintext">

+>>> my_dict

+((meaning . 42))

+>>> my_vector

+#[1 2 3 4]

+>>> pmt.make_tuple(pmt.from_long(321), pmt.from_float(3.14))

+{321 3.14}

+>>> pmt.cons(pmt.from_long(1), pmt.from_long(2))

+(1 . 2)

+>>> my_pdu

+(() . #[1 2 3 4])

+</syntaxhighlight>

+

+ <sha1>mox7is6oymllqhrkqtc39dpmlvu1r2d</sha1>

+ window=filter.firdes.WIN_BLACKMAN_hARRIS)

+ self.snk_win = sip.wrapinstance(self.snk.pyqwidget(), Qt.QWidget)

+</mediawiki> \ No newline at end of file

+ <id>8713</id>

+ <parentid>8602</parentid>

+ <timestamp>2021-06-30T11:10:32Z</timestamp>

+ <username>Marcindsp</username>

+ <id>1033</id>

+ <minor/>

+ <text xml:space="preserve" bytes="21769">[[Category:Usage Manual]]

+message passing system is that it works asynchronously, meaning that

+Note that the key and value are both PMTs. To create a string type PMT you can use pmt.intern("example_key").

+

+Consider the following flowgraph as an example. We will have an embedded python block insert stream tags at random intervals, and view these tags on the QT GUI Time sink.

+

+[[File:Epy_stream_tags_example_flowchart.png|800px]]

+

+Add the following code into the embedded python block. This code outputs the same signal as in the input, except with tags on randomly selected input samples:

+ in_sig=[np.float32],

+ out_sig=[np.float32]

+ for indx, sample in enumerate(input_items[0]): # Enumerate through the input samples in port in0

+ self.add_item_tag(0, # Write to output port 0

+ self.nitems_written(0) + indx, # Index of the tag in absolute terms

+ key, # Key of the tag

+ value # Value of the tag

+ )

+You may expect an output similar to the screenshot of the time sink below.

+

+[[File:Epy_stream_tags_example_timesink.png|800px]]

+

+We now know how to add tags to streams, and how to read them. But what happens to tags after they were read? And what happens to tags that aren't used? After all, there are many blocks that don't care about tags at all.

+

+The answer is: It depends on the ''tag propagation policy'' of a block what happens to tags that enter it.<br />

+There are [http://gnuradio.org/doc/doxygen/classgr_1_1block.html#abc40fd4d514724a5446a2b34b2352b4e three policies] to choose from:

+We generally set the tag propagation policy in the block's constructor using [http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a476e218927e426ac88c26431cbf086cd @set_tag_propagation_policy]

+When the tag propagation policy is set to TPP_ALL_TO_ALL or TPP_ONE_TO_ONE, the GNU Radio scheduler uses any information available to figure out which output item corresponds to which input item. The block may read them and add new tags, but existing tags are automatically moved downstream in a manner deemed appropriate.

+As an example, consider an interpolating block. See the following flow graph:

+

+[[File:tags_interp.grc.png|700px|tags_interp.grc.png]]

+

+[[File:tags_interp.png|500px|tags_interp.png]]<br />

+

+As you can tell, we produce tags on every 10th sample, and then pass them through a block that repeats every sample 100 times. Tags do not get repeated with the standard tag propagation policies (after all, they're not tag ''manipulation'' policies), so the scheduler takes care that every tag is put on the output item that corresponds to the input item it was on before. Here, the scheduler makes an educated guess and puts the tag on the '''first''' of 100 items.

+

+Note: We can't use one QT GUI Time Sink for both signals here, because they are running at a different rate. Note the time difference on the x-axis!

+

+On decimating blocks, the behavior is similar. Consider this very simple flow graph, and the position of the samples:

+

+[[File:tags_decim.grc.png|400px|tags_decim.grc.png]]

+

+[[File:tags_decim.png|500px|tags_decim.png]]<br />

+

+

+We can see that no tags are destroyed, and tags are indeed spaced at one-tenth of the original spacing of 100 items. Of course, the actual item that was passed through the block might be destroyed, or modified (think of a decimating FIR filter).

+

+In fact, this works with any rate-changing block. Note that there are cases where the relation of tag positions of in- and output are ambiguous, the GNU Radio scheduler will then try and get as close as possible.

+

+Here's another interesting example: Consider this flow graph, which has a delay block, and the position of the tags after it:

+

+[[File:tags_ramp_delay.grc.png|500px|tags_ramp_delay.grc.png]]

+

+[[File:tags_ramp_delay.png|500px|tags_ramp_delay.png]]<br />

+

+

+Before the delay block, tags were positioned at the beginning of the ramp. After the delay, they're still in the same position! Would we inspect the source code of the delay block, we'd find that there is absolutely no tag handling code. Instead, the block [http://gnuradio.org/doc/doxygen/classgr_1_1block.html#acad5d6e62ea885cb77d19f72451581c2 declares a delay] to the scheduler, which then propagates tags with this delay.

+

+Using these mechanisms, we can let GNU Radio handle tag propagation for a large set of cases. For specialized or corner cases, there is no option than to set the tag propagation policy to <code>TPP_DONT</code> and manually propagate tags (actually, there's another way: Say we want most tags to propagate normally, but a select few should be treated differently. We can use [http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a461f6cc92174e83b10c3ec5336036768 <code>remove_item_tag()</code>] (DEPRECATED. Will be removed in 3.8.) to remove these tags from the input; they will then not be propagated any more even if the tag propagation policy is set to something other than <code>TPP_DONT</code>. But that's more advanced use and will not be elaborated on here).

+

+data file source/sink (see [[Metadata_Information]]) that use tags to store

+sample rate or frequency changes, a new tag is issued.

+

+== Example Flowgraph ==

+

+Let's have a look at a simple example:

+

+[[File:tut5_tagstest_fg.png|600px|tut5_tagstest_fg.png]]

+

+In this flow graph, we have two sources: A sinusoid and a tag strobe. A tag strobe is a block that will output a constant tag, in this case, on every 1000th item (the actual value of the items is always zero). Those sources get added up. The signal after the adder is identical to the sine wave we produced, because we are always adding zeros. However, the tags stay attached to the same position as they were coming from the tag strobe! This means every 1000th sample of the sinusoid now has a tag. The QT scope can display tags, and even trigger on them.

+

+[[File:tut5_tagstest_scope.png|500px|tut5_tagstest_scope.png]]<br />

+

+We now have a mechanism to randomly attach any metadata to specific items. There are several blocks that use tags. One of them is the UHD Sink block, the driver used for transmitting with USRP devices. It will react to tags with certain keys, one of them being <code>tx_freq</code>, which can be used to set the transmit frequency of a USRP while streaming.

+

+=== Adding tags to the QPSK demodulator ===

+

+Going back to our QPSK demodulation example, we might want to add a feature to tell downstream blocks that the demodulation is not going well. Remember the output of our block is always hard-decision, and we have to output something. So we could use tags to notify that the input is not well formed, and that the output is not reliable.

+

+As a failure criterion, we discuss the case where the input amplitude is too small, say smaller than 0.01. When the amplitude drops below this value, we output one tag. Another tag is only sent when the amplitude has recovered, and falls back below the threshold. We extend our work function like this:

+

+<pre>if (std::abs(in[i]) &lt; 0.01 and not d_low_ampl_state) {

+ add_item_tag(0, // Port number

+ nitems_written(0) + i, // Offset

+ pmt::mp(&quot;amplitude_warning&quot;), // Key

+ pmt::from_double(std::abs(in[i])) // Value

+ );

+ d_low_ampl_state = true;

+}

+else if (std::abs(in[i]) &gt;= 0.01 and d_low_ampl_state) {

+ add_item_tag(0, // Port number

+ nitems_written(0) + i, // Offset

+ pmt::mp(&quot;amplitude_recovered&quot;), // Key

+ pmt::PMT_T // Value

+ );

+ d_low_ampl_state = false; // Reset state

+}</pre>

+In Python, the code would look like this (assuming we have a member of our block class called <code>d_low_ampl_state</code>):

+

+<pre># The vector 'in' is called 'in0' here because 'in' is a Python keyword

+if abs(in0[i]) &lt; 0.01 and not d_low_ampl_state:

+ self.add_item_tag(0, # Port number

+ self.nitems_written(0) + i, # Offset

+ pmt.intern(&quot;amplitude_warning&quot;), # Key

+ pmt.from_double(numpy.double(abs(in0[i]))) # Value

+ # Note: We need to explicitly create a 'double' here,

+ # because in0[i] is an explicit 32-bit float here

+ )

+ self.d_low_ampl_state = True

+elif abs(in0[i]) &gt;= 0.01 and d_low_ampl_state:

+ self.add_item_tag(0, # Port number

+ self.nitems_written(0) + i, # Offset

+ pmt.intern(&quot;amplitude_recovered&quot;), # Key

+ pmt.PMT_T # Value

+ )

+ self.d_low_ampl_state = False; // Reset state</pre>

+We can also create a tag data type [http://gnuradio.org/doc/doxygen/structgr_1_1tag__t.html tag_t] and directly pass this along:

+

+<pre>if (std::abs(in[i]) &lt; 0.01 and not d_low_ampl_state) {

+ tag_t tag;

+ tag.offset = nitems_written(0) + i;

+ tag.key = pmt::mp(&quot;amplitude_warning&quot;);

+ tag.value = pmt::from_double(std::abs(in[i]));

+ add_item_tag(0, tag);

+ d_low_ampl_state = true;

+}</pre>

+Here's a flow graph that uses the tagged version of the demodulator. We input 20 valid QPSK symbols, then 10 zeros. Since the output of this block is always either 0, 1, 2 or 3, we normally have no way to see if the input was not clearly one of these values.

+

+[[File:Demod_with_tags.grc.png|750px|Demod_with_tags.grc.png]]

+

+Here's the output. You can see we have tags on those values which were not from a valid QPSK symbol, but from something unreliable.

+

+[[File:Demod_with_tags.png|500px|Demod_with_tags.png]]<br />

+

+== Use case: FIR filters ==

+

+Assume we have a block that is actually an FIR filter. We want to let GNU Radio handle the tag propagation. How do we configure the block?

+

+Now, an FIR filter has one input and one output. So, it doesn't matter if we set the propagation policy to <code>TPP_ALL_TO_ALL</code> or <code>TPP_ONE_TO_ONE</code>, and we can leave it as the default. The items going in and those coming out are different, so how do we match input to output? Since we want to preserve the timing of the tag position, we need to use the filter's '''group delay''' as a delay for tags (which for this symmetric FIR filter is <code>(N-1)/2</code>, where <code>N</code> is the number of filter taps). Finally, we might be interpolating, decimating or both (say, for sample rate changes) and we need to tell the scheduler about this as well.</text>

+ <sha1>laoj1l0sm4zk80obf1h7rdq4htbsg3v</sha1>

+ <id>8735</id>

+ <parentid>8603</parentid>

+ <timestamp>2021-07-23T15:10:11Z</timestamp>

+ <ip>172.18.0.3</ip>

+ <comment>/* CRC32 */ github changed the method to access the actual file content. url with 'blob' now goes to decorated file listing (cut-n-paste no bueno) not the bare file content (cut-n-paste ready!)</comment>

+ <text xml:space="preserve" bytes="13506">[[Category:Usage Manual]]

+prepend a synchronization word before every packet or append a CRC. So while some

+gr::sync_block etc.) in that they are driven by the input: The PDU length tag tells the block how to operate, whereas other blocks are output-driven (the scheduler tries to fill up the output buffer as much as possible).

+Block: [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-digital/lib/crc32_bb_impl.cc gr-digital/lib/crc32_bb_impl.cc]

+Block: [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-digital/lib/ofdm_frame_equalizer_vcvc_impl.cc gr-digital/lib/ofdm_frame_equalizer_vcvc_impl.cc]

+Block: [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-blocks/lib/tagged_stream_mux_impl.cc gr-blocks/lib/tagged_stream_mux_impl.cc]

+Block: [https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-digital/lib/ofdm_cyclic_prefixer_impl.cc gr-digital/lib/ofdm_cyclic_prefixer_impl.cc]

+== Troubleshooting ==

+ <sha1>7zjm0zyisjndz7o8pih62qwhn0r6ctg</sha1>

+ <id>9094</id>

+ <parentid>8843</parentid>

+ <timestamp>2021-11-17T16:00:00Z</timestamp>

+ <username>777arc</username>

+ <id>632</id>

+ <comment>/* Basic Block */</comment>

+ <text xml:space="preserve" bytes="8027">[[Category:Usage Manual]]

+ def __init__(self, decim_rate):

+ out_sig=[numpy.float32],

+ decim = decim_rate)

+ self.set_relative_rate(1.0/decim_rate)

+ self.decimation = decim_rate

+ def work(self, input_items, output_items):

+ output_items[0][:] = input_items[0][0::self.decimation]

+ return len(output_items[0])

+** This behaviour can be altered by overloading the forecast() method but is not mandatory

+import numpy as np

+ def __init__(self):

+ in_sig=[np.float32, np.float32],

+ out_sig=[np.float32])

+ def general_work(self, input_items, output_items):

+ #consume the inputs

+ self.consume(0, len(in0)) #consume port 0 input

+ self.consume(1, len(in1)) #consume port 1 input

+

+ <sha1>jlgt0ofen1ui79z2lk7vhsyffax6jr5</sha1>

+# pip install selenium

+# I had to also do pip install --upgrade requests

+# Download geckodriver from here https://github.com/mozilla/geckodriver/releases and put it in Downloads

+# sudo chmod +x geckodriver

+# export PATH=$PATH:/home/marc/Downloads (or wherever you put it)

+

+from selenium import webdriver

+from html.parser import HTMLParser

+pages_to_save = ['Handling Flowgraphs',

+driver = webdriver.Firefox('/home/marc/Downloads/geckodriver') # dir that contains geckodriver

+print("STARTING")

+ print("Processing", page_name)

+ h = HTMLParser()

+print("DONE")