Hi Volker,
Thanks for the images, I was able to reproduce what you are seeing.
It took me a minute to determine why this is happening and have determined the cause.
In the latest release, we have changed how we plot the limit line. The algorithm we use to test the limit is still the same but instead of plotting what we test against (the interpolated points) we plot the limit line as requested. Since your limit line includes a Spike between two output bins it gives the visual appearance of failing the limit line but in fact the testing is being done on adjacent interpolated bins. If you were to load this limit line into 3.1.11 you will notice the limit line being displayed will not actually come up to -60dBm as we plot only what is being tested against. In fact I included a screen shot of 3.1.11 with the same -60dBm peak being loaded into the limit line and you can see it gets rendered at ~-68dBm because that is the interpolated value that is being tested against. You can also see my input signal below -60dBm.
On review of this, I think we will need to go back to plotting the values tested against rather than the requested limit line.
In conclusion, my current understanding is that we have changed how we are plotting limit lines in the new version but the pass/fail message will match what you would see in the older version 3.1.11.
It might be more beneficial to create a box like limit line that has at least a width of 1 bin (RBW), and then sharply drops off, I think this will create the result you are looking for with more consistency. Currently with a very narrow spike, the high point can easily fall between two bins at which we can’t test at.
If you want to load an older version of the software you can find the link here.
productbundlesdemo.kinsta.cloud/sigdownloads/Spike/Spike(x64)_3111.zip
I will work on restoring the old way of plotting the limit line for the next release.
Let me know if you have follow up questions.
Regards,
Andrew
