AD9689 PN9 and PN23

Ok, I finally figured out with the help of two colleagues. The issue was that there was a bug in my vendors' firmware which was causing the ADC data to be inverted. On top of that, there are several things that are not mentioned in the manual. Here a reminder of all tricks:

For PN9:

- pow(2,9) -1 = 511 is the period

- Start with 0x92 as seed in a 9-bit register. It does not matter if you assume big endian or little endian, it is a palindrome.

- Get the XOR 9 and 5, call it e.g. newBit

- Create a new 9-bit register, which is the like the previous register shifting all bits to the left, and then bit0 = newBit.

- Calculate again newBit, etc.

- Finish the sequence whenever you reach the PN9 period, which is 511. You will have thus created 511 9-bit registers.

- Then, self-duplicate this array of registers, namely as many times so that it is aligned with 14. (so that we can then divide the array in groups of 14). newArraySize = least_common_multiple(511, 14) = 1022 ; nCopies = newArraySize/originalArraySize = 2; so that 1022/14 = 73 exact groups or data output words.

- Now, form the real 73 output words using groups of fourteen trans-consectuve bits, namely the highest bit (bit 8) of every consecutive 9-bit register that you in your extrapolated array.

- For example, you will obtain 0x125b, 0x3c9a by grouping the first 28 highest bits in two output words.

- Finally, configure your ADC to not invert the data (register 0x561) and to not use binary mode, but the default two's complement. Otherwise you would have to flip the last bit of your output words.

Similar for PN23:

- pow(2,23) -1 = 8388607 is the period

- Start with 0x7FAE00 as seed, because manual is in big endian, see /cfs-file/__key/communityserver-discussions-components-files/426/AD9680_5F00_PN_5F00_test_5F00_modes.pdf

- Get XOR 23 and 18 as newBit

- Create a 23-bit register, etc. as before

- newArraySize = lcm(8388607, 14) = 8388607*14, nCopies = 14

- etc.

Attached is a spreadsheet illustrating the calculation.

PNsequence.ods.zip

Ok, I finally figured out with the help of two colleagues. The issue was that there was a bug in my vendors' firmware which was causing the ADC data to be inverted. On top of that, there are several things that are not mentioned in the manual. Here a reminder of all tricks:

For PN9:

- pow(2,9) -1 = 511 is the period

- Start with 0x92 as seed in a 9-bit register. It does not matter if you assume big endian or little endian, it is a palindrome.

- Get the XOR 9 and 5, call it e.g. newBit

- Create a new 9-bit register, which is the like the previous register shifting all bits to the left, and then bit0 = newBit.

- Calculate again newBit, etc.

- Finish the sequence whenever you reach the PN9 period, which is 511. You will have thus created 511 9-bit registers.

- Then, self-duplicate this array of registers, namely as many times so that it is aligned with 14. (so that we can then divide the array in groups of 14). newArraySize = least_common_multiple(511, 14) = 1022 ; nCopies = newArraySize/originalArraySize = 2; so that 1022/14 = 73 exact groups or data output words.

- Now, form the real 73 output words using groups of fourteen trans-consectuve bits, namely the highest bit (bit 8) of every consecutive 9-bit register that you in your extrapolated array.

- For example, you will obtain 0x125b, 0x3c9a by grouping the first 28 highest bits in two output words.

- Finally, configure your ADC to not invert the data (register 0x561) and to not use binary mode, but the default two's complement. Otherwise you would have to flip the last bit of your output words.

Similar for PN23:

- pow(2,23) -1 = 8388607 is the period

- Start with 0x7FAE00 as seed, because manual is in big endian, see /cfs-file/__key/communityserver-discussions-components-files/426/AD9680_5F00_PN_5F00_test_5F00_modes.pdf

- Get XOR 23 and 18 as newBit

- Create a 23-bit register, etc. as before

- newArraySize = lcm(8388607, 14) = 8388607*14, nCopies = 14

- etc.

Attached is a spreadsheet illustrating the calculation.

PNsequence.ods.zip

Great work Ferdymercury. Thanks for sharing your results on EngineerZone.

Thank you for the clue to put it back to two's complement mode. This helped a lot.

I am not sure I understand how many copiess or repeats of the table you nedd. I made a single 511 point table like this:

#define NPTS_PRBS 511

...

int16_t prbs[NPTS_PRBS];

...

x = 0x125B;
for (i=0; i<NPTS_PRBS; i++)
{
    prbs[i] = x;
    for (k=0; k<14; k++)
        x = (x<<1 | (x >> 8 & 1 ^ x >> 4 & 1)) & 0x3fff;
}

For the first test word received, I search to find the first macth, then roll around the table using rpos = (rpos+1) % NPTS_PRBS

William.

You are welcome. Concerning the 'repeats' of the table, you do not really need it if you use the % operator to roll around. The 'repeat' is only relevant if you are interested in knowing after how many 'rolls' you will get the same 14-bit word you started with. For PN9, you will need to go twice through the table, as shown in my attachment with 511*2 rows, and you get a closed sequence 0x92, 0x125B, ... 0x13F6 that gets repeated on an on. The sequence length is 1022, that's why I copy-paste the table twice. nCopies = least-common-multiple of (2**N-1, 14)