Energy indexing

[johnhcc]

First, thanks for making this amazing software available.

I have a question about the channel-to-energy conversion. In PolynomialEnergyCalibration.cs, we have this for a second degree polynomial:

this.coefficients[2] * Math.Pow(n, 2) + this.coefficients[1] * n + this.coefficients[0];

Do you consider the first channel to be n=0, or n=1?

Consider a Radiacode XML output file that has a well-defined peak in the n-th channel in the XML file. When I compare such a well-defined peak in the Radiacode app vs. BecqMoni, I suspect that:

• Radiacode calculates this energy as c*n**2 + d*n + e
• BecqMoni calculates this energy as c*(n-1)**2 + d*(n-1) + e

In other words, I suspect that BecqMoni considers the tenth channel to be n=9 (indexing 0..9), while Radiacode consider it to be n=10 (indexing 1..10).

For a typical set of coefficients (c, d, e), the difference in energy produced by these two calculations can be on the order of 2 to 4 keV. This is minor, but shifts the location of peaks when plotted against energy.

All this is to ask:

• Is there a standard way to do this, and does BecqMoni follow that standard? (or does Radiacode not follow that standard?)
• is there a way to accommodate these differences?

Thanks for considering this. As I said, it's minor, but if we can address this and eliminate a difference of a few keV, that's a win!

EDIT: Adding a demonstration plot below.

[Am6er]

A very interesting remark, thank you!
The problem is not as simple as it seems at first glance, and while I was looking at it, I did not find the right solution.
Running right to the end (spoiler alert), I'll say that it's not about channel numbering, and there's a lot of facts and factors to consider.

Just a little hint:
The same channel in RadiaCode applications (for Android, for Windows) has 3 different energies:

• at the beginning of the channel (and it corresponds to the classic version of "calculate according to the formula E(channel)"
• in the middle of the channel
• at the end of the channel

I have shown this on the pictures below.

Center (23 keV):

Left side (22 keV):

Right side (24 keV):

Now about the channel numbering.

Experiment number 1.
If we take the *.xml spectrum and open it in InterSpec, it will show that the first channel has energy according to calibration E(channel = 0). Although, it will display that this is the "1st channel". But, it's rather more for the human readable experience.

Experiment number 2.
If the same spectrum is opened in BecqMoni, it will display channel 0, and the corresponding energy, taking into account calibration E(channel = 0). It's not really a human readable experience, it's more of a mathematical rigor.

Experiment number 3.
We export the same spectrum to the N42 format in BecqMoni. You can then look at the internal structure of the file and see that the first entry corresponds to the first DataPoint entry in the xml version of this spectrum. We are trying to open the N42 file in InterSpec. The picture will be exactly the same as in experiment number 1.

Experiment number 4.
View this spectrum in the RadiaCode App by carefully moving the cursor from the beginning to the end of the same channel, as I wrote above. And you'll notice the difference. Initially, the xml format appeared in BecqMoni in 2012. But it is not a "standard" as such.

File to reproduce screenshots here:
Radium chk src 19.5 hr.xml

Now that this problem is more deeply visible, we need to think about what to do about it.

• If we do 0 -> 1 hard shift in BecqMoni, it will break integration with InterSpec (there will be a shift by 1 channel according to the data). All exports to files where calibration is present will break.
• You may need to select the channel more carefully in the RadiaCode App. Then there should be no shift. But how convenient is it? Perhaps it's a good idea to just ask the RadiaCode team what was the point of marking the same channel using different energies?

A difficult task. It was the 1st episode of this series. "To be continued..." :)

[johnhcc]

Great detective-work. It is indeed much more than a "0" or "1" issue, as I can see now.

Playing with InterSpec, the energy displayed for a given bin changes as I mouse across a bin from left to right, which is similar to what Radioacode does in their software (again, I'm just talking about display on the screen). But one of your main points, if I understand correctly, is that InterSpec calculates energy with a "base 0" system, and that energy corresponds to the left side of the bin.

I have no immediate answers to any of this either. But here are some thoughts:

• Definitely agree that a hard-shift is not the answer. Breaking compatibility with InterSpec would not be desirable.
• I have asked Radiacode support about this. They gave me a cursory "non-answer". But if I find out anything more I will let you know.

It is indeed an interesting problem! Feel free to bounce ideas off me, and I'll continue mulling this over. Looking forward to episode 2...

[Am6er]

By the way, yes, you're right!
I didn't immediately notice in InterSpec that moving the cursor along one channel changes the energy. Only unlike the RadiaCode App, there are not three points of energy change inside one channel, but some kind of linear function, most likely. Boundary conditions are set [E(channel); E(channel + 1)] and stitching takes place between them. A linear-piecewise function inside a channel, something like that.

I talked to Evgeny from the RadiaCode team yesterday. He gave a pretty simple answer, which is very obvious (it's just that when I asked him, I thought there was something else I hadn't anticipated):
From the ADC comes the discrete spectrum, because this is the fundamental principle of its operation.
But, the spectrum of energy itself is continuous. Therefore, there is such a thing as the energy width of a channel, and therefore, inside the channel, the energy varies from edge to edge. And ... That is all. There is nothing else. What else to do with that - nothing to do.

[Am6er]

Perhaps it was a preparation for changing the basis (channel mapping <-> energy mapping), where you can draw a variable channel width. Maybe so. I don't know that. And I don't know the meaning of such an operation either.