Needing more than a spark test?

[homebrewed]

This one is actually more attractive in concept in some ways than the PIN photodiode.
What we need is some sort of graph of cadmium tungstate response vs KeV.
From the numbers given, it says 12 to 15 photons/KeV. So even looking at Am241 source, that comes to 714 to 893 photons.
I am thinking that is kinda not much, and it's of a sort of sky blue colour, which is OK, if it were bright enough to see some.

CsI(Tl) has a higher # of photons per Kev (54 vs 12-15). The same company sells 10 mm dia x .5 mm thick scintillators for $115, and that's for 5 pieces. $23 apiece isn't too bad if it holds up!

I'm just not sure what "slightly hygroscopic" means in terms of longevity in a real application. Encapsulating it will attenuate low-energy xrays so that could be problematic.

One issue with either one of them is that not all of the photons will make it to the detector, being emitted in random directions. That's why commercial scintillator assemblies are coated with highly reflective white paint. Depositing electroless silver on the scintillator would work for CdWO6 but not for CsI(Tl) because the silver solution is water based. Electroless silver will be very thin so it won't attenuate x-rays much, and the gain in the number of photons hitting the detector will more than offset the loss through the silver film.

If one had access to a metal deposition setup -- either e-beam, tungsten wire or (perhaps) a sputter deposition system it would be fairly straightforward to coat CsI(Tl) with just about any metal you want. Making any one of these would be a major project in itself. Not going there.

We're sort of getting ahead of ourselves here since we still don't know if our PIN diode approach is going to work or not. But it IS fun to think about this kind of stuff.

 

[graham-xrf]

CsI(Tl) has a higher # of photons per Kev (54 vs 12-15). The same company sells 10 mm dia x .5 mm thick scintillators for $115, and that's for 5 pieces. $23 apiece isn't too bad if it holds up!

That sounds better.

I'm just not sure what "slightly hygroscopic" means in terms of longevity in a real application. Encapsulating it will attenuate low-energy xrays so that could be problematic.

Yes - just like the scintillators from cold war era, like the (unused) one I have. There are zillions of them around. It was the way of Soviet production at the time. The main feature that decides their price, is that they have not suffered water ingress from air vapour. It pretty much messes them up. Why folk on eBay would ever think anyone should buy a leaked one, I cannot fathom. Maybe they still work to some extent. They need not deteriorate, so long as the can stays sealed, or when fitted into that aluminium cavity in front of the PMTs. However they are sealed in, they can stay that way. I bought separates, instead of the complete assembly.

One issue with either one of them is that not all of the photons will make it to the detector, being emitted in random directions. That's why commercial scintillator assemblies are coated with highly reflective white paint. Depositing electroless silver on the scintillator would work for CdWO6 but not for CsI(Tl) because the silver solution is water based. Electroless silver will be very thin so it won't attenuate x-rays much, and the gain in the number of photons hitting the detector will more than offset the loss through the silver film.

If one had access to a metal deposition setup -- either e-beam, tungsten wire or (perhaps) a sputter deposition system it would be fairly straightforward to coat CsI(Tl) with just about any metal you want. Making any one of these would be a major project in itself. Not going there.

Hmm, so what's wrong with some cling film, or just spray one side with paint, like the PIN diode is?
Sealing it up to a visible photodiode should not be a problem either.

We're sort of getting ahead of ourselves here since we still don't know if our PIN diode approach is going to work or not. But it IS fun to think about this kind of stuff.

The PIN diode really should work, though not to low energies which would have trouble escaping even from the material they were provoked out of. The Am241 gamma may penetrate more than a millimetre. Maybe the resolution from one KeV to the next might be limited. We might expect more than 150eV, which would "spread" the peak around the buckets. This is OK, I am having a good time trying, even though I don't yet get to play at it full steam.

The thing is, you show your early experiment setup various stuff, and you see a plot that definitely changes. Peaks that move and change! I don't care that we don't yet quite know the finest detail about everything that is happening. It will get built, refined, tested, sorted out, until we know the limit of what a PIN diode will do. Enough is going on for me to think it will all work reasonably well! So far, I have not exactly spent a fortune on it. Lots of good stuff I would have a use for anyway, like the SMD solder station.

 

[homebrewed]

I'm looking for some guidance here w/regard to my ADC board. I have done additional testing and found more issues with my driver S/W, but after resolving them now I'm seeing about a 2500 count offset in the ADC output. It's not noise, it's pretty consistent +/- about 150 counts. The offset doesn't change much with the sample rate, but that could be due to the fact that that the ISR runs at the same speed regardless of what the sample rate is.

The output DC offset of my opamp buffer is about 800uV so that isn't the problem -- 2500 counts is somewhere around 90 mV with a 2.4V Vref.

I haven't looked at any signals on the board with my oscilloscope yet. I can use the CNV\ signal to trigger my scope so that should help track the problem down. But I suspect this kind of problem has been encountered before. Somewhere.

The board design pretty much duplicates what is shown in the AD7667 data sheet.

One nice thing I discovered while working up the driver is that it's not necessary to include the ADC library. Using IntervalTimer worked out fine, but to use it it's necessary to initialize it with the microsecond interval rather than a sampling rate. Apparently not intended for use for this kind of thing but it works OK for that. However, the call to the IntervalTimer's instance of the begin() function is specified in microseconds so it may not be possible to use it for anything faster than a 1MSPS ADC application. In other words, I don't know if it can accept floating point arguments, since anything less than 1us has to be a fractional number.

Once again I ran into "interesting" silent type-conversions that caused all manner of problems. I don't think that the Arduino IDE version # really applies, it's mostly related to Teensyduino compiler settings. Just don't subtract a mix of ints and uints and expect a reasonable result, because the compiler won't alert you to the fact that strangeness will happen. I can see where some laxness sorta-kinda could make a programmer's life easier -- if handled correctly -- but that doesn't seem to be the case. And surely it would be problematic if one tries to use a different development platform that is even halfway picky about type mismatches.

Back to the offset, I haven't tried inputting any input voltages to the ADC to see if they will add to the offset or not I'm still just doing testing with the opamp buffer's input jumpered to ground.

 

[graham-xrf]

Back to the offset, I haven't tried inputting any input voltages to the ADC to see if they will add to the offset or not I'm still just doing testing with the opamp buffer's input jumpered to ground.

I am not able to be much help when it comes to compiler knowledge on Arduino or Teensy libraries, but maybe I can help with the ADC. This is my first with AD7622, but ADCs I have had little battles with in the past, all had much the same principles for connections.

If there is any way to temporarily disconnect the route from the driver output from the ADC, then I would do that, and then short-circuit the ADC input to INGND, which would be the analog ground plane. If you used the connection diagram Figure 26, then lifting the 15Ω between the driver and the ADC pin 43 would do that. Then put a short circuit across the capacitor of that RC filter. We want zero volts.

In the circuit, see the digital supply at top right shows a "ground" symbol connection to pin 17. This is digital interface, not the same as GND used as the zero volts for both analog and internal digital. The ground plane GND goes to 1,41,42,36, and very specially, it also goes to DGND on 20, and 30.

This is the important "star" point. Pin 19, a internal digital supply, is derived from the analog supply with some 20Ω isolation, and a whole lot of decoupling. Pins 5. 8. and 6 also link to that clean digital supply. It is very important that this "digital" ground, which is allowed to share the analog ground only at this place, does not get "bounced around", nor have to share a current return path with any digital 0V involving the computer.

All digital interface is done relative to OGND pin 17 only, and any return ground planes are separate.
Also look at the 5V analog supply. It really should not have anything to do with any 5V supply used for the Teensy. I think ADCs, internally, are fundamentally differential. If in any inadvertent way, the IGND ground plane is also running return DC currents for other stuff, it might possibly be affecting the numbers.

An ADC set up in this way, has no excuse but to return the test specification. I guess you might see the last three LSB changing.

If you see 2500, it might be the the ADC is all OK, and something is getting glitched in fetching the numbers off. It occurs to me that you might be able to trigger your scope, and check if the data outputs are zero when they are suppose to be.

I used to use two temporary equal resistors across the reference voltage, each with about 10nF across, to make a voltage at half reference, and measure it on ADC. The answers were never exactly half, because the resistors were never that good, but it was a quick test.

 

[graham-xrf]

I'm looking for some guidance here w/regard to my ADC board. I have done additional testing and found more issues with my driver S/W, but after resolving them now I'm seeing about a 2500 count offset in the ADC output. It's not noise, it's pretty consistent +/- about 150 counts.

Hi Mark
As passing thought..
2500 is 00001001 11000100
Any number in the LSB 8 bits can only be jumping around in values up to 256.
If in fetching the "other" 8 bits, if the fifth and the last were always stuck, or fetched, as a "1", it might give you the symptom you are seeing.

Please allow that I don't really know! A mad guess, if you like, and I would not willingly waste your time chasing some stupid speculation. I was just imagining what the bits would have to look like to do that, and I know that you are accommodating the Teensy by fetching off the data 8 bits at a time.

 

[homebrewed]

I am not able to be much help when it comes to compiler knowledge on Arduino or Teensy libraries, but maybe I can help with the ADC. This is my first with AD7622, but ADCs I have had little battles with in the past, all had much the same principles for connections.

If there is any way to temporarily disconnect the route from the driver output from the ADC, then I would do that, and then short-circuit the ADC input to INGND, which would be the analog ground plane. If you used the connection diagram Figure 26, then lifting the 15Ω between the driver and the ADC pin 43 would do that. Then put a short circuit across the capacitor of that RC filter. We want zero volts.

In the circuit, see the digital supply at top right shows a "ground" symbol connection to pin 17. This is digital interface, not the same as GND used as the zero volts for both analog and internal digital. The ground plane GND goes to 1,41,42,36, and very specially, it also goes to DGND on 20, and 30.

This is the important "star" point. Pin 19, a internal digital supply, is derived from the analog supply with some 20Ω isolation, and a whole lot of decoupling. Pins 5. 8. and 6 also link to that clean digital supply. It is very important that this "digital" ground, which is allowed to share the analog ground only at this place, does not get "bounced around", nor have to share a current return path with any digital 0V involving the computer.

All digital interface is done relative to OGND pin 17 only, and any return ground planes are separate.
Also look at the 5V analog supply. It really should not have anything to do with any 5V supply used for the Teensy. I think ADCs, internally, are fundamentally differential. If in any inadvertent way, the IGND ground plane is also running return DC currents for other stuff, it might possibly be affecting the numbers.

An ADC set up in this way, has no excuse but to return the test specification. I guess you might see the last three LSB changing.

If you see 2500, it might be the the ADC is all OK, and something is getting glitched in fetching the numbers off. It occurs to me that you might be able to trigger your scope, and check if the data outputs are zero when they are suppose to be.

I used to use two temporary equal resistors across the reference voltage, each with about 10nF across, to make a voltage at half reference, and measure it on ADC. The answers were never exactly half, because the resistors were never that good, but it was a quick test.
View attachment 436387

My circit pretty much duplicates what was shown in the AD7667 DS. One exception is that I added a 3.3V LDO regulator, running off of the input +5. I did not put a 20 ohm resistor in the 5V line going to the LDO so that might be an issue. I think I can do some board surgery to test that.

There are some things about the PCB layout that may be causing problems, most notably my decision to place the main digital Vcc bypass capacitors right over the DGND ground plane. This could be injecting noise into the DGND plane. I'll take a closer look at the layout to see if anything else jumps out at me.

 

[homebrewed]

Hi Mark
As passing thought..
2500 is 00001001 11000100
Any number in the LSB 8 bits can only be jumping around in values up to 256.
If in fetching the "other" 8 bits, if the fifth and the last were always stuck, or fetched, as a "1", it might give you the symptom you are seeing.

Please allow that I don't really know! A mad guess, if you like, and I would not willingly waste your time chasing some stupid speculation. I was just imagining what the bits would have to look like to do that, and I know that you are accommodating the Teensy by fetching off the data 8 bits at a time.

The tricky thing is that I'm only grabbing the lower 8 data bits, using the ByteSwap pin to mux the upper 8 bits onto the data bus. So if the lower nybble of the upper data byte is stuck at 1001, so would the lower byte. Looking at it that way, there are no common "stuck" bits, at least not for 2500.

Since I'm actually using a Teensy4.1 to test my driver code I can forego toggling the ByteSwap pin altogether. It's a little messier because I have to add 8 more jumpers. And I will also need to change the connections for the lower 8 bits. Not a big deal. I started out using the T4.0 code just for expediency's sake & got hung up working out the problems I discovered there.

At this point I'm leaning toward some kind of layout problem, with one exception -- the omission of a low-value resistor feeding my 3.3V LDO.

 

[WobblyHand]

@homebrewed quick question, where did you source the 3.3V regulators? Haven't been able to find them.

DigiKey has created a FedEx tracking number for my order, and says it has shipped, but they have yet to hand it to FedEx. It probably means its sitting on the loading dock waiting for pickup. Wish they wouldn't claim shipment unless it has left their premises...

 

[graham-xrf]

My circuit pretty much duplicates what was shown in the AD7667 DS. One exception is that I added a 3.3V LDO regulator, running off of the input +5. I did not put a 20 ohm resistor in the 5V line going to the LDO so that might be an issue. I think I can do some board surgery to test that.

There are some things about the PCB layout that may be causing problems, most notably my decision to place the main digital Vcc bypass capacitors right over the DGND ground plane. This could be injecting noise into the DGND plane. I'll take a closer look at the layout to see if anything else jumps out at me.

The very important thing is where the return current for the 3.3V is going. What is the 3.3V LDO powering? If it is DVDD on pin 19, then it should not be. The low end of DVDD is connected to the 0V GND ground plane used by analog, and ADC internal digital. It had better be clean as the driven snow, and not return to the Teensy, and as I read it, is not ever 3.3V. If the 3.3V does hang on a regulator, using from the analog 5V supply, and supplies pin 19 returning to a Teensy connected to pin 17, then I think we are likely to have trouble.

Taking from the 5V supply to make a 3.3V for pin 18 is almost worse, because the 0V end of the 5V supply had to find its way to OGND on pin 17, defeating the whole point of having a pin 17. I get it that the digital supply has to come from somewhere, and there is nothing wrong with regulating down from a computer digital 5V to 3,3V. The problem is contriving an analog supply that does not borrow from it. This is a problem for me also, and I may resort to battery for the analog supply. Alternatively, heavily filtering both + and - , with series chokes and fat capacitors. before the 3.3V regulator, and in effect, making a "new" digital 0V, somewhat isolated from the original 5V supply return.

[Edit: Checking the data sheet, DVDD on pin 19 is specified as 4.75V to 5.25V It is never 3.3V ]

If the 3.3V choice had anything to do with interfacing with the Teensy, then it's not right, and should not be applying 3.3V to Pin 19. That supply does need the isolation from AVDD by 20Ω, and is never 3.3V. If that is what you have, it might be the reason the internal digital circuits that return to DGND are not operating properly.

The Teensy interface is conveniently allowed to be 3.3V, or 5V. Whichever it is, it is applied on pin 18, returns from pin 17, and must not have any common return path that found DGND. This is the only way the ADC has of not adding the noise, and offset of the Teensy digital return.

 

[homebrewed]

@homebrewed quick question, where did you source the 3.3V regulators? Haven't been able to find them.

DigiKey has created a FedEx tracking number for my order, and says it has shipped, but they have yet to hand it to FedEx. It probably means its sitting on the loading dock waiting for pickup. Wish they wouldn't claim shipment unless it has left their premises...

I think I had to buy them from Mouser.