Ce n’était pas très évident …
Ayant récemment passé avec succès l’examen radio-amateur, je dispose maintenant d’un identifiant :P et du droit d’utiliser des équipements radio dans les bandes de fréquences adaptées. Souhaitant m’initier doucement à ce domaine … complexe, j’ai demandé autour de moi quel équipement je pouvais acheter pour avoir un setup fonctionnel simple, pas cher, pas encombrant, pour faire référence. L’on m’a conseillé, entre autres choses, la carte LimeSDR Mini. J’en ai donc acheté une.
Maintenant, il faut la mettre en oeuvre. Et ce ne fut pas de tout repos, car il n’y a pas d’exemple / quick start dédié à cette carte. Les docs du fabricant sont surtout orienté vers la LimeSDR pas-Mini, qui est assez différente. Genre si on regarde la page wiki, les docs HW / SW sont bien les docs spécifiques à cette carte, par contre le “get started”, c’est “LimeSDR-USB made simple”, donc adapté pour la carte pas-mini. Ça ne va pas faciliter les choses.
Bon, j’y suis allé quand-même. J’ai donc installé les drivers qui vont bien, et lancé Lime Suite, pour voir ce que ça donne. C’est une interface très complète … Et beaucoup trop compliquée. L’on m’ dit qu’il n’était pas nécessaire d’aller farfouiner dedans, et en pratique j’ai constaté que ce n’était effectivement pas nécessaire. j’aurais bien, néanmoins, voulu essayer un test basique, genre loopback TX->RX, mais autant la procédure est bien expliquée pour la LimeSDR pas-mini, autant les contrôles sont différents sur la Mini, et j’ai l’impression que ce test n’est pas possible. Ah, avant ça j’ai lancé le Lime Quick Test, et tout est passé en vert. Bon signe. A noter que la carte chauffe beaucoup, on est dans les 50°C sur le shield en nominal.
Bon. Comment on fait pour vérifier qu’elle fait effectivement au moins du RX ? Suivant certaines indications vues sur le wiki Myriad, j’ai installé Pothos, ce qui m’a perdu plus qu’autre chose. Donc j’ai plutôt cherché des sites où de joyeux radioamateurs auraient mis en oeuvre cette carte. J’en ai trouvé un en particulier qui met en oeuvre la carte avec GnuRadio. Cela me semblait être une étape plus lointaine, mais vu que je n’arrive pas à me dépatouiller des outils bas-niveau, autant attaquer direct avec le gros morceau. Et quel morceau … Sachant que j’ai déjà joué avec GnuRadio, mais sur un poste du Lab, pas sur une machine à moi.
L’on va donc installer GnuRadio sous Windows, pour commencer (il faudra que je fasse la même chose sous Linux un de ces quatre). Je lance GnuRadio-companion (l’interface graphique) et là message d’erreur :@\@Failed to open registry key HKLM\SOFTWARE\Python\PythonCore\2.7\InstallPath”Is Python 2.7 installed?”@\@Grmpf … Effectivement je n’ai pas installé Python sur cette machine. Soit, j’installe Python 2.7, je lance GnuRadio, même erreur. Diantre. Je vais donc faire un coup de Regedit (ça faisait longtemps).
Dans HKEY_LOCAL_MACHINE\SOFTWARE je trouve bien la clé Python, qui contient bien la clé PythonCore qui contient bien la clé 2.7 dans laquelle il n’y a pas de clé InstallPath, par contre une clé PythonPath, qui contient des valeurs liées à FreeCAD et Pothos, tiens donc, étrange. En cherchant sur qwant, je suis tombé sur le code source de GnuRadio et en particulier ce fichier. Il va chercher la clé de registre dans un chemin écrit en dur dans le code. C’est sûr que si la clé en question n’existe pas … Donc, bon, je décide de la créer. Dans 2.7 je fais donc clic-droit Nouveau/clé, et je l’appelle InstallPath. je relance GnuRadio-companion, message d’erreur mais différent, ce coup-ci il ne me dit pas qu’il ne trouve pas la clé, il me dit qu’il n’arrive pas à la lire. Intéressant, on avance. Donc je retourne dans Regedit, j’attrape la clé que je viens de créer et je clic droit/modifier, et je met en valeur le chemin d’accès vers l’exe de Python 2.7 (C:\Python27 dans mon cas, chemin d’accès par défaut quand on clique “suivant” sans se poser de question). Je relance GnuRadio-companion et là message différent, il me de lancer un script python pour gérer les erreurs. Ok, il lance un invite de commande, et ça lance plein de scripts, dont beaucoup me disent “Warning : Pytho 2.7 support will be dropped on 01/01/2020” … Huhu. Au bout d’une vingtaine de minutes, il a fini, je relance GnuRadio et, enfin, ça démarre. C’est pas dommage.
Maintenant il faut mettre en oeuvre le bazar. Pour rester sur un test simple, je me suis dit que faire un bête récepteur FM et chopper une radio “normale” pouvait être une bonne idée. J’ai donc cherché des exemples de démodulateurs FM pour GnuRadio. J’ai trouvé ça, ça et surtout ça. En particulier, je me suis appliqué à remonter ce schéma, mais il utilise une autre interface HW. Donc, dans le lien précédent j’ai recopié la config qu’il met pour la source : osmocom source, et dans “Driver Argument” : driver=lime, soapy=2. Là je ne réfléchis surtout pas, je ne comprends rien à ce que je fais. Puis je fais le reste du circuit, ce qui donne ceci:
J’ai commencé par centrer sur 107.7, pour essayer de chopper la radio des autoroutes. Ça ne m’a rien sorti d’autre que du bruit blanc. En regardant le spectre, j’ai vu qu’il y avait un petit pic autour de 107.1. J’ai donc testé dans ce coin-là, il y avait un son bizarre, pas un bruit blanc, mais rien d’audible, et le pic semblait encore un peu plus bas, je suis donc descendu à 107.08. Et là bingo ! Je ne m’attendais pas à être aussi content de tomber sur de la boumfta-boumfta auto-tunée :)
Expérience concluante : j’arrive à faire du RX sur la LimeSDR Mini avec GnuRadio. Ce n’était pas évident, ça m’a pris une bonne partie de la journée pour faire tous ces essais, installer les logiciels, me rendre compte que c’était des fausses pistes …
Je mets en PJ le fichier GnuRadio, pour référence. Le 03 c’est avec les interfaces en WX, le 04 avec les interfaces en Qt.
A noter:
- Sur le 03 j’ai utilisé WX GUI FFT Sink et WX Slider GUI, ce qui impose de configurer GnuRadio pour utiliser WX, et pas Qt. Je ne saisis pas tous les tenants et les aboutissants, mais en gros, Qt c’est une lib pour faire des interfaces graphiques, en C++, et WX c’est une lib Python. Ça se configure dans le bloc en haut à gauche “Options”, on doube-clic, et dans le menu déroulant “Generate option” on choisit “WX GUI”.
- Le slider de volume avec WX déconne complètement. Quand j’essaye de le bouger la fenêtre freeze, et je suis obligé de stopper le script pour me sortir du pétrin, donc je l’ai enlevé. Je me demande si c’est lié au fait que mon PC n’est pas assez puissant pour tout gérer à la fois ? Toujours est-il qu’avec le 04 en Qt ça marche très bien, le slider (“QT GUI Range”) fait son office.
- Le slider de volume justement, on définit un contrôle qui va varier entre deux valeurs, ici j’ai mis de 0 à 100, en float. Sur le chemin du signal audio (donc après le WBFM - qui est le démodulateur - et le Resampler, en fait juste avant le Audio Sink qui est la sortie vers la carte son, c’est pas mal), on met un Multiply Const, qui est un bloc qui va multiplier le signal par une valeur, qui ne provient pas d’un autre flux. Il faut le configurer en float (sinon les connections ne se font pas), et si dans le champ “Constant” on met l’ID du slider (ici “Volume”, que je divise par 100 pour avoir une valeur entre 0 et 1 en float), le fait de bouger le slider va changer la valeur de la constante … Qui est donc variable :D Tout est normal.
Sur le 04 en QT, ça donne ça:
EDIT : J’ai ajouté un contrôle textbox pour changer la fréquence, et ça marche pas trop mal :)
