Editing Header/Payload Demux

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 12: Line 12:
 
===Symbols, Items and Item Sizes===
 
===Symbols, Items and Item Sizes===
  
To generically and transparently handle different kinds of modulations, including OFDM, this block distinguishes between symbols and items.
+
To generically and transparently handle different kinds of modulations, including OFDM, this block distinguises between symbols and items.
  
 
Items are what are consumed at the input. Anything that uses complex samples will therefore use an itemsize of <code>sizeof(gr_complex)</code>. Symbols are a way of grouping items. In OFDM, we usually don't care about individual samples, but we do care about full OFDM symbols, so we set <code>items_per_symbol</code> to the IFFT / FFT length of the OFDM modulator / demodulator. For single-carrier modulations, this value can be set to the number of samples per symbol, to handle data in number of symbols, or to 1 to handle data in number of samples. If specified, guard_interval items are discarded before every symbol. This is useful for demuxing bursts of OFDM signals.
 
Items are what are consumed at the input. Anything that uses complex samples will therefore use an itemsize of <code>sizeof(gr_complex)</code>. Symbols are a way of grouping items. In OFDM, we usually don't care about individual samples, but we do care about full OFDM symbols, so we set <code>items_per_symbol</code> to the IFFT / FFT length of the OFDM modulator / demodulator. For single-carrier modulations, this value can be set to the number of samples per symbol, to handle data in number of symbols, or to 1 to handle data in number of samples. If specified, guard_interval items are discarded before every symbol. This is useful for demuxing bursts of OFDM signals.
Line 23: Line 23:
 
====Example:====
 
====Example:====
 
PSK-modulated signals, with 4 samples per symbol. Again, itemsize is <code>sizeof(gr_complex)</code> because we're still dealing with complex samples. items_per_symbol is 4, because one item is one sample. <code>guard_interval</code> must be set to 0. The header length is given in number of PSK symbols.
 
PSK-modulated signals, with 4 samples per symbol. Again, itemsize is <code>sizeof(gr_complex)</code> because we're still dealing with complex samples. items_per_symbol is 4, because one item is one sample. <code>guard_interval</code> must be set to 0. The header length is given in number of PSK symbols.
 
 
===Handling timing uncertainty on the trigger===
 
===Handling timing uncertainty on the trigger===
  
 
By default, the assumption is made that the trigger arrives on exactly the sample that the header starts. These triggers typically come from timing synchronization algorithms which may be suboptimal, and have a known timing uncertainty (e.g., we know the trigger might be a sample too early or too late).
 
By default, the assumption is made that the trigger arrives on exactly the sample that the header starts. These triggers typically come from timing synchronization algorithms which may be suboptimal, and have a known timing uncertainty (e.g., we know the trigger might be a sample too early or too late).
  
The demuxer has an option for this case, the <code>header_padding.</code> If this value is non-zero, it specifies the number of items that are prepended and appended to the header before copying it to the header output.
+
The demuxer has an option for this case, the header_padding. If this value is non-zero, it specifies the number of items that are prepended and appended to the header before copying it to the header output.
  
 
====Example:====
 
====Example:====
Say our synchronization algorithm can be off by up to two samples, and the header length is 20 samples. So we set <code>header_len</code> to 20, and <code>header_padding</code> to 2. Now assume a trigger arrives on sample of index 100. We copy a total of 24 samples to the header port <code>out_hdr</code>, starting at sample of index 98.
+
Say our synchronization algorithm can be off by up to two samples, and the header length is 20 samples. So we set header_len to 20, and header_padding to 2. Now assume a trigger arrives on sample index 100. We copy a total of 24 samples to the header port, starting at sample index 98.
  
====Payload and padding====
+
===Padding===
 
The payload is not padded. Let's say the header demod reports a payload length of 100. In the previous examples, we would copy 100 samples to the payload port, starting at sample index 120 (this means the padded samples appended to the header are copied to both ports!). However, the header demodulator has the option to specify a payload offset, which cannot exceed the padding value. To do this, include a key <code>payload_offset</code> in the message sent back to the HPD. A negative value means the payload starts earlier than otherwise. (If you wanted to always pad the payload, you could set payload_offset to -header_padding and increase the reported length of the payload).
 
The payload is not padded. Let's say the header demod reports a payload length of 100. In the previous examples, we would copy 100 samples to the payload port, starting at sample index 120 (this means the padded samples appended to the header are copied to both ports!). However, the header demodulator has the option to specify a payload offset, which cannot exceed the padding value. To do this, include a key <code>payload_offset</code> in the message sent back to the HPD. A negative value means the payload starts earlier than otherwise. (If you wanted to always pad the payload, you could set payload_offset to -header_padding and increase the reported length of the payload).
  
Line 45: Line 44:
  
 
# Timing tags might be relevant to know when a packet was received. By specifying the name of a timestamp tag and the sample rate at this block, it keeps track of the time and will add the time to the first item of every packet. The name of the timestamp tag is usually 'rx_time' (see, e.g., gr::uhd::usrp_source::make()). The time value must be specified in the UHD time format.
 
# Timing tags might be relevant to know when a packet was received. By specifying the name of a timestamp tag and the sample rate at this block, it keeps track of the time and will add the time to the first item of every packet. The name of the timestamp tag is usually 'rx_time' (see, e.g., gr::uhd::usrp_source::make()). The time value must be specified in the UHD time format.
 +
 
# Other tags are simply stored and updated. As an example, the user might want to know the rx frequency, which UHD stores in the rx_freq tag. In this case, add the tag name 'rx_freq' to the list of special_tags. This block will then always save the most current value of 'rx_freq' and add it to the beginning of every packet.
 
# Other tags are simply stored and updated. As an example, the user might want to know the rx frequency, which UHD stores in the rx_freq tag. In this case, add the tag name 'rx_freq' to the list of special_tags. This block will then always save the most current value of 'rx_freq' and add it to the beginning of every packet.
  
Line 80: Line 80:
 
== Example Flowgraph ==
 
== Example Flowgraph ==
  
This flowgraph can be found at [https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/packet/packet_rx.grc]
+
Insert description of flowgraph here, then show a screenshot of the flowgraph and the output if there is an interesting GUI. Currently we have no standard method of uploading the actual flowgraph to the wiki or git repo, unfortunately. The plan is to have an example flowgraph showing how the block might be used, for every block, and the flowgraphs will live in the git repo.
 
 
[[File:Packet_rx_fg.png|800px]]
 
  
 
== Source Files ==
 
== Source Files ==

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)