PRBS generator in LabVIEW - problem with proving that PRBS is a pseudo-random generator

[marcin_rajski]

As the title suggests I made a PRBS generator as a VI in LabVIEW. From what I know, the 256th generated number should be equal to the 1st generated number, the 257th generated number should be equal to 2th generated number and so on.. That's how my generator should work. 

So, I created 3 numeric indicators (1st number, 256th number, 511th number) which should show the exact same values. Unfortunately, every indicator shows a different value. I've attached a PRBS generator VI I made below.

[altenbach]

Not sure why you need all these coercion dots and U64 indicators. Instead of all these case structures, couldn't you just index out the relevant elements from the 1D array?

Do you have a link to a web page describing the algorithm. What is the correct value for the "iterations" control?

[RavensFan]

Something is wrong with your second VI.  It won't open unless I edit the filename to something else.  Probably an issue with some foreign language characters.

[marcin_rajski]

RavensFan - yes, you're right. I'm sorry, I haven't noticed the "ł" character in my filename.
altenbach - I fixed those coercion dots, they were unnecessary indeed. The same goes with U64 indicators - they weren't working well in my opinion anyways.. I used these case structures because at first I wanted to quickly ckeck only one generated value. But then I decided to check another value and another, so that's why it looks unprofessional.

[altenbach]

So do you have a link describing the algorithm? There are many PRBS.

[marcin_rajski]

Aw yeah, I didn't reply to all of your questions. It seems like every value of "PRBS iterations" which is greater than zero should be valid. The algorithm is quite simple - The PRBS generator in my case works like a shift register. The value of the 1st bit in the register is a XOR result of 2 last bits. The PRBS generator seed can't contain only zeros or only ones. I've attached some image, which should somehow illustrate the algorithm.
 

[altenbach]

Looks like you are trying something similar as described here. If you want a 255 periodicity with 8 bits, you need four taps. You only have two taps and you get a periodicity of 63 (done right, which you don't :D. You make quite a few mistakes, for example you create each number with a different seed)

Here is a quick example showing a 255 periodicity. If you sort the array, you can see that each possible value occurs exactly once per sequence period. the attached code will  generate two full periods (510 points). (If you only use taps 8 and 7, your period is 63).

[marcin_rajski]

altenbach, thank you for the explanation. It made me delve more into thinking how that generator should work. Now I understand, that I couldn't prove its recurrence with using different seed every iteration. 

I fixed my VI. Now, the 64th generated number is equal to the first one, which is fine enough for me. I'm attaching the file below, so it may be found helpful by someone. I'm tagging this thread as solved.

[altenbach]

Your code is actually still overly complicated. Note that 255 is allowed if you use XOR instead of notXOR (Allowed seeds and range of possible values: XOR: 1..255, notXOR 0..254). Also your random generator subVI should have blue inputs and outputs because it is designed for integers. Setting the boundaries correctly eliminates the while loop (Note that you also have "Random number (range).vi" in the numeric palette)

The way you are expanding the shift register is really not scalable and requires a lot of wire work (and thus has many more places for bugs to hide!). My solution using rotate array is significantly easier. Do you understand how it works?

Imagine you need to modify the code for 64 bits tomorrow.  In my code one would change a few diagram constant, but with your code you would need a bigger monitor to even make it. 😮

[altenbach]

Your code could look as follows (no expanded shift registers, no case structure, no comparisons):

Your case structures are very dangerous for debugging, because if your loop does not iterate enough times, some indicators might show stale info from previous runs. At least set the VI to "clear indicators when called" (VI properties...execution))

Note that the first number has index=0, not 1. (You want to compare values at indices 0 and 63, i.e. the 1st and 64th value).

Note that you really should show the entire output array. If you just show two values and they are equal, does not prove anything. maybe all values in the array are equal! 😮