Hi Nikos Roughly speaking, the old atan demod, would load my cpu(3ghz core 2 duo) on approx 8.5%, with the new modulator the load would be ~5% There is a little penalty however, it seems that my demodulator is a little more noise sensitive, but it is not much. /Anders On 01/30/2014 11:09 AM, Nikos Balkanas wrote:

Hi Perhaps you can add a simple performance test to rtl_fm. "decoding 100000 samples takes xxx ms" or something like that. It helps to compare different CPU and OS families. On Thu, Jan 30, 2014 at 4:19 PM, keenerd <keenerd(a)gmail.com> wrote:

On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec(a)gmail.com> wrote: You can bring us some examples. Or write a guide. Especially with "time" command.

On Thu, Jan 30, 2014 at 6:13 PM, Alexandru Csete <oz9aec(a)gmail.com> wrote: Not the best way, unless you print #of packets processed and cpu is limiting. A better choice would be gprof (Linux). Nikos

Ah, I think I should be looking at the stddev which is telling me that the average deviation from the range was approx 3-4Khz...? From: n1gp(a)hotmail.com To: osmocom-sdr(a)lists.osmocom.org Subject: kalibrate-rtl results... Date: Thu, 30 Jan 2014 13:21:43 -0500 I'm attempting to calibrate my RTL dongles. I notice they are all about 2-4khz off if I compare against a known broadcast station's frequency. I am trying out kalibrate-rtl and am getting varied results. I am in the US, so I did a 'kal -s EGSM -g 20' and got the following: chan: 991 (928.4MHz + 26.986kHz) power: 448020.99 chan: 1002 (930.6MHz - 5.631kHz) power: 320357.07 chan: 1003 (930.8MHz + 16.192kHz) power: 109489.92 Then 'kal -c CHANNELNUM -g 20' for each channel number. I then get the results below which the average frequency error looks different for each channel. It is consistent though if I run them multiple times. I would have expected less frequency error since I know that it is really only about 4Khz off. Or am I not reading the results correctly? -Rick Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 991 (928.4MHz) average [min, max] (range, stddev) + 21.342kHz [17837, 27433] (9596, 3402.206299) overruns: 0 not found: 199 average absolute error: -22.988 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1002 (930.6MHz) average [min, max] (range, stddev) - 11.529kHz [-15293, -5679] (9614, 3640.780273) overruns: 0 not found: 194 average absolute error: 12.389 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1003 (930.8MHz) average [min, max] (range, stddev) + 14.283kHz [9462, 19098] (9636, 4777.044922) overruns: 0 not found: 126 average absolute error: -15.345 ppm

GSM does not hop around inside its channel, this is wrong, the frequency is +- some Hz accurate, at least in normal western European commercial GSM networks. Ralph. From: osmocom-sdr-bounces(a)lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Nikos Balkanas Sent: Thursday, January 30, 2014 7:35 PM To: Richard Koch Cc: osmocom-sdr(a)lists.osmocom.org Subject: Re: kalibrate-rtl results... On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp(a)hotmail.com> wrote: I'm attempting to calibrate my RTL dongles. I notice they are all about 2-4khz off if I compare against a known broadcast station's frequency. I am trying out kalibrate-rtl and am getting varied results. I am in the US, so I did a 'kal -s EGSM -g 20' and got the following: chan: 991 (928.4MHz + 26.986kHz) power: 448020.99 chan: 1002 (930.6MHz - 5.631kHz) power: 320357.07 chan: 1003 (930.8MHz + 16.192kHz) power: 109489.92 Then 'kal -c CHANNELNUM -g 20' for each channel number. I then get the results below which the average frequency error looks different for each channel. It is consistent though if I run them multiple times. I would have expected less frequency error since I know that it is really only about 4Khz off. Or am I not reading the results correctly? Results seem OK. Do not forget that most BSTs hop around in their allotted 20 Khz channel. So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against "anchor" BSTs that are steady. And yes, recommendation is to calibrate against 3 BSTs and correct for the average or stddev if you wish... Nikos -Rick Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 991 (928.4MHz) average [min, max] (range, stddev) + 21.342kHz [17837, 27433] (9596, 3402.206299) overruns: 0 not found: 199 average absolute error: -22.988 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1002 (930.6MHz) average [min, max] (range, stddev) - 11.529kHz [-15293, -5679] (9614, 3640.780273) overruns: 0 not found: 194 average absolute error: 12.389 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1003 (930.8MHz) average [min, max] (range, stddev) + 14.283kHz [9462, 19098] (9636, 4777.044922) overruns: 0 not found: 126 average absolute error: -15.345 ppm

Hi, GSM doesn't hope _inside_ a channel, it hops between channels. And the main channel "C0" that contains the FCCH bursts that kalibrate locks to, doesn't hop at all, it's required by spec to be a continuous carrier. OTOH, the OP said he was in the US and used EGSM band option ... huh ... I thought the US was GSM-800 ?!? Cheers, Sylvain

On Fri, Jan 31, 2014 at 07:38:57AM -0500, Richard Koch wrote: I am pretty sure what Sylvain meant is GSM850. That's the lower band that is used in the U.S, see [1]. Kind regards, -Alex [1] https://en.wikipedia.org/wiki/GSM_frequency_bands

I am sure, a BCCH is a BCCH, this does not hop at all, and the frequency hopping carriers do not hop some KHz, but in a sequence over a fixed scheme of normal ARFCNs. There is no free frequency choice in GSM, hopping or not. Ralph. From: Nikos Balkanas [mailto:nikos.balkanas@eyeonix.com] Sent: Friday, January 31, 2014 12:01 PM To: Ralph A. Schmid, dk5ras Cc: Richard Koch; osmocom-sdr(a)lists.osmocom.org Subject: Re: kalibrate-rtl results... On Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras <ralph(a)schmid.xxx> wrote: GSM does not hop around inside its channel, this is wrong, the frequency is +- some Hz accurate, at least in normal western European commercial GSM networks. Are you sure about that? Check it out: https://svn.berlin.ccc.de/projects/airprobe/wiki/A Legend of first picture. If still in doubt that *most" GSM carriers are hoppers, use rtl_power to scan your region ;-) Nikos Ralph. From: osmocom-sdr-bounces(a)lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Nikos Balkanas Sent: Thursday, January 30, 2014 7:35 PM To: Richard Koch Cc: osmocom-sdr(a)lists.osmocom.org Subject: Re: kalibrate-rtl results... On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp(a)hotmail.com> wrote: I'm attempting to calibrate my RTL dongles. I notice they are all about 2-4khz off if I compare against a known broadcast station's frequency. I am trying out kalibrate-rtl and am getting varied results. I am in the US, so I did a 'kal -s EGSM -g 20' and got the following: chan: 991 (928.4MHz + 26.986kHz) power: 448020.99 chan: 1002 (930.6MHz - 5.631kHz) power: 320357.07 chan: 1003 (930.8MHz + 16.192kHz) power: 109489.92 Then 'kal -c CHANNELNUM -g 20' for each channel number. I then get the results below which the average frequency error looks different for each channel. It is consistent though if I run them multiple times. I would have expected less frequency error since I know that it is really only about 4Khz off. Or am I not reading the results correctly? Results seem OK. Do not forget that most BSTs hop around in their allotted 20 Khz channel. So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against "anchor" BSTs that are steady. And yes, recommendation is to calibrate against 3 BSTs and correct for the average or stddev if you wish... Nikos -Rick Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 991 (928.4MHz) average [min, max] (range, stddev) + 21.342kHz [17837, 27433] (9596, 3402.206299) overruns: 0 not found: 199 average absolute error: -22.988 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1002 (930.6MHz) average [min, max] (range, stddev) - 11.529kHz [-15293, -5679] (9614, 3640.780273) overruns: 0 not found: 194 average absolute error: 12.389 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1003 (930.8MHz) average [min, max] (range, stddev) + 14.283kHz [9462, 19098] (9636, 4777.044922) overruns: 0 not found: 126 average absolute error: -15.345 ppm

On 1/30/14, keenerd <keenerd(a)gmail.com> wrote: I've cleaned it up and it is in my repo. You can enable it with "-A ale" https://github.com/keenerd/rtl-sdr/commit/025fb56dff98 Some quick benchmarks: std: 10% fast: 7% lut: 7% ale: 7% Sound quality is also noticably worse with ale, but that might be from an error in the fixed point conversion. How does the math look to you? -Kyle http://kmkeen.com

Hi Kyle I’ve looked at your commit. They way you are calculating the derivative of the sample may not actuate enough. I’m calculating the derivative as ds(n) = (s(n+1) - s(n-1))/2. Implementing a higher order derivative gives better sound, but eats the performance gain. I’ve also tried to make a integer only version of the demodulator, but the rounding errors makes it sound terrible. Strange enough it is also faster doing things partly in integer and partly in floats. I’v tried to profile the four methods in osx: atan Fast: 11.5%running time aran:lut 17.6% running time atan std: 49.6% running time aes: fm_demod2 22.9% running time The percentage given is time spend in fm_dmod relative to the rest of the program. /Anders Den 30/01/2014 kl. 16.35 skrev keenerd <keenerd(a)gmail.com>om>: