La norme DVB-S a été développée dans les années 1990 pour la diffusion de bouquets de télévision satellite numérique, et remplacée par DVB-S2 en 2005. Ces dernières années les normes DVB ont été adoptées par la communauté des radioamateurs pour des expériences de TV numérique (DATV). Des récepteurs DVB grand public sont disponibles à faible coût sous la forme de boîtiers set-top-box, de cartes PCI et de clés USB. Malheureusement certains ne sont pas adaptés à la DATV :
Leur étage d'entrée est optimisé pour un signal entre 950 MHz et 2150 MHz (transposé depuis 10.700 .. 12.750 GHz par une tête satellite) alors que la DATV se pratique aussi dans les bandes 70 cm et 13 cm (voire 2 m et 6 m). Les convertisseurs de fréquences ajoutent des coûts, de la complexité et du bruit.
Ils sont conçus pour une mise en oeuvre aussi simple que possible, alors que les radioamateurs préfèrent avoir accès à un maximum de réglages pour optimiser la réception.
Certains récepteurs ne supportent pas les vitesse de modulation très basses que les radioamateurs doivent utiliser pour respecter les contraintes réglementaires.
Certains émetteurs DATV, comme le système HamVideo de l'ISS, semblent génèrer un flux MPEG légèrement différent de ceux des chaînes grand public ; certains récepteurs refusent de le décoder.
Avec des pilotes spécifiques il est apparemment possible de syntoniser au delà des fréquences spécifiées par le constructeur, de démoduler à bas débit, de contrôler davantage de paramètres et de récupérer les paquets MPEG bruts : voir http://www.vivadatv.org. Mais ceci ne fonctionne qu'avec certains chipsets.
Un récepteur logiciel permet de s'affranchir de ces problèmes. On trouve maintenant des récepteurs SDR pour de nombreuses bandes de fréquences avec divers compromis entre le coût, la bande passante et la sensibilité. Les récepteurs dits "RTL-SDR" couvrent les bandes 10 m, 6 m, 2 m, 70 m et 23 cm. Les produits d'Analog Devices, Lime Micro et Ettus Research atteignent 3.8 GHz ou 6 GHz.
Un récepteur DVB logiciel permet par ailleurs de profiter de tous les avantages de la radio logicielle :
Il est possible d'enregistrer un flux I/Q brut et de le démoduler plus tard. On réduit les risques d'erreur de manipulation pendant l'étape d'acquisition. C'est un avantage appréciable pour les signaux transitoires tels que ceux de l'ISS.
On peut passer autant de temps qu'on le souhaite à ajuster les paramètres de démodulation pour minimiser le taux d'erreur final.
On peut examiner les signaux et les filtrer numériquement avant de les démoduler, par exemple pour éliminer des signaux fantômes (birdies) ou corriger un écart en fréquence inattendu. Des algorithmes coûteux en temps de calcul peuvent être utilisés pour tenter de filtrer des bruits non aléatoires.
En combinant les symboles issus de plusieurs chaînes de réception, on peut obtenir du gain de diversité.
En combinant des enregistrements I/Q cohérents de plusieurs récepteurs, on peut espérer obtenir du gain matriciel, du gain de diversité ou une meilleure directivité.
On peut injecter un même signal numérique dans plusieurs demodulateurs logiciels pour comparer objectivement leurs performances.
Un récepteur SDR peut servir d'analyseur de spectre rudimentaire. Ceci permet de diagnostiquer divers problèmes tels que la présence de signaux parasites.
Un démodulateur logiciel ne devient jamais obsolète car tous les récepteurs SDR ont à peu près la même interface : configurer la fréquence centrale et la vitesse d'échantillonnage ; recevoir les données I/Q brutes. Au contraire, grâce aux progrès de l'industrie informatique, un démodulateur logiciel donné pourra traiter soit des débits plus importants, soit un plus grand nombre de canaux simultanément.
Cette flexibilité a évidemment un coût en terme de coût, d'encombrement, de consommation électrique et de sensibilité. En 2005, un démodulateur DVB-S2 55 Mbit/s tenait dans 14 mm² de silicium gravé à 130 nm. De nos jours un chercheur de satellite portatif vendu quelques dizaines d'euros contient : tuner RF, démodulateur DVB-S/S2, décodeur MPEG, écran LCD, processeur embarqué, clavier, batterie, ports divers. Il faut un ordinateur haut de gamme pour faire tourner un récepteur logiciel équivalent.
gr-dvb [GRDVB] est une implémentation complète de DVB-S pour GNU Radio. Elle est utile en tant qu'implémentation de réference et d'un point de vue pédagogique, mais sa consommation CPU est élevée et il s'appuie sur toute l'infrastructure associée à GNU Radio y compris Boost, SWIG et Python.
leandvb est écrit en C++ uniquement, avec très peu de dépendances. Il est développé sous Linux et compile vraisemblablement sur d'autres plate-formes de type UNIX ou embarquées. L'objectif est de traiter des signaux réels avec un débit utile en pratique plutôt que de chercher à atteindre les performances théoriques de correction d'erreur.
Tableau 1. Aperçu de leandvb
| Default mode | Highspeed mode | ||||||
|---|---|---|---|---|---|---|---|
| Input format | I/Q: uint8_t (rtl_sdr), int16_t (PlutoSDR, LimeSDR, etc), float I/Q | ||||||
| Pre-processing |
| ||||||
| Sampling ratio | 1.2 - 100+ samples/symbol | ||||||
| Bandpass filtering | RRC (optional) | None | |||||
| Equalization | None | ||||||
| Minimum baud rate |
| ||||||
| Maximum symbol rate | Limited by hardware capabilities. | ||||||
| Maximum symbol rate inaccuracy | TBD | TBD DVB-S2: 5 ppm | |||||
| Maximum carrier frequency error |
| ||||||
| DVB-S constellations | QPSK | ||||||
| DVB-S code rates | 1/2, 2/3, 3/4, 5/6, 7/8 | 1/2 only | |||||
| DVB-S error correction |
|
| |||||
| DVB-S2 MODCODs |
| ||||||
| DVB-S2 frame size | 64800, 16200 | ||||||
| DVB-S2 error correction |
| ||||||
| DVB-S2 mode adaptation |
| ||||||
| Error performance | See Section 7, « Performances » | ||||||
leandvb ne satisfait pas aux exigences des normes DVB en matière de correction d'erreurs.
La force du signal, le rapport C/N et le MER sont estimés sur un sous-ensemble des échantillons.
À bas rapport S/B, les mesures du MER ne sont pas suffisamment fiables pour servir d'estimation du rapport S/B. La raison est que le contrôle de gain fonctionne mal à bas rapport S/B. Il vaut mieux utiliser --cnr.
Les mesures de MER sont surestimées à bas rapport S/B. Ceci est dû à l'algorithme qui n'exploite pas les résultats du correcteur d'erreurs.
Pour contrôler le MER d'un modulateur avec leandvb, il faut utiliser un taux d'échantillonnage élevé (par exemple 8 échantillons par symbole). Sinon le vecteur d'erreur sera dominé par le bruit d'interpolation interne..
L'estimation du rapport C/N par analyse du spectre exige un bon calage en fréquence. Avec l'option --drift, les valeurs de C/N ne sont plus fiables lorsque le démodulateur se désynchronise.
Le facteur de roll-off doit être configuré manuellement. leandvb ignore la valeur fournie par la couche physique DVB-S2.
Télécharger et compiler leandvb :
git clone -b work http://github.com/pabr/leansdr.git cd leansdr/src/apps vi Makefile # For DVB-S2, find and uncomment LEANSDR_EXTENSIONS make
Exécuter les tests fonctionnels. Ceci fait parfois apparaitre des incompatibilités avec certaines architectures ou certains compilateurs.
cd leansdr/test make leandvb-ft
Compiler un décodeur LDPC externe pour DVB-S2 à bas rapport S/B :
git clone -b ldpc_tool http://github.com/pabr/xdsopl-LDPC-pabr cd xdsopl-LDPC-pabr make CXX=g++ ldpc_tool
Exécuter les tests de sensibilité.
cd leansdr/test cp .../ldpc_tool . make leandvb-snr
TBD Usage: ./leandvb [options] < IQ > TS Demodulate DVB-S I/Q on stdin, output MPEG packets on stdout Input options: --u8 Input format is 8-bit unsigned (rtl_sdr, default) --f32 Input format is 32-bit float (gqrx) -f HZ Input sample rate (default: 2.4e6) --loop Repeat (stdin must be a file) Preprocessing options: --anf N Number of birdies to remove (default: 1) --derotate HZ For use with --fd-pp, otherwise use --tune --fd-pp NUM Dump preprocessed IQ data to file descriptor DVB-S options: --sr HZ Symbol rate (default: 2e6) --tune HZ Bias frequency for demodulation --standard S DVB-S (default), DVB-S2 (not implemented) --const C QPSK (default), 8PSK .. 32APSK (DVB-S2 only) --cr N/D Code rate 1/2 (default) .. 7/8 .. 9/10 --fastlock Synchronize more aggressively (CPU-intensive) --filter Filter baseband (CPU-intensive) --hq Enable all CPU-intensive features UI options: -h Display this help message and exit -v Output debugging info at startup and exit -d Output debugging info during operation --fd-info NUM Output demodulator status to file descriptor --fd-const NUM Output constellation and symbols to file descr --gui Show constellation and spectrum --duration S Width of timeline plot (default: 60) --linger Keep GUI running after EOF Testing options: --awgn STDDEV Add white gaussian noise (slow)
--inpipe BYTES
--gui
Disponible uniquement sur les plate-formes avec X11. Voir également --fd-info.
-f HZ
Spécifie le taux d'échantillonnage du flux I/Q sur l'entrée standard. En général, la valeur est la même que dans rtl_sdr -s HZ.
--sr HZ
--tune HZ, --derotate HZ
Spécifie la fréquence centrale du signal DVB.
Cette option est utile lorsque le signal n'est pas centré à 0 Hz, par exemple :
lorsque le Doppler ou l'imprécision des oscillateurs locaux introduit un décalage en fréquence ;
lorsque le récepteur n'est pas réglé sur la fréquence nominale ;
pour sélectionner un canal dans un flux I/Q large bande.
Par exemple, un signal à 397.1 MHz peut être reçu soit par rtl_sdr -f 397100000 | leandvb soit par rtl_sdr -f 397000000 | leandvb --tune 100e3.
--resample
Active le filtrage passe-bande et le rééchantillonnage.
--decim N
Active la décimation du signal avant démodulation.
--sampler MODE
--drift
--cnr
TBD cnr dans leandvb_tui.sh
Le rapport C/N est obtenu en mesurant (C+N)/N à partir du spectre puis en en déduisant C/N.
--fastlock
Accélère la recherche de synchronisation.
Avec cette option leandvb se synchronise plus rapidement. Ceci est recommandé pour recevoir des transmissions intermittentes (communications half-duplex) et pour démoduler optimalement des signaux enregistrés. Combiné avec --viterbi, la charge CPU augmente significativement.
--hs
Sélectionne un mode haut débit avec les restrictions suivantes :
--ldpc-bf INT
--ldpc-helper COMMAND
--nhelpers INT
Pour un signal HamTV à 2395 MHz transposé à 397 MHz par une tête MMDS avec oscillateur local de 1998 MHz LO :
$ rtl_sdr -f 397000000 -s 2400000 capture.iq $ ./leandvb --gui --hq < capture.iq > capture.ts $ ffplay capture.ts
L'option --hq active des traitements coûteux en CPU. Elle permet d'extraire davantage de données.
Pour une réception et un décodage en direct, il suffirait en théorie de lancer :
$ rtl_sdr -f 397000000 -s 2400000 - | ./leandvb --gui | vlc -
Malheureusement le traitement de flux multimédia temps réel n'est pas si simple :
À forte charge CPU, les pipes peuvent déborder ; l'utilitaire rtl_sdr va alors supprimer des échantillons sans prévenir. Essayer rtl_sdr -b 32768, rtl_sdr -S et leandvb --inbuf 262144.
Certains lecteurs MPEG examinent le flux d'entrée avant de commencer à décoder. Il en résulte un délai que l'on peut parfois réduire en spécifiant les formats et codecs sur la ligne de commande.
La plupart des lecteurs MPEG cadencent l'affichage vidéo en utilisant le débit de la carte son comme horloge de référence, indépendamment du débit en entrée. Il en résulte inévitablement des artefacts sonores ou des saturations de buffers qui conduiront leandvb à se désynchroniser. On peut parfois remédier à ces problèmes en spécifiant manuellement une cadence d'affichage légèrement plus élevée que la valeur réelle.
Pour certains applications, par exemple la visioconférence, il faut également s'intéresser aux sources de latence.
La norme MPEG permet de transmettre les images dans le désordre, ce qui implique de la latence. Il faut paramétrer les encodeurs pour interdire la backward prediction.
L'entrelacement DVB-S introduit une latence incompressible de 2244 octets, soit 300 ms à 64 Kbit/s.
leandvb effectue certains traitements par blocs de taille fixe (mais la latence qui en résulte est en principe inférieure à celle imputable à l'entrelacement).
La plupart des décodeurs MPEG gèrent un tampon d'entrée pour que la lecture soit plus fluide.
Voici un script utilisé pour voir le flux vidéo de l'ISS en direct tout en enregistrant les échantillons I/Q :
$ while true; do rtl_sdr -g 22 -f 397000000 -s 2400000 - | tee $(date +%Y%m%d_%H%M%S%z.iq) | ./leandvb --gui | mplayer -demuxer mpegts -tsprobe 1 -vid 256 -aid 257 -vc ffmpeg2 -ao null - done
Parfois le décodeur détecte plus facilement le flux MPEG lorsqu'on force la mise en tampon :
$ ... | mplayer -cache 128 -
leansdrcat peut rejouer un fichier à débit constant. Ceci permet de tester si un décodeur MPEG est capable de traiter des flux temps réel.
$ ./leansdrcat --cbr16 2400000 < capture.iq | ./leandvb --gui | mplayer -
leandvb a besoin de connaître la fréquence du signal, la rapidité de modulation et (pour DVB-S) le taux de codage-S. Un outil auxiliaire, leansdrscan, permet d'automatiser la détection de ces paramètres.
La commande ci-dessous instanciera leandvb avec six combinaisons de fréquences de modulation (250 kS/s, 500 kS/s, 1000 kS/s) et de taux de codage (1/2, 7/8) jusqu'à l'obtention d'un flux MPEG.
$ ./leansdrscan -v --rewind ./leandvb -f 1024000 --sr 250000,500000 --cr 1/2,7/8 < capture.iq > capture.ts
Avec un flux temps réel, l'option --rewind n'est pas utile. Par ailleurs, l'option --tune devrait permettre de balayer plusieurs canaux à bas débit dans un flux à large bande :
$ rtl_sdr ... | ./leansdrscan -v ./leandvb -f 2400e3 --tune -500e3,0,500e3 --sr 250000 --cr 1/2,7/8 | ...
Le code source leansdr n'est pas conçu pour être facilement intégré dans d'autres logiciels. À la place, un logiciel tiers devrait lancer un process leandvb, lui envoyer des échantillons I/Q sur son entrée standard, et capturer sa sortie ou la rediriger vers un décodeur MPEG. leandvb indiquera son état sur les canaux auxiliaires spécifiés par --fd-info et --fd-const.
$ rtl_sdr ... | ./leansdrscan ./leandvb --fd-info 2 -f 1024e3 --sr 250e3,500e3 --cr 1/2,3/4 | mplayer -cache 128 - CR 1/2 SR 250000.000000 LOCK 0 FREQ 4047 SS 66.660774 MER 19.8 LOCK 1 FREQ 4062 SS 65.118179 MER 18.7 FREQ 4047 ...
Par exemple, leandvb_tui.sh présente l'état du démodulateur sur une ligne :
$ rtl_sdr ... | ./leandvb_tui.sh ./leansdrscan ./leandvb --fd-info 2 -f 1024e3 --sr 250e3,500e3 --cr 1/2,3/4 | mplayer -quiet -cache 128 - [SS 68] [Offset +4047 Hz] [MER 18.7 dB] [LOCKED] [SR 250000 Hz] [FEC 1/2]
Et leandvb_vt100ui.sh affiche la constellation et les symboles sur un terminal VT100 de 80x24 caractères :
$ rtl_sdr ... | ./leandvb_vt100ui.sh ./leandvb --fd-info 2 --fd-const 2 | mplayer -really-quiet -cache 128 -
|
leandvb VT100 UI example |
|
SS: 63 |
x x |
MER: 10.9 dB x x |x x
x#x x | x# x
Offset: +188123 Hz | x x
|
LOCKED |
---------------------+---------------------
FEC: 1/2 | x
x x |
SR: 2000000 Hz x | x x x
x# | # x
x x x x x
x | x
|
|
|
|
La charge CPU dépend de la fréquence d'échantillonnage, de la rapidité de modulation et, dans une moindre mesure, du taux d'erreurs à corriger.
L'option --gui augmente la charge CPU.
Tout composant logiciel qui traite des données d'origine tierce doit être considéré comme un risque du point de vue de la sécurité. Cette règle s'applique aussi bien aux serveurs web qu'aux récepteurs radio logiciels. En théorie, si la réception logicielle de modes numériques sophistiqués devient populaire, une transmission mal intentionnée sur une bande HF pourrait attaquer des failles logicielles dans un grand nombre de récepteurs à l'échelle mondiale.
À titre préventif, il est souhaitable de faire tourner leandvb avec des privilèges minimaux, sous SELinux, dans une machine virtuelle, sur du matériel dédié, etc.
Cette section illustre quelques problèmes courants.
Figure 1. Format de données incorrect
Les échantillons I/Q ne sont pas interprétés correctement.
Spécifier --u8 ou --f32.
Figure 3. Suréchantillonnage excessif
Le récepteur SDR capture une bande plus large que nécessaire.
Ceci poserait des problèmes dans une bande chargée.
Réduire la vitesse d'échantillonnage.
Figure 5. Saturation interne ?
Le motif I/Q en anneau suggère que le rapport S/B est bon (à gauche et au milieu).
Mais la distribution est anormale : l'amplitude est bornée, et les quatre nuages de points ne sont pas circulaires (à droite).
Ceci pourrait s'expliquer par une saturation à l'intérieur du récepteur RTL-SDR, avant l'étage DDC.
En attendant que ce phénomène soit mieux compris, on peut ajuster le gain manuellement.
Figure 6. Signal parasite
Le signal contient une porteuse parasite (en haut à droite).
Utiliser --anf pour la filtrer. Ceci améliore le motif I/Q en anneau (en bas à gauche).
Figure 7. Décalage en fréquence
Le signal est bon mais la syntonisation est imparfaite (en haut à droite).
Le spectre est re-centré avec --derotate -50000 (au milieu à droite).
N.B. : Le démodulateur aurait toléré ce décalage de toute façon.
Améliorer la sensibilité
DVB-S2 GSE
Multi-threading
Filtres en cascade pour réduire la charge CPU en cas de fort suréchantillonage.
Optimisations SIMD sur x86 et ARM
Ajustement automatique de la stratégie de démodulation en fonction du CPU
Permettre à leansdrscan de lancer plusieurs démodulateurs en parallèle.
Plugin GQRX
Application Android.
leandvb est développé principalement pour l'expérimentation non commerciale dans un contexte radioamateur. Sans entrer dans les débats sur la légitimité des brevets logiciels, quiconque envisagerait d'autres applications devrait probablement se plonger dans les considérations ci-dessous :
La norme DVB-S a été publiée initialement en 1994 sous la référence ETS 300 421. Les brevets applicables ont vraisemblablement expiré, ou expireront prochainement.
Pour construire un récepteur DVB logiciel complet il faut généralement ajouter un décodeur MPEG. La norme MPEG-2 a été finalisée vers 1995 et publiée en 1996. Cet article estime que les derniers brevets expireront en 2018.
D'autres normes telles que DVB-T (1997), H.264 (2003), DVB-S2 (2005), DVB-T2 (2008) et HEVC (2013) sont vraisemblablement protégées par des brevets.
Le projet ARISS HamVideo a suscité un intérêt pour la démodulation logicielle de signaux DVB-S en 2015. L'implémentation d'Edmund Tse pour GNU Radio ([GRDVB], 2010) a permis de confirmer la faisabilité.
Les premiers utilisateurs, F5OEO et K4KDR, ont fourni des enregistrements I/Q représentatifs de plusieurs types de modulateurs, de canaux de transmission et de récepteurs. Ceci a contribué à la mise au point de leandvb.
Le projet QO-100 de AMSAT-DL / QARS / Es'HailSat a motivé l'ajout de la compatibilité DVB-S2 en 2018.
Le modulateur DVB-S2 de GNU Radio, basé sur du code de Ron Economos W6RZ et Charles Brain G4GUO ([GRDVBS2], [DATVEXPRESS]), a contribué à valider la conformité DVB-S2.
Le décodeur LDPC de Ahmet Inan ([XDSOPL_LDPC]) a permis de tester et d'affiner la synchronisation DVB-S2 à faible rapport S/B.
L'analyseur de spectre et le système de discussion opérés par le BATC ont facilité la capture de signaux DVB-S2 utiles pour les tests.
[DVBS] Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite services. 1997. https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=5316.
[DVBS2] Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications; Part 1: DVB-S2. 2005. https://www.dvb.org/standards/dvb-s2.
[GRDVB] Software Radio for Digital Satellite Television. 2010. http://www.edmundtse.com/wp-content/uploads/2009/04/treatise.pdf. https://github.com/EdmundTse/gr-dvb.
[GRDVBS2] A DVB-S2 and DVB-S2X transmitter for GNU Radio. 2014. https://github.com/drmpeg/gr-dvbs2.
[GRDVBS2RX] DVB-S2 and DVB-T2 receiver blocks for GNU Radio. 2018. https://github.com/drmpeg/gr-dvbs2rx.
[DATVEXPRESS] DATV-Express GUI source code. 2014. https://github.com/G4GUO/datvexpress_gui.
[XDSOPL_LDPC] Playing with Low-density parity-check codes. 2018. https://github.com/xdsopl/LDPC.
[SOFTDATV] Réception logicielle des transmissions vidéo numériques de la Station Spatiale Internationale . http://www.pabr.org/radio/softdatv/softdatv.fr.html .