I bought 3 PMTs from ebay (specs on it here and here), pictured below:

PMTs from ebay.

The next step was wiring up the pins on the PMTs. I used a simple resistive divider that provides an equal potential difference between all dynodes, and twice that potential between the cathode and the first dynode. Small capacitors were added between the last 4 dynode stages, to minimize voltage drop during pulses. This circuit is very similar to the circuit Ortec uses in one of their photomultiplier bases.

Schematic diagram of the divider circuit.

The circuit wired up to the base.

I ended up not using the potentiometer that was supposed to connect to the ‘grid’ or ‘focus’ electrode, since it turned out that this connection was internally connected to the first dynode.

The detectors will be housed in paint cans. 2 Paint can each: one containing the (distilled) water and the PMT ‘head’, while the other contains the wiring and most of the base of the PMT. The high voltage input, signal output BNC and a ‘gain’ potentiometer in series with the high voltage supply are added to a 1-gallon-paint can lid.

Connectors on pain can lid.

The inside of the paint can that will contain the water is lined with heavy duty aluminium foil, to provide some reflections that will (hopefully) guide most photons to eventually reach the photo cathode on the PMT.

.
Aluminium foil lining.

The bottom of the can containing the majority of the PMT and the wiring was removed using a can opener. Effectively turning it into a short tube. I then proceeded to create a water tight seal around the PMT head and the inside of the tube using hot glue.

Hot glue seal.

For rigidity, I added some foam to the PMT’s base, holding it in place.

Foam ‘press fit’

Then, for safety, I used a cheap (badly scented) candle to melt over the form. To make sure that, if the hot glue seal does leak, it will stay out of the high-voltage section.

‘Safety’ seal.

After having finished both detectors and connecting them to my oscilloscope, I finally got an ‘event’ where both detectors fired at almost exactly the same time. This is almost certainly caused by a muon passing through both detectors. It works!

First light!

For a previous project involving Geiger–Müller tubes, I had bought a few old NIMs Nuclear Instrumentation Modules: a signal amplifier, a coincidence module and a zero crossing detector. All of these would come in pretty handy for this project.

Nuclear Instruments Modules

It turned out that the zero crossing detector required pulses with an amplitude of at least 200mv, which was much more than the signal that I had available, even after amplification. Therefore I modified the unit and simply replaced the circuitry of channels 3 and 4 with a simple comparator circuit, based on a pair of LM361 comparators I had laying around. I then dead-bug soldered them onto a scrap piece of PCB clad board.

LM361 modification

After wiring it up, everything worked as expected: the oscilloscope triggered only when both detectors actually fired ‘simultaneously’.

Coincidence triggering

I then realized that I would get a big increase in count rate when using both detectors on top of each other horizontally. This obviously makes the detector a lot less selective when it comes to the angle of the particles, plus it increases the detection area somewhat. After running the detectors in the new orientation for a few minutes, I noticed that the high voltage had suddenly dropped from around 1200 volt to slightly above 600 volt. I immediately knew what happened. A LEAK!. The distilled water had made it’s way into the high voltage compartment of one of the detectors after all!

Even though only one of the detectors failed, I decided rebuilt both. This time I actually cut a circular hole, slightly larger than the PMT head, out of the paint can lid, having the PMT’s head protrude it for about an inch, and use a generous amount of silicone to seal the PMT and the lid to the can that contains the water. Turning it into one, hopefully watertight, unit.

One PMT sealed.

Both PMTs sealed.

The new and assembled detector stack now looks like this:

The full setup currently looks like this:

The next step will be to get a NIM-BIN (a unit to slide the NIM modules into, as well as to power them), some way of data acquisition (USB oscilloscope?) and some software to log all the data.

To be continued…

RFID blblabla comminucating over RS-485 multidrop.

For more pictures check out the gallery

Here’s the very simple layout for the IGBT-board:

The IGBT driver board has 4 fully opto-isolated gate drivers. I chose to isolate all 4 drivers to get rid of any ground-noise that may arise from very high dI/dT (switching high currents really fast). It uses the MC33153Pcapable of sourcing 1 Amp and sinking 2 Amps to drive the IGBT gates. This is enough to switch on the IGBT in a little over 100nS and off in about 300nS. A simple digital opto-coupler (HCPL2601) is used to isolate the gate-drive signal from the rest of the circuit.

Schematic of a single gate driver (implemented on the driver board 4 times):

The 4 diodes in the top are just rectifiers for a floating alternating supply (no terminals shown).

Then there’s some basic logic to avoid illegal driving states (i.e. driving both gates turned on at the same leg causing shoot-through, turning the IGBT’s into small fireworks) and handle fault signals (IGBT Desaturation) from the MC33153P’s. Desaturation happens whenever the IGBT is unable to support the conducting current, due to which the Vce voltage gets dramatically high. A fault is detected when this voltage rises above 6 Volts, triggering a flipflop through an opto-coupler and blocks the drive-signals.

Last but not least, a floating supply for each driver. This is simply done by an SG3525A regulating pulse width modulator. It’s set to oscillate at a duty cycle a little under 50% at around 100KHz, driving a pair of IRFZ48Nmosfets, which in turn drive 3 toroidal transformers supplying the floating power to the driver circuits. I’ve only used 3 transformers since the supplies for the bottom IGBT drivers are wound around the same core: there’s no high dV/dT there, just some noise. I might even get away with powering both lower drivers from the same supply but this topology adds a little robustness to the system.

Finally a picture of the whole assembly. You can see the 3 transformers on the left and a little piece of prototyping board with a microcontroller (CY8C29466-24PXI) generating a pulse width modulated sine-wave for the driver board.

For more pictures check out the gallery

://feelbetteryoga.com/wp-content/themes/launch/css/typography.css
in typography.css

look for code around 85

picture blablablablafrf

rfrfrfrf

For more pictures check out the gallery

Like with most controller circuits, I started out with a PSoC micro controller. I chose the CY8C29466-24PXI) as this controller has room for 8 communication blocks, which I used for 4 MIDI outputs, 2 MIDI inputs and an RS232 UART for communication with a PC (laptop/netbook) through USB-to-Serial cable. With all 8 communication blocks used up, there still are 8 other configurable digital blocks left for other general stuff (Timers, PWM, etc…).

I haven’t made any schematics of the circuit itself, but it’s pretty straight-forward.
A simple google image search returns a lot of useful MIDI-interface circuits. I’ve used a couple of 74HC14 inverters as a buffer for the MIDI outputs and 6n138 opto-couplers for the inputs. All resistors in the midi-interface circuit are 220 Ohms.

The power supply is built around a LM2574HVN-5.0. There are 4 diodes configured as a bridge rectifier followed by a 220uF/35V capacitor at the power input so the controller can accept both DC and AC adapters of a wide voltage range.

The RS232 interface is a standard interface using a MAX232 and a handful of 100nF capacitors.

MIDI Controller API

The controller supports 4 layers, which means that one midi message on any input can be routed to a maximum of 4 channels (on the same or multiple outputs) at the same time

• int midi_setoutput(struct midi *m, int layer, int input, int inchannel, int output) // Set the physical output to which a certain input/midi channel combination for this layer should be routed to
• int midi_setchannel(struct midi *m, int layer, int input, int inchannel, int channel) // Set the output midi channel to which a certain input/midi channel combination for this layer should be routed to
• int midi_setvelocity(struct midi *m, int layer, int input, int inchannel, int velocity) // Set the velocity of this input/midi channel combination for this layer anywhere between 0-200%
• int midi_enabled(struct midi *m, int layer, int input, int inchannel, int enabled) // Enable/disable this input/midi channel combination for this layer
• int midi_getoutput(struct midi *m, int layer, int input, int inchannel) // Get the physical output to which a certain input/midi channel combination for this layer is currently routed to
• int midi_getchannel(struct midi *m, int layer, int input, int inchannel) // Get the output midi channel to which a certain input/midi channel combination for this layer is currently routed to
• int midi_getvelocity(struct midi *m, int layer, int input, int inchannel) // Get the velocity of this input/midi channel combination for this layer
• int midi_isenabled(struct midi *m, int layer, int input, int inchannel) // Check if the input/midi channel combination for this layer is enabled
• int midi_disableall(struct midi *m) // Disable all routes
• int midi_output(struct midi *m, int output, unsigned char *data, int len) // Send raw MIDI data to an output
• int midi_bufferinfo(struct midi *m, unsigned char *data) // Get info about the internal MIDI output buffer usage
• int metronome_start(struct midi *m, unsigned char *pattern, int len, int period) // Start metronome using a onfigurable speed and pattern
• int metronome_stop(struct midi *m) // Stop metronome
• int metronome_clickselect(struct midi *m, int click) // Select a click sample

Here‘s a link to the Picture Gallery.

Attached are the PSoC Designer files and an application (Linux) to test functionality. The final PC-side application hasn’t been built yet.

• PSoC Designer project: midicontroller.rar
• PC-side test application (C): testapp.tgz

The circuit becomes clear when looking at the pin usage after opening the project in PSoC Designer.

For more pictures check out the gallery

This device will have the same functionality as the DisplayBox when connected to a computer (laptop/netbook) running the appropriate software. It communicates over RS232 with a 9pin sub-D female connector. The entire board is incorporated into a sub-D connector housing and connects to a “Jump Mat”.
It times on- and off-events from the Jump Mat with a precision of 1/1024s and a maximum deviation of (apparently far) less than 30ppm (parts per million).

As with the DisplayBox project, no technical details or schematics of any circuits due to NDA.

A picture of 5 assembled PCBs and sub-D housings.

For more pictures check out the gallery

It’s a hand-held device used for rehabilitation. It connects to a “Jump Mat” which is basically a mat with a contact that closes whenever a person steps or jumps on it. It has a graphical true-color (16M colors, 24 bits) OLED display, CapSense™ buttons (like the I-Pod), a lithium-ion battery for system power, a USB interface and an RJ45 connector with a serial port and handshaking. The handshaking signals are only used to detect the state of the “Jump Mat” while the serial port is used for debugging purposes as well as accessing an 8MBit flash chip containing fonts and background images.
Of course I can’t post any technical details or schematics due to NDA, but I can post pictures of the product and the boards.

Here’s a picture of the initial prototyping stage while setting up the OLED communication. As you can see I keep a hammer nearby, in case things get out of hand.

These are the final PCB’s for this hand-held gadget:

For pictures of various stages of development check out the gallery