DRSSTC fiber optic link to the interrupter, and the fail-safe rule

The interrupter talks to the coil over an optical fibre. loneoceans gives two reasons for it on the UD2.7 page: physical isolation and noise immunity, over a link that carries one bit. flyingperson23 spells out the first one in a thread from somebody who wanted to run coax instead (HVF 3035). A metal cable is a conductor running into a machine full of lethal voltage, and a secondary arc landing on it ends badly for the cable, the interrupter and whoever is holding the other end.

A broken fibre must turn the coil OFF

Fibres get pulled out, broken and shaken loose. Transmitters lose power. Controllers hang. In every one of those cases the bridge has to go quiet, not stick on.

On the UD2.7 the convention is that light on means drive on, so dark is off and the convention matches the rule.

Test it on the machine. Pull the fibre out while it runs at low power and check that it stops. Reading the schematic is not a test.

What the receiver settles, and what it does not

The IF-D95T and IF-D95OC are logic receivers, with a photodiode, an amplifier and a Schmitt trigger in the package (Industrial Fiber Optics, IF D95). In the dark the output sits at a defined logic level instead of floating. On an active-high part dark is low, low is off, and the receiver gets the rule right by itself.

It cannot do that without a supply, and there is a documented case where that ends with the coil enabled.

Both fibre inputs on a UD2.7 have a pull-up. It is there for the part, not for safety: the IF-D95OC has an open-collector output and its datasheet asks for a pull-up resistor, so the board is laid out to take either variant. loneoceans calls the one on the IF input R11, which is a designator and therefore worth tracing rather than trusting. On profdc9's through-hole redraw of the UD2.7C it is 1 k on both inputs (schematic). When somebody on the forum asked whether the open-collector part could replace the push-pull one, alexhanyuan answered that either works and that the 1 k is there for the open-collector variant (HVF 2271).

With the receiver fitted and powered, the receiver overrides the pull-up and dark is off. With no receiver behind it, the resistor is the only thing on the node.

The receiver enforces the rule only while it has power. Without power, the input sits wherever the rest of the node puts it, and the schematic does not make that obvious.

Overcurrent protection gets this backwards. It lists the fail-safe on the fibre as "a divider that pulls the receiver's input to off rather than leaving it undefined". The datasheet contradicts both halves. The output is not undefined in the dark, and the resistor on the reference board pulls that input to on, not off. That line needs replacing with the paragraph above.

Active-high and active-low are not interchangeable

The receivers that fit one board do not even all switch the same way round, and that catches people. loneoceans says so twice on the UD2.7 page. The ST receivers, OPF-2412T and HFBR-2412T, are active low, and the board inverts their output once to match. The Industrial Fiber Optics parts are active high, and he tells you not to buy the active-low kinds. His bill of materials names those two as IFD95T and IFD95C. The datasheet calls the second one IF-D95OC, and it also notes that active-low outputs are available as a special order. That gives three ways to end up with the wrong one: the wrong family, the wrong suffix, and a special order.

The same page also notes that the two fibre inputs are ORed together, so only one of them may be driven at a time.

What people use instead, and the catch

• An optocoupler in place of the fibre. LoFoTroFo did this on a handheld build, dropping the HFBR2412 for a TLP2345-E with a transistor added, and later a TLP2362 on the driver input, because he wanted it cheaper and without an optical cable (HVF 3455). You change the kind of isolation rather than the amount. A fibre has no conductor across the gap at all, and an optocoupler is a component with a rating.
• Bluetooth. paulsimik runs two HC-05 modules, one master and one slave, paired at a fixed address in AT mode, and sends only the potentiometer positions. The PWM ramp and the bridge switching are computed on the coil's own board, and an ATmega328 on an Arduino Nano is enough for it (HVF 3524). He says MIDI over the same link is worse, because the data has to be processed far faster. LoFoTroFo built one too and reports that it needs very good shielding.

Neither builder writes down what his link does when it drops, and we have not read a published design that specifies it. Going wireless does not make the rule at the top optional. The reasoning here is ours, not theirs: a receiver that keeps running the last ramp it was sent is a machine with no off switch, so the coil's end has to time the silence and drop to off when it times out. Until somebody publishes a timeout that has been tested by switching the transmitter off mid-run, treat the wireless case as unproven and test it yourself.

What is not established

• Whether these receivers impose a minimum pulse width. A figure of 6 µs gets passed around for the IF-D95T as an asymmetry between turn-on and turn-off, and the datasheet does not carry one. It prints a single typical propagation delay of 6 µs against both tPLH and tPHL, with no minimum and no maximum beside it. One number for both directions is not a difference between them, and with no maximum the spread between parts is not specified there either. What the datasheet does bound is the data rate, up to 125 kbps, and the output rise and fall, no more than 70 ns at ten TTL loads.
• Whether IF-D92 is the faster alternative. On paper it is the slower one. It is a bare phototransistor with no logic in the package, rated to 20 kbps, with typical switching times of 25 µs at a 1 k load (Industrial Fiber Optics, IF D92). Loading it much harder and supplying your own threshold is a real technique and would change those figures, but we have not read a worked circuit for it, so we cannot say where it lands.

The symptom, if you ever see it

You pulled the fibre and the machine kept running. Three things cause that, all covered above. The receiver is the wrong polarity. Or the receiver is absent or unpowered while its pull-up is still ORed into the enable. Or the break is somewhere other than the fibre, in an interrupter that keeps transmitting after its own logic has stopped deciding anything. Stop everything and find out which. None of these is a fault you can work around.

What the transmit end costs

The range depends on how hard the transmitter drives its LED, and that is one resistor. sndnvaps publishes a DRSSTC interrupter on OSHWHub and records changing that resistor from 470 Ω to 140 Ω "以增加光纤传输距离", to increase the fibre's transmission distance. Keep that in mind before blaming a long run or a bad connector. A link that works on the bench and not across the room may be short of drive current rather than suffering from a bad fibre.

The same board also offers a copper option. It has two outputs, a direct connection "适用于SSTC驱动板" for SSTC driver boards and an ST multimode head "适用于DRSSTC" for DRSSTCs. Wiring copper straight to the driver is therefore ordinary practice on the smaller machine. Nothing we have read argues that it is safe, only that boards offer it, and a smaller coil does not change the argument for fibre: what is on the other side of that link is still mains derived and still what in a Tesla coil will actually kill you. Take the copper option as a record of what people do. We do not recommend it.

---

For what the interrupter sends down that fibre, see bangs per second and ontime. Why the link is plastic fibre and not copper is covered in DRSSTC safety.