Yup, there had to be a better way. A soundcard is just too slow - if you "shape" the signal enough for it to see it, there's just too much time-smear to handle any decent count rate - pileup kills you at even pretty low rates, and after all that low passing, it's hard to detect, it just smears everything out in the result. Not to mention the impulse reponse of a delta-sigma a/d is well...interesting (and usually over 40 samples long at a mere 48khz sample rate). Though you get fewer bits with the scope (it's about 9), you get a lot more samples, and you need no shaping at all for an NaI-class signal - you can adjust to get quite a few samples during each pulse to integrate the energy over.
While this particular scope won't quite do for a fast plastic scintillator on a fast phototube - well, those have horrible resolution anyway, since often much of the energy compton scatters out of the plastic.
Not having a nice cryo germanium detector, I have no clue what those signals look like, but if they are within what a scope can capture, this should do fine. You just need to set the sweep speed fast enough to capture a number of samples per pulse so the integration trick (which is really summing) doesn't have too many errors. Done right, you actually get more bits resolution than the native a/d gives.
Here, all I'm doing is detecting each pulse that starts below threshold, goes above it - integrate (sum) all the samples above threshold, and call that the "energy" which I use to decide which bin in a histogram to increment. The width minimum and maximum are designed to help with noise and pulse pileup situations. Evidently, there's an edge case I missed in the little state machine I coded to do all that; the capture from the scope itself now seems perfect - which turned into quite the chore on its own. It seems the GW-Instek imperfectly reverse-engineered the tektronix protocol, and the guys who wrote GDSH (a bash shell that also talks "scope") added another layer of not quite getting it. The upshot is that these scopes are quite picky in how they are talked to - too fast and they choke, too slow and something crashes - I got quite a bit of excercise getting up to power cycle the scope whilst working out that part of things. I don't bother to ask the scope about its timebase or vertical scaling, since that doesn't really matter here - you gather the pulse threshold, max and min width data simply by stopping the thing and looking at the raw scope plot, which is in 9 bit binary vertically, and sample number horizontally - gnuplot tells you the H and V numbers for where your cursor happens to be, so you can pretty quickly read that off a sample capture and set up the real MCA numbers.
I'm aware there are some theoretical issues with this approach. Pulses that just barely break theshold will add up to smaller numbers, since some of the pulse was below threshold - and it's a larger fraction for a small pulse than a large one, so the horizontal scale will be slightly "exponential" - small things will be off to the left, and large things off to the right, a little bit. I'll be testing with a real set of sources as soon as I get satisfied that I have that glitch handled on a "perfect" signal from my signal generator first - for example, the two main peaks from CS-137 are pretty far apart - one very low, one at 662kev. I might figure a way to linearize against that, we'll see - the code is actually pretty compact as of now, but then I do have a lot more freatures planned eventually.
I feel like I'm not losing much of anything here by only grabbing chunks of data - of course I have to ditch pulses already in progress at the beginning of each record, and those that don't end by the end, and I miss some data entirely during the time I'm analyzing the last record and waiting for the scope to send me the next at it's own sweet speed (not that fast). But since radiation is random as it gets, timing wise, as long as I get enough - I should get good spectra. If what I'm trying to measure has a periodic component - say 120hz ripple on a fusor power supply - I could get into issues with it "beating" so to speak, but we'll just have to see about that. I don't think it's going to be much of an issue in real practice.
I'm doing this because the last few MCA's we've bought off ebay were terrible or broken (notice no one selling one admits to being able to test it?), and I used up my loan time on the one good one I had for a bit before I did the experiment I wanted it for. Should have just used that money to buy a new one I suppose - it about added up to that, with nothing to show in return. And that money is now gone, so I'm doing this, which costs me nothing but time - I have the gear already. Seems most labs would have both a DSO and a PC, right?
The measurement I want is this - we know fusors make a bunch of X rays at the power supply energy level, at least. There should also be some from neutron capture in H in moderators at around 2.2 Mev, or 570kev if in boron. But not all fusion reactions make neutrons, some make fast protons (the one that also makes tritium). Those should also produce some gammas somewhere in the middle of that range, and provide a way to measure the relative ratios of the reactions vs conditions, something
no one else seems to have done - all assume everything is thremal, which in my case, is not a good assumption. There's also that interesting 3rd DD reacion that goes straight to 4He and should be producing about a 16 megavolt gamma....I want to see that one! You know what happens in astronomy every time you give those guys a new capability, right? New discoveries flow.
And I wanted a tool that if it broke, I could fix it. Even the good one we had borrowed fried. Had that happened a few years down the road - just try and get an old MCA fixed, they are such a low volume thing the manufs drop them like hot potatoes.
Luckily in that case, it was the internal HV supply that let out the magic smoke - and I wasn't using it anyway. But you know what I mean. You get one of those old NIM things, and all the parts are proprietary hybrid chips no longer made, and no one will give you a schematic either, so you're hosed. This way all you need is a working DSO - almost all of them speak the same language - and a sensor (with its own power supply - trivial with a CCFL inverter and a voltage regulator) and PC. Well, for this the PC has to be running linux (or windows with a crap-ton of add-ons), but you could do this on a windows box with Virtual box - which does give the guest opsys access to USB. It really isn't taxing the PC very much at the speeds I'm currently grabbing scope screens - the scope is more the limit there - even though I'm writing this code in an interpreted language (perl). Which after all, is at least several times faster than any other interpreted language as things sit. Maybe half as fast as C on the metal, but a lot less wordy to get the job done.
For the curious, here's the code as it sits, error and all (but don't run this assuming I've fixed it - I'll fix it and post it on this thread later when I do).
mcas.zip- Code, complete with a bug or two
- (7.01 KiB) Downloaded 341 times
This won't make much sense unless you open it with something that syntax-highlights perl (gedit, geany, padre, and many other editors). Then it's pretty obvious - I code perl like it was C with enforced bizarre hungarian naming rules (it's that flexible to let you do that). That's because C is really my native language. But for things with GUI's and more than one thread - perl's a lot easier if you don't really need much bit-banging at the systems level.
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.
