Editing Correlate Access Code - Tag Stream

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 14: Line 14:
== Parameters ==
== Parameters ==
; Access Code
; Access Code
: is represented with 1 byte per bit, e.g., <code>010101010111000100</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 <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 site.
: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:
:which was the "unique word" used on several early communications satellites.
; Threshold
; Threshold

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)