[Intl_DxMedPhys] Recent Tx Gain Variation on Siemens Sola 1.5T MRI

Tue Oct 28 12:23:03 EDT 2025

Dear Bob & others who reached out individually,

Thanks very much for all of the suggestions. It was very helpful. I am
unclear if list members intended to only reply to me, but I wanted to
include them in the main feed for others AND to acknowledge their gracious
help. (If you preferred to only reach out only directly to me, my sincere
apologies.)

>From Ho-Ling Anthony Liu, PhD, DABR, MRSE; Professor, Department of Imaging
Physics; University of Texas MD Anderson Cancer Center:

Interesting. Wondering if the scanner is turned off daily? Has that
schedule been changed?

 *[Steve]: Scanner is shut down daily. Tech confirmed that the schedule has
remained the same. But a good idea to confirm! I did look at the time of
day for the phantom scan, but the data was quite random and not correlated
to time of day. *

Have you tried to record this daily for a week or two to better see the
pattern?

*[Steve]: not yet. I will see if the workflow is feasible. This ambulatory
system onlys run a single shift (sigh) and there is not much downtime
outside of patient care. I will see if I can do this*

>From Dave Jordan, dave.jordan at gmail.com

 Have your Siemens FSE run a comprehensive set of “TALES” checks. You may
have a sick RF amplifier getting ready to give up the ghost.

*[Steve]: Thanks for the suggestion. I will request from Siemens service. *

>From Maclellan, Christopher (BIDMC - Radiology Administration);
cmaclell at bidmc.harvard.edu

I haven't seen this specific issue but I can throw out some ideas.

I would look at the service tests and dates and specifically BC tuning, BC
power losses, Rx Gain calibration. Make sure they're passing and check how
close they are to spec. Seeing the numeric results may be hard without a
higher level service key on XA software though. I think it's reasonable to
think that these may all impact your transmit gain. You may have already
done this as you've clearly been pretty thorough.
*[Steve]: I do have a service key, which I find crucial -- more comments
below. *

BC tuning is something I've seen Siemens FSEs leave slightly out of spec.
Their reasoning is it's not something that's always easy to fix and messing
with it can quickly get you in a hard down situation. (I can go into more
details on what the FSE told me if it's of interest) For the same reason, I
would think twice if you're inclined to run the QA checks yourself- if it's
out of spec by enough it will throw warnings to the operator and give the
"yellow line" in the bottom right. If it's even more out of spec you'll get
the "red line" and be hard down.
So, if any of those tests are out of spec or haven't been done in a while
you may consider pointing service that direction.

*[Steve]: It was helpful to look back thru service records. The PM in early
July did perform checks (QA-only) of Rx Gain Calibration, BC Tuning Check,
and BC Power Losses Check. The BC Tuning Check failed on the initial run;
however, it looks as though the svc engr simply repeated and it passed-- no
"BC Tuning"  (as part of Siemens "TuneUp - General" category) was run. In
fact, the TuneUp procedures you mentioned (Rx Gain Cal, BC tuning, BC power
losses) haven't been run since the system startup period in July 2023. I
will likely ask them questions about this and may strongly suggest they
consider repeating a complete TuneUp procedure. *

*While it would be interesting to run the QA checks, I would be concerned
about phantom setup -- I don't have any documentation for these tests. (I
think it would require a higher level service key.) *

From: Peter Hardy, PhD, DABMP; Associate Professor of Radiology,
Neuroscience and Biomedical Engineering; Faculty, Division of Diagnostic &
Nuclear Medical Physics; University of Kentucky College of Medicine

A very interesting problem. Good for you to document it so thoroughly. I
would not say you have over analyzed it.

Your graph shows an increase in the power required to achieve a 180 pulse
as well as an increase in the variation of the estimate of that power. For
me, that points most likely to a problem with the body transmit coil rather
than the head receive coil. If you had a problem with the head receive coil
such as losing one channel, I think you might see a reduction in SNR which
might be manifest as a reduction in the number of low contrast spokes
detectable. I don’t think it would be manifest in the Tx power. So assuming
you have a problem in the body transmit it might be helpful to run a few
tests on the body transmit coil. I hardly ever run those tests so I’m not
familiar with the entire set. There might be a tuning test or a stability
test which was run sometime in the past prior to the beginning of the onset
of the variability in Tx and with which you can compare a current
measurement.  See if you can get a level 7 service key and check out the
set of tests available for the body coil.

I guess I have to consider one possible way the head receive coil could be
responsible. When the body coil transmits the head coil has to be shut off
by detuning the receive elements. This is done by sending a DC pulse to
each coil. If something is messing up the connection between the coil and
the table like dirt on the connectors then it is possible the detuning is
not occurring reliably. If the coil is not detuned then the assessment of a
180 will be affected. So one other item to look at is the connector on the
table where the head coil plugs in and make sure it is clean and no pins
are bent.

 *[Steve]: Thank you for all those suggestions. I would agree that the TxRx
body coil is the likely culprit. With Chris's suggestions above, I am
hopeful I could work with the Siemens engineer to look more closely at the
Body coil tuning setup. *

>From : Bob

I would contact Siemens and have the engineer run his tests. Don’t assume
that he’ll run his test and say everything is fine. Let him run the tests.

 *[Steve]: **Bob, you make a good point -- I should proceed with service
and not assume they will run the bare minimum. Ideally, I should be present
for tests, as I can relay my concerns directly and advocate for some of
the tests suggested above. I hope my schedule will allow, as this system is
an hour's drive from the main campus.*

Again, thanks all for the help.

Best, Steve

Steven Shea, PhD
Associate Professor, MR Scientist
Department of Radiology & Medical Imaging. Loyola Medicine

On Mon, Oct 27, 2025 at 8:21 AM Bob Kobistek <bob at rjkmedphys.com> wrote:

> Hi Steve:
>
>
>
> I would contact Siemens and have the engineer run his tests. Don’t assume
> that he’ll run his test and say everything is fine. Let him run the tests.
>
>
>
>
>
> Robert J. Kobistek, MS, FACR, DABR, MRSE(MRSC™)
>
> Medical Physicist
>
> RJK Medical Physics, Inc.
>
> 440-463-7879
>
>
>
> *From:* Intl_dxmedphys_wd_osu_list
> <intl_dxmedphys_wd_osu_list-bounces+bob=rjkmedphys.com at lists.osu.edu> *On
> Behalf Of *Steven Shea via Intl_dxmedphys_wd_osu_list
> *Sent:* Friday, October 24, 2025 6:13 PM
> *To:* intl_dxmedphys_wd_osu_list at lists.osu.edu
> *Subject:* [Intl_DxMedPhys] Recent Tx Gain Variation on Siemens Sola 1.5T
> MRI
>
>
>
> Hi list friends, I am reaching out regarding recent findings in the ACR
> Weekly QA on a Siemens Magnetom Sola 1. 5T MRI system at our institution.
> The recorded Tx Gain (found as reference amplitude on the Siemens system)
> started varying by +/-
>
> Hi list friends,
>
>
>
> I am reaching out regarding recent findings in the ACR Weekly QA on a
> Siemens Magnetom Sola 1.5T MRI system at our institution. The recorded Tx
> Gain (found as reference amplitude on the Siemens system) started varying
> by +/- 30 V since ~July. Previously, it had been rather stable within a
> ~+/- 5 range (may be a little higher). The graph below demonstrates:
>
> I did annual testing in late August and did not identify any other issues
> with standard ACR phantom tests, homogeneity tests, or the head coil tests.
> I look for any service events that would explain this but could not find
> any. I decided not to flag it in my report and I waited a month or more to
> see if the variation would continue, which it has. I then went through the
> DICOM headers to see if any protocol parameters were changing. They were
> not; coil elements selected were also quite consistent (a potential issue
> on Siemens systems). I even managed to fish out the Reference Amplitude
> values from the Private Tag [0021, 1019]. They confirmed the same
> measurements that the technologist had been recording. I could even see
> that the reported Reference Amplitude was quite consistent between
> different sequences, which means that even if the tech recorded from
> different series, it would not have caused above:
>
>
>
> I should also state that the phantom setup procedure is quite repeatable
> due to the Siemens provided holder and one technologist is running the 90%
> of the QA. This is a long way of saying I have come to the conclusion that
> this is real. (And, yes, I likely over-analyzed the issue.)
>
>
>
> My main issue is concern on how I deal with Siemens service on this. If I
> send them above, I expect they will come out and run standard tests and
> tell me the system is fine. Have any of you ever run into this and know of
> causes? Or specific things to test/target? Anything else I or the tech
> could do? I would appreciate any insights.
>
>
>
> Thanks, Steve
>
>
>
> Steven Shea, PhD
>
> Associate Professor, MR Scientist
>
> Department of Radiology & Medical Imaging. Loyola Medicine
>
>
>
> PS: I should mention that the system has a known, slow helium leak which
> is captured on the center frequency measurements. However, that predates
> this issue and has been present for more than +1 year. (It is scheduled to
> finally be addressed in the next month -- needless to say that has me at
> odds with local service.) I do not feel as though this is the source.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.osu.edu/mailman/private/intl_dxmedphys_wd_osu_list/attachments/20251028/da8c02c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 61224 bytes
Desc: not available
URL: <https://lists.osu.edu/mailman/private/intl_dxmedphys_wd_osu_list/attachments/20251028/da8c02c6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 35568 bytes
Desc: not available
URL: <https://lists.osu.edu/mailman/private/intl_dxmedphys_wd_osu_list/attachments/20251028/da8c02c6/attachment-0001.png>