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.

 

Your words are failing me here. A schematic diagram would be most helpful. Would that be too much to ask?

 

Here is the schematic.

Note that the schematic is configured for a 57 stage FBSR with XNOR feedback from stages 57 and 50. Since the feedback is NOT from the last two stages, It does not exhibit the issue described.

See also:-
https://sound-au.com/project182.htm

 

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.

 

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.

 

i remember trying ChaptGPT couple of times and gave up. results were useless. nowadays if i want to chat with AI, i use Grok or Google AI. Grok is pretty good but free version ends current session after certain number of exchanges so i use it less and less.

here is what Google AI came up with:

....
With a low clock frequency of 60–150 kHz, timing or race conditions are completely out of the equation. Knowing that the original circuit called for three CD4094s (24 bits) instead of your current configuration confirms exactly why you are observing a precise two-bit dropout.
The issue stems from a classic mix-up in how the CD4557 calculates internal bit length compared to standard shift registers.

The Source of the Two-Bit Shift Error
A standard shift register (like the CD4094) operates under a simple rule: if you want a length of 8, you read the 8th output stage.
The CD4557 does not work this way. It is internally hardwired with an baseline minimum offset. Its logic formula for programmed bit length is:
\(\text{Total\ Bit\ Length}=\text{Sum\ of\ Binary\ Programming\ Pins}+1\)
Because you have \(L_{1}\), \(L_{16}\), and \(L_{32}\) tied to \(V_{CC}\) (\(1 + 16 + 32 = 49\)), the CD4557 adds its internal fixed \(+1\) offset to provide a total shift length of exactly 50 bits.

The 2-Bit Discrepancy
If the original audio noise circuit used three CD4094s (providing a total shift length of 24 bits) and tapped Q7 of the final register, the original master tap position was exactly at bit index 23 (\(8 + 8 + 7 = 23\)).
When adapting this circuit to use a CD4557 to replace the first two CD4094s (\(8 + 8 = 16\text{ bits}\)), the designer likely intended to replace those 16 bits directly. However, notice the mathematical shifts:

• If the designer set the CD4557 to a targeted "\(48\)" bits to shorten a large loop, or calculated a substitution for a larger cascading array, changing the physical component alters how the feedback loop lines up.
• By adding 50 bits (from your CD4557 setup) to the 7 bits of your CD4094, you have a 57-bit total loop.
• If the primitive math for the noise generator's original pseudo-random polynomial expected a specific tap-to-tap balance (for instance, an exact 2-bit delta or a specific 2-bit spacing within the 24-bit window), the internal \(+1\) calculation rules of the CD4557 shift the phase positioning exactly wide.

Because the CD4557 introduces a +1 delay that doesn't exist on bare cascaded pins, and because your bit count is precisely two counts off what a clean multiplication would give, the data stream is arriving at the XNOR feedback gate two clock cycles late.

The Result on Your Scope
Because the feedback data arrives two clocks late, the XNOR gate generates a correcting bit that cancels out or mimics the previous states for exactly a two-cycle window. In an LFSR, when the feedback polynomial is thrown off by exactly a 2-bit phase delay, it forces the register stream to produce a repeating dead zone where two consecutive bits are crushed down to zero (00) every single time the sequence loops.

How to Fix It
To fix the two-clock dropout, you need to subtract 2 bits from the CD4557's programming array to pull the timing back into phase alignment:

1. Look at your programming pins: \(L_{32}\) and \(L_{16}\) equal 48.
2. Disconnect \(L_{1}\) from \(V_{CC}\) and tie it to GND.
3. This changes your calculation to: \((32 + 16) + 1 =\) 49 bits.
4. If it still shows a 1-bit shift on the scope, disconnect \(L_{16}\) and pull up \(L_8 + L_4 + L_2 + L_1\) to walk the variable length explicitly down until the phase-canceled dead zone disappears.

...

like any AI, it is not infallible but it did offer an interesting suggestion that is easy to try on your breadboard version.

 

where are you tapping off of ?
remember the first register is tap 1, not zero.
remeber that for an xor , the all zero is invalid, for xnor, the all 1 is invalid,
also remember not all lfsr are just 2 taps from last bits ,
it looks to me as if you actualy have just an inverter , not an xor , so you end up with 15 bits 1, then 15 bits low