RTL SDR Song Request

De Ensiwiki
Aller à : navigation, rechercher


Project schedule.png
Titre du projet RTL SDR Song Request
Cadre Projets Réseaux Mobiles et Avancés

Équipe Marius MICHAUD, Geoffrey TANGUY, Jerome THEATE
Encadrants Franck Rousseau


Introduction

Nous avons décidé, pour ce projet, de réaliser un système permettant d'exprimer des requêtes de chansons par talkie-walkie, afin de les diffuser sur un ordinateur. Le signal du talkie-walkie est réceptionné par un dongle RTL SDR. La demande vocale est envoyée sur AWS Transcribe afin de faire de la reconnaissance vocale. Une fois la demande transcrite, nous exécutons automatiquement une recherche Youtube et nous ouvrons la page correspondant au résultat le plus pertinent.


Amazon Transcribe

Afin de pouvoir comprendre le titre de la chanson demandée via le talkie walkie, l'étape de transcription - c'est-à-dire transformer l'audio reçu en texte - est essentielle.

Transcribe.png

Le choix d'Amazon Transcribe nous est apparu évident pour plusieurs raisons :

  • Amazon met à disposition une librairie Python Boto3 (version 1.9.90 utilisée pour ce projet) facilitant grandement l'automatisation
  • En tant qu'étudiant Ensimag il est possible d'obtenir $100 de crédit pour AWS (contacter un responsable de filière pour plus d'information)
  • L'utilisation de ce service nous évite d'avoir à entraîner un réseau de neurones pour faire la reconnaissance

La meilleure piste pour commencer à utiliser Amazon Transcribe via la librairie Boto3 est le tutoriel fourni par Amazon.

1 transcribe.start_transcription_job(
2     TranscriptionJobName=job_name, # Nom du job qui doit être unique (utiliser la date par exemple)
3     Media={'MediaFileUri': job_uri}, # URL du fichier audio à transcrire hébergé dans un bucket S3
4     MediaFormat='wav', # Format du fichier en entrée
5     LanguageCode='en-US'# Langue de l'audio
6 )

NB: La transcription en français n'est pas disponible sur Amazon Transcribe (février 2019), le plus proche est le français Canadien (code fr-CA) mais les performances sont très mauvaises tant en matière de durée que de qualité de transcription.

Gestion de la connexion à AWS

Pour éviter d'inscrire ses identifiants de connexion à AWS en dur dans le code et de préciser à chaque fois quel serveur utiliser, il est possible de fournir des paramètres par défaut. Pour ce faire créer un dossier .aws dans le home (Unix) de votre machine, avec les deux fichiers suivants:

  • config
1 [default]
2 region=us-west-2
  • credentials
1 [default]
2 aws_access_key_id=AKIAIOSFODNN7EXAMPLE
3 aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Vérifier bien que AWS transcribe est disponible dans la région que vous choisissez dans le fichier config.

Vous pouvez obtenir vos identifiants de connexion à AWS sur l'AWS Management Console : après vous être identifié, cliquer sur votre nom en haut à droite de la page, cliquez sur "Security Credentials" dans le menu déroulant et rendez-vous dans la section "Access Credentials".

Performances

Un point important à mentionner est que AWS Transcribe n'est pas initialement optimisé pour traduire des segments audio très courts tels que ceux générés par notre projet type song request (typiquement 5 secondes au plus).

A titre indicatif les performances augmentent drastiquement avec la longueur du fichier: un clip de 10 minutes prend environ 5 minutes, un clip de 40 minutes environ 17 minutes et un clip de 2 heures environ 36 minutes.

La conséquence principale est que les durées de transcription sur notre projet sont d'environ 3 minutes (transcription de l'anglais) ce qui constitue un frein à une utilisation "immédiate" de notre application, dans le sens où l'on ne peut pas avoir la chanson qui se lance à peine après avoir fini de parler dans le talkie-walkie. Dans le cadre de ce proof of concept, cette latence ne nous empêche pas de démontrer la faisabilité du projet.

L'une des améliorations envisagées serait de privilégier une solution de transcription temps réel, telle que celle développée par AWS fin de l'année 2018. Cependant, au début de l'année 2019, cette technologie n'est embarquée que dans les packages Java - la fonctionnalité repose sur des flux http2 bidirectionnels, pour le moment uniquement supporté en Java, pour émettre l'audio tout en recevant le texte transcrit.


Logiciels utilisés

GnuRadio Companion version 3.7.9

Gnuradio.svg

Logiciel de traitement du signal. Proposant notamment la détection du dongle RTL SRD utilisé dans le cadre de ce projet.
En outre de multiples options de filtrage (filtre passe bas, passe bande) ainsi que de redirection du flux audio génèré sont disponibles (sortie audio standar, enregistrement de fichier audio). Gnu Radio est un logiciel très complet, open source, dont l'extension sous version graphique (Gnu Radio Companion) est très intuitive. Les éléments sont facilement disposés sous forme de blocs graphiques permettant de concevoir facilement le processus de traitement du signal.
De nombreux forums permettent en outre un soutien complet et une prise en main facilitée.

L'une des difficultés rencontrées dans le cadre de ce projet a été d'adapter la chaîne de traitement du signal à notre matériel. Les cours de notre lointaine époque de classe préparatoire nous ont fait défaut.
Nous avons ainsi préféré utiliser une solution open-source, basée sur GnuRadio, et implémentant l'ensemble des traitements nécessaires à notre projet : GQRX.
De ce fait l'abandon de GnuRadio n'a pas porté préjudice à notre projet, puisque remplacé par une solution jugée plus adaptée.


Exemple de schéma blocs GnuRadio Companion

GQRX version 5.3.1

Ce logiciel de traitement du signal, conçu à partir de Gnu Radio, automatise la chaine de traitement du signal dans une interface graphique très intuitive et ergonomique.
Proposant une solution clé en main bien que limitée dans ses options de personnalisation, GQRX nous est apparu comme étant le logiciel adéquat pour mener notre projet. Les différents traitements embarqués et automatisés par GRQX étaient suffisants pour détecter, débruiter et enregistrer nos signaux radios.
Au sein de notre projet - dédié à la réception de flux audios émis par talkie walkie puis traduit en requête Youtube - l'une des principales limites rencontrées avec GQRX a été son insertion au sein de notre application. Bien que très performant, ce logiciel est en partie paramétré via son interface graphique. L'unique solution permettant d'automatiser le lancement et le paramétrage de GQRX serait d'utiliser un logiciel de manipulation d'IHM, tel que : xdotool.

N.B. : Pour de plus amples informations, l'option -h de gqrx permet d'afficher l'aide. L'option -c demande le chargement d'un fichier de configuration permettant de paramétré en partie grqx au lancement.

Fenêtre GQRX

Les étapes de configuration GQRX :

  • La bande de fréquences étudiée a dû être paramétrée sur 446 MHz (plus précisément 445,99 MHz pour notre Talkie-walkie)
  • Les options de filtrage Filter width et Filter shape peuvent être laissées sur normal dans un premier temps. Une étude plus approfondie des options disponibles permet de mieux filtrer le bruit si le son traité n'est pas de qualité suffisante. Un lien pertinent pour le paramétrage de GQRX juste ici.
  • Nous pouvons démarrer la réception des signaux radio via le premier bouton de l'IHM, en haut à gauche.

Bien que le lancement de GQRX doive passer par son IHM, il est possible de réaliser l'analyse du flux audio sortant dans notre programme. Pour cela, nous devons activer une nouvelle option :

  • démarrer la redirection telnet via le septième bouton de la barre des tâches de l'IHM tel que présenté sur l'image ci-dessus.

Dès lors, il suffit de créer une socket TCP et de se connecter sur le port de la redirection (port 7356 en localhost par défaut) :

1 import socket
2 
3 """ Création de la socket et connexion au flux du programme QGRX """
4 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # socket avec configuration par défaut
5 sock.connect(("localhost", 7356)) # établissement de la connexion
6 sock.sendall(<une commande GQRX>) # envoie d'une commande à GQRX
7 sock.recv(1024) # receptionne une réponse pouvant aller jusqu'à 1024 bits

Différentes commandes peuvent être soumises à GQRX une fois celui-ci contrôlé par Telnet : paramétrage de la fréquence, obtention de la fréquence étudiée, obtention du mode de démodulation, etc.
L'une d'entre elles nous permet de prendre connaissance de la puissance du son en sortie de traitement GQRX afin de détecter une transmission entrante, puis inversement, de détecter une fin de transmission.

1 s.sendall(b"l STRENGTH\n") # envoie de la requête binaire à GQRX
2 signalStrength = float(s.recv(1024)[:-1]) # on parse la réponse pour connaître la puissance du signal

Nous pouvons désormais détecter une élévation de la puissance sonore afin d'adapter le comportement de l'application.
Dans le cadre de ce projet, nous redirigions le flux audio de GQRX dans un fichier .wav afin de faciliter la suite de nos traitements.


Les avantages de GQRX : Les limites de GQRX :
  • Interface graphique facilitant le paramétrage radio
  • Facilité de prise en main
  • Option de contrôle à distance
  • Interface uniquement graphique limitant l'intégration de GQRX au sein de programmes tiers
  • Options de traitement du signal réduit comparativement aux fonctionnalités natives de GnuRadio


Automatisation et Sous-routines

La mise en place de la détection d'une communication entrante sur le talkie walkie est assurée par un daemon python. Ce dernier se connecte via une socket TCP au flux audio sortant de GQRX. Dès réception d'une communication - détectée par une élévation de la puissance du signal comparativement au bruit ambiant - le flux audio est redirigé vers un fichier audio .wav. À l'issue de l'enregistrement d'une transmission radio, le fichier audio généré est automatiquement traité par une sous-routine instanciée par le daemon. Ce nouveau traitement est principalement assuré par une succession de scripts Shell. Ces derniers opèrent dans l'ordre :

  • la détection du système sur lequel tourne le programme afin de déterminer les paramètres Amazon Web Service (AWS) correspondant.
  • la dépose du fichier audio à traiter sur un bucket S3 AWS correspondant à la session en cours grâce aux identifiants précédemment déterminés.
  • l'exécution de la transcription textuelle de l'audio par Amazon Transcribe.
  • la récupération de la page Youtube la plus pertinente par rapport au texte transcrit avec des wget.
  • l'ouverture de la vidéo dans le navigateur Firefox.

En parallèle de l'exécution des traitements audio, le daemon instancie une sous-routine destinée à lui signaler la fin du processus si la commande 'Stop recording' est transmise depuis le talkie-walkie.
Si nous détectons cette commande particulière, une fois le texte transcrit retourné par AWS Transcribe, alors elle est interprétée par la sous-routine qui par sa terminaison indique au daemon de terminer tous ses processus fils puis de s'arrêter.


Matériel utilisé

Dongle RTL SDR

Dongle.jpg

Une problématique majeure qui s'est posée dès le début du projet est celle de la réception du signal par l'ordinateur. Un dongle RTL SDR est un scanneur de signaux radio à prix abordable. Il permet de scanner les ondes ayant une fréquence de 500kHz à 1,75GHz.

Un de ses principaux avantages est qu'il est très apprécié et utilisé par la communauté open-source, qui a assuré une prise en charge par de nombreux logiciels.

Nous avons toutefois rencontré plusieurs soucis lors de l'utilisation de ce dongle:

  • La connectique USB est défectueuse, il faut s'assurer que le dongle est bien stable au risque d'importantes pertes de performance
  • Après environ une demi-heure d'utilisation, la qualité des enregistrements se dégrade (bruits additionnels) ce que nous avons attribué à une surchauffe du dongle. Le logiciel de traitement des signaux radio et de gestion de l'audio utilisé - GQRX - ne parvenant pas à endiguer ce bruit additionnel, cela provoque une gêne pour notre application où la clarté du signal est essentielle afin que AWS Transcribe puisse interpréter correctement le fichier audio. La transcription AWS devient ainsi moins fiable quelques dizaines de minutes après le déploiement de l'application.

L'une des solutions envisagées pour pallier ce problème serait d'investir dans un dongle plus performant (plus cher).

Talkie-Walkie PMR 3000R


Talkie.jpg

Nous avons choisi le talkie-walkie par opportunité, un exemplaire étant déjà possédé par un des membres de notre projet.

Il s'agit d'un modèle relativement vieux (10-15 ans), en unique exemplaire (le device partenaire n'ayant pas survécu au temps), émettant en analogique et pouvant utiliser la bande de fréquences des 446MHz.

Ce modèle est mal documenté sur Internet, et nous ne possédons aucune autre documentation, mais il y a une jolie photo pour la postérité !