L'application RF Analyzer sur Androïd permet d'enregistrer des fichiers IQ captés avec un dongle RTL-SDR (entre autres). Les 60 premières minutes sont gratuites, ensuite, on peut acquérir la license pleine pour environ 8 euros. Il suffit de relier la clé USB au smartphone avec un adaptateur OTG USB-A//USB-C. Il est alors facile d'aller capter les signaux où c'est possible. Par exemple, ci-dessus, le VOR-DME de Sprimont, dont on distingue le callsign 'SPI' (... .--. ..) sur 113.1 MHz, capté au sommet du terril Sainte-Barbe et Tonne à Liège.
C'est amusant mais le but est d'avoir de la matière pour jouer avec GNU Radio. GNU Radio permet de faire un tas de choses mais la prise en main n'est pas spécialement facile. Certaines choses sont particulièrement difficiles à faire et le tout est très mal documenté. À ma connaissance, il n'existe qu'un seul livre sur la question, 'Communication Systems Engineering with GNU Radio: A Hands-on Approach' où les auteurs n'ont pas pu s'empêcher de traiter de sujets plus complexes les uns que les autres avec GNU Radio après une introduction trop brève du B-A-BA de quelques modules.
Par exemple, ce qui, à ma connaissance, n'a pas de solution simple, c'est de lire un fichier IQ de RTL-SDR, composé de bytes pour générer un flux de complexes float, généralememnt utilisés par les modules GNU Radio. Alors qu'il est trivial d'utiliser une source RTL-SDR 'live' avec le module osmocom, lire un fichier capturé par rtl_sdr(1) est incroyablement complexe (ou je n'ai pas trouvé...). Ensuite, si je veux extraire un signal hors de ma capture sur une bande de 2.5 MHz, je peux utiliser le module 'Frequency Xlating FIR Filter' ...dont la documentation est incompéhensible. Heureusement, il existe un exemple (peu commenté) dans le bouquin, page 72, 'POCSAG Multichannel Decoding' où l'on comprend que le champ 'taps' du module est simplememnt un filtre passe bas. Et donc, avec le workflow grc
On obtient le résultat suivant :
Le fichier source contient 5 secondes d'enregistrement à 2500000 échantillons par secondes. On le lit en boucle (repeat=yes). Cela produit le 'waterflow' du milieu avec une bande passante de 2.5 MHz, [111.85..114.35] MHz (113.1 - (2.5/2) .. 113.1 + (2.5/2)). Dont on extrait le VOR de Sprimont à 113.1 MHz (center frequency=0) et celui de Olne à 112.8 MHz (center frequency=-300) avec une bande passante de 2 * 25 Khz. On en profite pour réduire la cadence d'échantillonnage d'un facteur 20 (decim=20), ce qui fait que le 'waterfall' n'a plus que 125 KHz [-65..+65] de bande passante. Si les deux signaux sinusoïdaux donnant la direction sont à 30 Hertz comme indiqué dans Wikipédia, on doit y avoir un phénomène d'aliasing... (?). C'est un peu bizarre d'avoir quelque chose qui fasse 30 tours par seconde... Sur les waterfalls, on devrait pouvoir deviner les callsigns en morse des deux balises : 'SPI'(... .---. ..) et 'LNO' (.-.. -. ---) mais l'enregistrement est trop court et la répétition n'aide pas.
Dans le cas d'un enregistrement avec un HackRF/Portapack.Mayhem, on part de shorts signés, la lecture est plus simple.
Inscription à :
Commentaires (Atom)



