Cameca digital noise issues

[Probeman]

Recently we were acquiring some quant maps on our SX100 using stage scanning and upon close examination we are seeing some single photon count artifacts (vertical stripes) on one of the spectrometers (Sp2, LTAP):



The above image is the raw data on-peak acquisition at 100 nA, 10 keV and 60 msec per pixel. We do not seem to see this artifact on the other channels, but this particular spectrometer was tuned to F Ka on TAP and so the count rate is very low.  It may be that the artifact is "buried" in the background on the other spectrometers.

Since these artifacts reproduce at the same stage X interval, maybe it's related to the stage movement? This is the Cameca fast scan direction.  The scan is 900 um wide using 1 um pixels and there's 21 "bands" so the vertical artifacts appears every 42.8 um in the X direction.

Does anyone have any ideas as to what might be the cause of these artifacts?  I guess the next step would be to tune up F Ka on several TAP spectrometers and see if we see the same thing on these other spectrometers...

[sem-geologist]

is your sx100 electronics new or old type?

[Probeman]

is your sx100 electronics new or old type?

The instrument was bought in 2006, and when we upgraded a few years ago to PeakSight 6.1 (to be able to run PeakSight under Win 7), we found that the stage mapping no longer worked. That is, it would acquire the first map set, but after that the instrument would be in a "locked up" mode and not able to respond anymore. Details are described here:

https://probesoftware.com/smf/index.php?topic=1171.msg8354#msg8354

After much discussion and negotiations with Cameca we ended up sending two of the electronics boards back to France so they could have their firmware updated (~$2K).  After we got the updated boards back, everything seemed to work OK again.

What I want to do next is acquire a bunch of maps using several spectrometers tuned to F ka, all on TAP crystals, and see if we see the same vertical stripe artifacts on the other spectrometers.

[sem-geologist]

Lets wait first for a second experement (with F ka on other spectrometer). I would not blame resistors - no way a resistor could  (linear analog component which is even not used for any logic, but only for voltage drop) cause this. I would rather suspect digital side. I would bet either on VME crosstalk (false count impulse generated by nearby VME address bus (24-31 bits)... or FPGA on WDS card is programmed with bugs.

[Probeman]

Not sure if this is the best topic for this issue, but recently we were acquiring some quant maps on our SX100 using stage scanning and upon close examination we are seeing some single photon count artifacts (vertical stripes) on one of the spectrometers (Sp2, LTAP):

Does anyone have any ideas as to what might be the cause of these artifacts?  I guess the next step would be to tune up F Ka on several TAP spectrometers and see if we see the same thing on these other spectrometers...

I did not, but the material is AlN so pretty robust. Did not view in SE though.

[Probeman]

Lets wait first for a second experement (with F ka on other spectrometer). I would not blame resistors - no way  resistor could  (linear analog component which is even not used for any logic, but only for voltage drop) cause this. I would rather suspect digital side. I would bet either on VME crostalk (false count impulse generated by nearby VME adress bus (24-31 bits)... or FPGA on WDS card is programmed with bugs.

I'm out of the lab for an extended period of time, but I will see if my lab manager can do this test.  I would tend to agree that is more likely some sort of bus noise. 

On what might be a related or unrelated topic, we have for many years seen a sort of digital noise on our electron imaging monitor, mainly in the lower 1/3 of the display, but it doesn't show up in the data.  Our engineer has tried to track down the source of this noise "hash" but so far been unsuccessful.

[sem-geologist]

If your sx100 has old type of electronics (visualisation board), the composition (adding texts, lines, applying LUTS, overlaying a scalebar) of video is done on visualisation board, which have its own memory, and old memory can get corrupted. I .e. our old visualisation board has faulty LUT memory, and random bits flips adding colors randomly (off course that is not seen in acquired and saved image), reloading luts fix issue (temporary).

In your case it can be faulty memory of overlay layer (texts, markers...) or memory for temporary storage of signal (as 8bit gray data). Anyway that is not VME bus issue, as else you would see the same patterns on acquired image to PC (which bypass, or more precisely - that process does not include visualisation board at all). With new gen powercquicc II processor (which replaces old Motorola 68030) and new electronics (actually scanning, visualisation and acquisition in the single pack) the RGB composition is done (I am near certain, but not 100% sure) in PowerQuicc II processor, and same image is sent to PC and physical monitor (tailored with additional elements overlayed).

We have such configuration on SXFive, and we are getting vertical stripes on all images (phys. monitor and PC) - I cant find where that noise is coming from, and this actually could be bus related, indeed.

[John Donovan]

Apologies for my ignorance - I've deleted my post so as not to give others bad info. Please let us know how the next test goes.

As SEM Geologists notes above, the other issue probeman has been seeing (digital hash on the electron image display, but not in saved data), could be bus noise.

Julie is going to try and run a test (on all spectrometers) for the vertical stripe issue (originally described) in a few weeks when she finishes a dozen or so maps for a customer. In fact I'm moving this thread to a new topic as it seems we may be able to find a solution and it isn't stage related apparently.

[sem-geologist]

As SEM Geologists notes above, the other issue probeman has been seeing (digital hash on the electron image display, but not in saved data), could be bus noise.

No I did not. I said that would be theoretically possible with the new (visu/acq/baley) electronics (however as I re looked into this - it is rather not), and as far as I read here the SX100 of probeman has only the new stage and wds electronic boards so probeman's artifacts on physical display could originate rather in faulty memory on (old) visualisation board (Also it could be by some parallel power line running to VGA cable, as an analog signal is susceptible to EMI). Additionally to that, if monitor is new LCD it can't sync with slow pixel clock (only on old visualisation board) and oversampling will cause vertical lines on the physical monitor, but as I understood probeman had described other kind of artifacts. When I talked about the bus I mean the specific bus - VMEbus (please, consider that there are other data buses).

Going back on topic, Lets look into that stage mapping defined pixel noise and my proposed VME bus cross talk. To get artificial counts the pipeline of WDS signal can be affected at two places and that is different kind of noise. The WDS spectrometer sends an analog signal, which after initial preamplification is sent to WDS board. The signals have relatively low voltages and is quite susceptible for EMI. F Ka particularly has relatively low pulse energy (theoretical PHA position for F Ka is very much at left side). Please consider that what you see in PHA that is after some additional amplification, and signal I am talking about is in sub-volt range so any slight cross-talk onto that sub-volt analog signal could produce false pulse (if outside the dead-time range from last digitized pulse). Can VMEbus do that? Rather not, as these signals gets into card at third connectors and only P1 and P2 (middle row) connectors are used by VME. If some cross-talk is done on this stage it should happen on the board itself, but for that knowledge about pcb traces is needed, and we have none of that and would never ever get from Cameca.
Second possibility is the false digitized pulse (or noise taken as pulse). It is not exactly clear if new WDS board generates WDS digital pulses in LVTTL (3.3V) or that is 3.3V CMOS (old board was producing 5V TTL pulses). Now the VME bus cross-talk is very possible for those as they are sent out from WDS card at P2 connector, and Address bits (24 and 25) of VME bus is very nearby. It can be that some high address is set every nth pixel (a coincidence), and so if that crosstalk impulse amplitude is higher than threshold, it can be counted as a pulse.

So I think it would be interesting to do experiment not only on other spectrometer, but try to do with different pixel dwell time. It needs to be identified if noise is pixel n sensitive or time period sensitive.

[Probeman]

OK, thanks, good to know. We will run the test on multiple spectrometers using two different dwell times.

[sem-geologist]

So had you made tests and got to know what is causing those artifacts?

My diagnosis of our problems with SX100 monitor was correct - I had fixed our random color appearing on physical monitor. Thanks to USA market, I could find and order the replacement part (because older parts are still used in industry, military and space, there are special dealers dealing in refurbished or stored old parts), this would not be possible to find in green-obsessive Europe. The chip costed 5$, but shipping 100$ (actually I had to buy three, to get over 15$ of minimal order + custom and other taxes). After popping the old chip out and putting in a new, those random LUT bit-flips are at last gone.
    Now the fun part - A Few years ago I asked Cameca engineers, what could be done with these random colors - and the answer was to replace that board with new generation electronics... but mixed generation boards are known to work poorly, and so it is advised to change all VME boards. Of course special price if opting-in to gold service contracts... I am so happy we had no funds to go that way, as these old boards occur much more fixable. Most of logic is in schematics, while new generation boards moved lots of logic into FPGA's, and that is a complete black box as we see in schematics only the FPGA pins. New generation is much more energy efficient (Old boards are powered by 70A 5V rail, where new generation is powered by 25A 5V rail), and boards are smaller... but if something is not working right - there is near zero possibility to troubleshoot that independently from Cameca. I am not against FPGA (if I would do custom board replacement that would be first chose of mine), but against lack of documentation, and black boxing the system.

[jon_wade]

I don't know how I missed this post - apologies

amongst the many 'foibles' I've had with our sx5 FEG we also had similar nice stripes.  We got them on the EDS images as well, both vertical and horizontal (I will dig out some images - very trendy Scottish tartan! ). However we have changed pretty much every board more than once so pinpointing the exact cause is lost to my memory but the regularity of it on stage maps pointed to a an issue with the stage motors.  The fix (from recollection) was more Earthing on the stage motors.

[sem-geologist]

Jon,
I think It is not first time I hear that there is this problem with stage motors. Do you know exactly how that was fixed? As far I can remember some other mailing lists, there were mentions that ground of stage motors was not enough separated from ground of align coils (or align coil PSU, or maybe control - the description was not very clear). We get such patterns on our SXFiveFE, albeit only on high contrast BSE, and monotonic element mappings (where it gets "invisible" if in variable composition materials). I had hear that fix was by adding some resistors somewhere - tried to deduce the point in the schematics, but it is hard to come up with hardware workflow for troubleshooting as values are really small. The checker pattern (or as You had called "Scottish tartan") is due to changing beam intensity which changes when beam alignment changes, malfunctioning stage position can't produce that alone. Due to the not most brilliant design of SXFiveFE column, other apertures (immovable/non-adjustable) than objective aperture (movable/adjustable), in particularly splash aperture,  can be situated a bit of axis, and so "well aligned" (centering beam to go through C2 and C3 axes) beam will not go centrally through such aperture. When unintentionally altering beam align coils (by leaking ground in our case during mapping) the intensity can increase if beam is moved more to the center of immovable aperture (or decrease, if beam goes more off-axis).

[jon_wade]

this sounds exactly what we had/have.  My understanding was their was an issue with the Earth on the stage motors which meant that there was some feedback somewhere. The 'fix' was to add an supplementary Earth to the motors although, if I were honest, I cannot remember the full details (honestly, we have had a fair few fixes over the years). But the symptoms you describe are exactly ours.  Has it entirely gone away?  Hard to say....

[sem-geologist]

(honestly, we have had a fair few fixes over the years)

Has it entirely gone away?  Hard to say....

strangely, this sounds so familiar...
I think that is the common problem with new generation hardware – fixes sometimes work... but sometimes fix can miss the problem (or even worse – introduce a new problem).
Generally, I start to be happy with our SXFiveFE - the FEG tip is managed with my custom protocol and running near flawlessly already 2.5 years - good as new (I am probably "a bit" exaggerating). It still has a number of hardly-fixable shortcomings, but it is possible to work with it using a bit different workflow, and workarounds are not hard to come up with. The strongest point of the machine in my opinion is stable high current (700nA) while keeping the beam at focus. Could not achieve something like that on SX100 with tungsten tip.