17 files changed, 221 insertions, 123 deletions
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0813ce8157..a832cf20ed 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -176,6 +176,12 @@ set(EXPORT_FILE ${CMAKE_BINARY_DIR}/ImportExecutables.cmake)
 file(WRITE ${EXPORT_FILE}) #blank the file (subdirs will append)
 
 ########################################################################
+# Incorporate CMake function/macros overloading.
+########################################################################
+
+include(CMakeOverloads)
+
+########################################################################
 # Compiler specific setup
 ########################################################################
 include(GrMiscUtils) #compiler flag check
diff --git a/cmake/Modules/CMakeOverloads.cmake b/cmake/Modules/CMakeOverloads.cmake
new file mode 100644
index 0000000000..450d44c95a
--- /dev/null
+++ b/cmake/Modules/CMakeOverloads.cmake
@@ -0,0 +1,69 @@
+# Copyright 2017 Free Software Foundation, Inc.
+#
+# This file is part of GNU Radio
+#
+# GNU Radio is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GNU Radio is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Radio; see the file COPYING.  If not, write to
+# the Free Software Foundation, Inc., 51 Franklin Street,
+# Boston, MA 02110-1301, USA.
+
+########################################################################
+# This file contains functions that override those provided by CMake.
+# We do this to allow for more generic use of these functions than as
+# provided by CMake.
+########################################################################
+
+if(DEFINED __INCLUDED_CMAKE_OVERLOADS)
+  return()
+endif()
+set(__INCLUDED_CMAKE_OVERLOADS TRUE)
+
+# overload INCLUDE_DIRECTORIES to be a little smarter
+#
+# NOTE: moving all include directories to either BEFORE (internal to
+# source or build) or AFTER (external to source or build) will work in
+# general. The primary time it could fail is when include ordering is
+# required to find a specific version of a header when multiple of the
+# same name are available in the various include directories. This
+# situation seems like it's unlikely, so we ignore it here.
+
+macro(INCLUDE_DIRECTORIES)
+  # for each provided include directory ...
+  foreach(inc_dir ${ARGN})
+
+    # is this dir the literal string "BEFORE" or "AFTER"?
+    string(FIND ${inc_dir} BEFORE IS_BEFORE)
+    string(FIND ${inc_dir} AFTER IS_AFTER)
+    if(NOT ${IS_BEFORE} EQUAL 0 AND NOT ${IS_AFTER} EQUAL 0)
+
+      # not "BEFORE" or "AFTER"; a real directory.
+      # get absolute path of this include directory
+      get_filename_component(inc_dir_abs ${inc_dir} ABSOLUTE)
+
+      # is this include directory located within the SOURCE or BUILD?
+      string(FIND ${inc_dir_abs} ${CMAKE_SOURCE_DIR} IS_IN_SOURCE)
+      string(FIND ${inc_dir_abs} ${CMAKE_BINARY_DIR} IS_IN_BINARY)
+      if(${IS_IN_SOURCE} EQUAL 0 OR ${IS_IN_BINARY} EQUAL 0)
+        # yes: local SOURCE or BINARY; internal.
+        # call the overloaded INCLUDE_DIRECTORIES,
+        # prepending this internal directory.
+        _include_directories(BEFORE ${inc_dir_abs})
+      else()
+        # no: not SOURCE or BUILD; must be external.
+        # call the overloaded INCLUDE_DIRECTORIES,
+        # appending this external directory.
+        _include_directories(AFTER ${inc_dir_abs})
+      endif()
+    endif()
+  endforeach()
+endmacro(INCLUDE_DIRECTORIES)
diff --git a/docs/doxygen/other/msg_passing.dox b/docs/doxygen/other/msg_passing.dox
index 827ad4ee62..14de7bae4c 100644
--- a/docs/doxygen/other/msg_passing.dox
+++ b/docs/doxygen/other/msg_passing.dox
@@ -14,7 +14,7 @@
 GNU Radio was originally a streaming system with no other mechanism to
 pass data between blocks. Streams of data are a model that work well
 for samples, bits, etc., but are not really the right mechanism for
-control data, metadata, and, often, packet structures (at least at
+control data, metadata, or packet structures (at least at
 some point in the processing chain).
 
 We solved part of this problem by introducing the tag stream (see \ref
@@ -32,7 +32,7 @@ We want a more general message passing system for a couple of
 reasons. The first is to allow blocks downstream to communicate back
 to blocks upstream. The second is to allow an easier way for us to
 communicate back and forth between external applications and GNU
-Radio. The new message passing interface handles these cases, although
+Radio. GNU Radio's message passing interface handles these cases, although
 it does so on an asynchronous basis.
 
 The message passing interface heavily relies on Polymorphic Types
@@ -57,20 +57,33 @@ to register a new port are:
   void message_port_register_out(pmt::pmt_t port_id)
 \endcode
 
+In Python:
+
+\code
+  self.message_port_register_in(pmt.intern("port name"))
+  self.message_port_register_out(pmt.intern("port name"))
+\endcode
+
 The ports are now identifiable by that port name. Other blocks who may
 want to post or receive messages on a port must subscribe to it. When
 a block has a message to send, they are published on a particular
-port. The subscribe and publish API looks like:
+port using the following API:
 
 \code
-  void message_port_pub(pmt::pmt_t port_id,
-                        pmt::pmt_t msg);
-  void message_port_sub(pmt::pmt_t port_id,
-                        pmt::pmt_t target);
-  void message_port_unsub(pmt::pmt_t port_id,
-                          pmt::pmt_t target);
+  void message_port_pub(pmt::pmt_t port_id, pmt::pmt_t msg);
 \endcode
 
+In Python:
+
+\code
+  self.message_port_pub(pmt.intern("port name"), <pmt message>)
+\endcode
+
+Subscribing is usually done in the form of connecting message ports 
+as part of the flowgraph, as discussed later. Internally, when message
+ports are connected, the gr::basic_block::message_port_sub method is 
+called.
+
 Any block that has a subscription to another block's output message
 port will receive the message when it is published. Internally, when a
 block publishes a message, it simply iterates through all blocks that
@@ -91,6 +104,14 @@ Boost's 'bind' function:
     boost::bind(&block_class::message_handler_function, this, _1));
 \endcode
 
+In Python:
+
+\code
+  self.set_msg_handler(pmt.intern("port name"), <msg handler function>)
+\endcode
+
+When a new message is pushed onto a port's message queue,
+it is this function that is used to process the message.
 The 'port_id' is the same PMT as used when registering the input
 port. The 'block_class::message_handler_function' is the member
 function of the class designated to handle messages to this port. The
@@ -104,16 +125,22 @@ is:
   void block_class::message_handler_function(pmt::pmt_t msg);
 \endcode
 
-We give an example of using this below.
+In Python the equivalent function would be:
+
+\code
+  def handle_msg(self, msg):
+\endcode
+
+We give examples of using this below.
 
 
 \subsection msg_passing_fg_connect Connecting Messages through the Flowgraph
 
 From the flowgraph level, we have instrumented a gr::hier_block2::msg_connect
 method to make it easy to subscribe blocks to other blocks'
-messages. The message connection method looks like the following
-code. Assume that the block \b src has an output message port named
-\a pdus and the block \b dbg has an input port named \a print.
+messages. Assume that the block \b src has an output message port named
+\a pdus and the block \b dbg has an input port named \a print. The message 
+connection in the flowgraph (in Python) looks like the following:
 
 \code
     self.tb.msg_connect(src, "pdus", dbg, "print")
@@ -144,24 +171,92 @@ gr::basic_block::_post method of the blocks as the way to access the
 message queue. So the message queue of the right name will have a new
 message. Posting messages also has the benefit of waking up the
 block's thread if it is in a wait state. So if idle, as soon as a
-message is posted, it will wake up and and call the message handler.
+message is posted, it will wake up and call the message handler.
 
-The other side of the action in a block is in the message
-handler. When a block has an input message port, it needs a callback
-function to handle messages received on that port. We use a Boost bind
-operator to bind the message port to the message handling
-function. When a new message is pushed onto a port's message queue,
-it is this function that is used to process the message.
 
+\section msg_passing_posting Posting from External Sources
 
-\section msg_passing_python Message Passing in Python Blocks
+An important feature of the message passing architecture
+is how it can be used to take in messages from an external source. We
+can call a block's gr::basic_block::_post method directly and pass it a
+message. So any block with an input message port can receive messages
+from the outside in this way.
+
+The following example uses a gr::blocks::pdu_to_tagged_stream block
+as the source block to a flowgraph. Its purpose is to wait for
+messages as PDUs posted to it and convert them to a normal stream. The
+payload will be sent on as a normal stream while the meta data will be
+decoded into tags and sent on the tagged stream.
+
+So if we have created a \b src block as a PDU to stream, it has a \a
+pdus input port, which is how we will inject PDU messages into the
+flowgraph. These PDUs could come from another block or flowgraph, but
+here, we will create and insert them by hand.
+
+\code
+  port = pmt.intern("pdus")
+  msg = pmt.cons(pmt.PMT_NIL, pmt.make_u8vector(16, 0xFF))
+  src.to_basic_block()._post(port, msg)
+\endcode
+
+The PDU's metadata section is empty, hence the pmt::PMT_NIL
+object. The payload is now just a simple vector of 16 bytes of all
+1's. To post the message, we have to access the block's gr::basic_block
+class, which we do using the gr::basic_block::to_basic_block method and
+then call the gr::basic_block::_post method to pass the PDU to the
+right port.
+
+All of these mechanisms are explored and tested in the QA code of the
+file qa_pdu.py.
+
+There are some examples of using the message passing infrastructure
+through GRC in gr-blocks/examples/msg_passing.
+
+
+\section msg_passing_commands Using messages as commands
+
+One important use of messages is to send commands to blocks. Examples for this include:
+
+- gr::qtgui::freq_sink_c: The scaling of the frequency axis can be changed by messages
+- gr::uhd::usrp_source and gr::uhd::usrp_sink: Many transceiver-related settings can
+  be manipulated through command messages, such as frequency, gain and LO offset
+- gr::digital::header_payload_demux, which receives an acknowledgement from a header parser
+  block on how many payload items there are to process
+
+There is no special PMT type to encode commands, however, it is strongly recommended
+to use one of the following formats:
+
+- pmt::cons(KEY, VALUE): This format is useful for commands that take a single value.
+  Think of KEY and VALUE as the argument name and value, respectively. For the case of
+  the QT GUI Frequency Sink, KEY would be "freq" and VALUE would be the new center frequency
+  in Hz.
+- pmt::dict((KEY1: VALUE1), (KEY2: VALUE2), ...): This is basically the same as the
+  previous format, but you can provide multiple key/value pairs. This is particularly
+  useful when a single command takes multiple arguments which can't be broken into
+  multiple command messages (e.g., the USRP blocks might have both a timestamp and a
+  center frequency in a command message, which are closely associated).
+
+In both cases, all KEYs should be pmt::symbols (i.e. strings). VALUEs can be
+whatever the block requires.
+
+It might be tempting to deviate from this format, e.g. the QT Frequency sink could
+simply take a float value as a command message, and it would still work fine.
+However, there are some very good reasons to stick to this format:
 
-ADD STUFF HERE
+- Interoperability: The more people use the standard format, the more likely it
+  is that blocks from different sources can work together
+- Inspectability: A message debug block will display more useful information about
+  a message if it's containing both a value and a key
+- Intuition: This format is pretty versatile and unlikely to create situations
+  where it is not sufficient (especially considering that values are PMTs themselves).
+  As a counterexample, using positional arguments (something like "the first argument
+  is the frequency, the second the gain") is easily forgotten, or changed in one place
+  and not another, etc.
 
 
 \section msg_passing_examples Code Examples
 
-The following is snippets of code from blocks current in GNU Radio
+The following is snippets of code from blocks currently in GNU Radio
 that take advantage of message passing. We will be using
 gr::blocks::message_debug and gr::blocks::tagged_stream_to_pdu below
 to show setting up both input and output message passing capabilities.
@@ -193,10 +288,10 @@ The constructor of this block looks like this:
 }
 \endcode
 
-So the three ports are registered by their respective names. We then
-use the gr::basic_block::set_msg_handler function to identify this
-particular port name with a callback function. The Boost \a bind
-function (<a target="_blank"
+The three message input ports are registered by their respective
+names. We then use the gr::basic_block::set_msg_handler function to 
+identify this particular port name with a callback function. The 
+Boost \a bind function (<a target="_blank"
 href="http://www.boost.org/doc/libs/1_52_0/libs/bind/bind.html">Boost::bind</a>)
 here binds the callback to a function of this block's class. So now
 the functions in the block's private implementation class,
@@ -217,7 +312,7 @@ message_debug_impl::print(pmt::pmt_t msg)
 
 The function simply takes in the PMT message and prints it. The method
 pmt::print is a function in the PMT library to print the
-PMT in a friendly, (mostly) pretty manner.
+PMT in a friendly and (mostly) pretty manner.
 
 The gr::blocks::tagged_stream_to_pdu block only defines a single
 output message port. In this case, its constructor contains the line:
@@ -231,8 +326,8 @@ output message port. In this case, its constructor contains the line:
 So we are only creating a single output port where \a pdu_port_id
 is defined in the file pdu.h as \a pdus.
 
-This blocks purpose is to take in a stream of samples along with
-stream tags and construct a predefined PDU message from this. In GNU
+This block's purpose is to take in a stream of samples along with
+stream tags and construct a predefined PDU message from it. In GNU
 Radio, we define a PDU as a PMT pair of (metadata, data). The metadata
 describes the samples found in the data portion of the
 pair. Specifically, the metadata can contain the length of the data
@@ -266,7 +361,7 @@ tagged_stream_to_pdu_impl::send_message()
 }
 \endcode
 
-This function does a bit of checking to make sure the PDU is ok as
+This function does a bit of checking to make sure the PDU is OK as
 well as some cleanup in the end. But it is the line where the message
 is published that is important to this discussion. Here, the block
 posts the PDU message to any subscribers by calling
@@ -281,83 +376,6 @@ them. The data is then converted into an output stream of items and
 passed along. The next section describes how PDUs can be passed into a
 flowgraph using the gr::blocks::pdu_to_tagged_stream block.
 
-\section msg_passing_posting Posting from External Sources
-
-The last feature of the message passing architecture to discuss here
-is how it can be used to take in messages from an external source. We
-can call a block's gr::basic_block::_post method directly and pass it a
-message. So any block with an input message port can receive messages
-from the outside in this way.
-
-The following example uses a gr::blocks::pdu_to_tagged_stream block
-as the source block to a flowgraph. Its purpose is to wait for
-messages as PDUs posted to it and convert them to a normal stream. The
-payload will be sent on as a normal stream while the meta data will be
-decoded into tags and sent on the tagged stream.
-
-So if we have created a \b src block as a PDU to stream, it has a \a
-pdus input port, which is how we will inject PDU messages to the
-flowgraph. These PDUs could come from another block or flowgraph, but
-here, we will create and insert them by hand.
-
-\code
-  port = pmt.intern("pdus")
-  msg = pmt.cons(pmt.PMT_NIL,
-                 pmt.make_u8vector(16, 0xFF))
-  src.to_basic_block()._post(port, msg)
-\endcode
-
-The PDU's metadata section is empty, hence the pmt::PMT_NIL
-object. The payload is now just a simple vector of 16 bytes of all
-1's. To post the message, we have to access the block's gr::basic_block
-class, which we do using the gr::basic_block::to_basic_block method and
-then call the gr::basic_block::_post method to pass the PDU to the
-right port.
-
-All of these mechanisms are explored and tested in the QA code of the
-file qa_pdu.py.
-
-There are some examples of using the message passing infrastructure
-through GRC in gr-blocks/examples/msg_passing.
-
-\section msg_passing_commands Using messages as commands
-
-Messages can be used to send commands to blocks. Examples for this include:
-
-- gr::qtgui::freq_sink_c: The scaling of the frequency axis can be changed by messages
-- gr::uhd::usrp_source and gr::uhd::usrp_sink: Many transceiver-related settings can
-  be manipulated through command messages, such as frequency, gain and LO offset
-- gr::digital::header_payload_demux, which receives an acknowledgement from a header parser
-  block on how many payload items there are to process
-
-There is no special PMT type to encode commands, however, it is strongly recommended
-to use one of the following formats:
-
-- pmt::cons(KEY, VALUE): This format is useful for commands that take a single value.
-  Think of KEY and VALUE as the argument name and value, respectively. For the case of
-  the QT GUI Frequency Sink, KEY would be "freq" and VALUE would be the new center frequency
-  in Hz.
-- pmt::dict((KEY1: VALUE1), (KEY2: VALUE2), ...): This is basically the same as the
-  previous format, but you can provide multiple key/value pairs. This is particularly
-  useful when a single command takes multiple arguments which can't be broken into
-  multiple command messages (e.g., the USRP blocks might have both a timestamp and a
-  center frequency in a command message, which are closely associated).
-
-In both cases, all KEYs should be pmt::symbols (i.e. strings). VALUEs can be
-whatever the block requires.
-
-It might be tempting to deviate from this format, e.g. the QT Frequency sink could
-simply take a float value as a command message, and it would still work fine.
-However, there are some very good reasons to stick to this format:
-
-- Interoperability: The more people use the standard format, the more likely it
-  is that blocks from different sources can work together
-- Inspectability: A message debug block will display more useful information about
-  a message if its containing both a value and a key
-- Intuition: This format is pretty versatile and unlikely to create situations
-  where it is not sufficient (especially considering that values are PMTs themselves).
-  As a counterexample, using positional arguments (something like "the first argument
-  is the frequency, the second the gain") is easily forgotten, or changed in one place
-  and not another, etc.
+For a Python block example, see \ref pyblocks_msgs.
 
 */
diff --git a/gr-blocks/lib/tuntap_pdu_impl.cc b/gr-blocks/lib/tuntap_pdu_impl.cc
index 391b33937a..7bd0889d5e 100644
--- a/gr-blocks/lib/tuntap_pdu_impl.cc
+++ b/gr-blocks/lib/tuntap_pdu_impl.cc
@@ -57,7 +57,7 @@ namespace gr {
       :	block("tuntap_pdu",
 		 io_signature::make (0, 0, 0),
 		 io_signature::make (0, 0, 0)),
-	stream_pdu_base(MTU),
+	stream_pdu_base(istunflag ? MTU : MTU + 14),
 	d_dev(dev),
 	d_istunflag(istunflag)
     {
diff --git a/gr-dtv/lib/dvbt/dvbt_reference_signals_impl.cc b/gr-dtv/lib/dvbt/dvbt_reference_signals_impl.cc
index aa581aeda8..f92f9fa6d8 100644
--- a/gr-dtv/lib/dvbt/dvbt_reference_signals_impl.cc
+++ b/gr-dtv/lib/dvbt/dvbt_reference_signals_impl.cc
@@ -908,7 +908,12 @@ namespace gr {
       //Clause 4.6.2.9
       set_tps_bits(39, 38, config.d_transmission_mode);
       //Clause 4.6.2.10
-      set_tps_bits(47, 40, config.d_cell_id);
+      if (d_frame_index % 2) {
+        set_tps_bits(47, 40, config.d_cell_id & 0xff);
+      }
+      else {
+        set_tps_bits(47, 40, (config.d_cell_id >> 8) & 0xff);
+      }
       //These bits are set to zero
       set_tps_bits(53, 48, 0);
       //Clause 4.6.2.11
diff --git a/gr-zeromq/include/gnuradio/zeromq/pub_msg_sink.h b/gr-zeromq/include/gnuradio/zeromq/pub_msg_sink.h
index 8cf4bcfab4..fb046ca84b 100644
--- a/gr-zeromq/include/gnuradio/zeromq/pub_msg_sink.h
+++ b/gr-zeromq/include/gnuradio/zeromq/pub_msg_sink.h
@@ -49,7 +49,7 @@ namespace gr {
        * \brief Return a shared_ptr to a new instance of zeromq::pub_msg_sink.
        *
        * \param address  ZMQ socket address specifier
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments
        */
       static sptr make(char *address, int timeout=100);
     };
diff --git a/gr-zeromq/include/gnuradio/zeromq/pub_sink.h b/gr-zeromq/include/gnuradio/zeromq/pub_sink.h
index e87c5522f9..3fecc10b59 100644
--- a/gr-zeromq/include/gnuradio/zeromq/pub_sink.h
+++ b/gr-zeromq/include/gnuradio/zeromq/pub_sink.h
@@ -51,7 +51,7 @@ namespace gr {
        * \param itemsize Size of a stream item in bytes.
        * \param vlen Vector length of the input items. Note that one vector is one item.
        * \param address  ZMQ socket address specifier.
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments.
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments.
        * \param pass_tags Whether sink will serialize and pass tags over the link.
        * \param hwm High Watermark to configure the socket to (-1 => zmq's default)
        */
diff --git a/gr-zeromq/include/gnuradio/zeromq/pull_msg_source.h b/gr-zeromq/include/gnuradio/zeromq/pull_msg_source.h
index 17495152b8..13857ead5f 100644
--- a/gr-zeromq/include/gnuradio/zeromq/pull_msg_source.h
+++ b/gr-zeromq/include/gnuradio/zeromq/pull_msg_source.h
@@ -46,7 +46,7 @@ namespace gr {
        * \brief Return a shared_ptr to a new instance of gr::zeromq::pull_msg_source.
        *
        * \param address  ZMQ socket address specifier
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments
        *
        */
       static sptr make(char *address, int timeout=100);
diff --git a/gr-zeromq/include/gnuradio/zeromq/pull_source.h b/gr-zeromq/include/gnuradio/zeromq/pull_source.h
index 07cf6af128..ecfe508b0a 100644
--- a/gr-zeromq/include/gnuradio/zeromq/pull_source.h
+++ b/gr-zeromq/include/gnuradio/zeromq/pull_source.h
@@ -48,7 +48,7 @@ namespace gr {
        * \param itemsize Size of a stream item in bytes.
        * \param vlen Vector length of the input items. Note that one vector is one item.
        * \param address  ZMQ socket address specifier.
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments.
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments.
        * \param pass_tags Whether source will look for and deserialize tags.
        * \param hwm High Watermark to configure the socket to (-1 => zmq's default)
        */
diff --git a/gr-zeromq/include/gnuradio/zeromq/push_msg_sink.h b/gr-zeromq/include/gnuradio/zeromq/push_msg_sink.h
index 3ce6ebbdc0..941ad549f5 100644
--- a/gr-zeromq/include/gnuradio/zeromq/push_msg_sink.h
+++ b/gr-zeromq/include/gnuradio/zeromq/push_msg_sink.h
@@ -48,7 +48,7 @@ namespace gr {
        * \brief Return a shared_ptr to a new instance of gr::zeromq::push_msg_sink
        *
        * \param address  ZMQ socket address specifier
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments
        *
        */
       static sptr make(char *address, int timeout=100);
diff --git a/gr-zeromq/include/gnuradio/zeromq/push_sink.h b/gr-zeromq/include/gnuradio/zeromq/push_sink.h
index e2260aa3f6..f81dcaa941 100644
--- a/gr-zeromq/include/gnuradio/zeromq/push_sink.h
+++ b/gr-zeromq/include/gnuradio/zeromq/push_sink.h
@@ -52,7 +52,7 @@ namespace gr {
        * \param itemsize Size of a stream item in bytes.
        * \param vlen Vector length of the input items. Note that one vector is one item.
        * \param address  ZMQ socket address specifier.
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments.
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments.
        * \param pass_tags Whether sink will serialize and pass tags over the link.
        * \param hwm High Watermark to configure the socket to (-1 => zmq's default)
        */
diff --git a/gr-zeromq/include/gnuradio/zeromq/rep_msg_sink.h b/gr-zeromq/include/gnuradio/zeromq/rep_msg_sink.h
index 97f3d831ad..d11550d149 100644
--- a/gr-zeromq/include/gnuradio/zeromq/rep_msg_sink.h
+++ b/gr-zeromq/include/gnuradio/zeromq/rep_msg_sink.h
@@ -48,7 +48,7 @@ namespace gr {
        * \brief Return a shared_ptr to a new instance of zeromq::rep_msg_sink.
        *
        * \param address  ZMQ socket address specifier
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments
        *
        */
       static sptr make(char *address, int timeout=100);
diff --git a/gr-zeromq/include/gnuradio/zeromq/rep_sink.h b/gr-zeromq/include/gnuradio/zeromq/rep_sink.h
index 220bd34416..c1d2d370fc 100644
--- a/gr-zeromq/include/gnuradio/zeromq/rep_sink.h
+++ b/gr-zeromq/include/gnuradio/zeromq/rep_sink.h
@@ -50,7 +50,7 @@ namespace gr {
        * \param itemsize Size of a stream item in bytes.
        * \param vlen Vector length of the input items. Note that one vector is one item.
        * \param address  ZMQ socket address specifier.
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments.
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments.
        * \param pass_tags Whether sink will serialize and pass tags over the link.
        * \param hwm High Watermark to configure the socket to (-1 => zmq's default)
        */
diff --git a/gr-zeromq/include/gnuradio/zeromq/req_msg_source.h b/gr-zeromq/include/gnuradio/zeromq/req_msg_source.h
index 05d80b8e7f..28ac9f84f3 100644
--- a/gr-zeromq/include/gnuradio/zeromq/req_msg_source.h
+++ b/gr-zeromq/include/gnuradio/zeromq/req_msg_source.h
@@ -46,7 +46,7 @@ namespace gr {
        * \brief Return a shared_ptr to a new instance of zeromq::req_msg_source.
        *
        * \param address  ZMQ socket address specifier
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments
        *
        */
       static sptr make(char *address, int timeout=100);
diff --git a/gr-zeromq/include/gnuradio/zeromq/req_source.h b/gr-zeromq/include/gnuradio/zeromq/req_source.h
index 461f653b43..103da90f71 100644
--- a/gr-zeromq/include/gnuradio/zeromq/req_source.h
+++ b/gr-zeromq/include/gnuradio/zeromq/req_source.h
@@ -48,7 +48,7 @@ namespace gr {
        * \param itemsize Size of a stream item in bytes.
        * \param vlen Vector length of the input items. Note that one vector is one item.
        * \param address  ZMQ socket address specifier.
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments.
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments.
        * \param pass_tags Whether source will look for and deserialize tags.
        * \param hwm High Watermark to configure the socket to (-1 => zmq's default)
        */
diff --git a/gr-zeromq/include/gnuradio/zeromq/sub_msg_source.h b/gr-zeromq/include/gnuradio/zeromq/sub_msg_source.h
index d06a83c1fd..5c91d1e1ed 100644
--- a/gr-zeromq/include/gnuradio/zeromq/sub_msg_source.h
+++ b/gr-zeromq/include/gnuradio/zeromq/sub_msg_source.h
@@ -46,7 +46,7 @@ namespace gr {
        * \brief Return a shared_ptr to a new instance of gr::zeromq::sub_msg_source.
        *
        * \param address  ZMQ socket address specifier
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments
        *
        */
       static sptr make(char *address, int timeout=100);
diff --git a/gr-zeromq/include/gnuradio/zeromq/sub_source.h b/gr-zeromq/include/gnuradio/zeromq/sub_source.h
index def3a703e6..990c74cabd 100644
--- a/gr-zeromq/include/gnuradio/zeromq/sub_source.h
+++ b/gr-zeromq/include/gnuradio/zeromq/sub_source.h
@@ -48,7 +48,7 @@ namespace gr {
        * \param itemsize Size of a stream item in bytes.
        * \param vlen Vector length of the input items. Note that one vector is one item.
        * \param address  ZMQ socket address specifier.
-       * \param timeout  Receive timeout in seconds, default is 100ms, 1us increments.
+       * \param timeout  Receive timeout in milliseconds, default is 100ms, 1us increments.
        * \param pass_tags Whether source will look for and deserialize tags.
        * \param hwm High Watermark to configure the socket to (-1 => zmq's default)
        */