GCC available macros

Unbelievable: you can get a list of all pre-define macros by asking the preprocessor, using the -dM switch:

> touch dummy.hxx

> cpp -dM dummy.hxx

And you get

#define __DBL_MIN_EXP__ (-1021)

#define __UINT_LEAST16_MAX__ 65535

#define __ATOMIC_ACQUIRE 2

#define __FLT_MIN__ 1.17549435082228750797e-38F

#define __UINT_LEAST8_TYPE__ unsigned char

#define __INTMAX_C(c) c ## L

#define __CHAR_BIT__ 8

#define __UINT8_MAX__ 255

#define __WINT_MAX__ 2147483647

and so on. Whoa!

RTL-SDR frekvenciakalibráció

Ismert hátrányuk az RTL-SDR eszközöknek (RTL2832-alapú DVB-T vevőknek), hogy gyenge minőségű oszcillátorokkal szerelik őket, a pontatlanságuk 100 ppm körül is lehet. Korábban nem próbálkoztam ennek a kalibrálásával, de most elhatároztam, hogy utánajárok ennek a kérdésnek. Három módszert próbáltam ki:

1) szemre:)

2) kalibrate-rtl

3) LTE-Cell-Search

Alább a tapasztalatok, hátha másnak is hasznos lesz.

1. Szemmel kalibrálás

Tudom, hogy itt a városban 739 MHz-es vivőfrekvencián üzemelnek LTE cellák. (Honnan tudom? Lásd 3. pont!) Az LTE vivőfrekvenciája nagyon stabil, mindenféle trükkös többantennás jelfeldolgozási eljárásokhoz szükséges, hogy a cellák frekvenciáit nagyon nagy pontossággal szinkronban tartsák. Továbbá tudjuk azt is, hogy az LTE downlink OFDM jel “középső” alvivőjét, az egyenösszetevőt nem modulálják, hogy ne kelljen DC-csatolt jelfeldolgozást megvalósítani. Ezért az LTE spektrumának a közepén, a névleges vivőfrekvencián lennie kell egy “lyuknak”.

Fabrikáltam egy J-Pole antennát 739 MHz-re szalagkábelből (és ebayen gyűjtött hulladék semirigid kábelből:), de ez nem feltétlenül szükséges.

A szemmel kalibráláshoz a gnuradio-hoz az Osmocom-os srácok által írt gr-osmosdr csomag osmocom_fft programját használtam, screenshot alább. A mintavételi frekit a biztonság kedvéért 1 MHz-re növeltem. A screenshoton nem annyira látszik határozottnak a leszívás kerek 739 MHz-en (ez a kép nem a J-Pole-lal készült, hanem egy drótdarabbal; a J-Pole jobb volt), de ott van. Ehhez 90 ppm-re kellett állítani a frekvenciakorrekciót az R820T-s dongle-emmel. Elég brutális frekvenciahiba, több, mint 60 kHz-el volt arrébb a jel! Ekkora hiba mellett egy 3 kHz-es gyenge SSB adást előkeríteni nem egyszerű. Ez nem egy jól sikerült oszcillátor.

Screen Shot 2013-10-21 at 9.20.20 PM

A többi, kisebb mértékű leszívás a többutas terjedés miatt van; jobb pozícióban és jobb antennával ennél katonásabban látszik a DC-n a nem létező alvivő helye. Szóval, szemre 90 ppm. Lássuk a szisztematikusabb módszereket!

2) kalibrate-rtl

A kalibrate-rtl a jó öreg kalibrate rtl-re adaptált változata (talán Steve Markgraf nevéhez fűződik?) Még az USRP1-eken futó GSM bázisállomás, az OpenBTS mellé fejlesztették, hogy az USRP-k (egyébként sokkal jobb) oszcillátorát lehessen pontosítani a közeli GSM bázisállomások frekvenciakorrekciós burst-je alapján. A GSM-ben egy, névlegesen 26 MHz-es oszcillátorból vezetik le a vivőfrekvenciát és a bitszinkront is, és az OpenBTS bázisállomásokat is hozzá kell szinkronizálni a nagyon pontos GSM órajelhez. Tehát ennek az rtl-sdr-re adaptált változatával van dolgunk. Windows-ra is van lefordított verziója, Google segít megtalálni.

Az álmoskönyv szerint csak annyit kell tenni, hogy kiadjuk a

kal -s GSM850

parancsot (itt a vadkeleten ugye 850 MHz-en van GSM, nem 900-on, és ott is csak mutatóba), aminek hatására végignézi a 850-es GSM sáv downlink részét, és jól kiírja az elérhető bázisállomások jelszintjét és frekvenciáját. Ezt nekem sajnos több telephelyen, többek között GSM bázisállomásnak látszó ojjektumok tövében sem sikerült előidézni, talán a vevőt túlterhelte a sok CDMA meg LTE jel a környéken szűrés nélkül, nem tudom, de nem sikerült egy egészséges bázisállomás-listát produkálnom.

Ehelyett fogtam magam, és az osmocom_fft-vel próbáltam 890 MHz környékén GSM vivőket találni (screenshotok kicsit később). A telefon szerint -70 dBm körül kellett jönnie egynek, ezt aztán sikerült a levegőben is azonosítani, a vivőfrekvencia 893.4 MHz. Az alábbi parancs aztán hozta  akívánt eredményt, az E4000-es tunerrel szerelt régebbi dongle-re:

hp$ kal -v -f 893.4e6 -e -60
Found 1 device(s):
0:  ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Elonics E4000 tuner
Exact sample rate is: 270833.002142 Hz
kal: Calculating clock frequency offset.
Using GSM-850 channel 249 (893.4MHz)
offset   1: -1892.29
offset   2: -1877.83
[…]
offset  99: -1827.20
offset 100: -1830.30
average        [min, max]    (range, stddev)
– 1.845kHz        [-1876, -1810]    (66, 16.768282)
overruns: 0
not found: 1
average absolute error: -57.935 ppm

A birtokomban levő E4000-es dongle tehát -58 ppm körüli hibával rendelkezik.

A paraméterek magyarázata: -v a verbose kiírás, -f értelemszerűen a vivőfrekvencia, amin a beazonosított GSM bázisállomás ad, a -e pedig ppm-ben a frekvenciahiba. Ez utóbbi talán igényel egy kis magyarázatot: éppen azt várom a programtól, hogy adja meg nekem a dongle frekihibáját, akkor miért kéri ugyanezt az értéket bemenő paraméternek, honnan kellene ezt tudnom? Igen, valóban előfordulhat, hogy ezt az értéket meg kell adni. Ha máshogy nem, próbálgatással találhatunk megfelelő kezdő értéket (0, +50, -50 közül valamelyik minden bizonnyal jó lesz). Hogy miért van erre szükség? A GSM csatorna sávszélessége 200 kHz körül van, az előkelően FCCH-nak nevezett logikai csatorna, és a benne utazó frekvenciakorrekciós burst nem más, mint egy folyamatos szinuszos jel a vivőfrekvencia+67 kHz környékén, egy-egy GSM időrés erejéig. Viszont a dongle önmagában tévedhet 60 kHz nagyságrendben (ahogy az én R820T példányom is), így aztán az FCCH vivője kívül esik a keresési intervallumon, ha nem korrigálja a program előre a kristály hibáját. Próbálgatás helyett vagy az előző pontban bemutatott méréssel, vagy a következő pont alapján határozhatunk meg egy kezdeti értéket a ppm-nek. Ha a program nem kezdi el a fent bemutatott  mérést, vagy a végeredményül kapott ppm érték értelmetlen (pl. 12 számjegyű:), akkor más kezdeti értékkel kell próbálkozni. Az R820T dongle esetében ezzel a módszerrel is 90 ppm körüli érték jött ki.

A kezdeti ppm érték a spektrum alapján szintén belőhető, tudva, hogy az FCCH egy “tüskét” tesz a spektrumba fc+67 kHz környékén. Az alábbi két ábra az R820T dongle-lel, az osmocom_fft segítségével mutatja a (nehezen azonosítható) GSM vivő spektrumát 893.4 MHz-en; az első ábra 0 ppm beállításnál (kompenzálás nélkül), a második pedig a helyes 90 ppm kompenzálással. A “peak hold” opció révén látszik az FCCH tüske, az első esetben rossz helyen, a második esetben már jó helyen, 893.467 MHz környékén. Bázisállomás közvetlen rálátással persze könnyíti ezt a mérést…

Itt tehát még 0 ppm (helytelen) beállítással, a tüske rossz helyen, a vivő “alatt”:Nem kompenzalt GSM

Itt pedig már a helyes 90 ppm-es kompenzálással. A tüske a vivő+67 kHz-en:

Kompenzalt GSM

 

Érdekességképpen, a 90 ppm olyan brutálisan sok, hogy elsőre tévedésből 893.3 MHz-re kalibráltam 893.4 MHz helyett, és a kal boldogan kihozta, hogy -20 ppm a frekihiba, mivel 100 kHz-el odébb kereste az FCCH tüskét. (Persze feltűnhetett volna, hogy nem a 200 kHz többszöröse a 893.3 MHz.)

3. LTE Cell Scanner

Ez egy nagyon aranyos program, innen tölthető le a forrása. Ahogy a neve alapján sejthető, az LTE cellák paramétereit tudja kitalálni. Két része van, a Scanner (amivel tehát egy adott frekvenciasávon belül a cellákat tudjuk felderíteni), és a Tracker, amivel egy szektort lehet figyelni, pl. meg lehet jeleníteni a frekvenciaszelektív fading pillanatnyi torzítását a frekvencia függvényében (persze csak a jel “középső” 1.25 MHz-es szeletét nézi az rtl-sdr limitációi miatt, de az LTE úgy van kitalálva, hogy a cellainformációk a minimális LTE sávszélesség, 1.25 MHz megfigyelése mellett is dekódolhatók legyenek). A program mellékterméke egy becslés a dongle frekihibájára is.

Használata nagyon egyszerű (mivel már korábban felderítettem, hogy 739 MHz-en vannak a cellák; egyébként megadható egy szélesebb intervallum is):

hp@hp-Vostro-3700:~/LTE-Cell-Scanner/build$ sudo CellSearch -s 739e6 -e 739e6
LTE CellSearch v1.0.0 (release) beginning
Search frequency: 739 MHz
PPM: 120
correction: 1
Found Elonics E4000 tuner
Examining center frequency 739 MHz …
Detected a cell!
cell ID: 215
RX power level: -43.7429 dB
residual frequency offset: 39888 Hz
Detected the following cells:
A: #antenna ports C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID A      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
215 2    739M  39.9k -43.7 N  50 N one 1.0000539785702424744

(Elnézést a formázásért!) Itt a crystal correction factor alatt a szám a program becslése a frekihibára. (1-1.000053978)/1e-6 pedig 54 ppm körül van, nagyon közel a kalibrate által mondott 57 ppm-hez. Így ez az érték használható a kalibrate-rtl bemenő paramétereként.

Ugyanez az R820T dongle-re:

hp@hp-Vostro-3700:~/LTE-Cell-Scanner/build$ sudo CellSearch -s 739e6 -e 739e6
LTE CellSearch v1.0.0 (release) beginning
Search frequency: 739 MHz
PPM: 120
correction: 1
Found Rafael Micro R820T tuner
Examining center frequency 739 MHz …
Detected a cell!
cell ID: 215
RX power level: -24.7067 dB
residual frequency offset: -66237 Hz
Detected the following cells:
A: #antenna ports C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID A      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
215 2    739M -66.2k -24.7 N  50 N one 0.99991037751072686657

A ppm becslés tehát

(1-0.99991037751072686657)/1e-6 = 90 (ppm), a harmadik módszerrel is kijött a 90 ppm erre a stick-re.

Jó mulatást!

Follow

Get every new post delivered to your Inbox.