homebrew multi-channel analyzer

This is bound to get mixed up with things in Electronics, check both. Physics-specific stuff here, mostly.

homebrew multi-channel analyzer

Postby Philipp Windischhofer » Wed Aug 20, 2014 3:26 pm

Hi!

This is a small multi-channel analyzer I've been working on recently. It's to be used with scintillation probes that have a PMT as primary amplifying stage.
I only have a BC-412 plastic crystal (sensitive to >50keV gamma and fast neutrons) at the moment, which is pretty sensitive on the one hand, but pretty useless for gamma spectroscopy on the other. Still, it's sensitive to fast neutrons and I hope I can use the energy information to do some discrimination of real neutron hits against gamma / x-ray background and EMI.

PCBs.JPG
PCBs

This is how it looks inside with the shielding removed, all PCBs were etched at home.

These are the schematics of the 4 main boards (the ones inside the old TV-tuner box):
Preamp.pdf
Preamp -- nothing fancy
(91.89 KiB) Downloaded 450 times

PeakDetector.pdf
main analog circuit for peak detection
(202.69 KiB) Downloaded 442 times

RippleStripper.pdf
ripple stripper for noise-free HV
(84.34 KiB) Downloaded 440 times

Logic.pdf
digital part
(333.24 KiB) Downloaded 429 times


The detection of the impulse peak heights is done in hardware, the microcontroller (dsPIC33f) only has to sample the peak values afterwards. No pileup-rejection is implemented yet -- I saved this for revision #2, if necessary. I get the data out by means of I2C:

The HV for the PMT comes from a selfwound ferrite-type transformer used in a resonant Royer-oscillator (@ about 50kHz). The output voltage can be set to any value from 150V to 1500V, so it's a generic supply for geiger / PMT type projects (I would have posted a picture, had the board software let me add another attachment).

For a test, I fed pulses of well-defined height into the device using an arb-function generator. This is how the "spectrum" looks like:
shield_onoff_comparison.png
"spectrum"

Looks pretty gaussian to me, the total width of the peak corresponds to about 40mV "noise" on the A/D input. (This is one of the things I don't know yet -- is it "real" noise from outside, or is it just the S/H circuit jitter?)

A "real" spectrum looks more like this (sample was a small piece of Uranocircite, reads about 0.8uSv/h on my pocket geiger):
UranocirciteBackgroundSubtracted.png
uranocircite spectrum


Of course, this is nowhere near being perfect; but I think it's a start and good for some measurements -- if I can get neutron discrimination right with the energy resolution of the crystal, it's served it's purpose.

(I also posted the circuit over at fusor.net and asked for improvements / comments; but got nothing yet -- so probably somebody here can comment on the EE-part and give me some hints what to do better next time).

-Philipp
Philipp Windischhofer
 
Posts: 21
Joined: Wed Aug 13, 2014 2:12 pm

Re: homebrew multi-channel analyzer

Postby Doug Coulter » Wed Aug 20, 2014 6:17 pm

Looks really nice! I'll look over the design and maybe make a copy etc. We need this kind of thing here, but as you say, you need a better detector. We use the same as you for our basic neutron measuring device - it's much more stable than the 3He tube or the B10 tube, though pretty numb. That's not important at the neutron production rate we have. You probably want a NaI:Tl "big jug" detector for this to really shine. Until you go to HPGE - the detector itself isn't a lot better, I know because we borrowed an expensive MCA to put all our detectors on. NaI is just a little better than what you show (maybe) even on the best MCA, if it's a good big one (for higher energies) or a small one (only for lower energies). AFAIK, BGO and (certainly) plastic scintillators are a bit worse than a good NaI, and HPGE is far better (but needs LN2 to work at all, so that's out where I live - too far to go to get cryogenics).
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: homebrew multi-channel analyzer

Postby Doug Coulter » Wed Aug 20, 2014 8:35 pm

Looking this over I have few quesstions...it looks really similar to a design I've had floating somewhere near my mind for awhile - funny thing, cool.

I can see this getting into slew rate issues with a really fast scintillator..some of those would give nearly any opamp, and certainly that S/H chip, the willies (in the form of slew rate limiting and resulting distortion). But those are also lousy scintillators for gamma spectrometers anyway, and you might be just fine there with what people would actually hook up to this. (5ns or less plastic stinks as an energy measuring device anyway).

Obviously we need to get you a half-decent NaI of some sort to test on, and at least one really good fine-line sample (we use an "official" CS-137 .25uC one here for that, just the two lines, very nice).

I'm having trouble understanding the use of the ripple stripper, what it does, where it goes in the plan. Can you elaborate on that a little?

Here, we use CCFL inverters for the HV for the phototube. They are cheap, versatile, and the output tracks the input voltage very closely and stiffly. We just use something like an lm317 to regulate the input - done, it's good enough, and even a .01uF cap is plenty of filter, no noise at all. They do, however, radiate noise like crazy off the transformer, so in our builds they get put in their own little metal compartement with just the filtered DC in and out. I tend to use one rated at 1kv, 12w output, 12v input @ 1a max, but that's because one size can fit nearly all. I use a volt doubler if I need more, and a regulator on the input if I need less output. These run down to around 1.1v input, and after that the output is prety proprtional to the input voltage, haven't had any issues even with phototubes which are kind of picky about that. I suppose one reason is that most of the power to a phototube goes to the divider chain, and that's pretty constant as a load. We haven't noticed any serious thermal drift issues with those, but we usually use 5v or greater input to them too, which would tend to minimize that re the Vbe of the transistors in the oscillator.

Though I'm a big fan of the PIC chips, I don't know that one. Is the a/d internal, and what's the resolution? Are you actually using I2C for the output data? That seems a little strange as most pics have a perfelcty good normal serial output.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: homebrew multi-channel analyzer

Postby Philipp Windischhofer » Thu Aug 21, 2014 2:18 pm

Doug,

thanks for your reply and the comments!

I can see this getting into slew rate issues [...]

I totally agree with you :)

We use the same as you for our basic neutron measuring device [...]

Did you shield the crystal with lead to block out the x-rays? In other words: how do you discriminate neutrons against background?

Obviously we need to get you a half-decent NaI of some sort to test on, and at least one really good fine-line sample (we use an "official" CS-137 .25uC one here for that, just the two lines, very nice).

I'm planning to acquire a nice Na:I for "real" spectroscopy -- but I'm a student, so I have to get along with a smallish student-type budget :roll:
As for the calibration source: it's pretty difficult to find a Cs-source here in Europe that you can legally own without having to register it -- the limit for Cs-137 is 10kBq.

As for the ripple stripper: I found the circuit in the schematics of a commercial gamma spectrometer (see attachment (it's also somewhere on the internet, but I forgot to bookmark the link); the stripper circuit is U41:B) and liked the idea at once. Given the simplicity of the circuit, it's probably the single most "efficient" (as in: "usefulness divided by part count") that I know of.
It acts as an active ripple reducer by generating and feeding back a 180° phase-shifted version of the input ripple signal. If you prefer, you can also think of it as a capacitance multiplier.
Since the output voltage of my HV-supply has about 1V of AC left at full snot (1500V), I added the stripper circuit to get the ripple down to the ~10mV range, where it does no harm.
And yes: my supply also has a very strong tendency to radiate noise all over the place, so it too has a nice metal box all of its own:
highvoltage.JPG
high voltage supply


I went down the CCFL path, too, for a while; but before I got the chance to get a commercial one, I guess I just wanted to try doing it myself once. (Actually this is the second transformer already, I fried the first one when I tried to determine its max. output voltage.) But it's certainly the most economic way of doing a HV supply quickly and efficiently.
Do you have any data on what kind of noise/ripple levels you can achieve with the ones you're using?

I'm a big fan of the dsPIC - it's a really powerful device. Microchip sells them as "digital signal controller", in fact they're somewhere in between an ordinary microcontroller and a big DSP. They can run at up to 40MIPS and have enough power to e.g. run multiple adaptive FIR-filters (filtered-X LMS) with about 100 coefficients each at 8kHz sample rate. (Tried this one for active noise control -- works great!)
They also have some more specialized version for motor control that comes with additional periphery (e.g. for doing field oriented control of 3-phase motors).
Sure, it also has standard serial output, but I chose I2C because it fits into the great plan better: next thing I'm going to do is a universal DAQ system for measuring voltages / temperatures etc. (for my upcoming fusor experiments). The backplane bus on that device will be I2C, and so I can seamlessly fit the MCA in, too. All data channels are bundled and then sent to the PC serially. They are stored in a postgres-DB and I run a java-application on a frontend PC that lets me read out data series either in realtime as they come in, or after collection for offline analysis.

This is how it currently looks like -- not completely done yet, but already useable:
screencapture.tiff
frontend application for DB


-Philipp
Attachments
UCS20manual.pdf
manual, schematics are at the end of the document
(1.39 MiB) Downloaded 421 times
Philipp Windischhofer
 
Posts: 21
Joined: Wed Aug 13, 2014 2:12 pm

Re: homebrew multi-channel analyzer

Postby Doug Coulter » Thu Aug 21, 2014 7:34 pm

Yes, we use lead, and since we're trying to just count neutrons, a threshold is plenty good - you don't truly get a spectrum out of a hornyak anyway...lots of smear in the signal depending on chance of where the neutron hits.
We miss a few neutrons that kind of don't hit the right spot, and get a few super high energy X rays that had to have come from some very fast charged particle hitting a nucleous...but those are so far above our supply voltage they have to mean "fusion" which is what we're really interested in counting anyway.

I still don't understand the ripple stripper, though I know what a cap multiplier is (I've been an EE for over 40 years now). Since you didn't really provide interconnect info, it just looks like an opamp that's open loop for DC...and which would merely drift off to one rail or the other.

Our supplies (depending on what they are used for) typically have 10's or < 10 mv ripple. If it's for a geiger, who cares? Signal is 50v, we can have some mV ripple. If it's for something fancier, well, I'm lucky to have bought a large quantity of .47 uf high voltage polyproplene capacitors...with a simple RC after the supply, it's just not been an issue at all = ripple equals the same you see with a shorted scope probe. I tend to run my phototubes on the "loud" side re signal, as other noise getting in is generally more of an issue, and use a relatively high load R with the cable part of the shaping RC (using a negative polarity supply for the photocathode so the anode is otherwise a float until I put a load R to ground on it). I used our CCFL based stuff with the expensive 8k channel MCA and there was no issue with the linewidth as a result - the NaI spread was, by far, the limit. And we have them all sizes and shapes - one might show up at your place "somehow", though probably not one of the 6" by 4" crystal ones...they're kind of precious here, but we've got a bunch of 1" sq by 4" deep ones stripped out of a PET scanner and various other kinds as well, we got them really cheap. We can ask Bill what he can find...if nothing else, I've got more than I'll ever use. Some better than others, all better than what you have for gamma spectroscopy.

Re data aq for fusor - we've done a pic based one like our standard counter (in the products section) and also a data aq based on that same board - USB interface to host. We've also done an arduino based one (also USB) and all you have to do is put it in a box and wire it up with RC input filters to suit...the code is there, I just didn't put that here, it's in software stuff. It's actually more accurate than the resolution of either chip's a/d converter due to the use of oversampling, dither, and other DSP tricks. Yeah, USB doesn't have galvanic isolation, and you have to pay attention to ground loops, but if you do, these are great for the money, and we do use a dedicated PC for the fusor so as to help control ground loop issues. In my case (I have way too many computers) I actually kind of went overboard and am now using an intel NUC (i5), two displays, where I used to use whatever was about to fall off the end of my upgrade chain, since this actually isn't all that demanding of the PC - the little micros do all the realtime deadline stuff, the PC just writes it down and plots it while we run (very helpful when you're tuning things). Analysis is done later on another box for convienience.

I'm right now having these (with a linux/perl gui) write to log files and plot in real time as the data is collected, it's all up here GPL2. I've also written some adapter code that lets you arbitrarily map any function of all the inputs in a log file (which are editable, human readable ascii text) onto up to 4 dimensions (x,y,z, and color) in scatter plots in gnuplot - and then twirl the plot in 3d to look for patterns in the data. Not sure how up to date it is up here, but I generally don't put things up here till they work, and then update them as I do here. It's what I use here for all my data aq, and it's been very good.

We've found I2C to be prone to bus lockup in high noise situations (yes, you can detect and correct that in the driver, but it's a major pain and the microseconds are gone), and a fusor can make quite a bit of noise if there's an arc....sure, the other stuff isn't perfect either, but it's far more resiliant. Some of our stuff is ethernet as well, but again, you have to deal with time jitter when there are multiple sources if you want to tease cause and effect apart from one another.

I'm right now working on a database schema to tie it all together, which is actually the important part to get right - changing schema later is hard. The plan is to have a "dear diary" for before and after a run comments, which produces a run number that also goes into each device's table which otherwise contains all the raw data. A set of schema tables for each device shows what is connected to what, scaling factors, units etc for later automation and plot labeling. It's just not done yet. Heck, I've not even decided what db engine I want to use - MySQL, SQLite...there's a lot of choice, and this doesnt need any non-standard SQL or propritary stuff. The computer generates 10us accurate timestamps (NNTP etc), and the devices timestamp their own data with their own clocks - drift correction across devices will need some software, but otherwise jitter in any modern opsys (data comes in from two devices at once, which one get the PC timestamp right? Probably neither.) kills you for accuracy. We might want to get together on a vid chat and talk all this out - it's a lot of typing, and combine our efforts in some way, that's the point here on this board. I've got a ton of the "other stuff" already going, why should you have to dupe all my effort? It works, doesn't need fixing or improving at this point.

We are adding things like realtime pro soundcard aquisition for counters etc (some of them sample 192 khz and 24 bits on 10 channels, though you have to "back out" the waveform distortion/delay their inbuilt FIR filters add with your own math), capture from a 4ch 2.5 ghz scope (both raw data and screen images) and so on to this system. Right now it's a bit of a hodge podge of stuff, but I can usually learn something important on every fusor run from it all. Which is what matters, at least to me.

As for samples, 10k BQ should be plenty for calibration, and there are spark-gap tubes available surplus (with Cs-137 in them) and cheap we've compared with our official sample that are just plain legal as far as I know. At any rate, most of that cost would be in the shipping anyway. You'd only notice the difference with HPGE, there's no difference with even our best NaI "gallon jugs".
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: homebrew multi-channel analyzer

Postby Philipp Windischhofer » Fri Aug 22, 2014 9:04 am

Doug,

thanks for you comments -- I appreciate it!

Ripple stripper: I only have about 1/10 of your experience in EE (as measured in years), so I might not be getting this 100% right, but here is how I think it works.

circuit.tiff
comparison: passive lowpass and ripple stripper


The AC source on the left generates the ripple (that would normally sit on top of ~1000V DC). The ripple stripper is connected after a passive low pass to decouple it somewhat from the supply (a resistor alone would probably work fine, too). C1 removes the DC part, so the OP gets only the ripple coupled into its negative input; therefore generating a more or less 180° phase shifted, amplified version of the input signal at its output. This signal is fed back to the noisy signal, reducing its amplitude (if the C's and the OP itself didn't introduce too much of a phase delay) and closing the feedback loop, preventing the OP from saturating permanently.
As for D1: I'm not entirely sure why it's there, at least SPICE says the circuit works equally well without it - I haven't tried in real life.

Here is what the bode plot of the two filters above look like. Green is the passive filter (using the same C's, but without the "active" parts), blue is the ripple stripped version.

bodeplot.tiff
significant improvement!


And we have them all sizes and shapes - one might show up at your place "somehow" [...]

Man -- that would be truly awesome!!

Re data aq for fusor [...]

I skimmed the threads covering your standard counter and DAQ stuff -- really nice! The I2C noise sensitivity certainly is a potential issue, I'll try whether it's acceptable. If not, I'll use isolated RS-485 for the longer (point-to-point) connections, and try to keep I2C for short-distance communication (i.e. between PCBs sitting together in a rack). I just want to avoid having to mess around with too many serial interfaces going from each device to the PC.

Sure, by all means; we can focus on the DAQ stuff together! I've been wanting to learn Perl for awhile now, so reading through your software might be a start ;)

[...] there are spark-gap tubes available [...]

Thanks for the pointer, I'll be on the watch!

-Philipp
Philipp Windischhofer
 
Posts: 21
Joined: Wed Aug 13, 2014 2:12 pm

Re: homebrew multi-channel analyzer

Postby Doug Coulter » Fri Aug 22, 2014 2:49 pm

You should send me a private message. I think we can fix you up. Also, I'm on google+ as...+Doug Coulter and am often online in my evening (late night for you). Sometimes at other times, ring me up.

Note all my vacuum pumps and mass spec were made in Austria...the best there is, or so I think.

Not sure that reading my perl code is the best way to learn...but my stuff tends to work ok. It's kind of like I'm writing in C, only sending it off to perl, I'm not a perl wizard at all, just like the stuff, it's easy, and CPAN has a ton of nice modules with decent documentation that do most of the stuff you'd want for you already. It's less of a steep learning curve than say, MFC or the entire library system for .NET or Java, as you only have to learn the one module you're using at a time, or the ones you actually use. Unlike those other languages, there's little or no interaction to have to learn or deal with. I tend to write for clarity, not compactness or speed - if there's a need for speed, we call out to a C library, perl makes that easy, or a whole different program, which perl also makes easy. It's duct tape. Search it for @@@ marking anyplace I thought I was doing something dodgy. perl is particularly nice with databases...almost no code required, it's all in a really nice set of driver modules, so your resulting code is short, simple, to the point. I really like that aspect.

The basic plan I use in data aq is to let the uP (whatever kind, I'm using pics, arduinos, and ???ASIC in things like the scope) do the heavy real-time deadline stuff, buffer it, and send it along to the PC. I'm even going to try wireless if I can get the fusor quiet enough to not drown out my AP with corona/arc noise. Then we let the PC do any "heavy lifting" math wise, since it's got the cycles, memory, disk, display, nice programming languages...and so on. The main weakness of the approach is making the PC stuff bullet proof against one of the data aq devices failing, and getting it all in time sync to whatever accuracy is desired, so you can always be sure which thing happened first in data from more than one uP. The current scheme is way below the standards I used for "government agency" time-sync, but no one else can afford that anyway. We'll adapt as we learn. The uP clocks are good enough for low data rates (the norm) and short runs (the norm), as long as we time-stamp the whole mess with accurate clock times from the PC now and again (10 uS resolution and gotten from the 'net), then interpolate to correct any uP drift from reality. I haven't even come close to doing that part yet, but it's theoretically possible....

I've been mainly using the pic from the standard counter (USB), and the scope so far (still working more on that, since grabbing the raw data is better and more compact than getting a huge bmp now and then), and mine has the ethernet interface, which beats USB totally. One issue with USB, besides the ground-loop problem (we've kind of solved that one, but it was a pain for just a couple things), is that some PC opsys (linux) will drop the USB device and not recover if there's a "lightning bolt" like an arc in the main fusor power (you'll have those until you upgrade your feedthrough to BN like I did, almost no matter what else you try). Billion watt pulses...stored energy in high Q capacitors, like air dielectric (eg the FT itself) is nasty stuff, even if you have a big ballast R protecting from discharging the power supply stored energy instantly. There's always a few pf somewhere else....I've had to encase the entire HV system in coax, or what amounts to that.
Here's a vid about that:
https://www.youtube.com/watch?v=dnJw6Y716ZM

This one shows the data aq in use, or some of it. I analyze the files later to find the operating conditions that make the most neutrons/watt and other things.
https://www.youtube.com/watch?v=ZGiU_Ck192Q


We've since moved ahead quite a lot...better, more accurate grid made a 10x+ improvement, and getting that oscillation into the roughly correct RF range gave us such a boost (around 2800x! - but only an estimate, it made all my counters block), I had to spend the last couple months adding shielding so I could live through a replication I hope to post soon.

One of the things I want a gamma spectrometer for (we had to give the nice one back) is to look for gammas at other than power supply voltage - neutron capture gammas, protons hitting the tank walls, stuff like that. I think there might be something new to learn there. The new scope (old one ate a lightening bolt) will do that kinda-sorta into around 20 bins (so the manual says, haven't gotten that going yet). That might do, but I'd rather have really good data...

One issue - I did those GUIs with glade and Gladexml.pm. The newer glade versions don't make compatable XML for the GUI perl module, so I'm in the process of learning and switching over to WxGlade and that system for doing GUI's in perl. It's more work, but they do look better - use the native widgets of whatever opsys. What the heck. I was not a big fan of XML to begin with.

The diode looks like reverse polarity detection. I still see nothing that would keep the opamp from drifting off to a limit (bias/offset current!) and sticking, except maybe input ripple and accidental rectification due to hitting the non-linear part of the opamp response. Most designs put in some huge R (megs or a gigohm) as negative feedback to prevent that. In my case, I just use a capacitor in a big RC filter at HV. A little dangerous - even at a kv half a uF stores enough for a real jolt, but it works and I'm careful.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: homebrew multi-channel analyzer

Postby Doug Coulter » Fri Aug 22, 2014 4:32 pm

Since you like PICs, as I do, you might want to check this out: http://www.digilentinc.com/Products/Det ... IPKIT-WF32
I got a couple of them. They do wifi and have better range than my laptop or Nexus 10. While not a super high rez a/d, they have a lot of channels (fast, and there are tricks like sigma-delta to make higher resolution). With wifi and the low power use (about a watt and a half) you've got galvanic isolation as good as it gets. In theory, you could run it off batteries and float one right up at the main high voltage terminal...if there's not too much 2.4 ghz noise, that is. For now, I've re-written their web server to better suit my needs for the original use - data aq and control for remote buildings on my campus, dumb stuff like "is the plumbing in the basement about to freeze over there" and run C CGI programs that can do things like turn valves for my water collection system and so on...but we might wind up with one or more of these in the fusor system as well. The wifi isn't screaming-fast - about 300k bit/s - but that's enough for most things.

Now I'm sorry I didn't get the DSPIC compiler from CCS along with the others...and my license has run out so I'd have to pay some hundreds $ to get it. Kind of increases the cost of using them for me. The chpikit stuff is free. It's not super high quality (java "IDE" and some gcc backend I think) - but it works. The IDE was in quotes as it lacks almost all the good features of a real IDE, but it's enough to write, test, burn code for a lot of things PIC (it's just kind of a copy of the arduino free one, with most of the same features missing in both). Since I'm a printf or toggle a pin debug kind of person, I don't mind the missing features except the one that lacks the ability to click on a compiler error and jump to the offending line (which frankly, never works all that well in any IDE anyway - the real error is usually some lines earlier and you just get the error where the compiler finally barfs).
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: homebrew multi-channel analyzer

Postby Philipp Windischhofer » Mon Aug 25, 2014 1:54 pm

The chipKIT board looks promising, lots of power; and also decently priced here in Europe (€55) -- thanks for the tip!

I'm using the free "light" version of Microchip's XC16 compiler for the dsPICs. You don't get access to the higher optimization levels, but it has worked fine for me so far. I have MPLAB X as an IDE, it's also provided for free on their website. It's based on Netbeans / Java and mostly works well, but there still seem to be a few reliability issues when using the in-circuit debugger.

I really do like your Fusor setup! Especially the idea with the resonant feedback to the ion source is pretty cool! I've got a few questions about that, too; but probably this is drifting a little too far off gamma spectroscopy -- should we place the Fusor discussion in the other thread?

--Philipp
Philipp Windischhofer
 
Posts: 21
Joined: Wed Aug 13, 2014 2:12 pm

Re: homebrew multi-channel analyzer

Postby Doug Coulter » Wed Aug 27, 2014 12:12 pm

Yeah, my bad. I get so caught up in data aq/processing I forget...not really a good excuse.
Edit: here's a pic of some NaI:Tl heads and a crystal I cut off one that had a bad phototube.
NaIHeads.JPG
What I have spare here.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Next

Return to Metrology

Who is online

Users browsing this forum: No registered users and 5 guests

cron