Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi)

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierPila's blog

ESP32 : Un script bash pour paramétrer les variables d’environnement

Par Pila

Attention : valable uniquement pour les versions de ESP-IDF non basées sur CMAKE ( versions < 4.0 )

Travaillant actuellement sur un projet nécessitant une interface audio en bluetooth, je me suis tourné vers la solution la plus en vogue, l'ESP32.

Embarquant Wifi, Bluetooth (dont BLE), un CPU dual core avec 4 Mo de Flash, mais également très abordable, il dispose également d'un SDK entièrement open-source, très bien documenté !

La procédure d'installation de ce SDK nécessitant de modifier certaines variables d'environnement ( en particulier la variable PATH ), et n'aimant pas modifier des éléments aussi critiques du système ( il est possible en modifier de PATH de remplacer certaines commandes du système à l'insu de l'utilisateur ! ), j'ai donc, avant toute expérimentation avec l'ESP32, pris le temps d'écrire un petit script bash.

Ce script permet de démarrer un nouvel interpréteur BASH contenant les variables d'environnements permettant le bon fonctionnement du SDK ESP32, sans affecter les variables d'environnement utilisées par tous les autres terminaux du système. De plus, il possède un prompt de commande personnalisé, afin de distinguer rapidement le terminal utilisé pour le SDK.

Son contenu, succin, est le suivant :

!/bin/bash
bash --rcfile <(cat ~/.bashrc; echo 'PS1="\e[33;1mesp32 \$\e[0m "' ; echo 'export PATH="$HOME/esp32/xtensa-esp32-elf/bin:$PATH"' ; echo 'export IDF_PATH="$HOME/esp32/esp-idf"')

Attention : il est supposé que l'ensemble des fichiers nécessaires au SDK se trouvent dans le dossier ~/esp32. Si ce n'est pas le cas, modifier les chemins en conséquence

Il suffit d’exécuter le script pour obtenir un interpréteur BASH adéquat, et de quitter l'interpréteur (commande"exit", ou CTRL+D) pour revenir à un terminal normal.

J'ai testé son fonctionnement quelques heures, et en suis tout à fait satisfait. N'hésitez pas à me communiquer tout bug, ou amélioration possible !

Machine a pince EXPENDEDORA « A-BIFUCA » : Configuration et mod

Par Pila

Ayant été confronté à la configuration de cette machine à pince, et devant le peu de documentation disponible sur le web, j'ai décidé de rédiger ce bref article regroupant mon expérience avec cette machine

source : http://www.mapefe.com/gruas.html

Configuration

La configuration s'effectue en enclenchant l'interrupteur situé derrière le monnayeur. Attention, contrairement aux apparences, il s'agit d'un interrupteur 2 à positions stables : 1 appui passe en mode configuration, et un second appui est nécessaire pour en sortir.

Les différents paramètres sont reconnaissables par leur numéro sur l'afficheur 7 segment. On passe au paramètre suivant en poussant le joystick vers la gauche, et on change la valeur en poussant le joystick vers la droite. Certains paramètres ne sont pas modifiables, comme les compteurs de nombre de parties.

L'ensemble des paramètres disponibles sont regroupés dans le tableau suivant. Malheureusement, le rôle de certains m'échappent encore (la fonction de ces paramètres est marquée d'un point d'interrogation dans le tableau), si vous en savez plus, n'hésitez pas à me contacter, je mettrai à jour cet article.

Paramètre Valeur orig Valeurs possibles Incrément Fonction
1 0 [0:1] 1 ?
2 10 [0:10] 1 Nombre arrêt descente pince possibles
3 0 [0:1] 1 Descente pince dans conduit
4 50 0 + [50:99] 1 Rentabilité ?
5 0 [0:1] 1 Désactiver son descente pince
6 0 [0:1] 1 Désactiver autre son ( son gagnant ) ?
7 0 4155 Compteur nombre de crédits
8 0 0622 Compteur parties gagnées
9 0 0002 Compteur triche monayeur ?
10 ?
11 10 [10:30] 5 Durée partie
12 2 [0:10] 1 Nombre de pièces (1€) pour jouer
13 1 [0:10] 1 Nombre de parties
14 0 [0:1] 1 Autoriser mouvement pince au sol
15 1 [0:1] 1 ?
16 0 [0:1] 1 ?

Pour valider la configuration souhaitée, il suffit de repasser en mode exploitation, en appuyant sur le bouton situé derrière le moniteur.

Mise en lecture seule de l'EEPROM

Dans l'environnement où cette machine est utilisée (coupures de courant fréquentes), il est vite apparu que cette machine avait un gros défaut de fiabilité. Des dysfonctionnement réguliers, allant du changement de valeur aléatoire de certains paramètres de la configuration, au refus pur et simple d'accepter des pièces, furent observés. Tous ayant pour point commun des valeurs aberrantes de certains paramètres ( parfois totalement en dehors de la gamme de valeurs possibles ). Il est vite devenu évident que l'EEPROM stockant les paramètres devenant corrompue, probablement à la suite d'une coupure de courant intervenue au mauvais moment (lors de l'écriture de l'EEPROM).

Située dans un coin de la carte, il s'agit d'une CI 24LC04B, une EEPROM 4K interfacée en I²C, produite par Microchip.

La documentation de ce CI indique qu'une broche (nommée WP), permet, en la raccordant au VCC, d’empêcher l'écriture de l'EEPROM, ce qui résoudrait sans doute mon problème de fiabilité !
Malheureusement, cette broche est reliée à la masse via une piste située juste en dessous de l'EEPROM. Il est donc d’abord nécessaire de dessouder cette dernière, pour pouvoir couper cette piste :

Ensuite, il ne reste plus qu'à réinstaller l'EEPROM, une résistance de 1kohms tirant cette broche à la masse, et un petit cavalier permettant de la raccorder directement au VCC, engageant ainsi la protection en écriture :

Attention tout de même : il est nécessaire de retirer le cavalier avant de modifier la configuration de la machine, sans quoi les modifications ne seront pas appliquées. De plus, en cas de coupure de courant pendant une partie, les crédits en cours ne sont plus sauvegardés ! Dans mon cas, la machine étant exploitée comme objet de décoration, il s'agit plus d'un avantage que d'un inconvénient.

Modification du monnayeur

Cette machine étant utilisée en décoration et comme objet de loisir, le monnayeur a été retiré, et remplacé par un détecteur optique ( réalisé à partir d'un détecteur optique à fourche), créditant toute pièce et la rendant immédiatement au joueur. Quelques photos de cette modification :

  • La fourche optique donneuse
  • La partie émetteur/bornier
  • La partie émetteur installée
  • La partie récepteur installée dans le monnayteur modifié (retrait du bloc monnayeur, replacé par un guide pièce en plexiglas doté de chicanes pour ralentir la pièce)
  • Récepteur, coté pistes
  • Emetteur, coté piste

Si cet article vous a été d'une aide précieuse, ou si vous pensez qu'une information est manquante, n'hésitez pas à m'en faire part dans les commentaires !

Édition de tag RFID MIFARE sous Linux avec le lecteur ACR122

Par Pila

Ayant récemment acquis un lecteur NFC ACR122, je m'attendais à trouver un logiciel me permettant de l'exploiter simplement sous Linux Mint.

Étonnamment, je n'en ai pas trouvé, et l'emploi du lecteur pour programmer des tags Mifare s'est avéré moins intuitif que je ne l'espérait.

Après quelques heures de galère, voilà un résumé de la procédure :

Installation

Installer libnfc et ses outils :

$ apt install libnfc-bin

Modifier le fichier /etc/modbprobe.d/blacklist-libnfc.conf pour inclure le driver pn533_usb. En effet, celui ci (ainsi que les autres déja inclus dans ce fichier ) interfèrent avec le bon fonctionnement du pilote utilisé par libnfc :

$ echo "blacklist pn533_usb" >> /etc/modprobe.d/blacklist-libnfc.conf

Redémarrer la machine ( cette fois ci le bon pilote sera chargé ).

Lister les tags visibles

Lister les tags visible s'effectue avec la commande nfc-list :

A vide (sans tag sur le lecteur )


$ nfc-list
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opene

Avec un tag Mifare sur le lecteur ( UID = A4 0B 44 76 )

$ nfc-list 
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): a4 0b 44 76
SAK (SEL_RES): 08

L'option -v permet d'en savoir plus sur le tag détecté ( ici un tag différent de celui lu précédemment ) :

$ nfc-list -v
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04  
* UID size: single
* bit frame anticollision supported
       UID (NFCID1): ec  11  9c  1e  
      SAK (SEL_RES): 08  
* Not compliant with ISO/IEC 14443-4
* Not compliant with ISO/IEC 18092

Fingerprinting based on MIFARE type Identification Procedure:
* MIFARE Classic 1K
* MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation
Other possible matches based on ATQA & SAK values:

0 Felica (212 kbps) passive target(s) found.

0 Felica (424 kbps) passive target(s) found.

0 ISO14443B passive target(s) found.

0 ISO14443B' passive target(s) found.

0 ISO14443B-2 ST SRx passive target(s) found.

0 ISO14443B-2 ASK CTx passive target(s) found.

0 Jewel passive target(s) found.

Lecture / écriture

Les opérations de lecture / écriture sur un tag Mifare Classic s'effectuent avec la commande nfc-mfclassic. Les clés par défaut sont utilisées mais il est possible de spécifier sont propre fichier de clé ( cf man nfc-mfclassic)

Lecture du contenu du tag et enregistrement dans le fichier mifare.mfd

$ nfc-mfclassic r a mifare.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): a4 0b 44 76
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Reading out 64 blocks |……………………………………………………….|
Done, 64 of 64 blocks read.
Writing data to file: mifare.mfd …Done.

Ecriture du tag depuis le fichier mifare.mfd

$ nfc-mfclassic w a mifare.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): a4 0b 44 76
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Writing 64 blocks |………………………………………………………|
Done, 63 of 64 blocks written.

Edition du contenu

Pour l'édition, l'emploi d'un editeur hexadécimal est nécessaire. Je recommande bless. Pour faciliter la lecture du contenu, je préconise d'ajuster la taille de la fenêtre pour afficher 16 octets sur chaque ligne, ainsi chaque ligne contient 1 bloc du tag :


En rouge le bloc 0 contient l'UID de la carte

En jaune le bloc 4 contient les données que j'y ai écrit

Le premier bloc de chaque secteur contient les permissions d'accès. Par défaut l'accès en lecture / écriture est possible avec les clés d'origines. Le bloc 0 est en lecture seule. Attention de ne pas modifier la longueur du fichier ( utiliser le mode remplacement plutôt que le mode insertion avec la touche "insert" du clavier )

Les 16 caractères d'un bloc me suffisant pour mon application, et n'ayant pas de problématique de sécurité, cet article touche à ça fin. Peut être le compléterais-je plus tard si je venais à devoir stocker des données sur plusieurs blocs, ou à mettre en place différentes clés pour l'accès aux données. Ce second cas est cependant improbable, étant donné que les carte Mifare sont gravement défaillante d'un point de vue sécurité (cf les nombreux article sur le web concernant la récupération des clés, ainsi que la possibilité d'obtenir des cartes dont le bloc 0 est accessible en écriture )

Raspberry Pi : Du son en réseau avec Jack

Par Pila

Il y a déjà 5 mois, j’expérimentais la transmission de son en réseau avec PulseAudio.

Bien que concluant, le système péchait par sa latence (certes faible, mais toujours perceptible), et son manque de stabilité.

Je me suis depuis penché sur Jack. Il s'agit d'un serveur son pour Linux, axé productivité musicale.

Il est possible de le configurer pour transmettre du son sur le réseau, mais le manque de documentation rend la tâche ardue.

J'ai pu obtenir un système assez stable après de nombreux essais, permettant d'utiliser un Raspberry Pi comme sortie son distante, avec une latence quasiment imperceptible.

Le projet repose sur l'utilisation de NetJack2, la 2ème révision du protocol réseau de Jack, ainsi que l'utilisation de Jack_Autoconnect, et a pour objectif de rendre le fonctionnement aussi fiable que possible.

J'ai rendu l'ensemble disponible sur GitLab : https://gitlab.com/Pilatomic/networkedjack

Le résultat est très satisfaisant, mis a part un unique problème restant : le client ne doit pas être stoppé pendant que le serveur est en fonctionnement, sous peine de devoir redémarrer le serveur. Il est sans doute possible de le régler avec un petit script bash, qui ping continuellement le client, et arrête le serveur lorsque le client n'est pas joignable, mais cette situation n'étant pas pénalisante dans mon cas, je ne me suis pas penché sur le sujet.

L'ensemble est suffisamment fiable, je l'utilise pour de la transmission de son en temps réel en entreprise

Raspberry Pi : Du son en réseau avec PulseAudio

Par Pila

Cet article décrit comment utiliser le Raspberry Pi comme sortie son ( sink ) distante ( en réseau ), pour un ordinateur sous Linux.

Il exploite les capacités réseau de PulseAudio, tant coté Raspberry que sur l'ordinateur source.

2 méthodes de connexions sont proposées :

  • La découverte automatique du Raspberry par Pulseaudio, simple et pratique, mais pas toujours très fiable
  • La configuration manuelle du Raspberry comme sortie son "tunnel" sur l'ordinateur source

Configuration du Raspberry Pi

Installer les packages nécessaires :

$ apt-get install pulseaudio avahi-daemon dbus-x11

Configurer PulseAudio, en ajoutant à la fin du fichier /etc/pulse/system.pa, la ligne suivante (dans ce cas, tous les clients du réseau 192.168.0.0/24 sont autorisés à se connecter)

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24

Ajouter ensuite un service systemd pour PulseAudio, en créant le fichier /etc/systemd/system/pulseaudio.service, avec pour contenu :

[Unit]
Description=PulseAudio Daemon

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
PrivateTmp=true
ExecStart=/usr/bin/pulseaudio --system --realtime --disallow-exit --no-cpu-limit

Il ne rester qu'à activer le service, puis à le démarrer :

$ systemctl enable pulseaudio

$ systemctl start pulseaudio

A ce stade, la mise en place du coté du Raspberry Pi devrait être achevée. Cependant, chez moi, cette configuration produisait des craquements très audibles.

Le problème a été résolu en éditer le fichier /etc/pulse/system.pa, et en remplaçant la ligne

load-module module-udev-detect

Par

load-module module-udev-detect tsched=0

A partir de là, 2 choix (qui ne sont pas mutuellement exclusifs, les 2 cohabitent très bien) s'offrent à vous :

Découverte manuelle :

Plus fiable que la découverte automatique, mais plus contraignante (nécessite de configurer chaque ordinateur voulant exploiter la sortie son du Raspberry, et ne fonctionne pas si le Raspberry n'est pas joignable au démarrage de l'ordinateur source)

Sur l'ordinateur source, ajouter dans le fichier /etc/pulse/default.pa la ligne suivante :

load-module module-tunnel-sink-new server=XXX.XXX.XXX.XXX sink_name=Remote sink_properties="device.description='Raspberry'" channels=2 rate=44100

En indiquant l'adresse IP du Raspberry

Découverte automatique

Sur le Raspberry, installer les packages nécessaires :

$ apt-get install pulseaudio-module-zeroconf

Toujours sur le raspberry, configurer PulseAudio, en ajoutant à la fin du fichier /etc/pulse/system.pa, la ligne suivante

load-module module-zeroconf-publish

Sur l'ordinateur source, installer le paquet de configuration du PulseAudio

$ apt-get install paprefs

Exécuter paprefs, puis activer la découverte des appareils en réseau :

Redémarrer ensuite l'ordinateur cible, le Raspberry devrait être disponible comme nouvelle sortie son !

Conclusion

En commençant cette manipulation, j'avais peur que la latence de l'audio ne la rende inutile.

Si un peu de latence se fait en effet sentir (+200ms mesurés par rapport à une sortie sur la carte son interne du PC), elle est toutefois suffisamment faible pour ne pas perturber un usage d'écoute musicale.

Pour une utilisation Home Cinéma en revanche, il se peut que cette latence pose problème, à vous de juger !

Source :

Raspberry Pi : Commandes utiles pour réaliser un affichage dynamique en mode portrait

Par Pila

Cet article est un mémo contenant lqes commandes utiles pour la réalisation d'un affichage dynamique vertical avec un Raspberry Pi

Désactiver la mise en veille de l'écran

sudo nano /boot/cmdline.txt

ajouter sur la même ligne :

consoleblank=0

source : https://www.raspberrypi.org/documentation/configuration/screensaver.md

Affichage en mode portrait

sudo nano /boot/config.txt

ajouter sur une nouvelle ligne :

display_rotate=1

Fichiers temporaire en RAM (pour économiser des cycles d'écriture sur la carte SD)

sudo nano /etc/fstab

ajouter les lignes suivantes :

tmpfs /tmp tmpfs defaults,noatime 0 0
tmpfs /var/log tmpfs defaults,noatime,size=64m 0 0

Système de fichier en lecture seul

sudo nano /etc/fstab

ajouter "ro" dans les attributs du système de fichier racine

Repasser le système de fichier en lecture / écriture à chaud

sudo mount -no remount,rw /

Point d'accès Wifi pour administration

https://frillip.com/using-your-raspberry-pi-3-as-a-wifi-access-point-with-hostapd/

Grbl Overseer : Une interface de contrôle touch-friendly pour CNC

Par Pila

Mon hackerspace local disposant depuis peu d'une fraiseuse à commande numérique pour la gravure de PCB, j'ai beaucoup joué avec.

La machine (low cost, mais robuste) est dotée d'un firmware libre dédié au contrôle de CNC par un hardware basé sur Arduino : Grbl

Plusieurs interfaces utilisateurs (pour PC) existent déjà pour Grbl. Cependant, aucune d'entre elles ne semble permettre la gestion automatisée de plusieurs tâches, ni n'offre d'interface optimisée pour un écran tactile. Ce sont là 2 des objectifs de ce projet.

Capture d'écran avec le panneau "Jobs" déployé

Ses principaux atouts sont :

  • Une interface utilisateur simple, optimisée pour un usage clavier / souris mais aussi sur écran tactile
  • Une prise en main facile
  • Une vue 3D des différentes tâches, ainsi que de la position actuel de l'outil
  • La planification de plusieurs tâches, avec des points d'origine différents
  • La vérification automatique de la validité du gcode, afin d'éviter de rencontrer des erreurs pendant la phase de production
  • Le support de Grbl à partir de sa version 1.1 (celle ci fige enfin l'interface de commande)
  • Commandes de déplacement manuelles exploitant d'interface de "jog" de Grbl 1.1
  • Une console série "futée", afin d'avoir un aperçu clair et détaillé des communications avec la machines
  • Une barre d'état "futée", affichant toujours l'état et la position de la machine, et permettant une lecture rapide même à distance de l'écran
  • Un éditeur de configuration pour les différents paramètres de Grbl
  • Multiplateforme : Windows, Linux, MacOs + Android (en cours de développement)

Le point le plus intéressant, et qui fut même le point d'origine de ce projet, réside dans sa compatibilité avec les plateforme Android.

En effet, les tablettes Android représentent, par leur faible consommation, leur faible encombrement, et leur utilisation intuitive, une plateforme idéale pour une interface utilisateur.

Le support Android, à l'état de preuve de concept, est toujours en développement. Si l'application démarre sur la grande majorité des périphérique, une version  d'Android >= 3.1 et compilée avec le support USB Host est nécessaire pour s'interfacer avec la fraiseuse à travers un convertisseur USB / UART.

Le code source de Grbl Overseer et les instructions de compilation pour Linux sont disponibles sur Gitlab : >> ICI <<

Une archive contenant l'exécutable pour MS Windows est disponible >> LA <<

De nombreux bug subsistent encore, notamment dans la gestion particulière de l'USB et du rendu Open GL ES propre à Android.

Sur PC en revanche, le logiciel devrait se montrer stable, n'hésitez pas à l'essayer, et à me faire remonter vos remarques !

Asus GTX780 ROG Poseidon : Réparation du système de refroidissement

Par Pila

Commercialisée par ASUS début 2014, la GTX780 ROG Poseidon est une carte graphique haut de gamme, dotée de 3 Go de VRAM, et d'un système de refroidissement hybride : celui-ci est en effet composé d'un large dissipateur, épaulé par 3 caloducs, et refroidit par 2 ventilateurs, mais intègre également un (court) circuit eau, permettant un refroidissement par watercooling.

Ce système de refroidissement est également muni d'un logo "Republic Of Gamer" rouge clignotant, jouant sans aucun doute un rôle extrêmement important dans le fonctionnement de la carte, tel que changer un PC en discothèque, ou pire encore ...

l'ASUS GTX780 ROG POSEIDON (ventilateurs débranché)

Et c'est justement ce système de refroidissement qui m'a donnée du fil à retordre, puisqu'un beau jour, les ventilateurs ont tout bonnement cessé de fonctionner. Si cela ne pose aucun problème visible en utilisation bureautique de la carte (la fréquence ainsi que la tension d'alimentation du GPU étant fortement réduites dans ce type d'utilisation, la faible dissipation thermique qui en résulte permet de maintenir le GPU dans une plage de température acceptable, même sans aucun ventilateur en fonction), lors d'une utilisation pour du rendu 3D (principalement en jeu), c'est une toute autre histoire, la température du GPU augmentant rapidement de manière alarmante, jusqu'à son arrêt pur et simple, provoquant une perte de l'affichage jusqu'au redémarrage de la machine.

J'ai donc entrepris d'en réparer le système de refroidissement ...

Les 2 ventilateurs ne démarrant pas, mais tournant cependant librement sur leur axe, ma première hypothèse fut que le contrôleur des ventilateurs, intégré à la carte, avait cessé de fonctionner. Pour vérifier cela, rien de plus simple, il suffit de démonter les ventilateurs, et de les tester indépendamment. Séparer les les ventilateurs du dissipateur n'est pas une mince affaire, et implique de se battre contre plusieurs clips plastiques, visibles après coup sur la photo ci dessous :

Les ventilateurs enfin séparés du dissipateur

Les ventilateurs sont alors testés séparément, à l'aide d'une alimentation de laboratoire, réglée pour fournir 12V (1A max) via le connecteur 5 points qui les relie normalement à la carte graphique, et ...

Rien ne se passe ....

Comment ça, rien ?? Enfin, pas exactement rien, l'alimentation de labo indique 0V, 1A, c'est un court circuit franc ! Fichtre, un des ventilateurs est sans doute décédé ...

Avant d'aller plus loin, observons le câblage des dits ventilateurs : comme écrit précédemment, ceux-ci sont raccordés à la carte graphique par le biais d'un connecteur 5 points, véhiculant les signaux suivants : Masse, +12V, commande PWM pour la vitesse, ainsi que 2 signaux de retour indiquant la vitesse effective de chaque ventilateur. De ce connecteur partent 2 séries de fils : l'une va sur un ventilateur, tandis que l'autre dessert un second connecteur, d'où partent également 2 séries de fils : l'une desservant le second ventilateur, et l'autre alimentant le logo ROG clignotant.

Et si ... ?

Essayons à nouveau avec le fameux logo ROG débranché :

Le logo ROG débranché, les ventilateurs reviennent à la vie

Cette fois, les ventilateurs s'animent ! Plus de court circuit, qui provenait donc du logo clignotant.

En le démontant, on découvre un PCB relativement simple, comportant quelques leds, un jeu d'AOP LM324, ainsi que quelques composants génériques, rien de bien folichon :

Je n'ai pas pris le temps d'autopsier ce module, peu importe, son fonctionnement était agaçant de toute façon...

Ses ventilateurs réinstallés, la carte prend place dans mon PC, et c'est l'instant fatidique : démarrage !

la GTX780 en phase de test

Et les ventilateurs ne tournent toujours pas...

Ce qui, après réflexion, semble assez logique : un court circuit aussi franc que celui qui a eu lieu ici sur l'alimentation des ventilateurs à forcément endommagé le circuit d'alimentation des ventilateurs. Sans doute trouvera-t-on une piste brulée, ou un shunt grillé sur le PCB de la carte.

Cette recherche nécessite de séparer le système refroidissement du PCB de la carte, opération que j'avais jusqu'alors soigneusement évitée, étant précédemment en pénurie de pâte thermique, indispensable lors du ré-assemblage pour remplacer la pâte thermique d'origine, qui ne survit pas au démontage.

Le système de refroidissement séparé du PCB

Une fois le PCB entièrement accessible, on s’intéresse aux pistes menant au connecteur 5 pins qui alimente les ventilateurs. Et il ne faut pas longtemps pour identifier un coupable potentiel :

Juste à coté du connecteur, ce shunt semble avoir rendu l’âme

A proximité du connecteur, raccordé à la broche délivrant le +12V au système de refroidissement, une résistance marquée 0 (ayant donc un rôle de shunt ou de fusible) porte des traces de dommages. Elle est immédiatement remplacée :

La résistance remplacée. note pour la prochaine fois : acheter du nettoyant de flux

Une fois la résistance remplacée, la carte est réassemblée, le GPU recouvert de pâte thermique Artic Silver MX2, et reprend place dans mon PC.

Démarrage, et les ventilateurs s'animent enfin !

Windows se lance sans problème, mais surtout, la carte reste en fonctionnement lors d'applications 3D, avec des températures honorables de l'ordre de 70 °C !

Bref, une franche réussite. Il est cependant dommage que cette panne soit causé par un élément aussi insignifiant (et inutile) que le logo clignotant ! Il aurait été sage de la part d'ASUS de lui fournir son propre rail 12V, ou encore plus simplement, de le doter de son propre fusible, afin que sa défaillance n'interfère pas avec le fonctionnement du système de refroidissement !

Réparation d’une mini-chaine Dynabass DBT150

Par Pila

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 :

L'intérieur est spartiate...

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.

Feu le transformateur d'alimentation

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 :

 

L'alimentation utilise 2 enroulements secondaires du transformateur

É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 :

La topologie de la nouvelle alimentation

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)

La chaine en fonctionnement avec sa nouvelle alimentation

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 😉

Un minitel comme terminal linux USB. Partie 3 : Et avec systemd ?

Par Pila

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.

raspi-config Minitel

l'outil de configuration raspi-config sur Minitel

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

❌