Suggestion to Improve Span Measurements

I noted that, when entering a span in Spike, I get a different measurement when I actually put cursors on each end. See the attached image. The difference appears to be exactly one bin.
As I understand it, you’re using a set number of points based on the bin width. I have a span of 10 MHz and a RBW of 10 kHz with the Nuttall window. That means I would need a bin width of no more than (10000)/(2.02)=4950 Hz. Given that the bin width must be (80 MHz)/N, where N is a power of 2, the closest match would be N=16384 (2^14). (NOTE: If my calculations are correct, this means that you’re using 16160 points for the RBW, with the remainder of the time-record zero-padded to 16384.) This gives a bin width of (80 MHz)/(16384)=4882.8 Hz. The number of *points* (where a “point” is the center of a frequency bin) is calculated as span/(bin width), which in this case is (10 MHz)/(4882.8 Hz)= 2048. However, because of the fact that the span is essentially zero-indexed (the first point is essentially a bin value of 0), you wind up losing a half of a bin (only the upper half of that first bin on the left counts), while the last bin (all the way on the right) also loses the upper half of the bin (only the lower half counts). All told, you wind up losing a full bin.
I’d like to make two suggestions:
1) Add one more to the point count when calculating the number of points to display the span. In the case above, the point count should be 2049, not 2048.
2) Show the actual span, not the user-entered one, so that there’s no misunderstanding of the span being shown.
Thanks, and I do love Spike and my BB60C!

• This topic was modified 5 years, 4 months ago by Gary.