osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
912 discussions

RE: kalibrate-rtl results...
by Jiao Xianjun 31 Jan '14

31 Jan '14

Though GSM spec has frequency hopping option, it can be switched on or off by operator. Yes, most operator switch it on. I think You too are talking different thing. GSM doesn't hops inside each 200khz channel. It hops among multiple 200khz channel. There is an exception: The downlink broadcasting carrier which carries FCCH SCH BCCH etc doesn't hop, and accordingly uplink RACH carrier doesn't hop either. These two uplink and downlink carrier frequency have a fixed 45MHz spacing if I recall correctly. I think most of calibration programs use downlink broadcasting carrier to calibrate the dongle, because it doesn't hop and is easy to be captured. You may also try my matlab calibration tool: https://github.com/JiaoXianjun/multi-rtl-sdr-calibration -----Original Message----- From: "Nikos Balkanas" <nikos.balkanas(a)eyeonix.com> Sent: ‎2014/‎1/‎31 19:13 To: "Ralph A. Schmid, dk5ras" <ralph(a)schmid.xxx> Cc: "osmocom-sdr(a)lists.osmocom.org" <osmocom-sdr(a)lists.osmocom.org>; "Richard Koch" <n1gp(a)hotmail.com> 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

1 0

RE: How to get IQ samples from multiple rtl-sdr dongles inasynchronized manner?
by Jiao Xianjun 31 Jan '14

31 Jan '14

while, I can try it, and let's see. Actually, maybe I will turn it to C some time in the future. -----Original Message----- From: "Ron Senykoff" <rsenykoff(a)gmail.com> Sent: ‎2014/‎1/‎30 23:04 To: "Jiao Xianjun" <putaoshu(a)gmail.com> Cc: "jdow" <jdow(a)earthlink.net>; "osmocom-sdr(a)lists.osmocom.org" <osmocom-sdr(a)lists.osmocom.org> Subject: Re: How to get IQ samples from multiple rtl-sdr dongles inasynchronized manner? Hi Jiao, Thanks for your work on this. I'm curious if Octave could be used for some of this. -Ron / KB1UMH On Wed, Jan 29, 2014 at 10:14 PM, Jiao Xianjun <putaoshu(a)gmail.com> wrote: > Hi everybody, > > Let me report current progress of this thread. > > Now my matlab program can detect and correct sampling and carrier (both > phase and frequency) error for dongles, and show the sampling phase > difference between two dongles (at 8X oversampling rate) after correction. > > You can try it by yourself here : > https://github.com/JiaoXianjun/multi-rtl-sdr-calibration > > Some runs results have also been attached here. (time location of FCCH SCH > and BCCH have also been shown there in different color) > > In the attached pictures, you may find that from the GSM frame point of view > those FCCH, SCH and BCCH from two dongles seem almost in the same time > location. (this needs to be verified further by check/demodulate information > carried in SCH and BCCH, which is still under development). But if we > inspect the time location in a 8X oversampling scale (zoom-in), there is a > fixed sampling phase difference between two dongles (after correction > respectively). > > Unfortunately, this fixed sampling phase difference may vary from run to run > (one rum means we restart rtl_tcp). > Fortunately, it remains fixed in a single run. This offers us a opportunity > to track continuous input I&Q (don't re-run rtl_tcp!) from multiple dongles, > and needn't worry about phase/sampling jumping/discontinuous things. > > Why do carrier and sampling error estimation and correction respectively? > Inspired by James Peroulas james(a)peroulas.com (author of Lte-Cell-Scanner), > for example, when there is a non-coherent up/down-converter used outside > dongle (like MMDS LNB used by Omri Iluz omri(a)iluz.net to detect 2.4GHz band > signal), there won't be strict relationship between sampling error (which is > in baseband) and carrier error (which may be located in inside dongle or > outside dongle mixer). > > But for my in-hands dongles, sampling error and carrier seems have > relationship. This may be because they have common clock source inside > dongle. > > Which I detected by my matlab program gsm_sync_demod.m: > dongle 1: sampling PPM 27.1739, carrier PPM -28.513 > dongle 2: sampling PPM 116.3043, carrier PPM -118.4247 > > In my program a positive sampling PPM means sampling clock is slower than > standard/ideal source (in our case, this source is GSM base-station). If LO > of mixer uses the same clock as sampling, that may cause a lower LO in > mixer/down-converter. I guess the LO frequency of mixer in dongle is higher > than input antenna RF frequency, which means for mixer: output = LO - input. > Thus a lower LO generates a lower input into baseband, that's why I get a > negative carrier PPM (negative carrier PPM means detected carrier frequency > is lower than standard/ideal source). > I don't know if my guess is correct. Anyone is familiar with the hardware > architecture of the 820t dongle? > > BR > > Jiao Xianjun > > > > > On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow(a)earthlink.net> wrote: >> >> The last I looked rtl_tcp did not allow full control over the dongle. But, >> then, to do what I really want has required bypassing rtlsdr to go >> directly to the usb library so I can access the underlying USB system >> directly for a specific feature. (A feed through feature in rtlsdr's >> shared library would be nice when trying to nail down the dongle's >> identity for restoring context on program startup.) >> >> (Building an SDR program without multi-threading is rather like trying >> to build a bicycle without chains or cables. It can be done. But it's >> a pathetic tool when you get done with it. Erm, but I do note gear >> driven bikes need less maintenance under adverse conditions. Been there >> done that - MANY decades ago.) >> >> {^_^} Joanne/W6MKU >> >> >> On 2014/01/07 23:32, Jiao Xianjun wrote: >>> >>> Good idea. >>> >>> Thanks for your advice! >>> >>> But that seems we will do some repeating works. >>> >>> rtl_tcp already use mutiple buffers and multi-threading. So why not use >>> it >>> directly as a reliable relay. >>> >>> >>> On Tue, Jan 7, 2014 at 1:51 AM, jdow <jdow(a)earthlink.net >>> <mailto:jdow@earthlink.net>> wrote: >>> >>> Have you tried using ping-pong buffers? Process on one buffer and >>> receive >>> to another. You may have to use multi-threading to make this work >>> nicely. >>> >>> {^_^} Joanne/W6MKU >>> >>> >>> >>> On 2014/01/06 01:34, Jiao Xianjun wrote: >>> >>> Hi, >>> >>> Today I did some experiments using CW signal which is generated >>> by signal >>> generator. The conclusion is a little bit sad. >>> >>> sync read and UDP lose samples/data high probably: >>> 1. If there are some other operations (which costs some time) >>> between two >>> successive sync reads, some samples will be lost. >>> 2. Some times, UDP packets are just lost. >>> >>> So, seems that I have two choices: >>> 1. struggle to use async read mode. >>> 2. use rtl_tcp utility directly, which is offered with rtl-sdr >>> code. This >>> program use async mode and TCP, which has avoided the two >>> shortcomings I >>> addressed. >>> >>> I will try the 2nd method, and try to move on with calibration. >>> >>> BR >>> >>> Jiao Xianjun >>> >>> >>> >>> On Sat, Jan 4, 2014 at 8:34 PM, Jiao Xianjun <putaoshu(a)gmail.com >>> <mailto:putaoshu@gmail.com> >>> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> wrote: >>> >>> Hi, >>> >>> I have questions on usage of rtlsdr_read_sync(dev, buffer, >>> out_block_size, >>> &n_read): >>> >>> For example, if sampling rate is 1Msps, and out_block_size >>> is 1000000, >>> question is: >>> >>> 1. the rtlsdr_read_sync() will cost 1s exactly? Or is there >>> any >>> lower level >>> device/driver buffer, which perhaps feed rtlsdr_read_sync() >>> with >>> history >>> data quickly and makes rtlsdr_read_sync() return in a time >>> shorter >>> than 1s? >>> >>> 2. in this infinite processing loop: >>> while(1) >>> { >>> rtlsdr_read_sync(dev, buffer, out_block_size, &n_read); >>> processing_function(buffer); // let's assume that this cost >>> 0.001s >>> } >>> Those samples during the 0.001s processing period will be >>> losted or >>> not? Is >>> there any method to not lost them? >>> >>> Thanks very much! >>> >>> BR >>> >>> Jiao Xianjun >>> >>> >>> >>> On Thu, Jan 2, 2014 at 9:25 PM, Jiao Xianjun >>> <putaoshu(a)gmail.com >>> <mailto:putaoshu@gmail.com> >>> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> >>> wrote: >>> >>> I see some UDP packet performance issues in my laptop >>> (but not >>> in my >>> desktop computer). Will the common (interleave multiple >>> receives) UDP >>> link helps? >>> >>> The issue is that fread for the second dongle in matlab >>> get >>> less data >>> than expectation sometimes. Seem that fread for the >>> first >>> dongle works well. >>> >>> >>> ------------------------------__------------------------------__-------------------- >>> >>> From: Sdr Guru <mailto:sdrguru1@gmail.com >>> <mailto:sdrguru1@gmail.com>> >>> >>> Sent: 2014/1/2 5:39 >>> >>> To: osmocom-sdr(a)lists.osmocom.org >>> <mailto:osmocom-sdr@lists.osmocom.org> >>> <mailto:osmocom-sdr@lists.__osmocom.org >>> >>> <mailto:osmocom-sdr@lists.osmocom.org>> >>> >>> >>> Subject: Re: How to get IQ samples from multiple rtl-sdr >>> dongles in >>> asynchronized manner? >>> >>> Hi >>> >>> rtl-sdr-relay >>> Some of the recommendations. >>> Please add PPM error calculation, exactly like new >>> rtl_test -p >>> but multiple receivers simultaneously. >>> It provides immediate information if something is wrong >>> with >>> USB or dongles. >>> >>> https://github.com/keenerd/__rtl-sdr/commit/__b5f89dcf40463130e717b6c9bb3a3… >>> >>> <https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c…> >>> https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c >>> >>> <https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c> >>> >>> Please add automatic eeprom PPM calibration >>> >>> https://github.com/keenerd/__rtl-sdr/commit/__ecf267737ca52f5005b7a12a35230… >>> >>> >>> <https://github.com/keenerd/rtl-sdr/commit/ecf267737ca52f5005b7a12a352307e8c…> >>> >>> default sample rate 2.4M (28.8/12) or 1.2M (28.8/24), >>> probably >>> lower jitter >>> MAX_NUM_DEV 4->16 :) >>> >>> Some nice to have features. >>> ip binding >>> multicast support >>> one common (interleaved) stream of all the receivers >>> timestamped stream >>> >>> I'm trying to convert MATLAB script to Ocatve. >>> >>> SG >>> >>> On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun >>> <putaoshu(a)gmail.com <mailto:putaoshu@gmail.com> >>> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> >>> wrote: >>> >>> Hi guys, >>> >>> For the multiple dongles synchronization in signal >>> level >>> instead of >>> bits/packets level, I setup a working repo in >>> github, and >>> write a >>> initial demo framework. See below: >>> >>> https://github.com/__JiaoXianjun/multi-rtl-sdr-udp-__relay.git >>> >>> <https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git> >>> >>> You may find information and instruction of demo >>> quickly by >>> reading >>> the README. >>> >>> My initial purpose is performing in-fly calibration >>> for >>> multiple >>> dongles according to some pre-known signal (GSM, >>> ADS-B?) to >>> let them >>> work together coherently. >>> >>> An ideal scheme may be that we should generate a >>> very >>> narrow band >>> and very week signal in (or just located at the edge >>> of) target >>> working band of dongles, and perform the software >>> in-fly >>> calibration >>> in background (or driver level). This would be user >>> friendly. >>> >>> I know it is far from final state currently, and >>> many >>> things are not >>> clear yet (See TODO). But please join me if you also >>> think >>> this is a >>> good idea. Just check out the demo and run it to >>> have a look. >>> >>> Currently I just test the demo in Ubuntu-Linux. >>> >>> BR >>> >>> Jiao Xianjun > >

1 0

rtl_fm.c & fast_atan2
by Nikos Balkanas 31 Jan '14

31 Jan '14

Is this correct? if (x >= 0) { >.......angle = pi4 - pi4 * (x-yabs) / (x+yabs); } else { .......angle = pi34 - pi4 * (x+yabs) / (yabs-x); } Shouldn't it be: if (x >= 0) { >.......angle = pi34 - pi4 * (x-yabs) / (x+yabs); } else { .......angle = pi34 - pi4 * (x+yabs) / (yabs-x); } TIA, Nikos

1 0

Re: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner?
by Jiao Xianjun 31 Jan '14

31 Jan '14

Hi everybody, Let me report current progress of this thread. Now my matlab program can detect and correct sampling and carrier (both phase and frequency) error for dongles, and show the sampling phase difference between two dongles (at 8X oversampling rate) after correction. You can try it by yourself here : https://github.com/JiaoXianjun/multi-rtl-sdr-calibration Some runs results have also been attached here. (time location of FCCH SCH and BCCH have also been shown there in different color) In the attached pictures, you may find that from the GSM frame point of view those FCCH, SCH and BCCH from two dongles seem almost in the same time location. (this needs to be verified further by check/demodulate information carried in SCH and BCCH, which is still under development). But if we inspect the time location in a 8X oversampling scale (zoom-in), there is a fixed sampling phase difference between two dongles (after correction respectively). Unfortunately, this fixed sampling phase difference may vary from run to run (one rum means we restart rtl_tcp). Fortunately, it remains fixed in a single run. This offers us a opportunity to track continuous input I&Q (don't re-run rtl_tcp!) from multiple dongles, and needn't worry about phase/sampling jumping/discontinuous things. Why do carrier and sampling error estimation and correction respectively? Inspired by James Peroulas james(a)peroulas.com (author of Lte-Cell-Scanner), for example, when there is a non-coherent up/down-converter used outside dongle (like MMDS LNB used by Omri Iluz omri(a)iluz.net to detect 2.4GHz band signal), there won't be strict relationship between sampling error (which is in baseband) and carrier error (which may be located in inside dongle or outside dongle mixer). But for my in-hands dongles, sampling error and carrier seems have relationship. This may be because they have common clock source inside dongle. Which I detected by my matlab program gsm_sync_demod.m: dongle 1: sampling PPM 27.1739, carrier PPM -28.513 dongle 2: sampling PPM 116.3043, carrier PPM -118.4247 In my program a positive sampling PPM means sampling clock is slower than standard/ideal source (in our case, this source is GSM base-station). If LO of mixer uses the same clock as sampling, that may cause a lower LO in mixer/down-converter. I guess the LO frequency of mixer in dongle is higher than input antenna RF frequency, which means for mixer: output = LO - input. Thus a lower LO generates a lower input into baseband, that's why I get a negative carrier PPM (negative carrier PPM means detected carrier frequency is lower than standard/ideal source). I don't know if my guess is correct. Anyone is familiar with the hardware architecture of the 820t dongle? BR Jiao Xianjun On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow(a)earthlink.net> wrote: > The last I looked rtl_tcp did not allow full control over the dongle. But, > then, to do what I really want has required bypassing rtlsdr to go > directly to the usb library so I can access the underlying USB system > directly for a specific feature. (A feed through feature in rtlsdr's > shared library would be nice when trying to nail down the dongle's > identity for restoring context on program startup.) > > (Building an SDR program without multi-threading is rather like trying > to build a bicycle without chains or cables. It can be done. But it's > a pathetic tool when you get done with it. Erm, but I do note gear > driven bikes need less maintenance under adverse conditions. Been there > done that - MANY decades ago.) > > {^_^} Joanne/W6MKU > > > On 2014/01/07 23:32, Jiao Xianjun wrote: > >> Good idea. >> >> Thanks for your advice! >> >> But that seems we will do some repeating works. >> >> rtl_tcp already use mutiple buffers and multi-threading. So why not use it >> directly as a reliable relay. >> >> >> On Tue, Jan 7, 2014 at 1:51 AM, jdow <jdow(a)earthlink.net >> <mailto:jdow@earthlink.net>> wrote: >> >> Have you tried using ping-pong buffers? Process on one buffer and >> receive >> to another. You may have to use multi-threading to make this work >> nicely. >> >> {^_^} Joanne/W6MKU >> >> >> On 2014/01/06 01:34, Jiao Xianjun wrote: >> >> Hi, >> >> Today I did some experiments using CW signal which is generated >> by signal >> generator. The conclusion is a little bit sad. >> >> sync read and UDP lose samples/data high probably: >> 1. If there are some other operations (which costs some time) >> between two >> successive sync reads, some samples will be lost. >> 2. Some times, UDP packets are just lost. >> >> So, seems that I have two choices: >> 1. struggle to use async read mode. >> 2. use rtl_tcp utility directly, which is offered with rtl-sdr >> code. This >> program use async mode and TCP, which has avoided the two >> shortcomings I >> addressed. >> >> I will try the 2nd method, and try to move on with calibration. >> >> BR >> >> Jiao Xianjun >> >> >> >> On Sat, Jan 4, 2014 at 8:34 PM, Jiao Xianjun <putaoshu(a)gmail.com >> <mailto:putaoshu@gmail.com> >> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> wrote: >> >> Hi, >> >> I have questions on usage of rtlsdr_read_sync(dev, buffer, >> out_block_size, >> &n_read): >> >> For example, if sampling rate is 1Msps, and out_block_size >> is 1000000, >> question is: >> >> 1. the rtlsdr_read_sync() will cost 1s exactly? Or is there >> any >> lower level >> device/driver buffer, which perhaps feed rtlsdr_read_sync() >> with >> history >> data quickly and makes rtlsdr_read_sync() return in a time >> shorter >> than 1s? >> >> 2. in this infinite processing loop: >> while(1) >> { >> rtlsdr_read_sync(dev, buffer, out_block_size, &n_read); >> processing_function(buffer); // let's assume that this cost >> 0.001s >> } >> Those samples during the 0.001s processing period will be >> losted or >> not? Is >> there any method to not lost them? >> >> Thanks very much! >> >> BR >> >> Jiao Xianjun >> >> >> >> On Thu, Jan 2, 2014 at 9:25 PM, Jiao Xianjun < >> putaoshu(a)gmail.com >> <mailto:putaoshu@gmail.com> >> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> >> wrote: >> >> I see some UDP packet performance issues in my laptop >> (but not >> in my >> desktop computer). Will the common (interleave multiple >> receives) UDP >> link helps? >> >> The issue is that fread for the second dongle in matlab >> get >> less data >> than expectation sometimes. Seem that fread for the first >> dongle works well. >> >> ------------------------------__---------------------------- >> --__-------------------- >> >> From: Sdr Guru <mailto:sdrguru1@gmail.com >> <mailto:sdrguru1@gmail.com>> >> Sent: 2014/1/2 5:39 >> >> To: osmocom-sdr(a)lists.osmocom.org >> <mailto:osmocom-sdr@lists.osmocom.org> >> <mailto:osmocom-sdr@lists.__osmocom.org >> >> <mailto:osmocom-sdr@lists.osmocom.org>> >> >> Subject: Re: How to get IQ samples from multiple rtl-sdr >> dongles in >> asynchronized manner? >> >> Hi >> >> rtl-sdr-relay >> Some of the recommendations. >> Please add PPM error calculation, exactly like new >> rtl_test -p >> but multiple receivers simultaneously. >> It provides immediate information if something is wrong >> with >> USB or dongles. >> https://github.com/keenerd/__rtl-sdr/commit/__ >> b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f >> <https://github.com/keenerd/rtl-sdr/commit/ >> b5f89dcf40463130e717b6c9bb3a39a3c8b9535f> >> https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c >> >> <https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c> >> >> Please add automatic eeprom PPM calibration >> https://github.com/keenerd/__rtl-sdr/commit/__ >> ecf267737ca52f5005b7a12a352307__e8cd763ed6 >> >> <https://github.com/keenerd/rtl-sdr/commit/ >> ecf267737ca52f5005b7a12a352307e8cd763ed6> >> >> default sample rate 2.4M (28.8/12) or 1.2M (28.8/24), >> probably >> lower jitter >> MAX_NUM_DEV 4->16 :) >> >> Some nice to have features. >> ip binding >> multicast support >> one common (interleaved) stream of all the receivers >> timestamped stream >> >> I'm trying to convert MATLAB script to Ocatve. >> >> SG >> >> On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun >> <putaoshu(a)gmail.com <mailto:putaoshu@gmail.com> >> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> >> wrote: >> >> Hi guys, >> >> For the multiple dongles synchronization in signal >> level >> instead of >> bits/packets level, I setup a working repo in >> github, and >> write a >> initial demo framework. See below: >> >> https://github.com/__JiaoXianjun/multi-rtl-sdr-udp-__relay.git >> >> <https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git> >> >> You may find information and instruction of demo >> quickly by >> reading >> the README. >> >> My initial purpose is performing in-fly calibration >> for >> multiple >> dongles according to some pre-known signal (GSM, >> ADS-B?) to >> let them >> work together coherently. >> >> An ideal scheme may be that we should generate a very >> narrow band >> and very week signal in (or just located at the edge >> of) target >> working band of dongles, and perform the software >> in-fly >> calibration >> in background (or driver level). This would be user >> friendly. >> >> I know it is far from final state currently, and many >> things are not >> clear yet (See TODO). But please join me if you also >> think >> this is a >> good idea. Just check out the demo and run it to >> have a look. >> >> Currently I just test the demo in Ubuntu-Linux. >> >> BR >> >> Jiao Xianjun >> >

2 1

FW: Incorrect samplerate from RTL-SDR
by Richard Koch 30 Jan '14

30 Jan '14

JP, Thanks for your reply and explanation. I understand the cutting the coefficient table in half since it repeats in a backwards manner, but what I don't understand is why half the table is in 8 bit and the other in 12 bit? Also I now understand that there is not enough room for extra coefficients in the rtl2832 for lower bandwidth than 2048Khz. That is unfortunate if you want lower bandwidth as it forces you to sample at 2048 or greater and perform your own FIR and decimation consuming CPU cycles on your host. On an armv4 SBC that is very taxing :^) -Rick > Date: Fri, 10 Jan 2014 01:50:51 +0100 > From: j-pi(a)seznam.cz > To: n1gp(a)hotmail.com; osmocom-sdr(a)lists.osmocom.org > Subject: Re: Incorrect samplerate from RTL-SDR > CC: steve(a)steve-m.de > > You cannot fit internal FIR filter in SDR to such narrow bandwidth, it > does not have enough coefficients. > You can adapt it only to wider band width (some small improvement can be > done for > sample rates above 2048 kHz). Select proper values is a bit tricky and > specialised software > is almost unavoidable. You can get good hint from FIR filter designer in > GNU Radio, but > this software is not designed for this task and the work is cumbersome. > > The 8 / 12 bit means the coefficients can be only in range form -128 to > 127 / -2048 to 2047. > The usual FIR coefficients absolute value decreases from center to the > side eg: > > 1, -3, 5, 10, 5, -3, 1, > > so this just reduces complexity of the device. > > For lower bandwidth you need more cofficients (more samples because the > wave is wider). > > JP > > > Dne 9.1.2014 23:53, Richard Koch napsal(a): > > Hi Steve, > > > > In regards to your post about the anti-aliasing filter > > you referred to, it appears that it is getting set in > > librtlsdr.c, rtlsdr_init_baseband() > > > > If one wanted to change that to optimize the anti-aliasing > > to a lower bandwidth, say 1500 Khz instead of the 2048 Khz > > > > How would you change the fir_coeff[] table entries to achieve > > this? The 8 bit entries and 12 bit entries are confusing to me. > > > > > > ==== orig post ==== > > > >> I have seen other reports on the mailing list, saying that sample rates > >> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL > >> devices, then maybe it should be documented and the library can return > >> an error code for such sample rates. Otherwise people will keep walking > >> into this trap. > > We could return some sort of error in those cases, but such low rates > > (< 1MS/s) aren't recommended in general. First of all, the > > anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and > > although the coefficients can be changed, I doubt you can get a nice > > filter for lower bandwidths with such a low order. And then the ADCs > > only have 8 bits resolution, so you want to improve that by decimating, > > and also profit from decimation gain. > > Even Realtek uses 2.048 MS/s for FM reception in their original Windows > > software. > >

8 10

rtl_power sine_tbl
by Nikos Balkanas 29 Jan '14

29 Jan '14

What is the purpose of the sine wave added to the spectrum by rtl_power? Clouds all spectrum :-( TIA, Nikos

1 0

[ rtl-sdr / rtl_fm to decode NRF905 frames ]
by lementec fabien 29 Jan '14

29 Jan '14

Hi, I recently used rtl-sdr / rtl_fm and some adhoc code to decode NRF905 frames. A post is here: http://www.embeddedrelated.com/showarticle/548.php If you think it can be useful to anyone, maybe you can add it to the 'Known Apps' section of this page: http://sdr.osmocom.org/trac/wiki/rtl-sdr Thanks for your great work, Cheers, flm.

1 0

how to get a certain frequency spectrum using rtl_power
by 393775602 26 Jan '14

26 Jan '14

Hi, i am doing a project to get a certain fequencyspectrum . And thanks to the wonderful tool rtl_power, i can get some dbm data over a very wide area of the frequency specturm. and i read the source code in order to change it to get a certain frequency specturm.Sadly, i know little about digital signal processiong and getting a hard time solving it. does anyone know how to get a certain fequencyspectrum using rtl_power or some other tool. sincerely Chen Zujie

2 1

Re: how to get a certain frequency spectrum using rtl_power
by Jiao Xianjun 26 Jan '14

26 Jan '14

If you are familiar with matlab, maybe you can try my matlab scanner. It is easy to change frequency range, RBW, etc, and get spectrum picture. Please google: " rtl sdr matlab scanner" Good luck! 393775602 <393775602(a)qq.com> wrote: >Hi, > > i am doing a project to get a certain fequencyspectrum . And thanks to the wonderful tool rtl_power, i can get some dbm data over a very wide area of the frequency specturm. > > and i read the source code in order to change it to get a certain frequency specturm.Sadly, i know little about digital signal processiong and getting a hard time solving it. > > does anyone know how to get a certain fequencyspectrum using rtl_power or some other tool. > > > > sincerely > > Chen Zujie >

2 1

E4000 tuner gain settings
by Jochen Arndt 25 Jan '14

25 Jan '14

After playing around with the E4000 tuner gain settings, I will summarize my results. LNA Gain Enhancement -------------------- LNA Gain Enhancement is working in automatic mode but not in manual mode. To enable LNA enhancement, write 0x05 to register AGC11. This can be left unchanged even when enabling manual gain mode. Required updates for tuner_e4k.c: Function e4k_enable_manual_gain(): Remove or comment the line that disables LNA Enhancement for auto mode e4k_reg_set_mask(e4k, E4K_REG_AGC11, 0x7, 0); Function e4k_init(): Pull line out of null condition to enable LNA Enhancement e4k_reg_set_mask(e4k, E4K_REG_AGC11, 0x7, E4K_AGC11_LNA_GAIN_ENH | (2 << 1)); Automatic Mode -------------- The mixer control register AGC7 defines a threshold value. When automatic mixer control is enabled and the LNA gain index reaches the threshold value, the high mixer gain of 12 dB will be used. Upon reset, the AGC7 register is cleared and the threshold value is never set by the RTLSDR library. This results in always using the high mixer gain (threshold value 0 corresponds to the lowest LNA gain). The datasheet recommends writing 0x15 to AGC7. This corresponds to a threshold of 15 dB (0x15 >> 1 = 0x0A LNA gain index). A value of 0x1D would set the threshold to max. LNA gain. NOTE: When LNA Enhancement is enabled, setting the threshold to max. gain is not useful. There will be a strong gain increasement step from 25 + 4 = 29 dB to 25 + 5 + 12 = 42 dB. Required updates for tuner_e4k.c: Function e4k_init(): Replace the line e4k_reg_set_mask(e4k, E4K_REG_AGC7, E4K_AGC7_MIX_GAIN_AUTO, 0); with this e4k_reg_write(e4k, E4K_REG_AGC7, 0x14); The above modification will set the threshold value and disable auto mixer gain control. e4k_enable_manual_gain() is called later and will modify only bit 0 of AGC7. Manual Mode ----------- In manual mode LNA enhancement is not used. So the list of gains must be changed because the last two values assume that it is used. The actually used gains are based on Table 6 and the register map of the E4000 data sheet. The gain table contains those values plus the mixer gain of 12 db for the last value and 4 db for all others. But the LNA gain of 30 dB specified in the data sheet is only valid when LNA gain enhancement is enabled. Cite from data sheet section 1.16 LNA Gain enhancement referring register AGC7: "The LNA gain numbers quoted throughout this document assume that this register is programmed to the recommended value." Even when LNA Enhancement would work with manual mode, the second to last value is wrong because LNA enhancement requires that the mixer gain is at 12 dB. Required updates for librtlsdr.c: Change int e4k_gains[] from const int e4k_gains[] = { -10, 15, 40, 65, 90, 115, 140, 165, 190, 215, 240, 290, 340, 420 }; to const int e4k_gains[] = { -50 + 40, -25 + 40, 0 + 40, 25 + 40, 50 + 40, 75 + 40, 100 + 40, 125 + 40, 150 + 40, 175 + 40, 200 + 40, 250 + 40, 200 + 120, // 320, optional additional entry 250 + 120 }; Change top of e4000_set_gain() function from int e4000_set_gain(void *dev, int gain) { rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev; int mixgain = (gain > 340) ? 12 : 4; if(e4k_set_lna_gain(&devt->e4k_s, min(300, gain - mixgain * 10)) == -EINVAL) to int e4000_set_gain(void *dev, int gain) { rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev; int mixgain = (0 == (gain - 120) % 25) ? 12 : 4; if(e4k_set_lna_gain(&devt->e4k_s, gain - mixgain * 10) == -EINVAL) The above extraction of the mixer gain from the combined LNA and mixer gain can be used for all possible valid LNA/mixer gain combinations. Required updates for tuner_e4k.c: Change last value of static const int32_t lnagain[] from 300 to 250 Optionally change second to last value from 250 to 249 to force selection of the highest possible LNA gain index. The 2-dim array may be also replaced by a smaller 1-dim array when updating also e4k_set_lna_gain(): static const int32_t lna_gain[16] = { -50, -25, -50, -25, 0, 25, 50, 75, 100, 125, 150, 175, 200, 249, 250, 250 }; int e4k_set_lna_gain(struct e4k_state *e4k, int32_t gain) { uint32_t i; for(i = 0; i < ARRAY_SIZE(lnagain); ++i) { if(lnagain[i] == gain) { e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, i); return gain; } } return -EINVAL; } Detecting Signal Strength ------------------------- The signal strength can be calculated by determining the relative strength of a signal (e.g. using a FFT) and subtracting the total gain. To get the total gain in automatic mode, read the registers 0x14 to 0x17 (E4K_REG_GAIN1 to E4K_REG_GAIN4) and calculate the gains. Note again that the max. LNA gain of 30 dB is only valid when LNA enhancement is enabled and the mixer gain is at 12 dB. Otherwise, the max. LNA gain is 25 dB. For signals in the range of -50 to -10 dBm, the RSSI indicator can be also read from register 0x1C (E4K_REG_AGC3) in automatic mode to calculate the input power in dBm: double InputPower = 10 * log10(RSSI)) - 28.5 - LNA_Gain; The above calculation can be used when the RSSI value is in the range from 5 to 24. Higher RSSI values occur with strong signals at min. LNA gain and give too low results due to clipped signals. Jochen Arndt

1 0

← Newer
1
...
53
54
55
56
57
58
59
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr