Official bladeRF forum

Evening,

I have some doubts over the accuracy of the kalibrate-bladeRF tool and wanted to see what the rest of you thought about it.

Here's the observation I've made. Using the factory calibrated value of the trimdac (0x8a11 in my case), I get the following results for a 900MHz and 1800MHz GSM carrier, averaged over 100 samples.

(I disabled the code that sets the trimdac in bladerf-kalibrate to see what the results were with arbitrary trimdacs).

ARFCN: 18: -490Hz
ARFCN: 862: -633Hz

The obvious question here is, for almost exactly double the frequency, the error is not doubled, or close to doubled within the theoretical margin of error kalibrate-bladeRF (GSMRATE * 4 / 1024/ 512 = ~2.1Hz).

The first hypothesis was the existence of a constant frequency offset (of approx 490-(633-490)=347Hz); but elementary mathematics with a second measurement set with a different trimdac show that any fixed offset is different between the two pairs of measurements.

for TRIMDAC 0xa1ea:

ARFCN: 18: -1832Hz
ARFCN: 862: -3946Hz

The fixed offset is clearly not the same in the above result.

Now, to put to rest any concerns, the ARFCNs chosen have no significant neighbour carriers (there is clear dominance), the SNR is very good, and dumping out the detected FCCH bursts confirmed the code is locking properly onto the FCCH - I see a clean sine wave plotted in Matlab. Plotting the FFTs in Matlab show a very dominant pulse at 70KHz as expected, and nothing else.

The bladerf was left to warm up and each measurement was taken in rapid succession.

So I have to put it down to one of the following:

1. frequency synthesizer error in LMS
2. some non linear mixing in the bladeRF somewhere.
3. Frequency error in the source
4. Issues with the measurement software (kalibrate-bladeRF)

Now given 1,2,3 are highly unlikely (and in fact 3 would show up as a constant offset, and thus is invalidated by taking pairs of measurements) we have to look at 4.

Is there any other cause I may have missed before looking into this issue?

There seems to be some evidence here for 4.



This shows frequency error vs TRIMDAC.

The first observation is that this is more than just random error, and there appears to be a periodic pattern.

The second observation is the GSM1800 is "varying" twice as quickly as GSM900 with respect to TRIMDAC value.

The third observation is that GSM1800 and GSM900 phase of variation is aligned (i.e. every GSM900 "vertical transition" is aligned with every second GSM1800 one).

The fourth observation is that the period with respect to frequency seems to be a multiple of approximately the FFT bin size (270833 * 4 / 1024 = ~1058Hz).

The fifth observation is that the long term 'average ratio' of the two series is approx 2:1, i.e. in line with the ratio of the frequencies (1875.2:938.6 ~ 2.00:1).

The hypothesis here is that the sub-FFT bin precision interpolation algorithm is not correct.

If we look at the peak_detect() code in fcch_detector.cc, the interpolation method called in interpolate_point() appears to use a sinc interpolation method as if one were to interpolate time domain samples in the time domain.

I do not believe this is mathematically correct in the frequency domain, at least where a rectangular window has been applied to the samples. I will have to look into this when I am feeling more refreshed. I was hoping there might be a DSP expert or two here who can confirm that off the bat.


The other hypothesis is that the VCTCXO response is not linear with respect to the DAC voltage applied to it, but I do not believe this is likely, although I am not an expert in VCTCXOs. Any hardware engineers here? Although, if this hypothesis was true, then we would expect to see GSM900 and GSM1800 "wobble" at the same rate with respect to the TRIMDAC voltage.


Maybe this isn't actually a problem it seems. It appears the accuracy of the measurements close to the "zero" crossing (or any multiple of the FFT bin size) are quite unstable it seems, and jump around all over the place. For example, based on the regression line shown in the graph, my optimal DAC value should be 33900 to 33948. However the actual DAC value converged upon is 33876 which is probably accurate enough for most needs. I'm still uneasy about the error in the measurements close to convergence, and I will keep looking into this.

This is great work.

I believe all the measurements I've done indicates that the trimdac is basically linear with frequency.

The GSM1800 having twice the slope as GSM900 sounds like it's just the relative frequencies are off by the same amount of PPM. If you switch your frequency offset to be PPM instead of absolute frequency error, do the slopes match up closer?

Overall, though, thanks for taking a real serious look at this! This is great stuff.

Brian

Another thing that I can say is that doing frequency correction from the frequency domain seems like it's a little bit too late. The energy will have already been spread to the other bins. For 900MHz, and a GSM station having 50ppb of accuracy, you'll need something like 45Hz per FFT bin you're looking at something like a 32768 length FFT.

Most of the frequency offset tracking algorithms I've seen are done in the time domain using a filtered version of the instantaneous frequency (dφ/dt). You can get to the phase domain pretty easily, then integrate over many samples then do the long term average (integrate and dump style filtering). I believe this is what the E4406A ends up doing to calculate frequency offset given a known sequence of bits - it calculates the overall integrated phase and compare at the end of the burst. The difference between the two is the frequency offset.

The other way to get better resolution would be to take the original 1024 samples, zero-extend the sample set and then take the FFT.

Just some more thoughts.

Brian

The current FFT uses 1024 points, but the problem is, at 4 samples/sec a burst comes out as about 148 * 4 = 592 samples.

The current code then zero extends this to 1024 points, which is the same as applying a rectangular frequency domain window function to a subset of a theoretical 1024-sample burst.

This is where the problem comes in I believe as the window function in the typical case is essentially an unusual fractional proportion of the FFT size (592 vs 1024). When the frequency is close to the center frequency (which is what we least desire) the effects of this are most pronounced. I believe the sinc interpolation algorithm assumes a rectangular window of 1024 points, and any shorter window distorts the results.

Here is a case showing the FFT of the burst when the tracked frequency is extremely close to a bin centre; despite this we see irregular energy contributions in neighbouring bins.



Now when truncating to a 512 point FFT, the same burst shows as:




As a result, there are three methods I've found which seem to improve the accuracy:

* (counter intuitively) Decrease FFT size to 512 points, so that most bursts at 4-samples/sec are fully captured. Loss of useful energy however. Also loss of P/M as the noise power is spread over few bins. Doesn't seem to consistently offer improvements.
* Increase samples/sec to GSM_RATE * 8 such as that a 1024 point FFT buffer is completely filled. Slower processing. Seems to consistently offer improvements, although early indications are that the tone detector is less reliable.
* I like this one - even though it doesn't fix the underlying problem, it works around it because the interpolation algorithm seems much more stable at 1/2 FFT bin offsets, multiply the original signal by half a bin frequency complex sinusoid, and that subtract that from the final result. The final result appears significantly more stable. The standard deviation on most of my measurements is down to about 3 (these results are very reproducible). Unfortunately, I don't fully trust it. If you look at the graphs above the stable region is very flat, and indeed large ranges of TRIMDAC value map to a narrow range of frequencies...

bpadalino wrote:Another thing that I can say is that doing frequency correction from the frequency domain seems like it's a little bit too late. The energy will have already been spread to the other bins. For 900MHz, and a GSM station having 50ppb of accuracy, you'll need something like 45Hz per FFT bin you're looking at something like a 32768 length FFT.

It is doing interpolation of the FFT, but in a way that may not be mathematically valid (they are interpolating assuming a time domain window of the FFT size, rather than a fraction thereof because at 4 samples/sec, a burst doesn't fill the FFT input.

I say may be mathematically invalid because I haven't proved anything on pen and paper, but my gut feeling is it's wrong. I was hoping a guru here might be able to shed some light on this.

Even if the interpolation method is valid, the way the interpolated peak is 'locked on to' (see peak_detect() ) seems to be unstable particularly when the frequency is close to a bin centre - which is a problem because this will be the case as we get successively close to zero offset.


Also, to get a 32768 length FFT, given that a burst is only about ~500 microseconds, you need to have a crazy high sampling rate like 60MHz (not possible with bladeRF) or start zero padding the FFT input samples, which seems to be causing a lot of problems as I've found.

Yeah, I would switch to trying a time domain algorithm. Once you're in the frequency domain, even if you truncate to 512 samples, if the frequency offset you have is sufficient enough to be between two of the bins, the power will leak everywhere and it will be difficult to get an actual and real estimate of your frequency offset.

It looks like you can identify the bursts well enough. Try something like this:
For C code, use atan2() to get the phase of the samples and then unwrap the phase manually.

If you try this, do you get better results - or at least more consistent ones?

Brian

bpadalino wrote:
If you try this, do you get better results - or at least more consistent ones?

Thankyou for your suggested algorithm, but alas, it is far more unstable than the FFT one.

I am sampling over 100 good samples (visually inspected in the time domain to ensure they are correctly detected bursts). The detected frequencies range from about -1kHz to +1kHz over the 100 bursts. Even doing stuff like removing the top and bottom X=[5,10]% of difference samples doesn't seem to make much difference as the distribution is quite uniform.

If I average these 100 frequencies I get close to the FFT frequency (-50Hz vs the known offset of +0Hz). The standard deviation is 500Hz.

So whilst this algorithm might do for some applications, for calibration purposes I'll pass this one by. Over the same 100 bursts the modified FFT algorithm gives me a consistent +19Hz with standard deviation of 1Hz which is good enough for my purposes.