close-circle
Close
0%
0%

Avalanche

A high-voltage power supply and high-bandwidth pulser

Similar projects worth following
close
The venerable Jim Williams avalanche pulse generator is the canonical hobbyist means of high-bandwidth pulse generation. The avalanche circuit itself is simple, easy to build, and highly illustrative of an interesting semiconductor property that's rarely considered otherwise. Unfortunately, probably BECAUSE of this simplicity, one can't simply go online and buy one of these. Additionally, the high-tens to low-hundreds of volts power supply required for high-bandwidth operation represents a level of danger and difficulty that many hobbyists are unwilling to tackle. I'm working on a production-ready version of this circuit eventually available for purchase, as well as open-source reuse simply for the power supply module.

System Overview:

At a broad level, a HV power supply feeds an avalanche-biased transistor. This results in an output of indeterminately repetitive pulses with random timing and extremely fast rise time/high bandwidth. These are (optionally) fed into a high-speed detector for the purpose of timing the duration between pulses, and perhaps for measuring other parameters. This detector is hosted by a PC running software to make the raw and/or processed data available via API.

Power Supply:

At present, a 150-or-so volt power supply is created by using two external supplies, one 5V and one on the order of 12V. A 5V square(ish) wave is generated by a 555, fed into a buffer and inverter to create a cleaned up square wave and its compliment, and then these are fed into a SN754410NE quad half H bridge to create a push-pull output of the second (12V) supply. This is multiplied by a 7-stage Cockroft-Walton multiplier to around 150V. I do not like this topology for a number of reasons and expect to replace it with a variable, single-supply flyback circuit.

Pulser:

The ~150V out of the supply is used to drive a 2n3904-based Jim Williams avalanche pulse generator. The output is a very fast pulse (faster than my 100MHz scope can measure accurately, a rise-time measurement shows a bandwidth of 240MHz) of about 40V (again, this may be lower than the true output voltage given my scope's bandwidth limitation).

The theory of operation here is reasonably simple: when you greatly reverse-bias a PN junction, you approach a region called "avalanche breakdown." In this region, a small number of electrons will, probabilistically, cross the junction by mechanisms such as tunneling, and will thereby open the junction for further current. This has an additive effect and thus the breakdown process happens on extremely short timescales. The current caused by this breakdown is very high, in this design on the order of an amp, which flows through the 50 Ohm emitter resistor and to the output. However, once current is flowing, it will continue to do so until the junction overheats and breaks. This creates the need for the 220k supply resistor and the 22pf supply cap. The resistor prevents a dangerous amount of current from being sourced through the device by the supply, where the 22pf capacitor holds all the charge necessary for the momentary 1A current. Once the avalanching transistor has drained the capacitor, the collector is then at a low voltage and avalanche current stops. This gives the 22pf capacitor a chance to recharge and the cycle begins again the next time the device avalanches. The 10k base resistor to ground is to ensure that the transistor stays off with the exception of avalanche operation.

Detector:

The detector portion is very much on the drawing board still both in design and fundamental definition, however there is one concrete requirement. It will be required to accurately TIME the duration between pulses, as this is a fundamentally random variable. The distribution of durations is interesting to me experimentally as a function of supply voltage and also as a source of random entropy for cryptographic applications.

Software:

Naturally, for the detector to be useful, there must be a way to collect and use the data it gathers. At the simplest, this could take the form of some Python code reading data out of a serial port-connected microcontroller in the detector. This is a very likely route. Additionally, I expect to make a web-based API available so that, for example, an organization could deploy this hardware locally and query it for entropy over a local network connection. In practice, hardware random sources exist, and even high-quality open source ones. But then "practicality" is hardly a design motivation here.

  • VIDEO UP. Contest entered. Time to get going!

    alexwhittemore08/20/2014 at 23:29 0 comments

    Video is up and public and the world is good. Of course, it'll be a while before there are any code repos up since that's on the other end of main development.

    Next thing up is going to be the power supply and converting that to the flyback topology I'd like to use. Stay tuned!

  • Documentation, documentation

    alexwhittemore08/20/2014 at 23:14 0 comments

    The project details are much more filled in now (well, with what information exists to this point), including a very professional slide deck I paid a consultant BIG MONEY to make. Video soon.

  • Prepping for the prize

    alexwhittemore08/20/2014 at 20:58 0 comments

    A bit has developed about the project in my mind over the last few days thinking about it. I think it lends itself well to a highly modular structure with 4 comprising the full thing: 1) a power supply, 2) the pulse generator (both the namesake and most trivial component), 3) an embedded µC-based timing unit, and 4) software for that timing unit to pipe data to on a PC.

    1) Is straightforward, if I think one of the most useful bits of the project. Generating HV is useful for lots of things, but doing it in a comfortable fashion is tricky since, you know, it can kill you if you mess it up. Having banana leads clipped to mains floating around on the table is the easiest option, but also the most insane. I've been shocked going this route... well, we'll leave it there.

    2) Because a high-bandwidth pulse is sort of the point.

    3) it turns out, there are a lot of useful side-effects of the pulse generator circuit. Most obviously, its timing is non-deterministic, and the timing probability distribution is quite related to the charge voltage it's fed. I'm really interested in working with that both experimentally and as a random entropy generator. I need something with pretty high timing accuracy to actually listen to and log pulses.

    4) Gotta get that data into the computer. I imagine I'll also set up some web server software, probably with a RasPi, to make the random output available online as well. Nothing cooler than entropy sources accessible via API!

    Partly fleshed-out details and a video coming soon.

  • The beginning.

    alexwhittemore08/02/2014 at 02:58 0 comments

    Obviously this project is a bit more underway than "just starting," but for the sake of starting a proper project log, I'll update with where it's at now.

    The pulser bit is done. I mean, it's like 4 components, it's trivial. Although really, it's not done. It needs a PCB, proper RF connector, and probably some kind of source impedance. Realistically that's actually a number of details to work out.

    Even so, the much-harder part is the power supply, and that's where I really plan to put the value of this project. At present, the supply/pulser system is MOSTLY self-contained, meaning it only needs two power supplies. A 5V supply runs a 555 to generate a mostly-50% duty cycle mostly-square wave, and that is then used to drive a SN754410NE H bridge. This is where the second supply comes in - the H bridge is switched by the 5V from the 555, but it's PUSHING a much higher second supply of anywhere from 0 to 35-odd volts. In practice, I'm currently finding best functionality around 12 or so volts, but you'll see in the next part why it even matters. And actually, I lied, the H bridge isn't driven directly by the 555 but rather by a pair of signals coming from an inverter sitting in the middle - one of the signals is inverted from the other, basically driving two outputs of the quad half-H bridge in a push-pull configuration.

    So this push-pull output of the H bridge, equal to the second supply voltage (so peak to peak, double that) is then fed into a Cockroft-Walton multiplier of (as it happens to be now) 7 stages. The exact output of this multiplier, set by the second supply voltage (since it's a multiple of that), is used to drive the pulser. By adjusting it up, one can tune the frequency that the pulser recovers and thus re-pulses, though the exact timing is random. In general, if the output is just past the avalanche breakdown threshold of the device used (here, a 3904), you'll get one, infrequent pulse. By increasing it, the output capacitor charges more quickly and thus the device avalanches more frequently, though again, the timing is quite non-deterministic. In the final design, I very much intend to maintain adjustability of the power supply so one can fine-tune the output pulse frequency, since I'd like to do some experiments with that as a generator of random timing.

    Thing is, this power supply topology in general isn't particularly great. I don't really like using the multiplier, if only because it's terribly low-current. I've also had some issues with poor isolation breaking the H bridge device - for example, if you try to spark the multiplier output to its ground reference, you can do that, but the H bridge tends not to survive. I suspect it's probably because of some kind of high voltage ground bounce. I'd like the supply to be more resilient to this kind of abuse, so I'm working on a different topology. That'll be the next update, I think.

View all 4 project logs

Enjoy this project?

Share

Discussions

J Groff wrote 08/02/2014 at 17:27 point
you can get rid of the inverter by constructing an astable multivibrator composed of 2 of your 2n3904s and you can get rid of the 555. the circuit has 2 points that provide normal and inverted output. The reason your H bridge is failing is normal, you cant ground a MOSFET drain to source with no load and expect it to survive, even the big ones.

  Are you sure? yes | no

alexwhittemore wrote 08/02/2014 at 19:51 point
That's a fantastic idea, thanks! I'd like to get rid of the multiplier topology totally, but if I don't, the multivibrator is definitely a better way to drive the H bridge. Probably means I can get away with a single supply as well, though it'll still have to be a variable bench supply (as opposed to a single battery, for example).

You might be right about the H bridge death. At a secondary supply of 12V, in one phase, grounding multiplier output to what I'll call the low phase of the H bridge, there's no short at all, since the diode chain is reverse-biased. In the other phase, you're right that there's a path I hadn't considered - 14 forward-biased diodes representing a Vf of ~9.8V. Given that 9.8<12, theoretically that represents a large output current from the H bridge through low impedance, so it certainly could have fried that way.

  Are you sure? yes | no

J Groff wrote 08/03/2014 at 02:44 point
Sure! That multiplier will leave you with a drifty low current source. I would ditch it for a design that uses either 2 transistors and 2 diodes/caps per stage or better yet a boost converter because you dont need pulsed input to the avalanche generator because you would lose that through your multiplier stage anyway. Or did I miss something. Anyway, the reason you only damage the expensive P channel MOSFET on the high sideof your bridge is because the other side is basically sinking current and is grounded anyway. The top side is sourcing it so it fries, those dainty P chans. But to get a N channel to source current is like cats and dogs living together. You need something crazy, like hey, a voltage doubler or boost converter!

  Are you sure? yes | no

alexwhittemore wrote 08/05/2014 at 21:08 point
Why, I could use a multiplier as a gate driver! Just kidding.

Anyway, the problem with a boost converter is that it requires a more exotic/crappier/more expensive drive switch. For that reason, I'll probably go flyback.

  Are you sure? yes | no

Gabriel wrote 08/02/2014 at 03:56 point
Much vernacular, such science...wow

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates