Whatever you call them - spikes, sparks or arcs - the presence of unwanted electrical discharges during data acquisition can have a dramatic effect on the appearance of your EPIs and will likely result in poor or unusable data. (See Note 1.) There are many potential sources of unwanted electrical discharges - what I shall refer to as spikes for the rest of this post, regardless of the origin - in and around an MRI scanner. They can arise from within the scanner itself, or from items in the magnet room, or from items of clothing on a subject who hasn't been screened quite as thoroughly as he might have been.
Before we get to the sources, however, let's take a look at what we're talking about. Take a look at this mosaic of EPIs:
See the problem? No? Exactly! As I have mentioned several times in the past, many artifacts are best (or only) seen once the background level is brought up. Like this:
Aha! We clearly see the artifacts in this view: strange, variable patterns across entire slices.
Now, it isn't always necessary to crank the background intensity up to be able to see the effects of spikes, as we will see below. But as a general rule, the very first signs of spiking will be quite subtle and will likely be hidden away down in the noise with the N/2 ghosts and all the other crud. This is when you want to catch them, before they become intense and wreck your experiment. So, just to reinforce the point, take a look at this video and see if you can detect any anomalies in the images:
Any joy? There's a small amount of subject movement near the beginning of the run. And if you are eagle-eyed you might have spotted a faint pattern across some of the brain signals in the latter stages of the video. So let's see the same time series but with the background cranked up:
This video serves to make two important points about spikes: (1) spiking can be faint and insidious; and (2), spikes can also be rare events; the epitome of an intermittent problem. Had the time series acquisition terminated after about 200 volumes it's unlikely you would have noticed any data quality issues whatsoever, unless you had been watching very closely the data acquire in real time. (By the way, these spikes were generated by small movements of some locking nuts holding passive shim trays. More on this source of spikes below.)
There's a third important point to remember about spikes: certain users may see a problem when others don't, e.g. because of a particular experimental parameter, such as slice angle, or because they are scanning at a particular time of day, e.g. when the scanner is cold or has been run intensively for several hours. Precisely when spikes will be seen depends entirely on the origin of the problem! Thus, it pays for all users to be vigilant for signs of spiking all of the time!
The appearance of spikes in EPI
This is where things get interesting, and rather beautiful if you ask me. Some of the patterns generated by spiking can be quite artistic. For sure you're an unhappy camper at having your data corrupted but you might as well take a moment to appreciate the aesthetics.
So, what's the physics here? For such complicated and sometimes attractive patterns in the image domain the explanation is somewhat prosaic. First of all we need to recognize that any sort of spark generates a broad band of electromagnetic radiation, some of which occurs in the radiofrequency range of the spectrum. Spiking is, therefore, an intermittent form of RF interference; one that is occurring inside the Faraday shield.
Next, from your understanding of k-space you should be able to recognize intuitively that if a point in the k-space matrix is set artificially bright by virtue of a spurious RF source - a source other than the magnetization in the sample - then the resulting image will have a predictable pattern based on where in the k-space matrix that artificially bright spot happened to occur. If it's a single point in the k-space matrix that's affected then the point's location relative to the center of k-space determines both the spacing of the wave pattern in the image (after 2D Fourier transformation) as well as the angle of the wave pattern relative to the (square) edges of the image. The intensity of the contaminated point relative to the intensity of the MR signals determines the relative intensity of artifact to brain in the final image. (The book, Functional Magnetic Resonance Imaging by Huettel, Song & McCarthy has some nice demonstrations of single point sources in k-space and the resultant image domain. See Figures 4.16 and 4.19 in the 2nd Edition.)
Mentally extrapolating to more complicated patterns is also straightforward. More than one spark during the acquisition of the k-space matrix means that there will be multiple interfering patterns in the resulting image, for example. And sometimes there may be so many small, near continuous spikes that the artifact pattern appears almost noise-like. Examples of simple and complex, regular and irregular patterns appeared in the video you saw above. Expect to see anything and everything where spikes are concerned!
The most common causes of spikes
Spikes aren't, or shouldn't be, common on your scanner. This means that most of the time your data should be acquired spike-free. However, if you use your scanner at all, and especially if you run a lot of fMRI and diffusion scans, then the chance of spikes happening eventually is close to 100%. It's a wear and tear issue. Frequent checking of all common failure points by a service engineer can really help (more on that below), but unless these checks are conducted very frequently - say, monthly - then I'd put good money on your facility having a spiking incident at some point. And even with frequent checking things can and generally will go wrong eventually. It's a bit like a car. As the car ages and/or is driven more (or more aggressively), the chance of some component failing increases even if you have standard preventative maintenance, like oil changes and belt and hose inspections, performed regularly. 'Tings, they break.
But detecting spikes isn't usually the biggest complication, it's finding the accursed source. And if you have more than one source then expect to watch a service engineer spend many frustrated hours and perhaps days trying to figure it all out. That said, there are certain causes that are more likely than others. Below I list the most common sources that I've come across. It's not an exhaustive list, largely because different scanner vendors, different hardware designs, different usage profiles (e.g. lots of coronal rather than axial EPI) and different magnetic field strengths are all likely to dictate the particular failure characteristics.
1. Movement of locking nuts or some other metal component of the gradient electrical cables.
The scanner gradients are powered by hundreds of amps of current that are fed into the back of the magnet via fat copper cables that are bolted securely to the gradient set itself. These cables experience the high magnetic field at the rear of the magnet and flex slightly during each pulse of electricity that is supplied. (It's the same principle that produces the sound when the scanner is acquiring images.) Over time, the immense and repetitive torque experienced by the cables - especially those that provide the electrical supply to the readout gradient, which is usually Gx for axial slices - can cause locking nuts to loosen, and as they do these tiny movements of metal on metal will produce small (in terms of current) additional electrical discharges. The scanner becomes its own intermittent source of RF interference.
Another cause of movement, leading to loosening connections, is the frequent heating and cooling of the gradient connections. The large currents flowing through the copper wire cause heating through electrical resistance; all perfectly normal. But if the copper cables are held in place by steel nuts, steel being a harder metal and thus more suitable for ensuring things stay where they're put, then the differential rates of heating and cooling of the different metals can lead to movement via differential thermal expansion/contraction.
Sometimes it's the other end of the gradient cables that is the source of spiking. In 2010 my scanner developed spikes that were traced to a failed washer between locking nuts attached to a gradient cable filter in the wall of the magnet room (up in the penetration panel, where all the electrical cabling enters the magnet room). The washer was of a special split design, to allow rapid heating and cooling while not (hopefully) causing the adjacent nuts to loosen. This washer failed - literally disintegrated - and that led to additional spiking, as well as excessive heat build-up which ultimately caused the filter to buckle. There's a picture of the charred filter in the post on fires in MRI facilities. We were lucky that the problem was limited to one destroyed filter and some wasted days chasing spikes, and not a catastrophic fire.
2. Movement of locking nuts on shim trays or other components inside the bore tube.
The massive vibration caused by operating the gradients can also shake loose other scanner components, such as the trays holding the passive shims. These trays are an essential component that allows the magnetic field to be homogenized when the scanner is installed. Not only can movement of these components produce spikes, eventually it is likely that the magnetic field will become sufficiently heterogeneous that image quality is degraded whether or not spikes are actually occurring. (I know of one facility that detected the degraded magnetic field - an inability to shim subjects' heads properly - before spikes were detected.)
But the appearance of metal on metal spikes is generally similar regardless of the source. Thus, the usual procedure on detecting spikes as shown in the videos and images above is to check all easily accessible connections - gradient cables (both ends!) and passive shim trays - even if one "smoking gun" is found straight away. It's not uncommon for two or more sources of spikes to develop simultaneously.
3. Conductive debris in the RF coil sockets on the patient bed.
Foreign objects and debris, or FOD, that tracks into MRI facilities can contain all manner of stuff, not just dust and hairs. It's quite common for small magnetic particles to end up stuck in and around the magnet bore. If some of these metallic particles end up lodged inside one of the RF coil plugs on the patient bed, where you connect the head coil, then weird discharges or other modulation of signals can result. It's another variant of spiking.
Here is what spiking can look like in EPI when conductive FOD gets into an RF coil socket:
Because the spiking is modulating the MR signals directly, not just adding a contaminating source of RF interference to them, the appearance is quite a lot more intense than the previous examples of spikes arising from loosening connectors inside the magnet bore. There isn't the need to bring up the background intensity to get an unambiguous view of the artifacts here (although it is still a good idea to watch the background first, for subtle artifacts).
Here is what the temporal properties look like in an EPI acquisition:
Now, because this source of spiking isn't dependent on the intense vibration of the scanner during EPI, or on the heating of gradient cables produced from extensive scanner use, it's fairly common to be able to detect RF socket spikes in images other than EPI. On the left, below, is a clean slice through an MP-RAGE. On the right is a slice contaminated by spiking. Note the cross hatching around the subject's mouth and in the frontal lobe:
|(Click to enlarge.)|
And here are examples of clean (left) and spike-contaminated (right) gradient echo localizer images from the same session:
|(Click to enlarge.)|
Note that there is a movement artifact around the brain stem in both images, arising from arterial pulsations, that is only subtly different from the banding due to the spikes. However, if the background intensity were brought up it would be clear(er) that the spikes have produced artifacts across the entire image, not just in these signal-containing regions, as we saw previously for the spike-contaminated EPIs. (Apologies, I only have screen shots of the MP-RAGE and localizer scans. Not sure what happened to the dicoms or I'd show the recontrasted views, too.)
4. Other sources of metal-on-metal friction inside the magnet room.
This one's a doozie. I've heard from more than one installation engineer of the problems generated by overhead light fittings in the magnet room. Apparently some facilities use general contractors to provide services, rather than using a company with expertise in the MRI environment. Consequently, light fittings that jangle have been installed on occasion.
The metal-on-metal friction caused by scanner vibration (and perhaps other sources of vibration/air movement, such as air conditioning) can produce just enough static electrical discharge to produce yet another form of RF interference inside the Faraday shield. Usually your installation engineer will have checked for these sorts of problems before you ever get near the scanner. But it's something to keep in mind if all the above sources have been checked and eliminated, yet spikes are still detectable. It could be that something has broken, or been modified, in the ceiling above the scanner. If the ceiling tiles are removable, as they are in most facilities I've come across, then doing a quick inspection in the roof space doesn't hurt.
But it's not just the contractors who can be at fault. FMRI requires a lot of peripheral equipment, some of which may have the potential to vibrate and cause electrostatic discharges, too. If you're bringing a new piece of equipment into the magnet room then, having done the usual checks for magnetism and (persistent) RF interference, check it over for any potential for metal-on-metal vibration. Think you might have a metallic vibration source? Try separating the metal components with an insulator, such as electrical tape, and also minimize the relative movement.
5. Items of clothing on subjects.
I'm going to include this last source for completeness; it should already have been eliminated by virtue of comprehensive subject screening. Furthermore, I would assume that by the time you're ready to call a service engineer to investigate spikes, someone has bothered to put a phantom into the magnet and assured that the source of spikes is still present, i.e. it's not a "feature" of the last subject scanned.
One of my belts just happens to be a superb spike generator. Here's a picture:
The buckle comprises two brass loops - ideal pickup coils - that are held slightly apart by the canvas belt. Position the two loops (in)correctly and the currents being induced in the loops will gladly hop back and forth via a minuscule arc. Presto! Spikes in EPI data! But this is a classic intermittent spike source because the frequency and intensity of the spikes depends on the position of the two brass loops relative to each other and also their inclination to the switching gradient fields. The solution is pretty obvious: screen your subjects and have them take off all items they can that contain metal. Be particularly alert for metal loops on jeans and the like. Zips and metal snap/popper buttons are usually not good spike sources. To generate spikes there needs to be a couple of separate pieces of metal that can either move/rub relative to one another, or be held in close proximity such that electrical sparks can jump across the (small) gap.
Detecting spikes: when QA doesn't assure perfect data.
When confronted with unambiguous artifacts like those presented above, you might reasonably wonder why spike detection is a problem. Well, when things get really bad it is true that spikes are easy to spot, even by the untrained or the inexperienced. But early detection - when the problem is still manageable and data can still be used profitably - is the goal.
Presumably your facility physicist/tech runs quality control routines that check for spikes, amongst other things. There are also dedicated spike check routines that engineers use for diagnostic purposes. (Your scanner physicist may have access to these tools, too.) But one of the problems with quality control (or quality assurance, QA) is that even if it's done daily, and extensively, it is all to easy to miss a problem. For instance, spikes may become noticeable only later in the day, after the scanner has been in-use for several hours and is fully warm. In that case, running QA first thing in the morning, even after a period of operation to warm up the scanner, may not detect the problem. Ideally, then, all scanner users will be "spike detectors" while scanning.
On my scanner - a Siemens Trio - I've found that the earliest sign of spiking is a subtle and very occasional modulation of EPI ghosts. Now, it takes some experience to separate this source from the manifold ways ghosts can get perturbed, but on a phantom these little fellows have become reliable canaries in the coal mine. Here is an example of the earliest signs of spiking, acquired using EPI on a water-filled bottle. There are five flashes in total, see if you can catch them.... (You may need to view this video full-screen on Youtube to see the flashes clearly.)
It's interesting to note that these subtle ghost flashes show up well in advance of the vendor's spike check routine for detecting spiking.
Any phantom can be used to run a simple spike check such as this. I have a rig set up for daily QA so it's most convenient to use that. And I should note that one of the QA criteria we use is a visual inspection through three 6 minute time series EPIs, looking for ghost flashes such as these. (It would be possible to write an algorithm to detect the flashes automatically, but it takes only a couple of minutes to inspect the data and the human eye is a pretty good motion detector!) Furthermore, my QA routine includes a couple of different parameter settings; one that is typical for a routine fMRI user, the other - and the one that I hope triggers any spiking potential - drives the scanner as hard as it will go (and still give usable data). The latter approach I liken to "kick it in the nuts, see if it cries." It's not the most elegant approach to QA, I admit, but it does tend to satisfy the intended purpose. I'll do a separate post on approaches to QA another day. It's a big topic and there are many schools of thought.
Once flashes like these are seen in test data, we call the service engineer to come in and check all the usual suspect failure points: the gradient cables and the passive shim trays. If the flashes are subtle, like these, I generally don't take the scanner offline. Instead, the engineer comes in at a convenient time for his and the scanner's schedule, and we continue with routine data acquisition. Again, that is a matter of policy for a center to determine, there's no universal rule. (My feeling is that if subject motion is likely to be an order of magnitude more problematic for the vast majority of studies then the scanner can still be used productively. I'm sure some people will disagree.)
It's also a good idea, if you haven't already done so, to request that your service engineer checks all the likely failure points during quarterly preventative maintenance (PM). Don't rely on the vendor's spike check routine, it can give false negative results. Ask the engineer to put a wrench on each locking nut he can get access to. I know I had to make a special request to have this check done; it wasn't on the list of standard checks that the vendor sanctions. (See Note 2.) But it is of course better for both the vendor and the customer to spend a few additional minutes checking locking nuts during PM than for the vendor to have to answer a separate service call when something gets loose!
Finally, humidity. Your facility may well have a humidifier to ensure the magnet and electronics rooms don't become too dry in climates prone to low ambient humidity. If humidity gets too low then static discharges are more likely to occur. We record humidity in the operator room at my facility, even though we have a humidifier. We also record the humidity reported at a nearby airport, so that I can monitor weather-related or seasonal variations in subtle spiking behavior. It's not uncommon for low sources of spikes to show up only during dry months. (There's more water in the Martian atmosphere than in parts of the Californian atmosphere in the middle of summer.) And unless you have months or years' worth of data to draw upon, detecting trends can be all but impossible.
But this is something for your facility physicist to worry about. Your job, as I said at the outset, is to be ever vigilant for signs of spiking in your data. As a proportion of total data acquired, and because of the varied acquisition conditions presented by real experiments, it is *far* more likely that a user will encounter spikes before the QA is able to detect them.
1. I hear there are spike removal routines that may suffice for eliminating a handful of contaminated slices from an EPI time series, but I'm afraid I don't know anything about them. I found this on the MIT Imaging Knowledge Base. And Google searches suggest there are spike removal routines in FSL and SPM. Perhaps someone will be kind enough to post some links in a comment? I would think that use of these routines would be limited to infrequent and/or low intensity spiking. Presumably this issue crops up on discussion threads concerning so called "pre-processing" methods. (It's all post-processing to me, the moment the 2D FT generates a set of images!)
2. For some connections a special non-magnetic torque wrench is needed. These cost thousands or tens of thousands of dollars, so they aren't generally carried by every single service engineer! Your service person may well have to have it shipped in specially. For other nuts, such as on the passive shim trays on my scanner, a regular non-magnetic (e.g. titanium) wrench suffices. Whatever tools it takes, it's just plain good sense to check all the connections that are accessible with the rear cover off the magnet (at the very least). And of course, if you ever find your scanner is prone to another failure mode, make sure that failure point is checked every single service visit! I've had to remind my service guys to do checks a few times. Far better to check the known failure points as often as practicable. Don't let your service engineer follow some predefined script which was developed primarily for clinical scanner use, by the way, not the aggressive stuff we researchers tend to run.