Faraday utility

[sem-geologist]

Apparently we saw problems reading the JEOL beam current back in the day for the 8200 instrument and have utilized this code loop ever since. The symptom was that the JEOL instrument would return a floating point value that had the digits "16383" (with a variable decimal point), until the beam current was stable...

However, this is a separate issue from the FaradayWaitInTime delay required for newer JEOL instruments to obtain a stable beam current reading.

I don't think it is separate issue, but rather quite revealing details why it is like that.

16383 is the largest number in 14bit DAC. From your shared code it gets clear that picoamperometer of 8200 hardware-wise indeed shows similarity with Cameca SX instruments. SX has 5 picomaperometer ranges of 0-0.5 nA; up to  5nA, up to 50nA, up to 500nA and up to 10000nA. I-V converted faraday value is read with 16bit ADC on SX. Tracking those 16383 numbers with different dec point position it is also clear that there is 5 ranges on Jeol probe.

Why we want separate ranges and would not just have a single range and measure with higher resoltion 24bit or 32bit ADC? For precision measurement low values would be most susceptible to the noise and least stable and accurate.

On Jeol (8200) you would not get floating point, but fixed point decimal numbers which under-hood are actually based on 14bit integers. The decimal point is being placed to the number at specific position by firmware depending from which measurement range is active. If ADC is overflown (i.e. measuring 10nA, while expecting 0-1.6383nA range) all bits will be 1-es resulting in 16383 integer.

And probably here lies algorithmic firmware difference. As your code checks for all possible decimal positions in number 16383 (with exception of 16383(.0) which is ridiculously too large number very tricky to reach on probe) it is clear that Jeol 8200 firmware was starting at 0-1.6383 nA range, and stepping up sequentially through ranges until the measurement would fit within the activated range. That is absolutely sub-optimal and lazy as solution could be achieved in maximum 2 jumps much faster: If number of higher bits (i.e. first 4 most significant bits) are all zeros select the range by position of first "one" bit encountered while scanning the number in its bitarray form toward least significant bit.
If number is max of ADC (overflown) jump to the largest range and find out optimal range there (apply previous instruction).

It is also good idea to use reduced ADC range as it tends to have some aberrations at lowest and highest input voltages, so probably real designed ranges at Jeol are set to  0 to 1.5nA, to 15nA, to 150nA, to 1500nA and to 16383nA. I think what these new JEOL do, they do similar verification in EIKS code as your presented code, and return the measured value after correct range is selected.

There could be design difference in picoamperometer between Cameca and Jeol where on Jeol scaling into range of measurement to ADC would be at buffer OPAMP, where on SX I am sure it is done at Precission OPAMP (I-V), so @coredump's oscilloscope measurement of I-V OPAMP's output could miss those range switching delays, in case the algorithm of range selection is very sub-optimal.

[John Donovan]

I don't think it is separate issue, but rather quite revealing details why it is like that.

16383 is the largest number in 14bit DAC. From your shared code it gets clear that picoamperometer of 8200 hardware-wise indeed shows similarity with Cameca SX instruments. SX has 5 picomaperometer ranges of 0-0.5 nA; up to  5nA, up to 50nA, up to 500nA and up to 10000nA. I-V converted faraday value is read with 16bit ADC on SX. Tracking those 16383 numbers with different dec point position it is also clear that there is 5 ranges on Jeol probe.

Why we want separate ranges and would not just have a single range and measure with higher resoltion 24bit or 32bit ADC? For precision measurement low values would be most susceptible to the noise and least stable and accurate.

OK, this is really good information.  Yeah, 14 bits makes sense.  So it's a firmware issue after all.

Though I wonder why this auto-ranging duration of the probe current is getting longer with more recent versions of the JEOL instruments...

But to be honest, this auto-ranging is really only an issue for the Probe for EPMA software because by default it measures the beam current twice per point analysis. So the first beam current measurement (Faraday cup) is made when the cup is already inserted just before it is removed. Then after the last element is measured it inserts the Faraday cup and measures the beam current again. The average of these two measurements are utilized for the cps normalization. It is this 2nd beam current measurement where the "settling time" of the auto-ranging appears to matter as one would expect.

The opposite is true of the absorbed current measurement (if selected).  The first absorbed current measurement must wait until the cup is removed and then (again) it needs to settle before we can obtain a stable absorbed current measurement.

The second absorbed current measurement takes place after the elements are all measured but before the cup is re-inserted, so the auto-ranging will already be settled.  Of course we don't average the two absorbed current measurements because it isn't really used for anything other than a monitor for sample damage.

The rationale for having two of these measurements is exactly what it would seem. To be absolutely sure that the auto-ranging has settled. Because we want to see reproducible agreement between the first and second beam (and absorbed) current measurements. For example seen here:

ELEM:    Si ka  Mn ka  BEAM1  BEAM2
BGD:      OFF    OFF
SPEC:        2      5
CRYST:    TAP    LLIF
ORDER:      1      1
3322G  3997.8  4626.9  20.005  19.988
3323G  3966.8  4658.5  20.016  20.003
3324G  4007.1  4663.9  20.020  19.980
3325G  4004.8  4628.4  20.042  20.006
3326G  3996.7  4592.2  20.092  20.032
3327G  4036.6  4643.7  20.080  20.016
3328G  4017.0  4626.6  20.069  20.005

AVER:  4003.8  4634.3  20.046  20.004
SDEV:    21.3    24.1    .034    .017
1SIG:    19.9    21.4
SIGR:    1.07    1.13
SERR:      8.0    9.1
%RSD:      .53    .52
DEAD:    3.350  3.300
DTC%:      1.4    1.5

OK, I will share a little secret for those who are interested. If you want to turn off these 2nd probe current measurements, you can set this flag in your Probewin.ini file in the [faraday] section:

[faraday]
DoNotMeasure2ndFaradayAbsorbedCurrentsFlag=0            ; set to non zero to skip 2nd faraday and absorbed current measurements.

But of course, the 2nd Faraday will always be zero so it won't be averaged with the first measurement.