A basic safety signal detector - Page 1
Forum section: electronics / projects

author: berke
author_rank: Frequent Contributor
timestamp: December 30, 2022, 11:40:14 pm
content: The following circuit outputs high only if it receives a given LFSR sequence for a sufficient duration (here at least 60 to 70 ms). The clock is supplied separately.This can be used to ensure that your FPGA is configured before acting on other signals, by outputting the LFSR sequence on a pin according to the external clock. If the FPGA is unconfigured, configured with some unrelated logic, or loses its configuration or clock the circuit is unlikely to fire. The circuit is unlikely to fire from constant or continuous-tone signals. The circuit only uses basic components. (Note that there seems to be a pin numbering bug in the 74*595 model available in the community LTSpice library.)Alternative approaches I've considered but rejected for my application include fixed bit patterns (would use too many lines to be reliable, and fails if the FPGA stops being clocked) and tone detection with a resonant RLC circuit (could be accidentally activated by a sweep, hard to make it narrowband without using resonators).Maybe someone has an approach with a lower parts count?

author: berke
author_rank: Frequent Contributor
timestamp: December 31, 2022, 01:14:33 pm
content: As I was writing an exaplanation for the circuit, I found a fatal flaw in the circuit above! It triggers on a constant high input. That's why it's nice to have a forum like this, it forces you to think things through. The corrected circuit is shown below.A couple notes about how this works. It's quite classical but I'll give some explanations for the newcomers to planet Earth.I assume you know what an LFSR is and how it works. That information is easily available.So let's look at a pseudorandom sequence of bits generated using an N-stage linear feedback shift register. Let the generated bits be x_0, x_1, etc.If you look at any window of consecutive N+1 bits say x_{i-N},...,x_{i-1},x_{i},x_{i+1} it will verify the parity relationship of the generator. In this circuit this is x_{i-6} ^ x_{i-3} ^ x_{i-1} ^ x_i = x_{i+1} where ^ denotes the XOR operation.Thus if you look at bits 0,1,3,6 in your window (where 0 is newest and 6 is oldest) there will be an even number of ones. For the algebarically inclined one can say that all the length N+1 windows are contained in a dimension N hyperplane of GF_2^{N+1}.To get back to the circuit, I'm trying to keep the parts simple and available, so I picked an 8-bit shift register 74HC595. This way I can look at windows of length 8, which imposes N=8-1=7 for the LFSR sequence. I selected a 4-tap feedback so that I can use a quad xor-gate 74HC86 to compute x_{i-6} ^ x_{i-3} ^ x_{i-1} ^ x_i and have a gate left to compare it with x_{i+1}. The result of which will be identically zero, but if you send the complement of the sequence the result will be identically ones.And here lies the fatal flaw in the first version of the circuit. If I send a constant sequence of ones, the output of the last XOR gate is identically one and the output ends up firing !To prevent this situation, I need to ensure that the sequence is not constant. However that is not enough. A sequence of zeroes produces a zero output, a sequence of ones a one output, therefore intermediate sequences will pass the "non constant" test yet if dense enough will still be able to fire the output.The heart of the issue is that the analog integrator is too tolerant, you just need the output to be 1 sufficiently often to fire the output. That could easily happen with a noisy line near the supply.The only good solution is to use a counter. This is shown below. I use a 4-bit counter clocked with the output of one of the XOR gates. If the input is constant, the counter won't be clocked. Additionally, I take the output of the final XOR gate to reset the counter. This way if there is any parity violation, the counter will reset. (This requires a little bit of filtering to avoid glitches.) I take the carry output as the output.Thus it takes 16 pulses to the 74HC163's clock input to lock. The clocks coming from one of the XORs, and assuming each bit value is equally likely it will take about 32 clock pulses to acquire a lock. To latch the output, I use the parallel enable (PE) entry to load all ones when TC goes high. This requires an inverter gate but I usually have spare NAND's around on the circuit.The probability of a false lock should be 2^-32 and the probability of a sustained lock is negligible. This second version is unforgiving and will lose the lock on a single bad bit, which is fine for the application at hand.I still have concerns about glitches. I may insert a couple RC/Schmitt deglitchers. Any comments are welcome.

author: berke
author_rank: Frequent Contributor
timestamp: January 25, 2023, 09:43:16 pm
content: I received a board incorporating the above circuit.The circuit starts unlocked and needs the sequence to lock, so detection works. To generate the safety signal, you just need a 7-stage LFSR clocked by the clock signal produced by the remote board. On positive clock transitions, do thisCode:q <= { q[5:0], q^q^q^q };where q is a 7-bit register to be initialized with a non-zero value. Emit any bit of q as the lock signal.But this circuit still has a flaw. If you remove the signal while the circuit is locked, it can stay locked, because a zero signal has the correct parity, and nothing clocks the counter. Worse, the counter tends to keep its state across power cycles.If I am to keep this circuit I will at least need to drive the counter's MR pin from the power-on-reset signal. But I also have to find a different way of using the counter, so that a missing signal causes the lock to be lost.Ideas are welcome.Rules of the game: design a simple digital safety signal detection circuit, to verify that an FPGA is correctly configured and operating.- Can use up to two signals, can be synchronous or asynchronous- Simple parts only (vanilla CMOS logic only, 74HC or 4xxx, transistors, caps, comparators, etc. alloed), but only with easily available parts- No complex ICs, microcontrollers, other FPGAs, things with flash memory and the like- No tight timing or frequency requirements- Parts count must stay low- Circuit should have a very low probability of giving a transient response to an incorrect signal, by which I mean constant, undriven, random or other simple signals, including rectangular signals of arbitrary duty cycle and frequency- Circuit should have a practically zero chance of giving a sustained response to an incorrect signal- Driving signal should be easy to generate from an FPGA- Loss of signal should be detected fairly quicklyBonus points if the family of signals can be parametric, so that you could have more than one safety signal generator/receiver pairs with incompatible codes.