Pseudo Random Binary Sequence / Feedback Shift Register. Can anyone explain?

Thread Starter

brianmk

Joined Dec 23, 2016
106
I have been experimenting with a Pink / White Noise generator using a PRBS.
I have played around with a number of different shift register lengths using XOR feedback from two stages to give maximum length sequences. Tables of suitable lengths and taps can be found online.

What I have found is that when I use feedback from the last two stages, I get what appears to be single bits within the pattern that repeat such that they appear stable when viewed on an analogue 'scope.
For example, a 15 stage FBSR with feedback from stages 14 and 15 gives a pattern like the one below.
(20uS/div, clock frequency approx 100kHz). The expected PRBS length is 2^15-1 = 32767 bits.
I see a similar effect for other SR lengths where feedback is taken from the last two stages. For other tap points, I just see random data as expected. Can anyone explain what I am seeing? Is it just a 'scope triggering artefact or is there something wrong with the random sequence?
The 'scope seems to be triggering on the rising edge of a repeating '1' bit such that the '0' a few bits later in the sequence appears stable. Note: I only observe this effect when using SRs with feedback from the last two stages.
The distance between the stable '1' and '0' bits corresponds to the overall SR length i.e. 15 bits in this example.

IMG_1831.JPG
 

panic mode

Joined Oct 10, 2011
5,285
the circuit creates perfect x⁵⁷ + x⁷ + 1 (same as x⁵⁷ + x^50 + 1). so mathematically this is solid. what likely causes issue is a bit too short reset (C19/R16). if that does not help, there may be timing issue (even though they are clocked by same signal). you may want to try inverting clock for one of them. for example on 4557, tie pin 4 low, and use pin 5 as clock.
 

Thread Starter

brianmk

Joined Dec 23, 2016
106
what likely causes issue is a bit too short reset (C19/R16). if that does not help, there may be timing issue (even though they are clocked by same signal). you may want to try inverting clock for one of them. for example on 4557, tie pin 4 low, and use pin 5 as clock.

A couple of sensible suggestions 'panic mode' but I have already ruled those out...

It's not the reset. I added a temporary push button switch that allows a manual reset. It makes no difference to the issue. The crude CR power on reset works fine despite the slow rise/fall time.

I had already considered that it might be down to timing or a race condition between the clock edge and the combinatorial XOR or XNOR logic. I had already tried inverting the first stage clock in the 4557 so it uses the negative edge while leaving the 4094 using the positive edge. That made no difference.

I have also tried arranging the feedback such that both signals are derived from the 4094 'Qn' outputs rather than having one fed from the 4557 output (i.e. the 4094 data input). That also made no difference.

I have two versions of the circuit: One on a breadboard so I can play around with the SR length and feedback taps and another on a PCB. Both behave the same way so I doubt it's related to power supply noise or glitches. I am using different power supplies for each. Perhaps it's not a fault at all. Is there a mathematical explanation? Chat GPT offers no help.

Incidentally, if I set the 4557 to 16 stages and use Q2 and Q7 from the 4094 for the feedback, the configuration matches that used in the original Project 182 from 'Elliott sound' (He uses three 8bit 4094 SRs). With this configuration, the feedback is not derived from the last two stages so it works as expected: I get random data with no repeating fixed '0' or '1' patterns.
One of the problems with using 4094s only is that they have no reset pin. The original circuit uses AC coupling and a pull up resistor on the first stage to avoid all 1's or all 0's. However I found that solution to be unreliable - it can lock up.

I am wondering if I may have fake or faulty 4557 or 4094 devices. I'm going to try and order some from another supplier to check. They are probably obsolete in DIP form.
 
Last edited:
Top