Million Count Limit

[neko]

Is there any reason for the million count limit in modern software? Is it just something Cameca's never bothered to update and just let people figure out the hard way when it ruins their analyses?

[sem-geologist]

It should not be a problem.
How does it ruin analyses? The moment You hit 1000000 counts it will take a note of the exact time spent for counting up to 1M and will move to the measuring background (at half of time than peak). As end result which we are interested is not number of counts, but ct/s/nA, I don't find that anyhow limiting to be honest. Actually, if I am able to hit 1M counts in reasonable time that means that I am really really having very high counting rate and pulse-pile up is much worse problem at such situation (and If You had seen discrepancies in values from what You expect it is for sure pulse-pile up eating your counts, pulse pileups is capable to "eat" away 60+% of counts in very high count rates). With 10kcps (safe rate with <=0.5% of pulse pileups) to get to 1M would require 100 seconds. Lets add 100seconds for background and we have 3+ minutes for a single major element. That is rather trace concentration counting times.

But Why this limit.
Cameca Hardware is based on VME (Versa Module Europa standard dedicated to serious stuff like industry, space, military and science equipment) Which is TTL/LTTL logic based. Pulses (LTTL or TTL) from WDS board is sent to acquisition board with maximum theoretical throughput of 500kHz (pulse length is 1µs and thus for any digital interface pulse 5V/3.3V (TTL/LTTL) pulse needs another 1µs for digital signal be enough time at zero. That is interoperable standard, so that it would be possible to push those pulses with coaxial cable to other counting/mapping/interoperable equipment (i.e. some older or some modern compatible EDS systems), maybe it is lately changing as for signal requirements, but that was at least such in last few decades. The connections between VME boards and backplane allows to send signals in 10MHz-20MHz range reliable. In newer version of VME (but those used in Cameca are the basic version from 1994) signaling can go up to 200MHz, but requires different noise immune sockets as base 96 pin sockets are pretty noise susceptible (You can catch inductively signal on one "pin" while huge peak is being sent in nearby other pin - in electric engineering it is so called *crosstalking*). Now if we take 500kHz square wave it can look that for modern computers like intel Xeon (working in GHz range) with huge load of very fast RAM good graphics the task to count those pulses would be super easy. That is completely opposite - any consumer OS based system not designed for real time tasks will fail such counting miserably in software. But wait a minute, our modern computers are handling GHz range of gigabite network, internally it have buses of tens and near hundred GBs - I should be wrong. While it is true, the thing is for all these high speed signals there is a dedicated hardware which gets serialized data as pulses and send to CPU and/or memory as chunk of data. Schedulers - that is the main culprit that even 500kHz pulse-to-pulse count by software is impossible. So it is not Cameca Software - but Hardware inside one of VME boards which is counting those pulses and returning the result or state of counting if requested. On older electronics it was physical chips so called counters. Counters can be 4bit, 8bit, 12 bit, 16bit, 24bit, 32bit. Sometimes it is a combination (i.e. 2x16bit counters connected so that second counter counts overflow events and so it works in conjunction as 32 bit counter). In some modern systems physical chips are replaced with virtual counter inside FPGA (newer Cameca electronics).  i.e. you can use 16bit+4bit (or if speed maters 8+8+4) to get 20bit counter. 20bit gives 1048576, which rounds up to 1M. I guess physical and virtual FPGA counters are 20bit and that is why it limits counting to 1M in my opinion, because going over 1048576 would overflow the counter and counter would start from 1. 21 bit would give the twice of that and 24bit counter would give over 16,7M counts.

OK... How to overcome this.
If You really need that...
Use subcounting, it will restart the counters at every subcounting, and thus You can get I think 30 * 1M = 30M counts.

[sem-geologist]

Neko,
I relooked into this issue, and I see that counters are actually probably 32 bit. In SXControl Window we can set max and that sets value to 2.15E9 which is 2^ 31 (last bit probably is not used, as feared for overflow). And I tried - it counts past 1M counts. You are right this is absolutely Peaksight Software limitation.

[neko]

Good news, it turns out it was a bug I triggered somewhere - creating new calibration files when you encounter this will remove the limit.

[jon_wade]

Good news, it turns out it was a bug I triggered somewhere - creating new calibration files when you encounter this will remove the limit.

There was a hard limit in an earlier version of peak site.  I asked them to remove it a while back (I had an interest in seeing how Fe speciation by site occupancy could be compared to XANES methods...don't ask!) and they did it in the following iteration.

[sem-geologist]

Good news, it turns out it was a bug I triggered somewhere - creating new calibration files when you encounter this will remove the limit.

There was a hard limit in an earlier version of peak site.  I asked them to remove it a while back (I had an interest in seeing how Fe speciation by site occupancy could be compared to XANES methods...don't ask!) and they did in the following iteration.

Which iteration? I have v. 6.5 and limit is still imposed.