FEC Async Decoder: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
[[Category:Block Docs]]
[[Category:Block Docs]]
[[Category:Stub Docs]]
Decodes frames received as async messages over a message port. This decoder deployment expects messages of soft decision symbols in and can produce either packed, PDU messages (packed = True) or messages full of unpacked bits (packed = False).
This is the template for the [[:Category:Block_Docs|"Page-per-block Docs"]]. This first section should describe what the block does and how to use it, using however many paragraphs necessary.  Note that the title of the wiki page should match the block's name in GRC, i.e. the one defined in the block's .grc file.  Look at the [[FFT]] Block for a good example.


As this is a basic template, it's also in the [[:Category:Stub_Docs|"Stub Docs category"]]. Please improve it.
This decoder works off a full message as one frame or block to decode. The message length is used to calculate the frame length. To support this, the decoder variable used will have had its frame_size set. This block treats that initial frame_size value as the maximum transmission unit (MTU) and will not process frames larger than that after being decoded.
 
The packed PDU form of this deployment is designed to work well with other PDU-based blocks to operate within the processing flow of data packets or frames.
 
Due to differences in how data is packed and processed, this block also offers the ability to change the direction of how bits are packed. All inputs messages are one soft decision per item. By default, the rev_pack mode is set to True. Using this setup allows the async block to behave with PDUs in the same operation and format as the tagged stream decoders. That is, putting the same data into both the tagged stream decoder deployment and this with the default setting should produce the same data.
 
Because the block handles data as a full frame per message, this decoder deployment cannot work with any decoders that require history. For example, the gr::fec::code::cc_decoder decoder in streaming mode requires an extra rate*(K-1) bits to complete the decoding, so it would have to wait for the next message to come in and finish processing. Therefore, the streaming mode of the CC decoder is not allowed. The other three modes will work with this deployment since the frame is self-contained for decoding.


== Parameters ==
== Parameters ==


; Decoder Obj.
; Decoder Obj.
: Description of parameter, provide any tips or recommended values.  Note that the name of the parameter above should match the param's label that shows up in grc (e.g. Sample Rate).
: An FECAPI decoder object child of the generic_decoder class.


; MTU (bytes)
; MTU (bytes)
: blah blah blah
: The Maximum Transmission Unit (MTU) of the output frame that the block will be able to process. Specified in bytes and defaults to 1500.


; Packed
; Packed
:  
: Sets output to packed bytes if true; otherwise, 1 bit per byte.


; Rev. Packing
; Rev. Packing
:  
: If packing bits, should they be reversed?


== Example Flowgraph ==
== Example Flowgraph ==
Line 26: Line 31:


; C++ files
; C++ files
: [https://github.com/gnuradio/gnuradio TODO]
: [https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/async_decoder_impl.cc]


; Header files
; Header files
: [https://github.com/gnuradio/gnuradio TODO]
: [https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/async_decoder_impl.h]


; Public header files
; Public header files
: [https://github.com/gnuradio/gnuradio TODO]
: [https://github.com/gnuradio/gnuradio/blob/master/gr-fec/include/gnuradio/fec/async_decoder.h]


; Block definition
; Block definition
: [https://github.com/gnuradio/gnuradio/blob/master/gr-fec/grc/fec_async_decoder.block.yml]
: [https://github.com/gnuradio/gnuradio/blob/master/gr-fec/grc/fec_async_decoder.block.yml]

Revision as of 08:46, 12 September 2019

Decodes frames received as async messages over a message port. This decoder deployment expects messages of soft decision symbols in and can produce either packed, PDU messages (packed = True) or messages full of unpacked bits (packed = False).

This decoder works off a full message as one frame or block to decode. The message length is used to calculate the frame length. To support this, the decoder variable used will have had its frame_size set. This block treats that initial frame_size value as the maximum transmission unit (MTU) and will not process frames larger than that after being decoded.

The packed PDU form of this deployment is designed to work well with other PDU-based blocks to operate within the processing flow of data packets or frames.

Due to differences in how data is packed and processed, this block also offers the ability to change the direction of how bits are packed. All inputs messages are one soft decision per item. By default, the rev_pack mode is set to True. Using this setup allows the async block to behave with PDUs in the same operation and format as the tagged stream decoders. That is, putting the same data into both the tagged stream decoder deployment and this with the default setting should produce the same data.

Because the block handles data as a full frame per message, this decoder deployment cannot work with any decoders that require history. For example, the gr::fec::code::cc_decoder decoder in streaming mode requires an extra rate*(K-1) bits to complete the decoding, so it would have to wait for the next message to come in and finish processing. Therefore, the streaming mode of the CC decoder is not allowed. The other three modes will work with this deployment since the frame is self-contained for decoding.

Parameters

Decoder Obj.
An FECAPI decoder object child of the generic_decoder class.
MTU (bytes)
The Maximum Transmission Unit (MTU) of the output frame that the block will be able to process. Specified in bytes and defaults to 1500.
Packed
Sets output to packed bytes if true; otherwise, 1 bit per byte.
Rev. Packing
If packing bits, should they be reversed?

Example Flowgraph

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.

Source Files

C++ files
[1]
Header files
[2]
Public header files
[3]
Block definition
[4]