le?
Because we weren't doing a student project, but building an electron beam u nblanking system which had to do what the customers needed.
When we were producing our narrowest - 500psec wide - unblanked pulses, we had some 40nsec of processing time between pulses that limited the maximum duty cycle to about 1.25%. Exactly the same hardware was used to produce wi der pulses which could have been up to 320usec wide.
I hadn't made that clear earlier because it complicates the story - and it certainly complicated the design.
We were accumulating our "stroboscopic" pulses into up to 1024 separate mem ory locations, and successive pulses could have been as little as 40nsec ap art, for a worst case duty cycle of 99.98%.
You can't over-drive transistors in that kind of circuit, if you expect the m to not only survive but also to keep on performing exactly the same way f or years.
Not half as insane as the amounts of money you'd need to spend re-inventing a whole host of different kinds of wheels.
The 18 months of debug time was on the complex - and fast - signal processi ng logic, which we did in ECL. That was our unique selling point. With hind sight, we should have settled for 10MHz processing inside a bunch of Xilinx chips, rather than going for 25MHz in ECL, but the mad technical director had gone to quite a lot of trouble to suppress that particular system desig n - I first heard about it in 2009.
That's what we should have done - I'd proposed the GaAs solution precisely because I thought it dramatised the point that the mad technical director's demands were mad, but - sadly - it turned out to be practicable, though ra ther impractical.
It wasn't money - as such - that was the problem, but where it was being sp ent. The mad technical director always wanted a new gizmo he could sell, and the y get developed at the expense of time spent on getting the last of the bug s out of the previous gizmos.
Not in our application.
We could have any duty cycle from 1.25% to 99%. It couldn't be designed as a pulsed system.
Only relevant if your load can be guaranteed to be a brief pulse, Ours coul dn't.
For an application that lets you get away with that kind of design.
I've spent time cutting holes in ground planes. It wouldn't have helped in our application.
The BFR96 was in a pill package. The BFG97 seems to be the same die, packag ed in a proper SOT223 surface mount package, and it's still around. Farnell has 399 in stock in Australia at $A1.58 each for 1-9.
I had.
In your application, not mine.
We had graduate students coming out of the woodwork at Cambridge. The mad t echnical director had got his Ph.D. there in 1968 - I'd come across (and re membered) one of his papers in Electronics Letters while I was doing my Ph. D. in Melbourne.
They found us at Cambridge Instruments. Their brilliant solutions to their toy problems looked less brilliant when applied to real problems. My best s tory is about a graduate student who had solved a particular problem with a Mulvey electron microscope "immersion lens". I knew enough to be aware tha t the Mulvey lens tends to run hot, so I asked him how he cooled it - he'd run it for 20 minutes and let it cools off for eight hours. We were being o ffered this for industry use. Texas Instruments ended up adopting a slightl y different solution, and the graduate student suddenly reappeared as an ex pert on neural networks ...
The layout was interesting, but it was all properly worked out microstrip c onnections. With hindsight, the base drives probably weren't fierce enough.
That work was done back in 1984/85, and the BFG31 wasn't around then.
Our PRF was usually close to 25MHz. Various drop-offs meant that it was dow n to 16MHz when the project was canned, but we would have fixed them within a few months if the project had lasted a bit longer.
As I said above, the duty cycle with 500psec pulses was only 1.25%, but wit h wider pulses (and we could make them very wide) it could go up to 99.8%. With pulses wider than a few nsec, the PRF would obviously go down with th e pulse width.