shutting a tube off with a relay

[nuke]

Per Arthur C. Clarke's Third Law: "Any sufficiently advanced technology is indistinguishable from magic".

It's a small solar cell ("photovoltaic") illuminated by an LED plus a little integrated junk to make it turn off faster.

I'm surprised there's enough photovoltaic voltage and current to drive the gate capacitance and still have reasonable turn-on times. Neat range of devices.

[R.G.]

[...] switching off the B+ is a very simple solution. I guess the previous rules necessitating the fast analog path still apply, though, right?

They're not so much rules as "here be dragons" maps. You don't want the MOSFET lingering in the middle of switching on or off long enough for it to overheat and die from heating. That means that you want it to not sit there with 500V on one side and a short to ground on the other for significant time. Something under 100uS is probably going to be OK, subject to the specific MOSFET(s). In off-line switching power supplies, the MOSFETs are doing the same thing, switching 350-400Vdc into charging a capacitor, and doing it 400,000 to 1M times per second. They have to turn on and off in nS to live through it.
With a slow turn on/off like tens of uS, you want to be sure you only do it once until the heat can work its way out of the silicon. The way to ensure this is to trip a latch so the circuit is not trying to turn the MOSFET on and off continuously. It's not impossible to get a controller fast enough, but simply using a bit of hardwired logic to do the latching is a way to ensure that you're not waiting for the uC's control loop to save the MOSFET. A CMOS S-R or J-K latch should work. Trip the latch and the B+ shuts down in uS. The uC can then detect the condition and manage LEDs and when or if to reset the latch and turn B+ back on.

So that would mean the MCU could detect a fault, turn on a single opto which would trigger a dual-mosfet setup to switch off the B+. If the analog path gets tripped, it would also trigger the mosfets. In both cases I guess the MCU would need to remain on and hold the mosfets in place until it detects a happy tube situation. Am I missing anything? That seems pretty simple if so.

The intriguing thing about engineering is that there is a whole web of interacting decisions. The early decisions have effects that ripple through everything afterwards. The decision to turn off only one tube at a time or all of them at once is a good example. If you want to turn off power to one possibly-shorted tube, you need to decide whether to switch the high/plate side or low/cathode side. Low side is easy, as the MOSFET will be tied with source to ground and its gate will only need to swing from ground to maybe 8-10V. High side is harder, because the MOSFETs' sources float on the plate voltage, which goes from maybe +50V to two times B+, so you have to use the two-MOSFET switch to avoid backwards-diode clamping. You need to decide whether the initial decision, (that is, turn off tubes individually) is worth the money and time to use one or two MOSFETs per tube and maybe a floating gate drive.

Flipping the decision to turning them all on/off at once means going back out to that decision point and re-making the tree of decisions that came out of that. If there's only one switch, is it high side or low side? Switching just the high side of the B+ before the OT means you can use a single MOSFET switch; and you can decide to switch the high side with a floating MOSFET drive, or the low side, on the joined cathodes of the output tubes, or maybe the return wire from the first filter cap back to the transformers.

You also need the latching to be sure that the uC can read the info about which tube went mad, and then make decisions and do reporting, when and if to reset and try again. You're right - you will need to figure out how to keep the uC powered up long enough to be useful. And whether the uC is running from a battery or supercap when the amp is off, or powered by a tiny power supply when the amp is plugged in. This starts a chain of decisions that rapidly leads to the uC being an amplifier power controller, not just a tube fail sensor.

Er... there isn't any such thing as over-engineering.

[Gainzilla]

Er... there isn't any such thing as over-engineering.

Ha, I suppose you're right. I still think it would be cool to handle each tube individually... Would give a 100w amp the option to remotely limp it on home through a gig or a session. But Killing the B+ is nice nice solution that also gives a remote standby potential via the app.

Here is the re-worked design using the Mosfets to switch the B+. Still uses the fast/analog path, but I've added a flip-flop to latch the Mosfets. The MCU will govern its behavior. On power-up: the 100k pull-down holds RESET1 low; as long as MCU doesn’t float the pin high at boot, Q1 will keep its last state. Firmware pulses RESET1 high once at init to guarantee Q1=0 (safe clear), then releases it. Instant hardware trip and a hard latch until reset.

Recap from ChatGPT.

MCU one-pager (flow)
1. Boot init
• Set A9 LOW (VOM1271 OFF, B+ off).
• Pulse RESET1 HIGH (2–10 ms) → Q1=0; release to LOW.
• Configure A10 ADC; confirm NONE (<0.4 V).
• Set A9 HIGH to enable B+.
2. Monitor
• Poll A10 at ~1 kHz (or on your own timer):
• Bucket: NONE / T1 / T2 / BOTH using bands:
• NONE <0.4V, T2 0.8–1.5V, T1 1.6–2.05V, BOTH >2.05V
• Require 2–4 consecutive samples to confirm.
• If not NONE → call fault_handler(type).
3. fault_handler(type)
• Log type (T1/T2/BOTH), timestamp.
• Force A9 LOW (hold VOM1271 off; B+ off).
• (Optional) ramp bias DACs to minimum.
• Light front-panel fault LED(s).
• Wait for user Reset action.
4. Reset path
• Require A10 < 0.4 V for ≥100 ms.
• Pulse RESET1 HIGH (clear latch → Q1=0).
• Restore bias setpoints; set A9 HIGH to re-enable B+.
• Resume monitoring.

PowerTube_Switch_v1.5.png

[R.G.]

I still think it would be cool to handle each tube individually... Would give a 100w amp the option to remotely limp it on home through a gig or a session.

Individual is nice - but there is a price for nice. Good engineering involves a mental background process that is roughly totaling up part cost and complexity as parts and features get added. There is a break point when the initial design requirements get met and maybe exceeded, where any added parts get critically looked at.

A useful trick is to enter each added part and its cost (and availability if you know it) is added to a spreadsheet as you go. The total keeps you aware of costs, and sorting by highest price first lets you know where there is any room for cost cutting.

But Killing the B+ is nice nice solution that also gives a remote standby potential via the app.

Here is the re-worked design using the Mosfets to switch the B+. Still uses the fast/analog path, but I've added a flip-flop to latch the Mosfets. The MCU will govern its behavior. On power-up: the 100k pull-down holds RESET1 low; as long as MCU doesn’t float the pin high at boot, Q1 will keep its last state. Firmware pulses RESET1 high once at init to guarantee Q1=0 (safe clear), then releases it. Instant hardware trip and a hard latch until reset.

Recap from ChatGPT.

[...]
• (Optional) ramp bias DACs to minimum.
• Light front-panel fault LED(s).
[...]

Take care with the DAC to Vbias design. That really has to be robust to avoid flaws killing tubes. Maybe think how to provide a fail-safe maximum off-bias in case the biasing and uC circuits are faulty in some way, even software.

If you're aiming to use this for retrofits, think about putting the tube indicators in a small module that can be attached to see through the back of the amp so as to not modify the front panel.