Documentation
¶
Overview ¶
Package pn generates the CCSDS pseudo-randomizer sequences used by the TM and TC synchronization and channel coding layers.
TM and TC do NOT share a randomizer. Both are 8-bit linear feedback shift registers preset to all ones, and both repeat after 255 bits, but the polynomials differ:
CCSDS 131.0-B-5 clause 10.4.2 (TM) h(x) = x^8 + x^7 + x^5 + x^3 + 1 CCSDS 231.0-B-4 clause 6.2 (TC) h(x) = x^8 + x^6 + x^4 + x^3 + x^2 + x + 1
The two sequences diverge at the second octet (TM opens FF 48 0E C0 9A and TC opens FF 39 9E 5A 68) so equipment fed the wrong one recovers noise. The generators are therefore named for the standard they belong to, and neither name is available unqualified: TMSequence and TMApply are for pkg/tmsc, TCSequence and TCApply are for pkg/tcsc.
Nothing about a randomizer can be checked by round-tripping it. XOR is its own inverse, so any sequence at all (right taps, wrong taps, or a constant) randomizes and derandomizes back to the input. Correctness here rests entirely on the vectors CCSDS publishes; see the tests.
pkg/ocsc deliberately does not use this. The optical randomizer of CCSDS 142.0-B works on blocks that are not a whole number of octets, so it needs a bit-addressable implementation of its own.
Index ¶
Constants ¶
const Period = 255
Period is the length in octets after which either sequence repeats.
Each register is 8 bits with a maximal-length polynomial, so the bit sequence has period 2^8-1 = 255. Since 255 and 8 share no factor, the octet sequence only realigns after 255 octets.
Variables ¶
This section is empty.
Functions ¶
func TCApply ¶ added in v0.4.0
TCApply XORs data with the TC sequence and returns a new slice, leaving the input untouched. Like TMApply it is its own inverse, and like TMApply that property proves nothing about the taps being right.
func TCSequence ¶ added in v0.4.0
TCSequence returns the first length octets of the TC randomizer sequence of CCSDS 231.0-B-4 clause 6.2. It opens FF 39 9E 5A 68, which is a different sequence from TMSequence, see the package comment.
It is cached and tiled exactly like the TM sequence.
func TMApply ¶ added in v0.4.0
TMApply XORs data with the TM sequence and returns a new slice, leaving the input untouched. The operation is its own inverse, so it both randomizes and derandomizes.
func TMSequence ¶ added in v0.4.0
TMSequence returns the first length octets of the TM randomizer sequence of CCSDS 131.0-B-5 clause 10.4.2. It opens FF 48 0E C0 9A.
The period is computed once and tiled, so a caller randomizing every frame on a channel is not re-running the register each time.
Types ¶
type OIDSequence ¶
type OIDSequence struct {
// contains filtered or unexported fields
}
OIDSequence generates the Pseudo Noise sequence that fills the data field of Only Idle Data transfer frames. CCSDS 132.0-B-3 clause 4.1.4.6.2 (TM, annex D) and CCSDS 732.1-B-3 clause 4.1.4.1.10 (USLP, annex H) mandate the same generator: a 32-cell Fibonacci-form linear feedback shift register realising
D^0 + D^1 + D^2 + D^22 + D^32
seeded to all ones at device start-up and never restarted between frames. Both standards publish the same opening octets, FF FF FF FF 6D B6 D8 61 45 1F, which is the only way to tell correct taps from a plausible-looking permutation of them, the same trap the 8-bit randomizer above fell into.
This is neither of the randomizers above: those are 8-bit registers applied by the channel coding layer to every frame, while this one is a 32-bit register whose output *is* the payload of an idle frame.
Unlike the randomizer this sequence is not tiled: its period is 2^32-1 octets, so it is generated as a stream. A value is safe for concurrent use.
func NewOIDSequence ¶
func NewOIDSequence() *OIDSequence
NewOIDSequence returns a generator in the 'all ones' start-up state. Keep one per channel for the life of the device; restarting it makes every idle frame carry the same octets, which is the insufficient randomization the standards warn against.
func (*OIDSequence) Fill ¶
func (s *OIDSequence) Fill(buf []byte)
Fill writes the next len(buf) octets of the sequence into buf, most significant bit first, advancing the generator.
Source Files