Hi and thanks for a great tool set. I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous frequency demodulator, like the already implemented atan method, but it uses some math tricks to get rid of the the actual atan calculation. Feel free to use it if you wish Best regards Anders
Great! Performance is always welcome;-) Do you have any benchmarks? Nikos On Thu, Jan 30, 2014 at 11:19 AM, Anders Lynge Esbensen <anders@lyes.dk>wrote:
Hi and thanks for a great tool set.
I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous frequency demodulator, like the already implemented atan method, but it uses some math tricks to get rid of the the actual atan calculation. Feel free to use it if you wish
Best regards Anders
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:
Great! Performance is always welcome;-)
Do you have any benchmarks?
Nikos
On Thu, Jan 30, 2014 at 11:19 AM, Anders Lynge Esbensen <anders@lyes.dk <mailto:anders@lyes.dk>> wrote:
Hi and thanks for a great tool set.
I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous frequency demodulator, like the already implemented atan method, but it uses some math tricks to get rid of the the actual atan calculation. Feel free to use it if you wish
Best regards Anders
On 1/30/14, Anders Lynge Esbensen <anders@lyes.dk> wrote:
Hi and thanks for a great tool set.
I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous frequency demodulator, like the already implemented atan method, but it uses some math tricks to get rid of the the actual atan calculation. Feel free to use it if you wish
Nice, thank you. It should probably be under the -A option with all the other types of FM demodulator math. Maybe benchmark it against the other FM demodulators, "-A fast" or "-A lut". The default "-A std" was not designed to be very quick, just accurate. Being faster than "-A std" is not very difficult. Let me see if I can get a fixed-point version written. -Kyle http://kmkeen.com
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@gmail.com> wrote:
On 1/30/14, Anders Lynge Esbensen <anders@lyes.dk> wrote:
Hi and thanks for a great tool set.
I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous frequency demodulator, like the already implemented atan method, but it uses some math tricks to get rid of the the actual atan calculation. Feel free to use it if you wish
Nice, thank you.
It should probably be under the -A option with all the other types of FM demodulator math. Maybe benchmark it against the other FM demodulators, "-A fast" or "-A lut". The default "-A std" was not designed to be very quick, just accurate. Being faster than "-A std" is not very difficult.
Let me see if I can get a fixed-point version written.
-Kyle http://kmkeen.com
On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1@gmail.com> 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.
We can already do simple benchmarking using the "time" command, or more detailed measurements using the "perf" tool that comes with the linux kernel. Alex
On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec@gmail.com> wrote:
On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1@gmail.com> 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.
We can already do simple benchmarking using the "time" command, or more detailed measurements using the "perf" tool that comes with the linux kernel.
You can bring us some examples. Or write a guide. Especially with "time" command.
Alex
On Thu, Jan 30, 2014 at 4:51 PM, Sdr Guru <sdrguru1@gmail.com> wrote:
On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec@gmail.com> wrote:
On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1@gmail.com> 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.
We can already do simple benchmarking using the "time" command, or more detailed measurements using the "perf" tool that comes with the linux kernel.
You can bring us some examples. Or write a guide. Especially with "time" command.
In a terminal you type: time rtl_fm with the rtl_fm parameters you want to use. When you stop the program it will print out how much real time has passed and how much time was used by the application. See "man time" for options. Alex
On Thu, Jan 30, 2014 at 6:13 PM, Alexandru Csete <oz9aec@gmail.com> wrote:
On Thu, Jan 30, 2014 at 4:51 PM, Sdr Guru <sdrguru1@gmail.com> wrote:
On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec@gmail.com> wrote:
On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1@gmail.com> 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.
We can already do simple benchmarking using the "time" command, or more detailed measurements using the "perf" tool that comes with the linux kernel.
You can bring us some examples. Or write a guide. Especially with "time" command.
In a terminal you type:
time rtl_fm
with the rtl_fm parameters you want to use. When you stop the program it will print out how much real time has passed and how much time was used by the application. See "man time" for options.
Not the best way, unless you print #of packets processed and cpu is limiting. A better choice would be gprof (Linux). Nikos
Alex
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
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@hotmail.com To: osmocom-sdr@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
On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp@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
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@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@lists.osmocom.org Subject: Re: kalibrate-rtl results... On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp@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 Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras <ralph@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@lists.osmocom.org [mailto: osmocom-sdr-bounces@lists.osmocom.org] *On Behalf Of *Nikos Balkanas *Sen**t:* Thursday, January 30, 2014 7:35 PM *To:* Richard Koch *Cc:* osmocom-sdr@lists.osmocom.org *Subject:* Re: kalibrate-rtl results...
On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp@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 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 ;-)
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
There is no GSM-800 option in kalibrate-rtl unless it goes by another name. I'm not that familiar with this technology. " -s band to scan (GSM850, GSM-R, GSM900, EGSM, DCS, PCS)" I tried all the options several times and the only hits I got were using EGSM.
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:
OTOH, the OP said he was in the US and used EGSM band option ... huh ... I thought the US was GSM-800 ?!?
There is no GSM-800 option in kalibrate-rtl unless it goes by another name. I'm not that familiar with this technology.
"-s band to scan (GSM850, GSM-R, GSM900, EGSM, DCS, PCS)"
I tried all the options several times and the only hits I got were using EGSM.
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
Hi,
I am pretty sure what Sylvain meant is GSM850. That's the lower band that is used in the U.S, see [1].
Here a very nice site regarding mobile phone bands: http://niviuk.free.fr/
Kind regards, -Alex
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@lists.osmocom.org Subject: Re: kalibrate-rtl results... On Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras <ralph@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@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@lists.osmocom.org Subject: Re: kalibrate-rtl results... On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp@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 Thu, Jan 30, 2014 at 5:43 PM, Nikos Balkanas <nikos.balkanas@eyeonix.com> wrote:
On Thu, Jan 30, 2014 at 6:13 PM, Alexandru Csete <oz9aec@gmail.com> wrote:
In a terminal you type:
time rtl_fm
with the rtl_fm parameters you want to use. When you stop the program it will print out how much real time has passed and how much time was used by the application. See "man time" for options.
Not the best way, unless you print #of packets processed and cpu is limiting. A better choice would be gprof (Linux).
The time command prints how much time was required by the application. If you divide that with the elapsed time you have the CPU load of the application. The number of packets is irrelevant and the cpu must not be limiting; if it is the application will not run in real time and the measurement will be incorrect. Alex
On 1/30/14, keenerd <keenerd@gmail.com> wrote:
On 1/30/14, Anders Lynge Esbensen <anders@lyes.dk> wrote:
I've implemented a faster FM demodulator for rlt_fm.
Let me see if I can get a fixed-point version written.
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
On Thu, Jan 30, 2014 at 5:35 PM, keenerd <keenerd@gmail.com> wrote:
On 1/30/14, keenerd <keenerd@gmail.com> wrote:
On 1/30/14, Anders Lynge Esbensen <anders@lyes.dk> wrote:
I've implemented a faster FM demodulator for rlt_fm.
Let me see if I can get a fixed-point version written.
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?
I have also be playing around with the atan demodulators. gnuradio uses fast-atan tables instead of the libC version. I dunno how libc implements it, but they could be worth considering... Nikos
-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@gmail.com>:
On 1/30/14, keenerd <keenerd@gmail.com> wrote:
On 1/30/14, Anders Lynge Esbensen <anders@lyes.dk> wrote:
I've implemented a faster FM demodulator for rlt_fm.
Let me see if I can get a fixed-point version written.
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
participants (10)
-
Alexander Huemer -
Alexandru Csete -
Anders Esbensen -
Anders Lynge Esbensen
-
keenerd -
Nikos Balkanas -
Ralph A. Schmid, dk5ras -
Richard Koch -
Sdr Guru -
Sylvain Munaut