Des basses “exacerbées” peuvent être agréables au cours d’une soirée dansante. Les processeurs de diffusion DBX Driverack, tel que le PA2, intègrent un générateur de sub harmoniques permettant d’obtenir ce résultat. Toutefois, lors d’une annonce faite au(x) micro(s) (disc jockey), ces basses ajoutées, issues de mes RCF 8002 AS dans mon cas, peuvent devenir très gênantes (“bruits sourds”) sur la voix de l’annonceur. le système présenté ici désactive automatiquement le générateur du Driverack dès que l’annonceur se met à parler et réactive automatiquement le système dès que le micro n’est plus sollicité. A noter que ce système ne fonctionne que sur la version PA2 du Driverack. Le bouton d’activation/désactivation de l’application logicielle (PC, Android) est actualisé selon la dernière commande envoyée par le SubDuck.
Mise en OFF du générateur de sub harmoniques d’un DBX Driverack PA2 pendant un usage de micro.
ADAT déporté jusque sur la scène via une liaison Ethernet.
Boitier de scène : 8 sorties symétriques / 8 entrées symétriques de “sensibilité micro”.Boitier de scène en vue de dessus.Boitier de scène : 8 (2 platines superposées) préamplis micro PGA2505 à commandes numériques + PAD + 48 VA côté de la console, en liaison ADAT + Word ClockPartie “Console” dans son boitier quand mon ami Nico aura usiné les faces avant et arrière dans l’alu.
L’appli Windows de configuration. Un “Clip” s’allume en rouge en dessous du PAD de chaque voie en cas de saturation.
Le PIC a pour rôle essentiel de “surveiller” le core audio. Dès qu’un problème de réception survient, détecté par une fréquence différente de 12 KHz en provenance de la réception Ethernet, le signal “mute” est activé et la réinitialisation de la configuration du FPGA éventuellement effectuée. Cela est important pour éviter des chocs audio. Le PIC s’occupe également des liaisons avec l’application de contrôle (Le WIFI reste à développer). Certes, un soft-processeur NIOSII aurait pu être utilisé mais il n’y a plus suffisamment de place dans le FPGA.
Le système déclenchant l’envoi d’une trame ADAT se divise en deux parties afin de réduire au maximum la gigue (jitter) par rapport à WC. La fréquence élevée (196.608 MHz) associée à la prise en compte du front le plus récent pour le déclenchement des process permet d’atteindre ce but. Je me suis basé sur https://ackspace.nl/wiki/ADAT_project pour la structure de la trame. Toutefois, je n’ai pas pris en compte l’implémentation FPGA fournie (qui traite d’ailleurs du décodage d’une trame ADAT et non de l’encodage) Attention, les bits de premiers indices désignent les bits de données audio de poids fort.
L’objectif de ce site est de présenter quelques développements et réalisations à caractère électronique numérique et informatique autour de la sonorisation d’amateur.
L’accent est essentiellement mis sur la conception/réalisation de boitiers de scènes à transmission numérique : 24/8 en LVDS et – le petit dernier – 8/8 ADAT via Ethernet . Cette réalisation met en œuvre essentiellement un FPGA dont le design est écrit en VHDL. Tout est donné en essayant d’être le plus clair possible. L’ensemble peut être une bonne source de renseignements pour des étudiants et un projet d’études. A noter : ce site ne contient pas de tuto. La compréhension de ce qui est présenté impose des prérequis dans les domaines de l’électronique et de l’informatique, ainsi que dans les environnements de développements associés. N’hésitez pas à poser vos questions.
Bonne lecture et merci pour votre visite.
Jean Marc Villers – 1968 – Professeur d’Informatique Industrielle (EN) sur le Bassin d’Arcachon.
Cela fonctionne bien mais commence à être un peu “has been”, notamment la mythique 01V. Je pense qu’aujourd’hui, j’utiliserais mon smartphone pour faire la vidéo, ce serait moins flou… C’est de là que vient l’idée du Pont MIDI via Ethernet TCP/IP
Permet d’émuler un clavier ou une souris USB via une application sur tablette ou un smartphone. A partir de là, il est possible de mette en œuvre, par exemple, une surface de contrôle (à développer) pour un logiciel. Par exemple, je pilote musique.Virtual DJ depuis une application Android développée “vite fait” sous “App Inventor” dont les 3 pages écran sont ci-dessous.
L’objectif du système est de pouvoir établir une liaison sans fil sur deux canaux pour certaines configurations de sonorisation, enceintes déportées notamment. La portée en champs libre est de l’ordre de 100 m, la latence est de 23 ms. La transmission audionumérique se fait par paquets avec reprise (Ce n’est quand même pas du TCP…) et est sans compression. Toutefois, si nécessaire afin de fiabiliser la liaison, une compression SLAC peut-être appliquée.
Un émetteur (à droite) avec ses entrées symétriques XLR et un récepteur avec ses sorties XLR symétriques. L’émetteur est aussi le maitre et le récepteur est un esclave de part la technologie PurePath de Texas Instruments. Chaque appareil possède une liaison RS232 isolée galvaniquement afin de connaitre son état à distance par le report des informations de la face avant.
Face avant du module maitre : LED rouge:Liason OK. RSSI : Qualité de réception du module esclave. Cette information est envoyée par le canal auxiliaire de données. Idem pour le taux d’erreurs (Paquets non reçus). Les deux LEDs rouges éteintes sous la LED verte indiquent les CLIPs sur chaque entrée. Cette information est renvoyée au module esclave par le canal auxiliaire de données. Face avant du module esclave. Comme mentionné précédemment, les deux LEDs rouges sous la LED verte indiquent les CLIPs sur les entrées du module maitre.Vue globale de l’intérieur du module maitre.Vue de la carte mère commune. C’est la même des deux côtés. On y distingue notamment: Le module ANAREN dont l’antenne sort du coffret, un PIC 18F46K20, un convertisseur DC-DC à isolation galvanique pour alimenter le convertisseur de niveaux RS232, les lignes de données TX et RX sont isolées par un FOD8012. Le firmware intègre les routines permettant de télécharger le firmware généré par le logiciel “PurePath Wireless Configurator” de TI. Je n’ai pas acheté l’interface “CC Debugger”.Carte du CAN, un PCM1808 en boitier TSSOP, pas évident à souder mais on y arrive. Il est au milieu de la carte, sous le fil blanc. Les entrées symétriques sont assurées par des classiques NE5532 (Merci SONELEC!). Le PCM1808 est en communication I2S directement avec le module ANAREN
Carte DAC du module esclave. Le circuit est un WM8521 (version 9V) comme sur le Multipaire. Le DAC est en laison I2S avec le module ANAREN. La symétrisation pour les sortie est encore assurée par des NE5532 (Encore Merci à SONELEC)
Un “délire” commencé en 2015. Je trouvais le gros câble du multipaire analogique trop lourd et “difficile” à manipuler. Et en tant qu’amateur, difficile de m’offrir une solution numérique à partir du boitier de scène.
Les caractéristiques principales sont:
Transmission numérique sur 24 bits / 48 Khz
Latence : 20.48 µs depuis I2S CAN d’un module jusqu’à I2S DAC de l’autre module
24 Préamplis micro haute qualité (PGA2505) sur le module de scène. Le gain est à commande numérique et peut donc être réglé à distance.
Validé sur 35 m
PAD (-20 dB) et 48 V Phantom commutables à distance sur chaque voie micro
Paramétrage à distance des préamplis depuis une application de contrôle Android (Gain, PAD, 48 V Phantom). Application PC (Sous QT) en cours de finalisation.
Visualisation sur l’application de la “présence signal” et du clip de chaque voie
LED sur chaque module indiquant qu’une voie au moins clippe. Une consultation sur l’application de contrôle permet de définir la(les)quelle(s) afin de modifier le gain
Mémorisation de la configuration (Gain, PAD, 48 V de chaque voie) en mémoire F-RAM. Ainsi, le système retrouve la configuration précédente à chaque mise sous tension.
Vue globale du module de scène prévu pour être racké dans un flight 4U
Faute de temps, Il n’y a que 8 voies réalisées dans le sens scène vers console pour le moment. Toutefois, le traitement numérique fonctionne déjà pour 24 voies.
Tout est donné sur les liens ci-dessous: Designs VHDL, Sources C des microcontôleurs softcores embarqués dans les FPGA et du microcrontrôleur PIC de multiplexage des “clips”, description des trames LVDS et d’échanges avec l’application de contrôle, Java de l’application de contrôle sous Android. J’ai essayé de commenter un maximum, sauf l’application Android, que j’ai laissée “dans son jus”, développée sous Android Studio. Je ne donne aucun typon. De toutes façons, il y a eu trop de corrections. A votre EDA préféré !
A noter : Cette présentation n’est pas un “tuto”. Comprendre ce qui est exposé impose des prérequis. Si tout cela peut servir à un projet d’études, l’objectif sera alors atteint.
Les développements ont été effectués sous Quartus II 14.0 / Nios II 14.0 Software Build Tools for Eclipse / Modelsim 10.1e. On considère que ces environnements sont un minimum maitrisés.
A savoir!: – Un élément mineur a volontairement été retiré dans le design VHDL. Néanmoins, cela empêche – sans danger – le fonctionnement du système; – Une résistance manque sur un schéma. Son absence est aussi sans danger mais sa présence est indispensable. Il suffit de me contacter gentiment pour obtenir (gratuitement!) les corrections. L’objectif de la manœuvre est d’essayer pour moi de recenser les personnes intéressées par le projet.
Vue globale arrière de la partie inférieure du module de scène Les alimentations du module côté scène. De gauche à droite : +/- 5 V pour les préamplis micros (Achetée chez Audiophonics), 48 V pour les alimentations phantom (Merci Sonelec!), +/-15 V pour la symétrisations des 8 sorties (Audiophonics), 12 V / 8 A à découpage pour les parties numériques. Certes 8 A, c’est démesuré…
Vue globale du module côté console prévu pour être racké dans un flight 2U. 8 XLR mâles pour récupérer les 8 premières voies (micros, …) entrées sur le module de scène. 8 XLR femelles pour l’envoi des sorties de la console vers les amplis de la façade et des retours.
Arrière du module côté console Câble Ethernet de 35 m utilisé pour les tests. Attention! Les liaisons sont en LVDS, non en Ethernet
