Correlate Access Code: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(Created page with "Category:Block Docs Examine input for specified access code, one bit at a time. input: stream of bits, 1 bit per input byte (data in LSB) output: stream of bits, 2 bits...")
 
(Added link to "Correlate Access Code - Tag" block, as that was the replacement for this block.)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Block Docs]]
[[Category:Block Docs]]
Examine input for specified access code, one bit at a time.
Examine input for specified access code, one bit at a time.
<br><code>This block has been deprecated in 3.8</code>. It has been replaced by [[Correlate_Access_Code_-_Tag| Correlated Access Code - Tag]].


input: stream of bits, 1 bit per input byte (data in LSB)
input: stream of bits, 1 bit per input byte (data in LSB)
Line 10: Line 11:
== Parameters ==
== Parameters ==
; Access Code
; Access Code
: is represented with 1 byte per bit, e.g., "010101010111000100"
: is represented with 1 byte per bit, e.g., <code>010101010111000100</code>
 
:It is important to choose an access code that is not "cyclical".  A cyclical code contains a repetition of itself within the length of the code.  This can cause false access code detections, and will cause byte boundaries (and hence valid packet length and payload recovery) to be recovered in error, with bizarre results!
 
:For example, an access code of <code>11111111</code> is a poor choice because it is cyclical. Let's look at why this is.
 
:The first eight <code>1</code> bits in a row from the block's input stream will correctly detect the first access code.  The first packet (in standard form <code><access code> <length1> <length2> <payload></code>) will be recovered nominally. 
 
:However, when the correlate access code block's state machine goes back into scanning/detection mode after the first packet, the first bit of the NEXT access code (which forms the <code>11111111</code> preamble of the next packet) will cause an immediate access code detection.  This is because the access code detection routine within the block always shifts the last detected access code one bit to the left, and ORs in the current input bit.
 
:In our example, the valid bits <code>11111111</code> from the first access code detected will get shifted left one bit (to give <code>11111110</code>), and then the next input bit (the first bit after the end of the first packet) will be ORed into the value (<code>11111110 OR 1</code>, giving <code>11111111</code>) resulting in an erroneous detection of the next access code, because <code>11111111</code> will of course match the access code that the block is searching for. 
 
:This will falsely detect the start of the next packet (alignment off by 7 bits) and your flowgraph will explode with subsequent bad headers and invalid data.  Not a pretty sight.
 
:So, when choosing an access code, select one that is not cyclical!
 
:A possible (and historically interesting) non-cyclical 32-bit access code might be 0xe15ae893:
 
:<code>11100001010110101110100010010011</code>
 
:which was the "unique word" used on several early communications satellites.
 


; Threshold
; Threshold

Latest revision as of 22:33, 6 July 2024

Examine input for specified access code, one bit at a time.
This block has been deprecated in 3.8. It has been replaced by Correlated Access Code - Tag.

input: stream of bits, 1 bit per input byte (data in LSB)

output: stream of bits, 2 bits per output byte (data in LSB, flag in next higher bit)

Each output byte contains two valid bits, the data bit, and the flag bit. The LSB (bit 0) is the data bit, and is the original input data, delayed 64 bits. Bit 1 is the flag bit and is 1 if the corresponding data bit is the first data bit following the access code. Otherwise the flag bit is 0.

Parameters

Access Code
is represented with 1 byte per bit, e.g., 010101010111000100
It is important to choose an access code that is not "cyclical". A cyclical code contains a repetition of itself within the length of the code. This can cause false access code detections, and will cause byte boundaries (and hence valid packet length and payload recovery) to be recovered in error, with bizarre results!
For example, an access code of 11111111 is a poor choice because it is cyclical. Let's look at why this is.
The first eight 1 bits in a row from the block's input stream will correctly detect the first access code. The first packet (in standard form <access code> <length1> <length2> <payload>) will be recovered nominally.
However, when the correlate access code block's state machine goes back into scanning/detection mode after the first packet, the first bit of the NEXT access code (which forms the 11111111 preamble of the next packet) will cause an immediate access code detection. This is because the access code detection routine within the block always shifts the last detected access code one bit to the left, and ORs in the current input bit.
In our example, the valid bits 11111111 from the first access code detected will get shifted left one bit (to give 11111110), and then the next input bit (the first bit after the end of the first packet) will be ORed into the value (11111110 OR 1, giving 11111111) resulting in an erroneous detection of the next access code, because 11111111 will of course match the access code that the block is searching for.
This will falsely detect the start of the next packet (alignment off by 7 bits) and your flowgraph will explode with subsequent bad headers and invalid data. Not a pretty sight.
So, when choosing an access code, select one that is not cyclical!
A possible (and historically interesting) non-cyclical 32-bit access code might be 0xe15ae893:
11100001010110101110100010010011
which was the "unique word" used on several early communications satellites.


Threshold
maximum number of bits that may be wrong

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
TODO
Header files
TODO
Public header files
TODO
Block definition
TODO