Needing more than a spark test?

[graham-xrf]

Thanks Mark.
It adds to my list of low noise FETs. There are essentially two circuit strategies. One is to use a low noise high GBW op-amp direct in the most simple design style, but split into stages to have the first TIA gain about 200,000 to 220,000. This for noise about 3nV/√Hz to about 6nV/√Hz

The other way is is use the low-noise FET enhanced front-ends along with a low noise op-amp. An example is the 2.4GHz GBW circuit using IFN147.
The difference is that straight TIA op-amps off noise in range 2 -10 nV/√Hz. The FET front-end types offer 0.8nV/√Hz to about 1.5nV/√Hz.

The IFN147 from Mouser is is the TO-18-3 sealed can, and is a whole £15-93. We can have a whole nice dual TIA op-amp for that much!
Interesting that when looking for the 2SK147, the Mouser search finds SMP147, definitely called a P-channel JFET, but the datasheet brings up InterFET's IFN147 again, shown a N-channel FET. Maybe it was a web page mistake!

2SK2145's are duals with lower capacitance, and similar noise figure, are only £0.51, but they have lower transconductance.
IF1330's you suggest would do just fine. Strange that the Mouser search brings up a IF1320 datasheet. I wonder if keeping the part in sync with the datasheet just a problem at Mouser?

For my first shot, I am trying to keep things simple, and as few components as possible. I was aware of LTC6268/6269. Same data sheet, different price, because the LTC6269 is a dual op-amp costing £10.44. Given the first stage has more than 56dB power gain, the noise figure ceases to be a problem, and 4.3nV/√Hz is, I think, low enough to be below the other noises anyway. One does then need at least another op-amp, and it can be lower cost type. If more are needed to implement noise filtering, ADC driving, reference buffering, whatever, it could be a quad.

Alternatively, using one of the quad to be the bias loop control with the discrete FET circuit would be another good solution.

 

[graham-xrf]

I am finding that suitable low noise references cost about $9 + the extra circuits and passives to implement them.
Also, the need to have either a low impedance differential driver to feed some ADCs vs those with pseudo-differential input add the cost of op-amps outside the ACD. There are some Lineear Technology ADCs with onboard references and interfaces that work out competitively to having that stuff outside the ADC, I like the simplicity. Very nearly down to only 2 or 3 main components.

 

[graham-xrf]

@homebrewed : Re: LTSpice extreme simulations
Mark - not all of the devices from Analog/LinearTech have spice macromodels, so I was pleased the most recent update hugely expanded the library.

I do stumble often when running into weird situations, like when a .noise simulation command suddenly starts behaving as if what is in it is all wrong, even though I can see the very text, and I keep filling out the values in the entry window, or editing the line directly. So I try ultra simple test circuits, just to get it back to sense. That led me to look at the netlist of the macro-model of an op-amp, and further, to the .lib model.

I never knew that LTSpice has programmed the internal tools for equation-implemented models, (avoiding simulating with sub-circuits primitives) to the extent you can play a CD signal, or a generator signal, .wav file directly into your amplifier LTSpice simulation, and display the waveforms, and "listen to the quality" playing back the wav file.

It gets a bit out of my league, but check this out --> LT Spice with Mike Engelhardt, 6/6
https://www.youtube.com/watch?v=d8DqWvMYyWg

 

[homebrewed]

Graham, refresh my memory. Are you running LTSpice under Linux/WINE? The reason I'm asking is that I'd like to use the recent version with the expanded library -- but I'm having problems installing the upgrade. The installation program apparently wants to install a 32 bit version (my current version of LTSpice is 64 bit). I can't use the built-in "sync" function, due to permission issue differences between Windows and linux so I have to run their installation program; and that's when I get the 32/64 incompatibility error.

 

[graham-xrf]

Graham, refresh my memory. Are you running LTSpice under Linux/WINE? The reason I'm asking is that I'd like to use the recent version with the expanded library -- but I'm having problems installing the upgrade. The installation program apparently wants to install a 32 bit version (my current version of LTSpice is 64 bit). I can't use the built-in "sync" function, due to permission issue differences between Windows and linux so I have to run their installation program; and that's when I get the 32/64 incompatibility error.

I have Linux Mint 19.3 64-Bit, and I run LT-Spice using Wine + winetricks, as normal from the repository.
I confirm that the version is LTspice XVII(x64) (17.0.18.0) from October 27 2020

The wine installation is on drive_c in the usual way. It's the default place synaptic installs to.
You can see the file paths in the pictures.

I do have a windows7 PC and a Windows8. They hardly ever get switched on. Neither has mouse, nor keyboard. Access is via NoMachine on LAN, and they do not have access to the internet. Sorry - but I became disconnected from Windows years ago.




It does end up in .wine/drive_c/Program Files/LTC/LTspiceXVII. I am not sure if the "LTC" was my save-as or not.

I don't actually keep my collection of LT/Spice tryouts down in .wine folder on virtual drive_c.
I just put them in my home folder, but they could just as easily be alongside the LTSpice examples folder in drive_c.



Looking closer at versions..

I can see the 64-bit dll's in there, and also the 64-bit XVIIx64.exe
I am not sure of XVIIx86.exe, whether it is needed, or is an artifact from a previous install.

I update from within a running LTSpice, at Tools --> Sync Release
it all just happens automagically, and suddenly, you have oodledoodles of new Analog Devices, and LinearTech models available.

Permissions
On a pure Windows Machine, you should be able to have the update.

If your Windows is in a virtualbox, or you're running Windows, and Linux is in the virtualbox, I guess it might get complicated to pass the permissions. The stuff I do tends to strain LTSpice to extremes sometimes, but I never put up with a long simulation. If that starts happening, you have to look at what forced silly timesteps. For me, so far, at worst, about 10 seconds is all I need. Nearly all the bits are macromodels.

I do hope this helps. My update went dead easy.
It occurs to me you might need a small adjustment to firewall - or "windows firewall" to allow update of the program.



Let me know how it goes

 

[homebrewed]

What version of Windows are you emulating under Wine?

 

[homebrewed]

I figured out what my problem was. I recently updated my computer to a newer linux distro (Ubuntu 20.04LTS) and apparently the wine32 binaries weren't part of the update. After I installed them, the LTSpice install/upgrade program worked fine.

 

[graham-xrf]

What version of Windows are you emulating under Wine?

As I understand it, Wine is not an "emulator" at all. It works at a much lower level than that, providing an environment that can run Windows executables, and deliver the results in it's own environment. It is called a "compatibility layer". The x86 code for the programs is run in the CPU at full speed under Wine, as if they were in a Windows environment - but without the environment being there.
Wine relies on POSIX environments like MacOS, Linux, BSD, and maybe Android.

Wine does not simulate Windows code. Instead, it translates Windows program calls (API calls) into equivalent POSIX calls as they happen, and has arrangements to land the outputs into the Linux desktop.

Not all Windows programs can be run in Wine like this. Some are too interleaved with some Windows "services" dependencies. I do not like that anything I do with a program, like the number of times I use it, and when, and where I am at the time, be information that is blabbed anywhere! Not to another program, nor anythiing be uploaded. I will not allow "Telemetry", nor "Cortana", do their thing. Avoiding the keylogger was one of the reasons I banned internet access for Windows machines. They are rarely used. For general computing, I abandoned Windows entirely.

Programs running under Wine do not have a mechanism to do that stuff, and the fact a program can run under Wine is a kind of badge of merit indicator that it is only doing what it is supposed to.

I suppose, in theory, one could run a whole Windows install under Wine. It would be bound to fail, but also, why would anyone want to do that? The whole point of Wine is to directly run programs usually installed into a Windows, without needing the Windows.

 

[rwm]

Just so y'all know I am still watching patiently. I am out of my depth on circuit design. Carry on!
Robert

 

[graham-xrf]

@rwm :
I now have a circuit in mind, and I have started ordering parts. Leaving out actual circuits, I can say what the design considerations are.

After considerable fooling about with simulation computations, I have explored most operational amplifier combinations, and it turns out that the combination of op-amps and low noise FET circuit Linear Technology circuit published earlier has no equal. We are trying to capture a very tiny charge, and amplify it without messing it up. I based my circuit on that, but used my own gain distribution.

My basic scheme is to mount the radioactive (smoke detector) bits in a circle, set around a tube with the sensor up the middle in a lead tube shield. The end of the tube is in lead, and the sources are angled in such a way that they cannot illuminate the detector, but do maximally irradiate the stuff under test.

I choose to separate gain stages into three, with a gain distribution that allows to see all the way to the noise floor, while having sufficient preserved bandwidth to reasonably capture a detected X-ray event that lasts up to 10 microseconds. If this were a radiation ticks counter, it could count up to 500,000 ticks per second without a pulse smearing into another - but that is not what we are after. The rise and fall of the pulse, over the time it lasts, is a count of the energy in the X-Ray, and that is what we want to have reasonably accurate, so as to put detail resolution in what we get.

Usually, in designing amplifiers, one uses voltages and currents. Currents can be amps, or milliamps, or microamps. Very rarely does one find oneself using pico-amps, and femto-amps, but it happens with this stuff. I discovered that some calculations involved only a few thousand electrons, up to about half a million or so.

The three stages gives opportunity to build in some filtering to reject 50/60Hz power line pickup, and wideband noise. Everything about it is to have exceptional low noise. I chose a 16-bit ADC (Analog to Digital Converter) to sample the pulse, aiming for 20 samples during a 10uS pulse event. That is 2 million per second. I chose it for it's low cost, and that it has already built-in much of the additional driver amplifiers we would have had to construct externally. This one needs an external reference, so it gets a precision bandgap 4.096V low-noise reference.

The ultimate in low noise would use battery power for the front stages, but I am mindful that a popular build would be to have the gadget on the end of a USB cable, stealing power from the USB, with the display/computing device being a smartphone with app. I might possibly keep battery power for the front end amplifiers, and let the USB supply power to the digital stuff.

The first implementation will not be to a phone. For that to happen, there has to be some little chip with the gadget that can locally do the data collection, and "speak USB". Mine has a quite powerful little credit-card sized Raspberry Pi computer right there with it. It needs to ship the data in using three short wires, and a 70MHz clock. It's a $55 bucks thing, but it is a full blown 2GHz computer that can directly run the open source PyMCA software provided by CERN (think Large Hadron Collider). It also has 2 x 4K video displays.

--> Raspberry Pi 4

I never thought I would be ever attempting learning radiation physics, and trying to press this into life. It is possible that I will still fall flat on my duff. The time I have to play with it has to be shared with other pressing stuff to be done at home, and I do get a bit distracted with my lathe. Any HM user wanting one will have to at least figure out how to turn some shield bits in lead, and be able to epoxy a small circuit board into place. There is lots of room for folk who want to get up innovative arrangements of their own.

HM-XRF may end up able to do more than identifying alloys. You could get curious about what is actually in all manner of stuff. The whole principle of it is to ignore the main radiation coming from the smoke-detector source, that being alpha particles (helium nucli). Am241 also emits a gamma radiation of 59keV which is enough to get an X-ray glow out of most metals we would be interested in. We have to think ahead on the physical construction. All paths from the radiation sources must not encounter any atoms on any materials that can make unwanted responses, not even glue! That is why it has to be lead, and even that will have a couple of characteristic responses we have to figure out how to ignore!

I will try to post a few (simplified, speculative) CAD pictures soon, and then folks can start proposing their alternatives. Right now, I only have some primitives not yet even positioned correctly, and sans the lead. Mark has already fired up the SparkFun Pocket Geiger 5, and explored what that version does. I won't bother, because I am going for extracting the only part on it I want - the photodiode.