I recently posted about the need to adjust the Faraday wait in and wait out times for JEOL instruments here:
https://smf.probesoftware.com/index.php?topic=1260.msg12974#msg12974
Especially for newer JEOL (8230/8530/iSP100/iHP200F) instruments which seem to require up to 2.5 to 3 seconds wait times for the picoammeter for reproducible accuracy of the beam (and absorbed) currents.
One can edit these values in the Probewin.ini file:
[faraday]
FaradayWaitInTime=2.4 ; delay after insertion
FaradayWaitOutTime=2.2 ; delay after removal
and re-start Probe for EPMA to check the accuracy of the beam current measurements, but there exists a small utility called Faraday which comes with PFE and is much quicker to test with.
(https://smf.probesoftware.com/gallery/1_21_11_24_11_18_53.png)
To test the beam current measurement, select the Faraday option, then click the Remove Faraday button, then click Measure and the app will insert the Faraday cup, wait for the specified time and print out the measured beam current.
To test the absorbed beam current, select the Absorbed option, then click the Insert Faraday button and again click the Measure button. The app will remove the Faraday cup, wait the specified time and measure the absorbed current.
One can decrease these wait in and wait out times by editing these entries in the Probewin.ini file, saving it, then re-starting the Faraday application. Repeat as desired to see the minimum wait times that are required to obtain an accurate reading.
I want to emphasize how important it is to have a sufficient delay after inserting the Faraday cup to get an accurate beam current reading on the newer JEOL EPMA instruments (8230, 8530, iSP100, iHP200F).
This is because Probe for EPMA measures the beam current both at the beginning of the analysis and also at the end of the analysis. The reason for this is to check for beam stability over the course of the x-ray measurement. This may not matter for analyses only lasting a few minutes, but it could be important for analyses that take longer. By averaging the two beam current measurements, PFE can "correct" for any beam current drift during the measurement (assuming the drift is linear).
This has always worked well on Cameca EPMA and older JEOL 8900, 8200 and 8500 instruments. But starting with the 8230/8530 instruments, the JEOL picoammeter is gotten much slower, requiring longer settling times. This may sometimes be caused by a "sticky" Faraday cup, but we have found that even a normally operating Faraday cup on a newer JEOL EPMA requires 2.5 to 3 seconds of delay after the cup is inserted to get an accurate reading.
Note that the first beam current reading performed by Probe for EPMA is always fine, because the cup is already inserted and therefore the beam current has already stabilized, but the 2nd Faraday cup measurement requires that the cup be inserted after the x-ray measurements have finished, and that is where the FaradayWaitInTime delay value in the Probewin.ini file becomes critical. You can see what the values are for these for your instrument in the Count Times dialog:
https://smf.probesoftware.com/index.php?topic=1260.msg12974#msg12974
Recently I noticed a user had these results for their beam current readings:
Off-Peak Corrected or MAN On-Peak X-ray Counts (cps/1nA) (and Faraday/Absorbed Currents):
ELEM: BEAM1 BEAM2
2G 19.986 18.323
AVER: 19.986 18.323
SDEV: .000 .000
This shows an ~8% variance between the two beam current measurements. Again, the first beam current reading is fine, but the second one requires a longer FaradayWaitInTime delay. Anette von der Handt sent me a plot of her JEOL iHP200F instrument and this shows how reproducible her beam currents are when this value is properly set:
(https://smf.probesoftware.com/gallery/1_12_12_24_9_34_04.png)
Here are the ProbeWin.ini values for these keywords on her instrument:
FaradayWaitInTime=3.0
FaradayWaitOutTime=1.0
Note that for absorbed current measurements it is the FaradayWaitOutTime that may need to be adjusted.
As hardware-aware person I just wonder why it is like that (technical reason). Maybe to large capacitance in the measurement line? Poor outdated PCB design emitting enormous amounts of EM noise, and thus added capacitors to filter out the noise of tiny current measurement?
Are those wait time values in second? If so, they are approx. twice as high as 733 - 8800/8900 gen.
As far as I remember, P/N of the beam shutter for 8530 is the same as that of 733 - 8800/8900.
Design change in the solenoid (that is, mechanical change) or electrical circuit?
Quote from: coredump on December 21, 2024, 07:53:48 PMAre those wait time values in second? If so, they are approx. twice as high as 733 - 8800/8900 gen.
As far as I remember, P/N of the beam shutter for 8530 is the same as that of 733 - 8800/8900.
Design change in the solenoid (that is, mechanical change) or electrical circuit?
Yes, in seconds. And yes, the required "settling" time for the 8900 was around 1 second, for the 8200/8500 around 1.5 second, for the 8230/8530 around 2 seconds and for the iSP100/iHP200F around 3 seconds.
As to why, that is what SEM Geologist asks above. I can only imagine that JEOL is trying to improve the accuracy of the picoammeter and therefore using an electronic circuit that requires a longer integration time (higher value capacitors).
I should add that this is not a problem for the JEOL software as it only measures the Faraday cup once at the beginning of an analysis when the cup is already inserted and therefore stabilized. But because Probe for EPMA measures the beam current both at the beginning and the end of the acquisition, the Faraday cup needs to be inserted before the 2nd beam current measurement. Therefore the Faraday cup insertion requires whatever settling time is necessary for a stable beam current measurement.
A similar consideration applies to the absorbed current measurement, because, again, Probe for EPMA measures the absorbed current (if specified) at both the beginning and the end of the acquisition. So because the absorbed current must be measured after the Faraday cup is removed, a similar settling time is required for a stable 1st absorbed current measurement.
Therefore if your Faraday cup requires a full 3 seconds to stabilize, your Faraday wait times might look like this:
[faraday]
FaradayCupPresent=1 ; non-zero = faraday cup interface present
FaradayCountTime=1.0 ; number of faraday integrations for Cameca and JEOL
FaradayCupType=0 ; 0 = automated, 1 = manual
FaradayWaitInTime=3.0 ; delay after insertion (important for accurate 2nd beam current readings)
FaradayWaitOutTime=3.0 ; delay after removal (important for accurate 1st absorbed current readings)
I suspect there are other factors, such as the reading algorithm in JEOL firmware or main software.
Delay caused by capacitor is difficult to imagine. It requires extremely large capacitor must be installed in the signal line to produce 2 - 3 sec delay. But I cannot imagine any reason to do so.
Long time constant also makes spectrometer adjustment very difficult. Furthermore, long time constant may hide certain troubles that occur in short period, such as sparks.
Mechanical delay of 733 is less than 500ms. So, I think the firmware contains an unwanted bug.
Quote from: coredump on February 25, 2025, 12:56:42 AMI suspect there are other factors, such as the reading algorithm in JEOL firmware or main software.
Delay caused by capacitor is difficult to imagine. It requires extremely large capacitor must be installed in the signal line to produce 2 - 3 sec delay. But I cannot imagine any reason to do so.
Long time constant also makes spectrometer adjustment very difficult. Furthermore, long time constant may hide certain troubles that occur in short period, such as sparks.
Mechanical delay of 733 is less than 500ms. So, I think the firmware contains an unwanted bug.
Sorry, but your presented circuit simulation to this situation is inadequate: First of all, replace voltage source with current source (that what the Faraday cup is) and I would also eperiment with different resistor values (100k, 1M, 10M...) (i.e. on SX100 there are 5 different feedback loops for different current ranges; I guess as Jeol is more a budget probe it would have single or just a few). Anyway, even leaving the resistor values of 1k and 100k (which is a bit a questionable chose IMHO) and replacing voltage source with current source, lets say 10nA, the stabilization of voltage at capacitor gets in about 2 seconds with 100 times smaller capacitor of 4.7µF than in your simulation - that is not huge capacitance as for sensitive line RC filter. (huge would be 10000µF; I seen 47uF and 4.7uF caps used all over where RC filters are used to filter sensitive signals, and in some case 470µF would also make sense. Not that Cameca probes would be equipped with any capacitors at all at this particular circuit.) The drain resistor could be 1M, or 10M (typical input-GND resistance for some of precission OPAMPS is even larger, more like 10Tohm) and then capacitor value to fit into 2 sec of full load can drop to 470nF or even 47nF... or even in picofarad range, where longer coaxial cable would start showing effect of its capacitance.
While looking to your 2nd graph, I got quite confused. Is that some real measurements? Are the time units correct (maybe should be ns (nano), not ms (milli)?; 15ms ringing period suggest the 50ohm coaxial cable from faraday cup to run for about thousand of km. Even with correct units of ns, that still looks wrong. Maybe there is too long cable which is tied into few rounds making kind of inductor. I guess picoamperometer is situated unnecessarily far from faraday cup. As for contrast, on properly designed Cameca SX probes, faraday cup is connected with very short cable to picoamperometer, where picoamperometer is situated just below the chamber. with only 1m of coaxial cable beam current change at FC would produced ringing with unterminated coaxial, but would be dampened down within 1ms. Another thing is that terribly huge noise. That is not a surprise whole 3 seconds are needed to average out the noise. Again, placing picoamperometer far away from digital noise as close as possible to the faraday cup will have less noise introduced, thus can be measured much faster.
and here my simulation (interactive):
the simulation in circuitjs (https://www.falstad.com/circuit/circuitjs.html?ctz=CQAgjCAMB0l3BWEBmAHAJmgdgGzoRmACzICcpkORICkNIJNApgLRhgBQAliGziPn59wuKLzDR0yeDNmQwrVBwDmvKgIRDUdQWMgcATuHSoR-dETphRO+BwDGIbWac7NDAazB0WMGdvQsMHRiHFRSIlRUYj0VVw1+Z0D0WIB3AUsXaWprfn0jBGCQUn4iMH4SsW85O1VsgUhTevQLWIBDFEgc0hSy-jAep3AkNiRqmV4-eGD8MhwcBARkULBkFKtZDnT63M7qNagtmiLKyKtB-XSz8EG+m-W45ONTXXZ1w6Md0Sfg0w2amSGeK7YS7OgwBBA5zQqx5cCbABKwP6JnAcNK4NgYGitAB8GQeig0EhBSK6ju6n+NSBhRSBzuBypmwAynsUL04OyxCkAGZtAA2AGcmGJIelaSB1BLKpdjnSUhLKUcJXQJYygXdVUVwfC5BryrwDhKWIyaJtxUUTQrtR9gaJfi5MZDHBYrN9Mi1qF7oDhyH7-QGEKwsJNYNMWksSgslitTfpVK6BK1E4nwUdrgMFURuil0BwAB40IikERIHCc6ymHL8AAuAHsADqCgCCABEAMIF3hYXOcq0NAk5XltAxtAAmbQAnl3UCGLBBsRB8CWhyB7G0AA5texcGttAB29iYDYb+6bdZ5TfQAFsm-Y62183e2gAjflMLshHTzAQUASoL1jBAOsNxrLg633AVnw3AAaE8z0FHk6wMJsEXbJseS4fkayYAwuH3ZR005ckDRlIi6EiBgDSVK5OXpA11Vo2EqLhWU7n7SwdX0RxnF2GEPAUNgIF8MN5HKBZ5EgUhrCwBAyiwEspggfJxHMdwWHUXQqS7QoS0qRYQ3IASUgAHghfdmx0kJJQJOSSx-VcTIQCyrLpCADJQQCiicyAXMLQo4Q8wcgJ83zLP86xDWoBAe0NCBHPGMKODrX85TESwjPQTEZFIXBNHwblUuQDg0DEAAxZTQ1kYSgzYHwIBfJg2mvAB9ewAFcDAMJh9xrEqXhDCr0p9ANRr9WqQymLoQzYYDQPAyD+Wg-q0RAIbsvkIlIBGCB9zrLhhSbAAKa8ADUAEoOCAA)
It is simplified essence of circuit used on SX, with addition of noise (slidebar from 1mV to 50mV injected into signal through resistor of 100k - kinda simplified simulation of noise introduction by nearby noisy electronics) and additional optional capacitor ,which demonstrates the very easy way to minimize such noise (the most lazy way, answering "why anyone would add a cap there"). SX instruments has no such cap as it is not needed (noise is not introduced, as system of FC-transmision line-picoamperometer are held within clean analog domain with no digital signals anywhere nearby or crossing its path. A cap is a physical way to filter out the signal from noise. The multi measurement and getting median is another way - without a cap. In any case, presented 2nd graph clearly demonstrates p-to-p noise in some cases reaching 50% of the median value. 3 seconds of integration of multi measurements even without cap is absolutely necessary.
Quote from: coredump on February 25, 2025, 12:56:42 AMI suspect there are other factors, such as the reading algorithm in JEOL firmware or main software.
Delay caused by capacitor is difficult to imagine. It requires extremely large capacitor must be installed in the signal line to produce 2 - 3 sec delay. But I cannot imagine any reason to do so.
Long time constant also makes spectrometer adjustment very difficult. Furthermore, long time constant may hide certain troubles that occur in short period, such as sparks.
Mechanical delay of 733 is less than 500ms. So, I think the firmware contains an unwanted bug.
I agree that something isn't right.
And yes, the early JEOL instruments required a much shorter delay. Less than a second as you say.
But each newer JEOL instrument model seemed to require a somewhat longer delay to obtain a stable beam current reading.
I would be interested obtaining a packet capture of the command used to read the instrument beam/sample current on a modern (8x30 or later) JEOL instrument, as the EIKS command may be part of the problem...
Quote from: sem-geologist on February 25, 2025, 02:03:15 AMSorry, but your presented circuit simulation to this situation is inadequate: First of all, replace voltage source with current source (that what the Faraday cup is) and I would also eperiment with different resistor values (100k, 1M, 10M...) (i.e. on SX100 there are 5 different feedback loops for different current ranges; I guess as Jeol is more a budget probe it would have single or just a few). Anyway, even leaving the resistor values of 1k and 100k (which is a bit a questionable chose IMHO) and replacing voltage source with current source, lets say 10nA, the stabilization of voltage at capacitor gets in about 2 seconds with 100 times smaller capacitor of 4.7µF than in your simulation - that is not huge capacitance as for sensitive line RC filter. (huge would be 10000µF; I seen 47uF and 4.7uF caps used all over where RC filters are used to filter sensitive signals, and in some case 470µF would also make sense. Not that Cameca probes would be equipped with any capacitors at all at this particular circuit.) The drain resistor could be 1M, or 10M (typical input-GND resistance for some of precission OPAMPS is even larger, more like 10Tohm) and then capacitor value to fit into 2 sec of full load can drop to 470nF or even 47nF... or even in picofarad range, where longer coaxial cable would start showing effect of its capacitance.
I simulated I-V circuite. I added 1k reg because Opamps generally cause problems with capacitive load. It still requires large capacitors to produce 2s delay. The diagram shows the output pin of OP77.
Quote from: sem-geologist on February 25, 2025, 05:25:40 AMWhile looking to your 2nd graph, I got quite confused. Is that some real measurements? Are the time units correct (maybe should be ns (nano), not ms (milli)?; 15ms ringing period suggest the 50ohm coaxial cable from faraday cup to run for about thousand of km. Even with correct units of ns, that still looks wrong. Maybe there is too long cable which is tied into few rounds making kind of inductor. I guess picoamperometer is situated unnecessarily far from faraday cup. As for contrast, on properly designed Cameca SX probes, faraday cup is connected with very short cable to picoamperometer, where picoamperometer is situated just below the chamber. with only 1m of coaxial cable beam current change at FC would produced ringing with unterminated coaxial, but would be dampened down within 1ms. Another thing is that terribly huge noise. That is not a surprise whole 3 seconds are needed to average out the noise. Again, placing picoamperometer far away from digital noise as close as possible to the faraday cup will have less noise introduced, thus can be measured much faster.
Yes, it is the real measurement. The unit of the horizontal axis is milliseconds. I guess the rising time of opamp used in 733-AEM is very slow. My probing is really bad. I used low-quality cable, not coaxial cable, to obtain output signal of I-V converter. So, the result has large noise.
Theoretically 733/8600 gens should have larger noise than later models. Those models use long coaxial cables to I-V converter. Then, the output of the I-V converter is connected to ADC via coaxial cable. However, the acquistion time of ADC is 30ms, so 3-digits reading value looks stable.
The ADC of 8800 is driven by 250kHz clock, so it can be sensitive to noise. I guess later models also use similar or faster ADC.
Quote from: coredump on February 25, 2025, 08:35:55 PMQuote from: sem-geologist on February 25, 2025, 05:25:40 AMWhile looking to your 2nd graph...
Yes, it is the real measurement. The unit of the horizontal axis is milliseconds. I guess the rising time of opamp used in 733-AEM is very slow. My probing is really bad. I used low-quality cable, not coaxial cable, to obtain output signal of I-V converter. So, the result has large noise.
Theoretically 733/8600 gens should have larger noise than later models. Those models use long coaxial cables to I-V converter. Then, the output of the I-V converter is connected to ADC via coaxial cable. However, the acquistion time of ADC is 30ms, so 3-digits reading value looks stable.
The ADC of 8800 is driven by 250kHz clock, so it can be sensitive to noise. I guess later models also use similar or faster ADC.
Ahh.. so this oscilloscope measurement is done after I-V conversion with some OPAMP, plus not perfect measurement setup. That explains the observed ringing which most likely then is just a oscilloscope measurement setup artifact, and thus also the observed noise could be introduced by oscilloscope measurement. Any ADC is driven with clocks and if PCB is designed correctly (no obtrusion of return currents) it should not cause any problems. I would not think that problem of ringing is in slowness of OPAMP - slower slew rate normally means less ringing and less overshot when capacitive load (i.e. probe cables for oscilloscope) is added. It is rather that precision OPAMP (which coincidentally normally have slow slew rate) has low capacitive load capability, and that cause ringing when oscilloscope probe is added to the circuit. Normally if signal after amplification needs to be transmitted to other unit (thus by cable) or exposed parallel to some external device (i.e. external oscilloscope), the output from precission OPAMP should be buffered with driver OPAMP with high capacitive load driving capability (Which precision OPAMPs has not).
To clarify, long coaxial cable (up to few meters) won't cause trouble if it is properly 360 degree grounded at both ends (to same earth), not through funky decoupling of capacitors, resistors, inductors - just plainly to the metal casing. Normally also coaxial cables with AC signals are terminated at the receivers end with resistor matching the cable impedance and matching resistor in series at transmitters end. The drawback of such termination is introduction of voltage divide (thus twice lower p-b ratio) or attenuation of current (in our case). And thus considering cable length of only up to few meters and that we measure basically slow DC signals, and that FC insertion and retraction rather won't create very steep nano seconds like signal edges - that means coaxial cable in FC to I-V OPAMP connection can work without any termination absolutely fine. As it got clarified the observed ringing is caused by oscilloscope probing setup, so my raised concern about the length of cable can be discarded here.
250kHz clock maters not and it is quite slow as for ADC. What matters is the rising edge of clock and PCB layout matching impedance for digital fast changing (where state flip happens in few ns) signals. There is very cheap way to check it out with any budget oscilloscope. connecting ground clip to probe of oscilloscope cable some about 5cm loop can be made. The loop can be used to troubleshoot for electromagnetic interference (EMI) problems or reveal potential problems. It works by bringing the loop near to PCB to suspect-able parts. Sometimes EMI is directional (i.e. can be seen in X-Y, but wont be seen in Y-Z, or X-Z direction). If You won't see any fields created around ADC, then there is rather no problem there.
All this brings me to believe that your blame on software is rather the right shot. Discarding all those oscilloscope measurement artifacts it is clear that measurement should be possible within 1s or even much less. As for SX case it is a bit different, as it use 5 precision OPAMP feed back loops, and needs time to switch to the right one. Also on these SX instruments... the same ADC (same single chip) is used to measure the FC and also is used to measure about 20 other slow signals from different parts of the instrument (kinda of unnecessary centralization) so probably FC measurement needs to wait in queue for its turn. Now this is kind a "...but Why?" moment.
I am not sure what exactly is going on with the newer JEOL instruments but as mentioned previously, on the older 8900/8200/8500 JEOL instruments, we read the probe current directly from the instrument itself.
While on the newer (8230/8530/iSP100/iHP200F) instruments, we read the beam current from the JEOL EIKS interface, which means talking to the JEOL software on the JEOL computer. Why the "settling time" for newer JEOL instrument is longer than for the older instruments, is a mystery to us.
On the other hand, for the Cameca SX100/SXFive instruments we read directly from the instrument through the MachLib interface, and only require a 200 millisec delay after insertion before reading a stable beam current.
Another note, we looked at the code to read the beam current and found that we utilize a loop to wait for two stable beam current readings in a row before accepting the value:
' Check for valid handle
If Jeolhandle& = 0 Then GoTo JeolGetFaraday2NoHandle
beamcurrent! = MAXMINIMUM! ' force loop entry
' Avoid JEOL garbage number (positive and negative) that JEOL 8200 sometimes returns
numtries% = 0
Do Until beamcurrent! > 0# And beamcurrent! < 16383# And beamcurrent! <> 1638.3 And beamcurrent! <> 163.83 And beamcurrent! <> 16.383 And beamcurrent! <> 1.6383
itest& = J8K_ReadCurrent(Jeolhandle&, tbeamcurrent!)
Call JeolGetError(itest&, "JeolGetFaraday2")
If ierror Then Exit Function
beamcurrent! = tbeamcurrent! * NAPA# ' convert from amps to nA
numtries% = numtries% + 1
If numtries% > MAXTRIES% Then Exit Do ' give up and return whatever
If numtries% > 1 Then ' only delay if first time failed
Sleep 10
End If
Loop
JeolGetFaraday2! = beamcurrent!
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.
Quote from: John Donovan on February 26, 2025, 08:27:56 AMApparently 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.
Quote from: sem-geologist on February 26, 2025, 01:58:45 PMI 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.