Editing Message Passing

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 190: Line 190:
 
* gr::qtgui::freq_sink_c: The scaling of the frequency axis can be changed by messages
 
* 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::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
+
* 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
 
There is no special PMT type to encode commands, however, it is strongly recommended
 
to use one of the following formats:
 
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::cons(KEY, VALUE): This format is useful for commands that take a single value.
* 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).
+
  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
 
In both cases, all KEYs should be pmt::symbols (i.e. strings). VALUEs can be
Line 205: Line 213:
 
However, there are some very good reasons to stick to this format:
 
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
+
* Interoperability: The more people use the standard format, the more likely it
* Inspectability: A message debug block will display more useful information about a message if it's containing both a value and a key
+
  is that blocks from different sources can work together
* 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.
+
* 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.
  
 
== Code Examples ==
 
== Code Examples ==

Please note that all contributions to GNU Radio are considered to be released under the Creative Commons Attribution-ShareAlike (see GNU Radio:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)