AnsweredAssumed Answered

Verifying PN23 data on the AD9680

Question asked by Poposhka on Nov 28, 2016
Latest reply on Jan 23, 2017 by umehta

We are trying to verify data captured from the AD9680 using the PN9 (PN short) and PN23 (PN long) sequences. Following documentation found on these forums we were able to construct a simple verifier for the PN9 sequence, but we have some questions about it. Also, we were not able to reproduce these results on PN23 data.


The PN9 algorithm follows ITU-T O.150, and the pseudocode is more or less the following:

Generate Next PN9 Value (GNV9)

given sample S

    bit0 = ((S>>8) & 1) ^ ((S>>5) & 1)

    S = S << 1

    S = S | bit0



The instruction manual for the AD9680 (Rev. C) says on page 78:

Pattern NameExpressionDefault/
Seed Value
Sample (N, N+1, N+2, ...)
PN sequence longX23 + X18 + 10x3AFF0x3FD7, 0x0002, 0x26E0, 0x0A3D, 0x1CA6
PN sequence shortX9 + X5 + 10x00920x125B, 0x3C9A, 0x2660, 0x0c65, 0x0697


1) Our GNV9, given 0x0092, will produce the given sequence 0x125B, 0x3C9A, 0x2660, 0x0c65, 0x0697 at 14-bit intervals as expected IF we first call GNV9 5 times. Why do we need to call it five shifts first? Shouldn't the first sample (N) be generated after 14 calls?


The output from GNV9 looks as follows


GNV9 CallsSample (14 bits)
... 19 (+14)0x3C9A
... 33 (+14)0x2660


Using GNV9 and an arbitrary snapshot collection of data from the ADC, we can "seed" our GNV9 algorithm with the first sample in the data, and verify the remainder of the data collected using GNV9, we just don't know why using your seed of 0x92 requires 5 shifts/calls to produce the first sample in your example sequence. The pseudocode for this looks as follows.

Verify PN9 Data

Given stream of words W

    w = read(W) // next word read

    e = GNV9(w, 14) // next expected value in 14 bits


    while W is NOT EMPTY

        w = read(W)

        if ((w & 0x3FFF) ^ 0x2000)) != (e & 0x3FFF)

            error: Validation of data failed

        e = GNV9(e, 14) // obtain next expected value in 14 bits



2) We are unable to follow the document ITU-T O.150 to produce a similar GNV23.


Generate Next PN23 Value (GNV23)

given sample S

    bit0 = ((S>>22) & 1) ^ ((S>>17) & 1)

    S = S << 1

    S = S | bit0



The output is as follows

GNV23 CallsSample (32 bits)


Not until GNV23 call 2374 does it result in the value 0x8b077fd7 which would be masked by 0x3FFF to 0x3FD7 (the first sample in the series N, N+1, N+2 in the table), the next expected sample 0x0002 does not follow in 14 bits / calls. Are we looking at this the completely wrong way?


We are also unable to verify arbitrary snapshot data collected using the PN23 test sequence with this algorithm.


Any help appreciated.