1
\$\begingroup\$

I'm currently working on an OSE-Signal processor to connect with my ESP32's GPIO input, in order to validate the state of an OSE Sensor. An OSE sensor is commonly used on automatically opening/closing doors to avoid hard collisions that may result in damage or injuries.

I found a documentation by one of the manufacturers that describe the signal output as a 1 kHz square wave with a 50% duty cycle (3.8V high, 0V low), when in normal working condition. The signal is interrupted on collision.

OSE-Datasheet

The same document also provides a processing circuit:

Recommended circuit

Recommended circuit output

Exactly reconstructing that circuit in ltspcie however, results in the output pwm bulging. With the limited knowledge I have about this topic and electrical engineering in general, I modified the circuit to fit my needs with a clean output pwm (3.3V high, 0v low) that gets directly feeded to the GPIO of my ESP32:

Fixed? circuit

Fixed curve

Am I missing something in general? As it looks like the recommended ciruit is not working like it should?

Also it would be awesome to know, how to calculate the RC-Circuit used here. C1 is for general filtering whereas C2, R1 and R2 form a highpass filter with a discharge restriction given by R1? R3 and R4 should be dimensioned correctly, with R3 peaking at 500µA current flow?

\$\endgroup\$
5
  • 3
    \$\begingroup\$ Given the mention of automatically opening/closing doors to avoid hard collisions that may result in damage or injuries, are there any functional safety requirements to be met for the PWM logic level shift? \$\endgroup\$ Commented Nov 17, 2024 at 9:05
  • 1
    \$\begingroup\$ Where is your Ri of the Ersatzschaltbild? \$\endgroup\$ Commented Nov 17, 2024 at 9:08
  • \$\begingroup\$ Ersatzschaltbild = "equivalent circuit diagram". \$\endgroup\$ Commented Nov 20, 2024 at 7:33
  • \$\begingroup\$ You can look into using the ESP32's pulse counter peripheral (PCNT), or the remote control transceiver (RMT) to monitor the incoming pulse train. \$\endgroup\$ Commented Nov 24, 2024 at 19:05
  • \$\begingroup\$ From a functional safety point of view, a real concern is the latency to stop the motor to prevent injury. This should be both deterministic and quick. Inadequate software design could cause this requirement to not be met. \$\endgroup\$ Commented Nov 26, 2024 at 0:14

2 Answers 2

2
+50
\$\begingroup\$

The sensor may be illuminated by many different light sources other than the intended one, such as the sun, glare from a window or artificial light flickering at 50/60Hz. If the receiver "sees" ambient light, it might confuse it with light from the intended source, an unbroken beam. To distinguish the intended source from ambient light, the beam is switched at 1kHz, a frequency very different from other natural or artificial sources of "noise". A "safe" condition can only be assumed if the signal frequency is near 1kHz.

The sensor source impedance \$R_i\$ was absent from your simulation, but it is essential because it forms a low-pass filter with the 10nF capacitor C1. The cut-off frequency of such a filter is:

$$ f_{LP} = \frac{1}{2\pi RC} $$

\$R_i\$ changes depending on signal state, but the two possible frequencies would be:

$$ \begin{aligned} f_{LP1} &= \frac{1}{2\pi R_iC_1} \\ \\ &= \frac{1}{2\pi \times 100 \times 10nF} \\ \\ &= 160kHz \\ \\ f_{LP2} &= \frac{1}{2\pi \times 560 \times 10nF} \\ \\ &= 28kHz \end{aligned} $$

If the signal is indeed 1kHz, then it would make more sense to have a much lower cut-off frequency than 28kHz. These values tell me that this filter is probably intended to suppress general noise/pick-up from radio or local appliances like switching LED lighting supplies.

The second stage consists of \$C_2=100nF\$ and \$R_i+R_1+R_2=R_i + 10k\Omega + 4.7k\Omega\$, forming a high-pass filter. Noting that \$R_1\$ and \$R_2\$ are very large compared to \$R_i\$:

$$ \begin{aligned} f_{HP} &= \frac{1}{2\pi C_2(R_i+R_1+R_2)} \\ \\ &\approx \frac{1}{2\pi \times 100nF \times 15k\Omega} \\ \\ &\approx 100Hz \\ \\ \end{aligned} $$

Only signals at frequencies significantly greater than 100Hz will make it un-attenuated past this stage, which includes our 1kHz pulses. Everything else is considered noise, from sources such as 50/60Hz mains pickup, light flickering, or power supply fluctuations. Being a high-pass filter, any DC offset in the source signal is removed, and the signal now oscillates symmetrically above and below 0V ground.

This satisfies the requirement that a steady or slow-changing light source will not make it through this stage, and you won't register a "safe" condition in error. The only dominant signal to get this far should be the 1kHz you expect.

The base-emitter junction of the transistor is a diode that clamps base potential \$V_B\$ to +0.7V or lower. Another diode is connected in anti-parallel to that junction, clamping \$V_B\$ to −0.7V or greater. This "lower clamp" is necessary for two reasons:

  1. It keeps the waveform symmetrical, so that its average is zero, and it spends as much time above zero as below. Without a lower clamp, negative excursions will be very deep compared to the +0.7V maximum, changing the signal's average potential, which we want to be in the middle ideally.

  2. The transistor's base-emitter junction is a zener diode which can break down and become highly conductive when reverse biased. By ensuring \$V_B>-0.7V\$ that can never happen.

\$V_B\$ oscillates symmetrically above and below 0V, constrained to \$-0.7V < V_B < +0.7V\$.

You'll notice that \$R_1\$ and \$R_2\$ form a potential divider, with attenuation \$\frac{R_2}{R_1+R_2}\approx \frac{1}{3}\$. The position of \$R_1=10k\Omega\$ is important; the diode clamps will become like a short-circuit to ±0.7V as the source signal extends outside the bounds −0.7V to +0.7V. \$R_2\$ limits current in such cases, relieving the sensor of such a heavy load, and permitting sensor voltage to continue to oscillate unhindered, to its usual full extents.

The attenuation of signal potential by \$\frac{1}{3}\$ seems to be a necessary and unfortunate by-product of the need for 15kΩ total, while the larger resistance of the two must appear prior to the clamps. Your +3.8V pulse is attenuated to the point that the base reaches the +0.7V required to saturate the transistor, but quickly decays to below that threshold. As you noted, raising \$R_2\$ to 10kΩ improves the situation, by attenuating less. However, \$R_1+R_2\$ has increased to 20kΩ, which lowers the cut-off frequency. You should consider decreasing C2 to keep the cut-off near 100Hz. Personally I think you should increase cut-off to more like 200Hz, to better attenuate any 100Hz or 120Hz ripple from a linear power supply:

$$ \begin{aligned} 200Hz &= \frac{1}{2\pi C_2(R_i+R_1+R_2)} \\ \\ C_2 &\approx \frac{1}{2\pi \times 200Hz \times 20k\Omega} \\ \\ &\approx 39nF \\ \\ \end{aligned} $$

schematic

simulate this circuit – Schematic created using CircuitLab

Calculating base current is quite difficult, so a simulation will help:

enter image description here

It peaks at more than \$I_B=100uA\$, and falls rapidly, due to the high-pass filter. It will be useful to know what collector current \$I_C\$ would flow when the transistor is saturated:

$$ \begin{aligned} I_C &= \frac{3.3V}{R_3} \\ \\ &= 330\mu A \\ \\ \end{aligned} $$

Assuming transistor \$\beta=100\$, base current required for saturation would be:

$$ I_{B(SAT)} = \frac{I_{C(SAT)}}{\beta} = 3.3\mu A$$

\$I_B=100\mu A\$ is clearly more than sufficient, and the transistor will remain saturated until \$I_B\$ has fallen to 3μA or so, explaining why the output remains planted near 0V for almost 50% of the cycle:

enter image description here

Having said all that, the original circuit is behaving (in your simulation) exactly as designed and expected (though you did not include \$R_i\$). It's not great though, as you saw. The two filters naturally retard signal rise and fall, and tend to soften sharp corners. The signals you show are perfectly acceptable digital signals, if a little sluggish. The biggest worry would be a signal that doesn't make it all the way to the top/bottom before returning.

The duty-cycle is not 50%:50% because the transistor only begins to switch on when its base rises beyond +0.6V or so. Since the base waveform is centered on 0V, oscillating between ±0.7V, the transistor spends most off its time off (output high). This is not a problem, because as I explained before, the characteristic of this signal which one interprets to indicate "safe" is the presence of changes. The duty cycle of those changes is irrelevant. Whatever hardware/software is used to interpret the output, it should detect changes, and as long as it sees at least 2 changes each millisecond, then there's nothing blocking the light beam.

\$\endgroup\$
5
  • \$\begingroup\$ Thank you for the reply. After further research as to why it's designed to switch at a certain frequency, it's due to the European safety norms for automatic moveing doors. These requirements demand that a safety device such as the OSE sensor described above must self-test and always stop the door from moving, even if the sensor or cable is damaged. The PWM circuit therefore ensures that, if interpreted correctly, the device will operate correctly. Standard photocells, which are only NC, must therefore have a test feature to ensure that a µC input is not somehow stuck at HIGH or LOW. \$\endgroup\$ Commented Nov 22, 2024 at 22:02
  • 1
    \$\begingroup\$ Sensing a GPIO change at the ESP32 every millisecond or half-millisecond, all the time, is a lot of overhead. Most systems try to keep this below 4ms or so (the size of a typical OS tick.) It also relies on the ESP32 to implement functional safety. Finally, the circuit misbehaves at duty cycles > 50%. I'm quite astonished that this would even fly, given the safety requirements. \$\endgroup\$ Commented Nov 22, 2024 at 23:47
  • \$\begingroup\$ Also, the OSE sensor is shielded from ambient sources: it's inside a rubber tube. Nonetheless the LED emitter is modulated with a higher-frequency 'carrier', which I presume is demodulated in the sensor to the 1Khz signal. This provides the optical noise rejection, much like an IR remote receiver. \$\endgroup\$ Commented Nov 23, 2024 at 0:06
  • \$\begingroup\$ @hacktastical I was unaware that the light channel was enclosed, didn't do my homework there. Still, there's the possibility of sensor losing power, or failing with output stuck high or low. That's a danger condition too, explaining why the sensor output must oscillate. I also feel that a microcontroller servicing a pin change interrupt every 500μs to reset a timer is not a significant overhead. I'll have to explore your point about the >50% duty cycle, though; that's potentially a big one. \$\endgroup\$ Commented Nov 23, 2024 at 5:12
  • \$\begingroup\$ Re f[c]: Apparently at least some of those sensors use a 38kHz carrier to send the ~1kHz signal via infrared. \$\endgroup\$ Commented Nov 24, 2024 at 18:58
2
\$\begingroup\$

The 'bulging' is because the base current tapers off after the pulse rises and the 100nF cap finishes its charging. This by itself shouldn't be an issue for the micro. But, there are other issues.

I built it too, try it out simulate it here:

enter image description here

I did a duty cycle sweep with 1kHz input. This is what I observe:

  • input low: output high
  • duty cycle < 50%: pulse train out
  • duty cycle near 50%: pulses not going all the way low - maybe a problem?
  • duty cycle > 50%: output high
  • input high: output high

I’m not so impressed with this circuit. It can’t tell the difference between a no-signal or a stuck-at. How can it with an AC coupling? It's troubling that the the behavior at ~50% duty is bad: there isn’t a valid level as it passes through that duty cycle. And, does the micro always need to be monitoring a pulse train? It only cares if there is a signal or not.

We can do better.

A little digging reveals that OSE (Optical Sense Edge) devices are just light sensor / LED pairs. The pair components are at either end of a soft rubber tube. The LED puts out a pulse train (bursts of higher frequency, kind of like an IR remote) and the sensor picks it up.

If the tube is bent/pinched due to making contact with something, the LED light is blocked and the sensor pulses stop. (Please correct me if I’m wrong about this. By the way, found the Datasheet.)

From a system design standpoint, hitting the micro with a 1kHz toggle signal is a lot of overhead. The toggling itself conveys no information other than whether the sensor is blocked or not.

I think a better solution is to pre-process the sensor with a missing pulse detector tuned for the pulse frequency. This is essentially what the ESP32 software would be doing; instead I propose a bit of hardware.

To make a missing pulse detector we need a retriggerable one-shot. Any kind will do; I suggest the 74LVC1G123, which can work on 3.3V and is available in a small 8-pin package.

Here's how that would work (simulate it here):

enter image description here

The input diode blocks any voltage higher than 3.6V, protecting the circuit. With nothing connected the input is high, which we can test for stuck-at (more about that below.)

The '123 timer is triggered by a rising edge from the sensor. SENSE-OK output stays high as long as the timer keeps seeing a rising edge before its timeout period (set to 3ms here.) If the sensor pulses stop, the timer times out and SENSE-OK goes low.

Not shown in the schematic: the 74LVC1G123 uses an RC pair to set the period. From the datasheet I estimate the R and C to be 30k and 0.1uF. This can be adjusted for the sensor as needed.

The SENSE-OK and STUCK-AT signals are forwarded to the micro. This gives enough information to do several things:

  • SENSE-OK going low can immediately stop the motor
  • STUCK-AT provides state for further diagnosis

Why go to this extra trouble? It’s fail-safe. SENSE-OK going going low can be used by itself to stop the motor immediately, without the micro. Meanwhile, the micro also sees the SENSE-OK=0 condition and, together with STUCK-AT, may take action such as reversing the motor, diagnosing a wiring fault, reporting state and so forth.

\$\endgroup\$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.