Is it right (wildly inconsistent results on different channels, e.g. -33.570 ppm vs 38.369 ppm)

[dragonyzl]

Dear Scateu: The result of kal for my hackrf like this:

~$ kal -s GSM900 -g 40 -a 1 -l 62 -g 40 
kal: Scanning for GSM-900 base stations.
GSM-900:
    chan: 9 (936.8MHz + 9.492kHz)   power: 4747328.95
    chan: 10 (937.0MHz + 33.101kHz) power: 4713891.86
    chan: 11 (937.2MHz + 27.741kHz) power: 4337386.69
    chan: 12 (937.4MHz - 34.957kHz) power: 4701652.01
    chan: 13 (937.6MHz + 5.849kHz)  power: 4921123.13
    chan: 14 (937.8MHz - 21.308kHz) power: 4489852.31
    chan: 15 (938.0MHz - 34.885kHz) power: 4948715.02
    chan: 19 (938.8MHz + 26.684kHz) power: 6055087.82
    chan: 20 (939.0MHz + 9.026kHz)  power: 5445623.90
    chan: 21 (939.2MHz - 18.874kHz) power: 5233643.37
    chan: 22 (939.4MHz - 24.310kHz) power: 5065278.10
    chan: 23 (939.6MHz - 23.830kHz) power: 4335606.89
    chan: 30 (941.0MHz + 10.342kHz) power: 4648356.57
    chan: 33 (941.6MHz + 38.018kHz) power: 4827731.90
    chan: 35 (942.0MHz - 22.521kHz) power: 5083162.67
    chan: 37 (942.4MHz - 26.626kHz) power: 4908658.42
    chan: 38 (942.6MHz + 33.284kHz) power: 5212849.03
    chan: 40 (943.0MHz + 31.026kHz) power: 5540634.65
    chan: 41 (943.2MHz + 6.383kHz)  power: 4640401.30
    chan: 42 (943.4MHz - 18.894kHz) power: 5560045.69
    chan: 43 (943.6MHz - 34.992kHz) power: 5796947.19
    chan: 83 (951.6MHz + 34.020kHz) power: 5017814.47
    chan: 86 (952.2MHz + 3.445kHz)  power: 4978590.71
    chan: 87 (952.4MHz - 20.500kHz) power: 4915357.25
    chan: 88 (952.6MHz - 38.684kHz) power: 5128484.07

$ kal -c 83 -g 40 -a 1 -l 62 -g 40 
kal: Calculating clock frequency offset.
Using GSM-900 channel 83 (951.6MHz)
average     [min, max]  (range, stddev)
+ 31.945kHz     [27474, 37282]  (9808, 2693.206787)
overruns: 0
not found: 2
average absolute error: -33.570 ppm

$ kal -c 43 -g 40 -a 1 -l 62 -g 40 
kal: Calculating clock frequency offset.
Using GSM-900 channel 43 (943.6MHz)
average     [min, max]  (range, stddev)
- 36.205kHz     [-39592, 2312]  (41904, 6233.333496)
overruns: 0
not found: 4
average absolute error: 38.369 ppm

I am confused about the result. -33.570 ppm and 38.369 ppm? For my dvb-t dongle, the result of kal-sdr is about -36 ppm for all channels.

Can you give some hints about it. Thank you!

[theforcedk]

Any news on this?

[rxseger]

I'm seeing similar results (one channel has positive error, another has negative), not sure what to make of it:

kalibrate-hackrf $ src/kal -s EGSM -g 40 -a 1 -l 62 -g 40  -D -v
kal: Scanning for E-GSM-900 base stations.
E-GSM-900: 
    chan: 22 (939.4MHz + 39.506kHz)     power: 479901.14
    chan: 23 (939.6MHz + 38.991kHz)     power: 552242.73
    chan: 124 (959.8MHz - 17.619kHz)    power: 462343.58
    chan: 975 (925.2MHz - 12.470kHz)    power: 456618.47
    chan: 978 (925.8MHz + 6.348kHz)     power: 253424.74
    chan: 993 (928.8MHz + 32.406kHz)    power: 788348.75
    chan: 995 (929.2MHz - 17.658kHz)    power: 853285.56        

kalibrate-hackrf $ src/kal -c 995
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 995 (929.2MHz)
average     [min, max]  (range, stddev)
- 17.188kHz     [-17642, -16452]    (1190, 414.669037)
overruns: 0
not found: 145
average absolute error: 18.498 ppm
kalibrate-hackrf $ src/kal -c 995
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 995 (929.2MHz)
average     [min, max]  (range, stddev)
- 17.197kHz     [-17650, -16460]    (1190, 437.720978)
overruns: 0
not found: 353
average absolute error: 18.507 ppm

kalibrate-hackrf $ src/kal -c 993
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 993 (928.8MHz)
average     [min, max]  (range, stddev)
+ 32.646kHz     [32334, 33467]  (1133, 359.282837)
overruns: 0
not found: 157
average absolute error: -35.148 ppm

This is with a HackRF One with firmware 2014.08.1 (stock firmware from the factory, old, will update). Any chance this could be related to https://github.com/scateu/kalibrate-hackrf/issues/2?

[rxseger]

Same with firmware 2015.07.2 https://github.com/scateu/kalibrate-hackrf/issues/2#issuecomment-224487715 - but to answer the original question, -33 ppm for one channel and +38 ppm for another doesn't make sense, something's wrong. According to the documentation, "GSM base stations are required to be accurate to within 0.05ppm"

The "not found" count is also suspect, though mine is much higher than @dragonyzl's. For comparison the original documentation shows:

jl@thinkfoo:~/src/kal-v0.4.1$ src/kal -c 145
kal: Calculating clock frequency offset.
Using GSM-850 channel 145 (872.6MHz)
average     [min, max]  (range, stddev)
-   1Hz     [-8, 7] (14, 3.948722)
overruns: 0
not found: 0

[giomasce]

+1, I have the same problem.

[nospam2000]

the same for me, using a rad1o hardware

[rct]

What I've found using kalibrate-rtl on RTL-SDR sticks that have fairly wide PPM errors is that once the device is warmed up and at a steady temperature, kalibrate can be used to get fine grained PPM error estimation, but you've got to narrow the range of the error first!

If the error is too large, kalibrate guesses the channel number incorrectly, which means it will give the wrong PPM correction.

When trying to determine the PPM error for a new device (non-TCXO) what I usually do is:

1. Let the device run for a while, usually at least 10 minutes, actively receiving something, not just plugged into USB so it will be at a normal operating temperature.
2. Use a waterfall or FFT plot with a commercial quality narrow band FM (NBFM, NFM) station on a known frequency. I'm in the US so I use NOAA weather radio, at least to start. Some of the major television broadcasters maintain analog FM frequencies for mobile crews in the 450 mhz range. These are usually maintained by professional broadcast engineers, so there shouldn't be a big error in the transmit frequency. Note: given that it is narrow banded FM, the channel spacing is fairly tight. Depending on the resolution and my patience I usually can eyeball the correct PPM error to around +/- 2.
3. Once I have an estimate of the error (and especially the direction), I then run kal supplying the guessed PPM correction from Step 2. I then get very stable results from kalibrate since it has eliminated the possibility of incorrectly guessing the wrong channel number.

Note: I'd guess the device kalibrate was originally written for used oscillator parts that had relatively small PPM errors compared to RTL-SDR or HackRF. I've seen it mentioned by Dominic Spill that the HackRF parts should be a tolerance of around 20 PPM. I'm not sure if that applies to all batches or versions of boards that are HackRF compatible. I see a +23 PPM error on my HackRF. I've seem 70+ on cheap RTL sticks.

I suppose it is possible that there is more information that could be pulled out of a GSM/LTE signal to know the absolute frequency. I'm guessing the correct information that is pulled out of the GSM signal currently is relative to the channel number which is why it can guess the wrong channel.

[Matioupi]

I'm having the exact same issue of ppm values that seems really out of specs, and widely changing from channel to channel (fw 2018.01.01)

[Schm1tz1]

Same observations here, even with TCXO installed. Is there any update on this issue?

[albertogonb]

I get the same behavior, variations between -35 and +38 Khz:

$ kal -s EGSM -l 40 -g 40
kal: Scanning for E-GSM-900 base stations.
E-GSM-900:
    chan:  103 (955.6MHz + 38.232kHz)   power: 3171605.17
    chan:  104 (955.8MHz + 9.988kHz)    power: 2877563.87
    chan:  105 (956.0MHz - 15.838kHz)   power: 3252816.50
    chan:  106 (956.2MHz - 35.671kHz)   power: 2097305.42
    chan:  117 (958.4MHz + 37.869kHz)   power: 3392056.30
    chan:  118 (958.6MHz + 26.028kHz)   power: 3075027.04
    chan:  119 (958.8MHz + 8.156kHz)    power: 3345089.27
    chan:  120 (959.0MHz - 11.466kHz)   power: 3525672.75
    chan:  121 (959.2MHz - 34.499kHz)   power: 3461628.61
    chan:  975 (925.2MHz - 34.221kHz)   power: 2161879.70
    chan:  990 (928.2MHz - 34.328kHz)   power: 3110094.20
    chan: 1002 (930.6MHz + 2.362kHz)    power: 5228492.68

[iliasam]

I found the solution. Current code contains a bug since 2014. Sample rate of SDR is set to 8MHz but all other code is expecting that sample rate is 1MHz: https://github.com/scateu/kalibrate-hackrf/blob/5d907327a490cc6b8ede7862d73c5e7394a5a253/src/usrp_source.cc#L235 https://github.com/scateu/kalibrate-hackrf/blob/5d907327a490cc6b8ede7862d73c5e7394a5a253/src/kal.cc#L117 Right sample rate for SDR is 1MHz. I made my own variant of this utility with this bug fixed, it will be good if someone can test it: https://github.com/iliasam/kalibrate-hackrf

[scateu]

@iliasam Thank you for the solution! And sorry for my lazy maintenance.

However I remember HackRF won't support sample rate lower than 8 MHz. Even if HackRF doesn't complain, some RF behavior may still be not right. In the datasheet of some chip in HackRF (don't remember which) you'll find the lowest sample rate support is 8 MHz.

Sometime you'll be lucky just because that batch of chip has manufacture margin that supports 1 Msps.

Another point is, back in 2013, I found this issue when transmitting a WBFM GNUradio graph to test TX performance of a batch of HackRF we homebrewed. Maybe low sample rate issue won't affect RX performance. So if works well in your case, please let me know, and I'll be honored to merge your patch.

Hope this helps.

Cheerio,

[iliasam]

@scateu You are right, that HackRF designers do not recommend to work below 8 MHz: https://hackrf.readthedocs.io/en/latest/sampling_rate.html But as I understand, original kalibrate utility was not designed for such high sample rate.

I tried to use "true" 8 MHz sample rate, but get "local overrun" error. After that I increased

define CB_LEN (36 * 16384)

"local overrun" error disappear after that, but signals are still not detected in this case. Maybe some other values in the code must be changed to support bigger sample rate. That is why I keep 1MHz sample rate, as it was in your commit e4014ec90f06b6057887e3e0a3abdcf6c14a342d

[uglurass]

just esc :)