Needing more than a spark test?

[RJSakowski]

If it were, say, 0.5mm (about 0.020") very pure aluminium, or anything we find handy, there are advantages. Even something from one of those slightly thicker products like the foil tubs used for Chinese take-away food. That kind of foil is pure, as opposed to sheet metal alloy.

We used 1100 aluminum for x ray attenuation purposes as it is 99+% pure. McMaster Carr sells 1000 series aluminum in foil form as thin as .0005".

 

[RJSakowski]

The excitation question(s).
So I think on back to a fundamental question I never did get to learn the answer for.
"When a higher energy (60KeV) photon arrives and excites some xrf photon out of an atom, is that the end of it for the 60KeV photon"?
What if it only provoked (say) some 5.4KeV flash from chromium. What happens to the rest of the energy?
Can we expect we might get both 5.4KeV AND 5.9KeV xrf photons out of the same atom of chromium?
Crucially, might these happen at the same time? Perhaps not.
It may be that an entire 60KeV incoming photon may be expended (wasted?) in only producing one flash at a time.

There is an actual delay before the elevated electron drops out of it's excited state. and I have no idea whether a single incoming photon can excite both Kα1 and Kβ1 states in one go, nor whether they flash out simultaneously.
Can a single higher energy (60KeV) photon ever wring more than one xrf flash out of a pile of atoms?

The photon continues on at a lower energy due to that given to the newly created photon. This will continue until the photon exits the target or is low enough in energy to be incapable of further excitation. Once the photon excites an electron, it's job is done. If it then encounters another electron it can excite it as well. Given the small dimensions and that the photon is traveling at light speed, for all intents and purposes, it is essentially simultaneous.

 

[graham-xrf]

The photon continues on at a lower energy due to that given to the newly created photon. This will continue until the photon exits the target or is low enough in energy to be incapable of further excitation. Once the photon excites an electron, it's job is done. If it then encounters another electron it can excite it as well. Given the small dimensions and that the photon is traveling at light speed, for all intents and purposes, it is essentially simultaneous.

Thanks much! It confirms @rwm 's reply.
I had always thought that the excitation into all shells would be pretty much instantaneous. I do recall (from way back) that once energized into a higher state, there can be a surprising "pause" before the shell alters to have the electron assume it's stable energy state, and give up the extra as the florescence. I think, for visible light glows, up to near infra-red, the delay ranges from 0.5nS to as long as 20nS.

For the very nerdy, I got a startling update about the Quantum Standard Model from "dry-as-dust" Ivan Nilsen. All the chapters are strung together, so you need to start the video at around 26:40 to get hit by a startling, and truly mighty, yet simple re-arrangement of the Standard Model. It goes nearly all the way into fully unified theory, explaining away and replacing all those "Charmed Quarks" and other quaintly named conceptual goodies.

It was fun, but now, I am happy to let him get on with it. KiCAD is a better diversion.
New theories of physics 2022 – Quantum filamentation and the new Standard Model – by Ivan Nilsen
It says "unavailable", but can watch on YT. Maybe because it's a long one. You just pick the place you want to watch anyway.

The actual URL was --> HERE

 

[rwm]

That video is amazing. I think he is on to something. It is just too elegant how 3 opposing charges unites all that and answers so many questions.

 

[homebrewed]

I have examined the pin assignments for the T4.0 and 4.1 boards. One thing that jumps out is that the 4.1 has exactly the same pin assignments as the 4.0, where the pin functions are the same. So a shield that is designed to plug into the 4.0 can plug directly into a 4.1 and work properly.

This means that we can design an A/D board that will work on either one of them: but the downside is that the maximum-possible sample rate is reduced because the driver will have to sequentially load in two separate 8-bit values & combine them to get the final 16 bit word. It actually is a little worse than that because the T4.0 only has two groups of 4 bits each that are contiguous so there is some additional overhead to combine them into an 8-bit value. The T4.1 has enough contiguous I/O pins to load all 16 bits at once (although the loaded-in value still will need to be right-shifted 16 places so the A/D LSB corresponds to D0 etc.). To realize the performance improvement of using a T4.1 it probably will be necessary to add some jumpers to personalize the A/D board for it, because the GPIO vs A/D bit assignments will be different for T4.0 vs. T4.1.

To summarize the differences, the T4.1 will have about 1/4 the overhead of a T4.0 to load 16-bit values. However, with a clock speed of 600MHz the additional overhead shouldn't be a deal-killer. I hope. I brought out all 16 bits on my prototype A/D board but was figuring on using hookup wires to customize the connection(s) to test out code for both flavors of T4 I have. The header pin assignments are arranged in linear fashion, also not compatible with the required Teensy pinout(s). Like I said, it's a prototype.

I have attached a document that describes the pinout(s) for T4.0 and 4.1 parallel I/O.

 

[WobblyHand]

Teensy 4.1 has 4x the flash memory and more IO. But 4.0 is almost $10 cheaper. For prototyping I'd pick the 4.1, that's what I did with my ELS. No fun to run out of memory or io.

 

[homebrewed]

Teensy 4.1 has 4x the flash memory and more IO. But 4.0 is almost $10 cheaper. For prototyping I'd pick the 4.1, that's what I did with my ELS. No fun to run out of memory or io.

I think the $10 difference will be minor compared to the total of other components needed to make a complete system, IF a Teensy is a part of it. We have part of the pocketgeiger (for the x-ray detector), _maybe_ some kind of additional amplifier board, an ADC board and the Teensy itself. Beyond that, possibly a Pi for the user interface, power supply components, the smoke detector capsules and some kind of enclosure plus the likely inclusion of some feel-good lead sheet to make sure we're not exposed to even low energy/intensity xrays. Graham's approach of using a Pi to run the ADC along with the UI sounds like it would be a bit less money -- once Pi's return to being more readily available.

BTW my latest visit to Sparkfun showed that the pocketgeiger price has increased to $89.95, not counting shipping. I also note that Mouser is asking $65.23 for the X100-7 part by itself: Sounds good, right? BUT they indicate that the manufacturer has placed the X100-7 in an end-of-life status. Not Good. We could be in a race as far as determining if the detector is good enough for our purposes vs. its EOL status.

 

[graham-xrf]

I think the $10 difference will be minor compared to the total of other components needed to make a complete system, IF a Teensy is a part of it. We have part of the pocketgeiger (for the x-ray detector), _maybe_ some kind of additional amplifier board, an ADC board and the Teensy itself. Beyond that, possibly a Pi for the user interface, power supply components, the smoke detector capsules and some kind of enclosure plus the likely inclusion of some feel-good lead sheet to make sure we're not exposed to even low energy/intensity xrays. Graham's approach of using a Pi to run the ADC along with the UI sounds like it would be a bit less money -- once Pi's return to being more readily available.

I have used an old Pi version 3B+, just because it was handy, I would be opting for the little Pi Zero 2W. SPI serial can go at 2M Samples/sec, although I would probably be initially using 1M Samples/sec, so that ADC does not need to be in warp mode. I have a Pi version 4, which can do all the that stuff, but with speed to spare, and not needed.

While I do like a dedicated built-on display interface device, I went cheaper-skate, thinking that one of my two old smartphones, placed near enough for BlueTooth, or WiFi, or just use a USB lead, can do that stuff. More likely, I would let my trusty Dell laptop do the honours, because it has a bigger screen Regardless, I intend making the board itself Teensy friendly, and it can have exactly the features you describe. Maybe we can now define our choices for preferred ADC connections to the Teensy, with a little row of hookup pins patch area for those the user may want to customize for T4.0 or T4.1, or anything else, and just press on. At present, I have two rows, and one can jumper anything to anything.

BTW my latest visit to Sparkfun showed that the pocketgeiger price has increased to $89.95, not counting shipping. I also note that Mouser is asking $65.23 for the X100-7 part by itself: Sounds good, right? BUT they indicate that the manufacturer has placed the X100-7 in an end-of-life status. Not Good. We could be in a race as far as determining if the detector is good enough for our purposes vs. its EOL status.

Let us not worry too much about the EOL status of the X100-7. We have at least two between us right now, and there are not so many of us who might get into nuclear physics HM projects soon. The circuit can use any PIN diode, and I do not expect the X100-7 need be the last PIN diode we could make work. Sooner or later, we would be adapting to allow the design to use available (or lower cost) components.

OK then, let us keep an eye out for newer PIN diode kit, but even then, I think semiconductor companies only ever manufacture all of a component type they are ever going to sell, in the first run, and will only run again if some customer wants a few million.

 

[rwm]

I hate to be the guy always asking for remedial education but....I am. We are over 1000 posts and it is just to hard to find and review relevant posts. Not knowing much (anything) about microprocessors I am confused about the devices and their basic purposes. Is the Teensy to function as the ADC or are we using another device for that? I assume the RPi will be the main processor to analyze the data and interface with the user? Can the Teensy not handle all that on its own? It might be nice to put together a basic flow/component diagram for anyone trying to follow this. At some point, you might want to start a "build thread" or "final version" to present this in a more direct and compact way. I hope this doesn't sound at all critical. It seems like you guys have made great strides.
I was explaining this project to a nuclear physicist last night and he was fairly impressed. His comment was that we might have a noise problem from a diode based system. He also suggested fresh smoke detector sources but I think he is off base on that since the half life of Am241 is 400 plus years.

 

[WobblyHand]

I hate to be the guy always asking for remedial education but....I am. We are over 1000 posts and it is just to hard to find and review relevant posts. Not knowing much (anything) about microprocessors I am confused about the devices and their basic purposes. Is the Teensy to function as the ADC or are we using another device for that? I assume the RPi will be the main processor to analyze the data and interface with the user? Can the Teensy not handle all that on its own? It might be nice to put together a basic flow/component diagram for anyone trying to follow this. At some point, you might want to start a "build thread" or "final version" to present this in a more direct and compact way. I hope this doesn't sound at all critical. It seems like you guys have made great strides.
I was explaining this project to a nuclear physicist last night and he was fairly impressed. His comment was that we might have a noise problem from a diode based system. He also suggested fresh smoke detector sources but I think he is off base on that since the half life of Am241 is 400 plus years.

I agree with you. This thread has been sort of a stream of consciousness and is hard to extract the key points. It's been great for the key contributors to exchange ideas and brainstorm, but it's not a build thread yet. I've learned a bit along the way, but there's not quite enough meat to just go off and make something and expect it to work. To be fair, there's lots of bits and pieces available so someone with an EE/programming could start, but the current state is a ways from being complete.

A Teensy is a capable processor for control. It would be great for managing the ADC and any preprocessing. But it lacks an operating system. An RPI has an operating system and the normal stuff that we think of in computers. Both devices excel in different areas. The RPI could run PyMCA and identify the elements, and the Teensy could run the ADC, do pulse rejection, do the binning and do safety related things like interlocks.

Not sure which device will do the display or plotting. Personally, I'd vote for a small display, so that the unit was self contained and could be used in the field. I'd put in an option for a Bluetooth display but that's just another thing to drag around and increases the kit complexity. If I'm in a junkyard, I need to have my hands as free as possible. At home, on the bench, a larger display would be great.

Anyways, that's my two cents. Feel free to disagree and discuss. Hopefully there will be some convergence soon and some more prototypes built. I'm toying with that idea now.