Looking through the postings, I can see we have all been working through this thing, and some of us learning this stuff from scratch. Heavyweight contributions are from
@RJSakowski in post #27, and
@hman in post #59. We know that
@pontiac428 knows a whole lot about it, but is not saying much just yet, which I take to be an indication we are still all making sense.
@GrayTech is lurking, and of course all the major content from
@rwm and
@homebrewed . Software skills and the exploitation of the same from others seems to be something he just has.
I am clearer about what I want to try. There will be some bench messing about with ..
1) A PMT with one or more scintillators. Powers supplies, Signals measure, noise, etc.
2) A Si(PM) with at least one bought-in scintillator. Similar measures.
3) A side experiment to find out if an acrylic "light pipe" can be made to deliver down onto a Si(PM). Can somebody please turn up an acryllic taper, cut off and polish the ends? It needs one end about 3 mm diameter, and the other end something to cover the size of a scintillator crystal - say about 15mm to 19mm diameter, with a taper half-angle about 10°. Can such be 3D printed? shine a laser or something up it. I don't have the best recipe yet, but the 10° is small enough for most entry angles to exceed the 42° total internal reflection, and make the whole thing about 40mm or around 1.5" long.
4) A possible offshoot where somebody tries mixing up something into a hot melt blob of acrylic, to find out if it scintillates.
5) If (4) works, then how on earth to cast a bit of that into a light pipe - or should we just make a disk melted onto the end of the pipe, or don't bother, and push it together with coupling oil and tape it up. Maybe use a drop of model airplane glue, whatever.
6) Follow the route suggested
@RJSakowski using a computer-controlled gated pulse peak grabber. This is in essence the same as the monoflop timeout method, using the compute to control the grab, the duration, the reset and wait for another, and the comparator to exclude sillies. (Duh - why is "comparator" not acceptable to the spell-check) ?
7) Plunder and use as much of the PyMCA software as we can. That goes for Thermino, and all other XRF-related code.
8) I had thought that Python, being an interpreted language, would be a significant overhead. I understand it has "semi compiled" speed-up features in that after the first pass, it need not re-interpret every line.
I thought that Java, with the latest version of Pi4J back end, which gives fast access to the GPIO connections, SPI, I2C, and similar stuff related to working external ICs might be needed.
Of course, getting at GPIO directly has been done with C and C++ programs, but by far the majority of projects out there, large or small, have used Python. So for now, I roll with Python. I have to get used to the darn indent being significant.
In all of the above, I am looking to figure out the lowest cost, yet functional gadget. I might end up with a first try that is significantly more expensive, but it has to be capable of showing us how we can lower costs.
e.g. One smoke detector instead of 6 or 8. More if needed
One photodiode, helped by an acrylic light-pipe. More/bigger area only if needed.
One scintillator, non-hygroscopic, thin, with sufficient area to make best use of the Am241 radiation.
One small computer - a £35 Raspberry Pi - perhaps with link to a regular laptop (notebook?) computer.
One external circuit, possibly mounted on to of the P-4 in the way most school project interfaces do.
Have we got this sort of right - so far? I am happy to have any suggestions at all, and even go after it very differently if it is explained why that would be better
. I was thinking a nice tools drawers chest on wheels could go right in it's place!]
). Still mulling over whether to try the Theremino pulse-stretching scheme or shoot for a fast 10 bit A/D approach.