OT protection??

[R.G.]

Found the PCB layout, but no schematic.

This one was for four tubes individually monitored and switched, with a light which showed which tube set the thing off. I'd have to reverse engineer my own work. That may take a while.

[Alf]

Well I'm not in a hurry R.G. take your time , I really appreciate it that you took the time to look into it at all !

Alf

[R.G.]

Well I'm not in a hurry R.G. take your time , I really appreciate it that you took the time to look into it at all !

No problem.

There's no magic. You just stick in a current sampling resistor, then use the voltage across that for an overcurrent signal. You have to lowpass filter that so that you don't trip at tiny transients. Picking the lowpass filter timing so the tubes can do the overload thing that everyone demands, but not tripping on short ones and still saving the tube from melting the plate or glass envelope takes some work.

After that, it's all logic and messing about to make is shut down the MOSFETs, come up from power-off with the tubes working, do standby (might as well, the hard part's already done) tell you which tube is a problem, junk like that.

I think if I redesigned that today, I'd probably case up everything except the current sampling and lowpass filtering in a microcontroller. A $2.00 microcontroller gives you many channels of A-D conversion, watching the standby switch, and all the tell-me, resetting, lights and fancy stuff you can imagine. And you can write the program in BASIC. And you'd only need one logic chip instead of six like I had to do when I did the hard-logic version back when.

[jakehop]

MAN! I would like to see a schematic of that...

[R.G.]

Yeah. Me too.

[Alf]

After that, it's all logic and messing about to make is shut down the MOSFETs, come up from power-off with the tubes working, do standby (might as well, the hard part's already done) tell you which tube is a problem, junk like that.

I think if I redesigned that today, I'd probably case up everything except the current sampling and lowpass filtering in a microcontroller. A $2.00 microcontroller gives you many channels of A-D conversion, watching the standby switch, and all the tell-me, resetting, lights and fancy stuff you can imagine. And you can write the program in BASIC. And you'd only need one logic chip instead of six like I had to do when I did the hard-logic version back when.

I am patienly waiting because you've lost me here !

Alf

[R.G.]

I am patienly waiting because you've lost me here

Sorry.

Just shutting down the amp when something overcurrents is like using a fuse. But there is no fuse there to tell you what happens. It'll start right back up when you power off and then back on. Which may be what you'd like to do, but there's a lot more you can do. I personally would like to know which tube did the deed. And it would be nice to be able to press a reset switch in case it was a transient glitch. And all this stuff makes a pretty good standby switch without running the high voltage around to a switch.

You can get that stuff by doing one current sensing resistor per tube and one comparator per tube to sense which tube was the offender, and one MOSFET per tube becomes necessary if you want the MOSFET to switch off in the ground side. It is entirely possible to switch off one place in the B+, but it takes some trickier circuitry, and I found it simpler and more reliable to do one MOSFET per tube.

So you have two 10 ohm 1% resistors and two MOSFETs. Also a dual comparator, one reference voltage to be a threshold for the sensing, and two R-C networks to average out the current waveforms so you don't trip the amp off when the drummer sneezes into his microphone.

Each comparator's output sets a logic flipflop to off. This is the flipflop whose output tells the MOSFETs to be on or off and thereby control the MOSFETs.

You'd like these flipflops to come up in the "MOSFETs ON" condition when the power switch is turned on, so there's some resistor/capacitor/logic stuff to make sure they come up "on".

The flipflops are also what you force on to reset. They're also what you turn off and on to do standby.

And pretty much for free - a resistor and an LED - you get the flipflop lighting an LED when the MOSFET it's supposed to control is turned off.

All of these are simple, one-thing-at-a-time issues, but they all need some resistors, some caps, a logic gate or two, some MML (Mickey Mouse Logic) to make them work. That all adds up, and you get over $2.00 pretty quick.

The $2.00 number is significant. That's the price for a programmable microcontroller which contains about eight channels of A-D that you can program in BASIC, doing things like:

UNTIL FOREVER DO
READ A-D INPUTs
IF (mosfet1) > 100ma THEN SET FAULT FLAG1
IF (mosfet2) > 100ma THEN SET FAULT FLAG2
IF FAULT FLAG1 or FAULT FLAG2 THEN GOTO OHMYGOD
ENDDO
OHMYGOD:
OUTPUT MOSFET1 OFF
OUTPUT MOSFET2 OFF
OUTPUT LED1 ON
OUTPUT LED2 ON
RESET LOOP:
READ RESET SWITCH
IF RESET SWITCH = OFF THEN GOTO READ RESET SWITCH

Which looks bad, but is really pretty simple. Just one step at a time of look at the conditions, and when something happens, do whatever is right for that situation. And you only have to get it right once, then you can run the amp forever with it working that way.

And you get to test how the Save-My-Amp-Now (tm) widgie works by just using control voltages instead of real tubes and transformers.

Anyway, it only seems complicate because you have to think about each tiny, microscopic step of what to do, then write it all down. People are so very good at encasing complicated things in one logical concept that we have trouble doing microsteps, which is what programming is.

[raiken]

RG:

There are some really nice modern all-in-one microcontrollers out there that have built-in 10-12 bit ADC's, comparators, power-on/brownout resets, and voltage references. They can directly drive logic-level MOSFET gates, so you can do the whole thing with just a couple resistors, a couple MOSFETs, and the CPU. No external comparators or latches are necessary.

Just put a pull-down resistor on the gate, and the MOSFET will come up in the off state for safety until the CPU boots (which will be instantaneous, for all practical purposes with that small amount of code) because all the port pins come up tri-stated. Use another port pin for LED indication. You can also allow for a reset switch and take advantage of the internal non-volatile RAM to store the history of which tube tripped. In addition, you can turn off the tubes in pairs if one tube of a quad trips, so the amp can limp by at half-power to get you through a gig.

You can write accumulator code or other simple filter code to ignore transients and trip only on average current. You don't really need any external comparators or filters, it can all be done in software, although a small amount of simple external RC filtering for pin protection wouldn't hurt. You can use another port pin as an input for the standby switch to turn off the MOSFETs for standby.

Most of the microcontroller manufacturers provide free example software and free IDEs based on Keil or Eclipse or something like that, so you can program them in C, which is really easy to learn. They also have cheap (<$100) eval kits that come with device programmers/emulators that plug into a USB port.

And never forget to add in a higher-current fuse in line as a backup - just because you have a fancy "drive by wire" system, doesn't mean it can't lock up or go off into the weeds. Just ask Toyota...

And stay away from those dreaded GOTO statements - they are the bane of programmers everywhere.

RA

[dai h.]

fwiw here's something which came up on ampage some time ago:

Internet Archive Wayback Machine

(I have no idea how it works though.)

[d95err]

And stay away from those dreaded GOTO statements - they are the bane of programmers everywhere.

Unfortunately, GOTO is the foundation upon which BASIC is built, so I don't know if you can do without it. At least in the simple BASIC used to program microcontrollers...

There are some very good C compilers for microcontrollers these days though.

[Steve Conner]

This is a pretty good microcontroller board that a friend told me about:
ET-ARM Stamp

32-bit, 50MHz, 128k of flash, 6 channel ADC, works with the Gnu free C compiler, $28.

There's also the Arduino for people of a more tender, artistic nature. :-)

I built one of these protection circuits (though mine was analog with about 3 transistors) but I found nuisance tripping a real problem.

[raiken]

This is a pretty good microcontroller board that a friend told me about:
ET-ARM Stamp

32-bit, 50MHz, 128k of flash, 6 channel ADC, works with the Gnu free C compiler, $28.

That's a great price! I use the NXP LPC family ARM7's extensively, in particular, the LPC2114 and LPC2124 - they are great microcontrollers, highly recommended. The GNU compiler also integrates nicely into the open-source Eclipse IDE.


RA

[R.G.]

There are some really nice modern all-in-one microcontrollers out there that have built-in 10-12 bit ADC's, comparators, power-on/brownout resets, and voltage references. They can directly drive logic-level MOSFET gates, so you can do the whole thing with just a couple resistors, a couple MOSFETs, and the CPU. No external comparators or latches are necessary.

Yes, I know. I'm trying to be as simple as I can for the average readers here. I knew someone with some code experience would pop in. That's why that particular code snippet was ... ah... less than accurate, if representative.

And stay away from those dreaded GOTO statements - they are the bane of programmers everywhere.

Yes, I've been extruded through several programming schools. I'm actually a big fan of whatever programming style for preventing you from doing things like GOTOs is current at the moment. Been through several of those:ADA, Pascal, several lesser well known ones, C++, Java, Yada, Yada, Yada. The point of those is to try to make it harder for you to do dumb stuff.

However much a programmer who has to turn out real, functional code decries it, they know about GOTOs and will quietly stick them in their code if the going gets rough and there's no clean or efficient way around them. Even if the language has strictures to try to make them impossible. I've seen GOTOs coded in the strangest ways!

I used to manage the kernel support/enhance group for AIX for a while. The programmers divided up into those who would freely admit doing whatever was needed to get the code to run reliably, and those who would do it slyly and bad-mouth the others. All the ones who would not do whatever was needed to get it to run (efficiently, properly documented, and peer reviewed, all by the book, understand) were no longer working in that group.

Of course, there's the he-man school of programming: Documentation? Documentation is for wimps. If it was hard to write it *ought* to be hard to understand. REAL programmers program right down to the bare metal.

I built one of these protection circuits (though mine was analog with about 3 transistors) but I found nuisance tripping a real problem.

Yep, that issue is the bane of any kind of active protection for tube stuff. You have to really slow down the protection, so that it takes big problems for seconds or even tens of seconds with equanimity. The one real underlying vote for controller based stuff is that you can just code in things like "wow, this has been going on for quite a while now. I think I'll turn the volume down, and if it doesn't look better in about 30 seconds, I'll shut 'er down." You don't have to synthesize the transient response of whatever you're doing to make it really protect. With programming, you can do things like making your circuit guess, or keeping track of how long the average song is so you can *guess* whether you need to shut it down.

That's tricker without GOTOs...

[raiken]

All GOTO's aside...(where they belong) ,

Have any of you guys messed around with the new Cortex-M3 offerings from Luminary Micro or ST? They look rather interesting - they can do a single-cycle 32x32 multiply at 80MHz and have a hardware divider as well.

Unfortunately, the 32x32 multiply only produces a 32-bit result, not the 64-bit you'd want, but I think it can do a 32x32->64 in 7 clock cycles.

I was thinking of playing around with implementing a digital reverb in one of them. I think they may be fast enough, and they have an I2S interface with DMA, and a good bit of internal RAM (up to 96kB), and a 32-bit external RAM interface. Seems like they'd make a nice "poor man's" fixed-point DSP...

RA

[Steve Conner]

Hi Randall

The guy who told me about that ARM board is working on an analog modelling synth that runs on the Cortex. I think he's actually got it to make noise.

A 32-bit result from the multiply is fine for DSP. You're probably going to truncate it to 32 bits anyway. But a real DSP would have a multiply-accumulate, going into a dedicated accumulator with lots of bits, so you only have to truncate (or round) it once at the end. I started out on the Analog Devices 21xx series, and they have a 16 x 16 MAC with a 40-bit accumulator.

The Microchip dsPIC is another "poor man's DSP".

The reason for "GOTO" being deprecated is simply that it makes code harder for people to understand. The program flow can jump off to absolutely anywhere. You're supposed to use function calls and subroutines instead. Then when you see the call, you know it's going off to do something, the name of the function tells you what it's doing, and you know it's going to come back and carry on where it left off.

Like Donald Knuth or whoever said, "Programs should be written mainly for humans to understand, and only incidentally for computers to execute."

If you need maximum performance, minimum code size, and you don't mind suffering horribly for it, you can fling all of this stuff out of the window and hand-code everything in assembler, like one of those old "Real Programmers". But nowadays you're advised to program in C and let an optimizing compiler fling it out of the window for you.

Even this attitude is now old-hat in the desktop world, today's programmers think of C the way I think of assembler, and like to work in really high-level languages like Python or Microsoft's .NET family. But in the embedded world C still rules.