Introduit en 1980 par le fabricant danois Bang & Olufsen avec le système Beolab 8000, le protocole Datalink 80 raccorde par un bus de données les différents appareils d’un même système , offrant à l’utilisateur un contrôle unifié sur ce dernier. Ainsi, une télécommande unique contrôle l’ensemble du système, et commencer la lecture sur un appareil provoque le basculement automatique de l’amplificateur sur l’entrée associée, ainsi que la mise en pause des autres appareils. Le protocole évolue au fil des années, voyant notamment, avec le Beosystem 5500, l’addition d’une transmission en temps réelle de l’état des appareils, alors affiché sur la télécommande (Master Control Panel 5500)
Étant propriétaire d’un système 5500 (BEOMASTER 5500, BEOCORD 5500, BEOGRAM CD 5500, et MASTER CONTROL PANEL 5500), j’ai souhaité lui ajouter une fonction Bluetooth audio, qui, contrairement à un adaptateur Bluetooth Audio classique, exploiterait le protocole Datalink pour offrir la même interface de contrôle que les autres éléments du système.
Le BEOMASTER 5500 étant doté d’une entrée TP2 permettant le contrôle d’un second BEOCORD, j’ai entrepris de concevoir un récepteur Bluetooth capable de simuler un BEOCORD 5500 sur le bus Datalink. Ce récepteur relaie les commandes du système (PLAY/PAUSE, etc.) via Bluetooth et transmet les informations sur la piste en cours de lecture au système.
Après un premier prototype à base d’ESP32 ne me donnant par entièrement satisfaction (codec SBC seulement, et stabilité de la connexion marginale), j’ai remanié le projet autour d’un module BM83 de Microchip, et je suis parvenu à un résultat satisfaisant, que j’ai nommé le BEOTOOTH 5500.
Sous la forme d’un boitier de 66mm de coté, et 27mm de haut, il dispose d’un câble (solidement maintenu en place par un support anti-arrachement) terminé par une prise DIN 7 broches pour se raccorder aux prises TP ou TP2 des équipements B&O, ainsi que d’une prise USB-C pour son alimentation. (5V, 100mA). De part de d’autre de la prise USB-C sont disposées une LED rouge qui indique l’état de la liaison Bluetooth (En veille / Connecté / Appairage), ainsi qu’un bouton poussoir, qui permet par un appui court d’entrer en mode appairage, ou par un appui prolongé (10 secondes) d’oublier tous les appareils appairés.
Ses principales fonctions sont :
La vidéo ci dessous démontre ces fonctionnalités :
Le BEOTOOTH 5500 est compatible avec tout appareil doté d’une interface Datalink (DIN 7 broches) et a été testé (par les membres du forum Beoworld) avec les systèmes suivants :
Appareil | Affichage du statut | Note |
Beomaster 5500 | Oui | Etat en temps réel sur entrée TP1 seulement |
Beosystem 2500 | Non | |
Beocenter 9500 | Non | |
Beomaster 5000 | – | |
BeoMaster 7000 | Oui | Statut affiché sur MCP6500, Confirmé OK contrôle et affichage status sur BL7000 et BL5000 |
Beosound Ouverture | Non | |
MCL2AV | Non | |
Beomaster 4500 | – | |
BeoSound 3200 | Non | Audio seulement ! Pas de liaison de donnée Datalink ! |
Il est possible de mettre à jour son micrologiciel simplement en le raccordant à un ordinateur (Windows ou Linux) via un câble USB-C.
Le BEOTOOTH 5500 est disponible assemblé et prêt à l’emploi, ou sous forme de kit incluant : la carte électronique préassemblée, la led rouge, le cable, la prise DIN 7 broche, le boitier usiné adéquatement, la pièce de support du câble, la visserie nécessaire, ainsi que l’étiquette. Le kit contient l’ensemble des éléments nécessaires à l’assemblage, mais nécessite des compétences en soudure électronique.
Un guide de montage et d’utilisation (en anglais) est disponible ici : Beotooth_Manual_V1.1
Si vous souhaitez acquérir un BEOTOOTH 5500, ou pour toute question, merci de publier un commentaire avec votre adresse e-mail, et je vous répondrai dans les plus bref délais.
Installation réalisée sous Linux Mint 20 avec un kernel 5.4
Une distro 64bit fonctionne parfaitement. Se référer à mon précédent article http://pila.fr/wordpress/?p=1078
Les cartes graphiques AMD exploitant le nouveau code d’affichage « DC » provoquent un kernel panic. Il faut ajouter la commande suivante dans le fichier /etc/default/grub pour utiliser l’ancian code :
amdgpu.dc = 0
Ne pas oublier d’appliquer les changements :
$ sudo update-grub
Sur cette machine, le taux d’occupation CPU restait important même au repos. Il s’avère que l’IRQ 9 est déclenchée à une fréquence très élevée (indiqué par le compteur du fichier /proc/interrupts), et monopolise à elle seule un des coeurs CPU. Les compteurs lisibles dans les différents fichiers à l’emplacement /sys/firmware/acpi/interrupts nous permettent de déterminer la source de cette IRQ : gpe11. Un service systemd nous permet de la désactiver, en créant le fichier /etc/systemd/system/disableGPE11.service avec le contenu suivant :
[Unit]
Description=Disables GPE 11 going crazy on this MacPro
[Service]
ExecStart=/bin/bash -c 'echo "disable" > /sys/firmware/acpi/interrupts/gpe11'
[Install]
WantedBy=multi-user.target
Ce service est rendu actif par la commande suivante :
$ sudo systemctl enable disableGPE11.service
Cet article décrit la réparation d'une minichaine Dynabass DBT150, qui refusait obstinément de s'allumer.
La DBT150 est une minichaine sur pied, avec fonctions radio / CD / USB / AUX / Bluetooth... et celle-ci refuse de fonctionner !
On y découvre que le transformateur d'alimentation est endommagé au delà de toute possible réparation, et comment contourner le problème en remplaçant toute l'alimentation par des éléments courants.
La séparation du pied, puis le démontage du panneau arrière s'effectuent en retirant les multiples vis de la face arrière :
Mes premiers soupçons se portent sur la carte située entre la prise secteur et le transformateur :
Le rôle de cette carte semble être de commuter, sur demande du microcontrôleur central, l'alimentation du transformateur général. Soit celui-ci est relié directement au secteur, soit il l'est à travers le condensateur rouge. S'agirait-il d'une bizarrerie visant à respecter les normes de consommation en réduisant la consommation du transformateur lorsque l'appareil est en mode de veille ?
Quoi qu'il en soit, la carte est rapidement mise hors de cause, le primaire du transformateur s'avère être ouvert. La cause semble être une diode de redressement située sur l'un des enroulements secondaires du transformateur qui est en court circuit ; le secondaire du transformateur s'est alors retrouvé en court circuit une alternance sur 2, causant un fort échauffement, et le déclenchement du thermofusible intégré à son enroulement primaire.
Malheureusement, la construction du transformateur empêche toute tentative de débobinage / réparation de ce dernier, et ses caractéristiques non standard prohibent l'obtention d'une pièce de remplacement. Il va donc falloir recréer une alimentation complète. Commençons par étudier la topologie du système :
Étrangement, le bloc lecteur CD / USB est alimenté par un enroulement dédié du transformateur, son alimentation est totalement isolée du reste de l’électronique sur la carte principale. Cette conception m'a initialement fait craindre que les deux rails d'alimentation ne partagent pas la même masse, ce qui aurait compliqué la réalisation d'une nouvelle alimentation basée sur des éléments préexistants. Heureusement, les masses sont en réalité raccordées au sein du bloc lecteur CD / USB. Le fait de ne pas les raccorder sur la carte principale a probablement pour objectif réduire le bruit qui pourrait être causé par une boucle de masse.
Cependant, lors de la réalisation de la nouvelle alimentation, je vais devoir mettre en commun les masses au niveau de l'alimentation. Je prévois en effet une alimentation principale délivrant la tension de 26V, et l'emploi d'un convertisseur buck (DC/DC non isolé) pour générer la seconde alimentation destinée au bloc lecteur CD / USB. Ne pas raccorder la masse au niveau de l'alimentation signifierait que tout le courant retournant du bloc lecteur CD/USB circulerait à travers la masse du câble de petite section destiné aux signaux audio, ce qui au mieux dégraderait la qualité sonore de façon bien plus marquée d'une boucle de masse, ou au pire pourrait endommager ce câble.
Le schéma de la nouvelle alimentation est le suivant :
Celle-ci repose sur un chargeur de PC portable pour générer la tension principale de 19V alimentation l'amplificateur et l'essentiel de l'électronique. Bien qu'inférieure à la tension originale de 26V, celle-ci devrait suffire à délivrer un niveau sonore satisfaisant. Un module DC/DC à base de LM2596, qui prend place dans l’alcôve du transformateur, permet de générer la tension d'alimentation de 11V pour le bloc lecteur CD / USB.
Les raccordements du convertisseur DC/DC et du chargeur de PC portable sont réalisés à la place des ponts de diodes
L'emplacement original de la connectique secteur contient maintenant le raccordement du chargeur de PC portable
Vient le moment fatidique, la mise sous tension !
Tout fonctionne parfaitement, aucune saturation détectable à l'oreille (c'était ma principale inquiétude quant à l'emploi d'une tension plus faible que celle d'origine)
Un effet intéressant lié à l'utilisation d'une alimentation à découpage à place de l'ancienne alimentation : lorsque l'on débranche le secteur, l'alimentation se maintient pendant plusieurs seconde (le chargeur de PC portable est prévu pour délivrer jusqu'à 4A, ici on consomme rarement plus de 0.5A). Donc pas d'interruption de la musique en cas de micro-coupure du réseau EDF !
En espérant que si toi lecteur tu es arrivé jusqu'ici, c'est que cet article t'a permis de réparer ta minichaine
Il y a 2 ans déjà, je publiais 2 articles décrivant comme réutiliser un Minitel comme terminal linux USB :
Cependant, si le premier article est toujours aussi pertinent, avec la migration des distributions Linux vers systemd, le nouveau gestionnaire de démarrage, le second article ne permet plus de configurer les Linux moderne pour utiliser le Minitel comme terminal.
Cet article vise donc à décrire la procédure nécessaire pour réaliser cette opération avec systemd sur Raspberry Pi sous la distribution Raspbian, mais cette procédure devrait s'appliquer, éventuellement avec des modifications mineures, à tout autre matériel exécutant une distribution Linux dotée de systemd.
Tout d'abord, systemd n'utilise plus le fichier innitab et les scripts de démarrages, mais raisonne en terme de services, chaque service étant décrit par un fichier contenant la commande à exécuter, des diverses informations, telles que les dépendances du services.
Un service en particulier est dédié à la gestion des terminaux série : serial-getty@.service
Cependant, il ne comporte pas les bonnes options de configurations pour dialoguer avec un Minitel, nous allons donc créer notre propre service, adapté à cet effet. :
Commençons par créer une copie du service, qu'on modifie ensuite :
sudo cp /lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty-minitel@.service
sudo nano /etc/systemd/system/serial-getty-minitel@.service
Les modifications apportées au fichier concernent la ligne de commande exécutée (getty avec les options adéquats, à la place de agetty), et la suppression de l'attente de plymouth pour démarrer ( en gras ci-dessous)
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service
After=rc-local.service# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes[Service]
ExecStart=-/sbin/getty -L -i -I "\033\143" %i 4800 minitel1b-80
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes[Install]
WantedBy=getty.target
Ensuite, il ne reste plus qu'à ajouter un lien sur ce fichier dans le répertoire getty.target.wants. Ce lien comporte une indication sur le périphérique concerné (ici ttyUSB0). systemd remplacera toutes les occurrences de %i dans le fichier serial-getty-minitel@.service par cette valeur.
sudo ln -s /etc/systemd/system/serial-getty-minitel@.service /etc/systemd/system/getty.target.wants/serial-getty-minitel@ttyUSB0.service
On redémarre le processus de systemd :
sudo systemctl daemon-reload
Puis on lance manuellement notre service (ou on redémarre le raspberry)
sudo systemctl start serial-getty-minitel@ttyUSB0.service
Et voilà, on retrouve le même fonctionnement obtenu précédemment en modifiant le fichier inittab
Pour plus d'info sur l'utilisation du minitel comme terminal sous Linux, voir les parties précédentes :
Source : doc serial-getty@.service