Version actuelle datée du 24 janvier 2022 à 23:23

Présentation générale

Description

La crise de la Covid-19 et les différents confinements ou cours à distance ont montré les limites des outils disponibles pour de l’enseignement à distance ou pour les enseignements en dehors des temps dédiés. Par exemple, il est extrêmement difficile de réviser un TP ou de le terminer en dehors des heures d’enseignement car l’accès aux salles est compliquée, notamment les soirs ou les week-end.

Ce projet propose de réaliser une plateforme permettant d’accéder au matériel de TP à distance. La plateforme sera composée d’équipements supportant le protocole LXI. Une unité pourra contenir un générateur de fonction, une alimentation stabilisée, un multimètre et un oscilloscope. Tous les équipements sont reliés au travers d’un réseau Ethernet.

Objectifs

L'objectif de ce projet est de réaliser un POC complet d'un banc d'observation pour réaliser des TP à distance.

La réalisation de ce POC est décomposé en 3 parties :

une matrice de commutation permettant de relier différents montages expérimentaux aux appareils de mesures ;

une interface de commande des appareils de mesures et de visualisation des données (partiellement réalisé) ;

une interface permettant l’accès à la plateforme de façon sécurisée et avec un planning avec réservation du/des banc(s) d'observation(s).

Préparation du projet

Cahier des charges

Fichier:CDC PI Louis Wadbled.pdf

Cahier des spécifications

Fichier:Cahier des specifications PI.pdf

Liste du matériel

Farnell :

200 0 ohm - https://fr.farnell.com/multicomp/mcwr12x000-ptl/res-couche-epaisse-0r-1-0-25w/dp/2695115RL

30 Relais - https://fr.farnell.com/oeg-te-connectivity/oje-sh-105lmh-000/relais-puiss-5vdc-spst-no-8a-trav/dp/3397625

30 transistors Mosfet en CMS - https://fr.farnell.com/nexperia/nxv55unr/mosfet-n-ch-30v-1-9a-sot-23/dp/3617842

30 diodes équivalent 1N4001 en CMS - https://fr.farnell.com/rohm/rr1vwm4stftr/diode-aec-q101-1a-400v-cms/dp/2886628

10 connecteurs BNC - https://fr.farnell.com/molex/73100-0154/conn-coax-rf-bnc-femelle-50-ohms/dp/1909205

10 fiches bananes - https://fr.farnell.com/multicomp/24-243-3/fiche-femelle-ci-4mm-jaune/dp/1698985

2 nucleo F7 (avec écran ?) - https://fr.rs-online.com/web/p/outils-de-developpement-pour-microcontroleurs/1231052

5 MC14514BDWR2G (décodeurs) - https://fr.farnell.com/on-semiconductor/mc14514bdwr2g/verrou-transparent-decod-4-16/dp/2845025?ost=mc14514bdwr2g

5 cordons BNC - BNC - https://fr.farnell.com/schutzinger/ko-88-58-100-sw/cordon-de-test-bnc-male-1m/dp/3224334

5 cordons BNC - banane - https://fr.farnell.com/mh-connectors/bnc4mml1mrg58/cordon-de-test-1m/dp/3153514?st=cordons%20bnc%20bnc

10 cordons banane - banane https://fr.farnell.com/staubli/28-0124-100-21/cordon-test-noir-1m-1kv-32a/dp/152737?st=cordons%20banane%20banane

2 connecteurs Nucléo vers carte matrice 2 rangées n contacts - https://fr.farnell.com/samtec/tsw-135-08-t-d/conn-header-70-voies-2-rangs-2/dp/3585156

2 connecteurs Nucléo vers carte matrice 2 rangées n contacts https://fr.farnell.com/samtec/esq-135-14-t-d/conn-fem-70-voies-2-rangees-2/dp/3514956

1 connecteur Nucléo vers RPi - https://fr.farnell.com/multicomp/2214s-40sg-85/connecteur-femelle-40-voies-2/dp/2847248

1 adaptateur serie USB https://fr.farnell.com/adafruit-industries/954/usb-to-ttl-serial-cable-raspberry/dp/2215041

ESI :

switch ethernet type SWITCH TP−LINK TL−SG108E - https://shop.esipro.fr/produit/cuc-317368-tp-link-tl-sg108e-switch-metal-8-ports-gigabit-igmp-vlan-qos

Ne pas acheter .... HUB USB - https://shop.esipro.fr/produit/2-4783130-15m-usb-2-0-active-cable-with-4-port-hub

caméra usb

1 kit RPi - https://shop.esipro.fr/produit/cuc-151366-starter-kit-officiel-raspberry-pi-3-b

Liste non exhaustive des tâches à effectuer

Interface Web

Création d'une BDD contenant : les logins des utilisateurs de la plateforme, les créneaux des bancs d'observations (réservés ou non) ;

Mise en place d'un serveur pour réaliser l'interface ;

Programmation des différentes pages de l'interface :
- Page d'accueil (identification de l'utilisateur) ;
- Page de réservation des bancs d'essai ;
- Page d'utilisation du banc réservé.

Matrice de commutation

Lister le matériel ;

Réalisation du PCB de la matrice :

Souder la matrice ;

Programmation du contrôle de la matrice : une Raspberry Pi recevant les ordres du serveurs et un microcontrôleur qui contrôle la matrice ;

Réalisation des tests de la matrice.

Documentation

Ecriture de la documentation technique du POC.

Diagramme de Gantt

Voici le diagramme de Gantt prévisionnel du projet. Celui-ci sera mis régulièrement à jour selon les tâches effectuées et potentiellement les tâches à ajouter/modifier.

Diagramme de Gantt prévisionnel du projet (Mise à jour du 04/10/2021)

Réalisation du projet

Semaine 1

Réalisation du cahier des charges

Semaine 2

Réalisation du cahier des spécifications

Cette semaine marque également un début de réflexion concernant la matrice de commutation. Pour relier une entrée de la matrice avec une sortie, on souhaite utiliser des relais.

Premier schéma de la matrice de commutation

Comme on peut le voir sur le schéma rapide ci-dessus, les relais n'ont besoins que d'un interrupteur ouvert ou fermé, donc on pourra choisir des relais SPST (Single Pole Single Throw). De plus, je préfère choisir ici des relais normalement ouverts ce qui implique que l'on envoie un courant à la bobine simplement pour fermer l'interrupteur.

Les relais seront contrôlés par le microcontrôleur. On ajoute une diode de roue libre pour protéger la bobine du relais.

Ici, la matrice a été pensée pour lier 4 entrées et 4 sorties. Or pour réaliser le POC de la plateforme, on souhaite placer au minimum 3 appareils sur un banc d'observation, donc ce schéma n'est pas complet puisqu'il faudrait ajouter une entrée et une sortie (5 entrées pour les appareils déjà prêt à utilisation : 2 pour l'oscilloscope, 2 pour le multimètre et 1 pour le générateur de signaux).

On peut ensuite dresser un premier schéma de la plateforme. Cela permettra de réaliser la liste du matériel nécessaire notamment pour les connecteurs.

Le serveur pourra contrôler les appareils de mesures selon ce que l'utilisateur de l'interface Web souhaite grâce à leurs adresses IP. Pour contrôler la matrice de commutation, le serveur communiquera avec une Raspberry Pi qui transmet les informations au microcontrôleur de la matrice afin de modifier les états des relais pour associer les appareils de mesures avec les dispositifs de tests.

Premier schéma de la plateforme physique

Réalisation de la liste de matériel

Semaine 3

Réalisation du diagramme de Gantt

Afin de réaliser le PCB de la matrice, certains sites permettent de trouver les empreintes des composants électroniques. Il est possible d'utiliser :

https://www.ultralibrarian.com/

De nouvelles réflexions ont lieu concernant la matrice de commutation avant de pouvoir réaliser le PCB. On ajoute ici un transistor MOSFET en commutation pour que la bobine du relais ne soit pas tout le temps alimentée. Le fonctionnement de ce transistor est le suivant : lorsque VGS < VT, le transistor représente un circuit ouvert donc la bobine sera alimentée (ce qui ferme l'interrupteur du relais); lorsque VGS > VT, le transistor représente un fil, donc la bobine ne sera pas alimentée (ce qui ouvre l'interrupteur du relais). VGS représente la tension grille-source et VT la tension de seuil du transistor.

Partie Relais de la matrice de commutation

En poursuivant la réflexion, il devrait être possible de placer le relais et le transistor en série. Le fonctionnement serait alors le suivant : lorsque VGS < VT, le transistor représentera un circuit ouvert donc aucun courant ne passe dans le transistor. Il passe donc par la diode de roue libre ce qui va faire décroitre le courant progressivement dans la bobine, ce qui entraine l'ouverture de l'interrupteur du relais. Dans le cas inverse, lorsque VGS > VT, le transistor représente un fil donc le courant passe dans le transistor, la bobine sera alors alimentée ce qui ferme l'interrupteur du relais.

Deuxième réflexion sur la partie Relais de la matrice de commutation

Le 2ème schéma ici semble plus approprié à ce que l'on souhaite réaliser. Il faudra réfléchir également au besoin d'ajouter ou non des résistances autour du transistor.

Du côté de l'interrupteur du relais, on trouve simplement un lien entre une entrée et une sortie, qui sont représentés par un connecteur BNC (pour connecter les appareils à la matrice) et par une fiche Banane (pour connecter le circuit de test à la matrice).

Le PCB sera réalisé en utilisant Altium. Sur le site comprenant les schématiques et empreintes des composants électroniques, il est actuellement impossible de télécharger les fichiers du transistor et des connecteurs Nucléo, je vais me lancer dans d'autres recherches pour des fichiers de ces composants.

Le schéma et l'empreinte du transistor sont trouvables ici :

https://www.infineon.com/cms/en/product/power/mosfet/n-channel/500v-950v/ipl60r360p6s/

Après avoir téléchargé les différents fichiers des composants, on peut réaliser un début de schéma de la matrice. Ici on ne place pour l'instant qu'un lien entre une entrée et une sortie.

Schema exemple avec un relais sur Altium

Il faut maintenant se pencher sur la partie du contrôle du transistor (côté grille du transistor). On utilise des démultiplexeurs pour utiliser moins de pins de la carte Nucléo. En effet, sans décodeur, on aurait eu besoin de 25 pins de la carte Nucléo, alors qu'avec 2 décodeurs 4 vers 16, on utilise seulement 10 pins.

Sur la vue schématique, on peut alors relier une sortie du décodeur vers le transistor. Les entrées sont reliées à 4 pins du connecteur Nucléo et 1 pin supplémentaire pour le contrôle des sorties. Les pins du connecteur Nucléo seront reliés par des fils sur la carte Nucléo.

Pour une entrée reliée à 5 sorties, on peut retrouver le schéma suivant :

Schema d'une entrée

Pour réaliser les entrées suivantes, étant donné la place prise pour une seule entrée, il est obligatoire d'utiliser plusieurs fichiers Schematics. Il faut alors ajouter des ports pour relier ces entrées aux sorties. Ces ports sont donc reliés aux fiches bananes et sont nommés "FB1" pour fiche banane 1 puis numérotés selon le numéro de la sortie. On peut retrouver l'exemple de la 5ème entrée placée sur une autre feuille schématique :

Schema de la 5ème entrée sur une autre feuille schématique

De plus, on peut remarquer des ports "2S4" jusqu'à "2S8" du côté de la grille du transistor. Ces ports sont reliés au second décodeur de la matrice.

Il ne semble maintenant rester qu'une seule partie de la matrice à schématiser : la partie connexion avec la carte Nucléo. N'ayant pas encore trouvé de librairie Altium pour le connecteur, je ne peux pas encore le représenter. Néanmoins, les connexions devraient être assez simple : nous avons besoin de 10 pins pour les relier en entrée des décodeurs(4 pins de data +1 pour chaque décodeur comme expliqué précédemment), et 2 pins représentant la tension d'entrée et la masse.

Semaine 4

Certains composants de la liste ont été modifiés (comme par exemple les transistors parce qu'ils allaient être trop compliqués à souder). En attendant les schématiques et les empreintes des différents composants (résistances et transistors) sous Altium, je commence à placer les composants sur le PCB, et router très rapidement les composants qui n'auront pas besoin d'être modifiés par la suite. De plus, on retire les décodeurs étant donné que les connecteurs ont largement assez de broches pour contrôler les 25 transistors.

Une fois les nouveaux schématiques et empreintes reçues, je modifie les différents fichiers schématics avant de les importer sur le PCB. Etant donné que la plupart des composants étaient déjà placés, les empreintes se sont mises directement aux endroits souhaités. Pour éviter de mettre des pistes sur les deux faces, on utilise des résistances 0 Ohm. Je les utilise notamment pour relier les grilles des transistors avec le connecteur 70 contacts de la carte NUCLEO. J'ordonne alors les transistors avec les connecteurs les plus proches pour essayer d'utiliser le moins de résistances possible.

Une fois que tout est routé, j'ai lancé le Design Rule Check (DRC). Celui-ci indiqué beaucoup d'erreur de collisions entre entre des noms de composants. J'ai donc modifié l'emplacement des noms des composants impliqués, et en relançant le DRC, plus aucune erreur n'est indiqué sur le PCB.

Design Rule Check du PCB

Il reste maintenant potentiellement quelques composants à placer sur le PCB : le second connecteur de la NUCLEO et le connecteur Raspberry Pi. Pour ces connecteurs, il faudra faire attention à la distance entre les deux connecteurs de la NUCLEO pour que celle-ci s'emboite directeur avec la matrice.

J'ai également programmé l'interface de la page de login, on peut en voir un aperçu :

Page de login de la plateforme de TP à distance

Pour mettre en place la plateforme, j'installe un serveur Apache2 sur la zabeth14 :

$ apt-get install apache2

Les fichiers du serveur se trouve maintenant dans le dossier /var/www/html et on peut voir les erreurs du serveur avec la commande :

$ tail -f /var/log/apache2/error.log

Il faut également installer PHP :

$ apt-get install php
$ apt-get install php-mysql

On installe également le paquetage lxi-tools, qui servira pour la commande des appareils de mesures :

$ apt-get install lxi-tools

Ensuite on redémarre le serveur pour qu'il puisse prendre le compte le PHP :

$ service apache2 restart

Avant de pouvoir se connecter sur l'interface, il faut créer la base de donnée. J'utilise alors la commande :

$ mysql

Je créer l'utilisateur 'lwadbled' ainsi qu'une base de donnée du même nom. Dans cette base de donnée, je crée une table 'utilisateur' contenant un identifiant et un mot de passe. Cette table permettra la connexion à la plateforme. J'y ajoute l'utilisateur 'lwadbled' avec un mot de passe.

Diagramme UML de la base de donnée

Ce diagramme UML représente la base de donnée que je met en place. Il est possible que celui ci soit modifié par la suite si je me rends compte d'une erreur. Le banc est représenté par un numéro, et possèdera au minimum 3 appareils. L'utilisateur est représenté par un identifiant et un mot de passe et un créneau par un jour. La réservation est l'association entre un utilisateur, un banc et une date. Cette table reprends les champs identifiant, numéro et jour, et ajoute également les heures de début et de fin du créneau. On peut traduire l'association par : pour un créneau donné, un banc peut être réservé par un unique utilisateur.

Une fois toutes les tables créées, on peut reprendre la page de login et se connecter avec l'utilisateur tout juste créé :

Connexion de l'utilisateur 'lwadbled'

Page de vérification de la connexion

La page de vérification deviendra par la suite la page de menu offrant d'autres possibilités. Une fois sur cette page, on ouvre une session avec une fonction PHP pour pouvoir garder en mémoire l'identifiant de la personne qui se connecte aux travers les différentes pages. Un bouton de connexion permettra de fermer cette session et ne permettra plus à la personne d'accéder aux autres pages sans se connecter à la plateforme.

Semaine 5

Concernant l'interface Web, j'ai créé un dépôt GIT contenant les codes de la page sur archives.plil (lien vers le dépôt dans la section Documents Rendus).

Lors de la connexion, on arrive maintenant sur une page de menu avec différents choix (deconnexion, réserver un créneau et voir ses créneaux). J'ai implémenté la possibilité de réserver des créneaux. Une fois le créneau réservé, les informations suivantes sont stockés dans la BDD : le banc choisi, le nom de l'utilisateur, la date, l'heure de début et l'heure de fin du créneau. Un créneau dure 1h. Je n'ai pas encore implémenté le blocage des créneaux déjà réservés, mais c'est quelque chose de très important à réaliser le plus vite possible.

De plus, j'ai ajouté une page pour voir les réservations effectués. Sur cette même page, il est possible de supprimer une réservation faite en la supprimant dans la base de données. Ensuite je vais y ajouter le lien vers la page de visualisation et de commande du banc lorsque l'on est dans le créneau (date+heure). Je n'ai pas encore touché à la page de visualisation et de commande du banc.

Les trois captures suivantes montrent les pages de réservations effectués. Le design reste à être modifié :

Exemple de la page de réservation

Exemple de la page "mes reservations"

Exemple de la page "mes reservations" après suppression de la réservation

Pour le PCB de la matrice, je réduis encore sa taille.

Semaine 6

J'ai ajouté maintenant la vérification de la disponibilité des créneaux. Pour réaliser cette fonctionnalité, une fonction Javascript permet de réaliser un appel Ajax lors du changement de la date dans la page de réservation. L'appel Ajax permet d'accéder à la base de données pour prendre les créneaux réservés sur la date choisie et les rendre non sélectionnable sur le site pour l'utilisateur afin qu'un créneau ne puisse être réservé que par une seule personne.

Le design est à présent un peu modifié par rapport à précédemment. J'ai également ajouté un message d'erreur lorsque la réservation n'a pas fonctionné pour éviter tout problème dans la base de données.

Dans la page "mes réservations", un bouton d'accès au banc a été mis en place, et celui-ci n'est utilisable que si la date du créneau correspond avec la date actuelle et si l'heure actuelle est dans l'intervalle du créneau. Ensuite, en ayant relié ce bouton avec l'interface de visualisation et de commande des appareils, on peut accéder à l'affichage du banc. Pour cela, j'ai modifié la façon de recevoir les informations pour l'interface de visualisation et de commande des appareils.

Dorénavant, on ne transmet à la page que le banc choisi (contrairement à tous les appareils un par un précédemment). Ensuite, avec une requête SQL, on peut prendre les informations des différents appareils (IP, nom et type) liés au banc pour afficher leurs résultats et réaliser leurs commandes.

Sur cette page, il reste alors à implémenter la déconnexion obligatoire à la fin du créneau. Sur la page "mes réservations", une fonctionnalité à ajouter est de supprimer les réservations qui ne pourront plus être accessible, ou au moins les masquer à la vue des utilisateurs pour un affichage plus propre.

Autre chose à implémenter : une page "admin" afin d'avoir un calendrier des réservations, ajouter des appareils à la BDD, ajouter des bancs...

Un lien entre la BDD et LDAP de l'école pour l'authentification est également quelque chose à réaliser pour que toutes les personnes de l'école puissent se connecter sur la plateforme.

Semaine 7

Pour l'interface Web, j'ai ajouté une partie "contrôle" à un compte administrateur (appelé simplement "admin"). Depuis le compte "admin" sur l'interface :

Il est possible d'ajouter ou supprimer des bancs. L'ajout et la suppression ne se fait que sur le dernier banc. Par exemple, si la plateforme contient 2 bancs, on peut soit ajouter le banc numéro 3, soit supprimer le banc numéro 2. La banc numéro 1 ne peut pas être supprimé.

Il est également possible de gérer les appareils. Cette page affiche la liste de tous les appareils de la base de données. Depuis cette liste, on peut soit supprimer un appareil de la liste, soit en ajouter un en entrant le banc auquel il appartient, son adresse IP, le nom de l'appareil et le type de l'appareil.

Et enfin un système de gestion des réservations est mis en place, cela permet d'avoir un calendrier des réservations des bancs. Selon la date et le banc choisi, une liste de tous les créneaux est affichée, avec le nom des personnes ayant réservé des créneaux (si ceux çi ont été réservés). Si personne n'a réservé un créneau, l'admin peut bloquer ce créneau (en le réservant pour lui) pour pouvoir utiliser le banc en présentiel par exemple. Si un utilisateur a réservé un créneau, l'admin peut supprimer la réservation de l'utilisateur. Si l'admin a réservé un créneau (en le bloquant auparavant), il peut débloquer le créneau pour permettre à des utilisateurs de le réserver.

Pour la partie PCB, la taille de la matrice est maintenant de 28cm x 22,5cm. La carte peut alors être réalisée à Polytech. J'exporte alors les fichiers Gerber pour les envoyer à la plateforme EEI.

Semaine 8

Je commence cette semaine en rédigeant la documentation technique de l'interface Web, à compléter avec la documentation de la matrice plus tard.

Pour la communication entre la Raspberry et le serveur, je réfléchis à plusieurs solutions. L'une d'entre elle est de réaliser cette communication par sockets avec Python. L'avantage de cette méthode est que derrière, la Raspberry pourra communiquer directement les données reçues par la socket à la carte Nucléo avec la communication série en python (ou du moins je pense que ça peut fonctionner). Pour tester la communication entre la Raspberry et le serveur, je crée deux fichiers python, l'un fait office de client qui envoie des données et l'autre le serveur ,qui tourne en boucle, reçoit ces données et transmet un accusé de réception au client (le tout en UDP). Le client python est placé dans le serveur tandis que le serveur python est placé sur une zabeth pour effectuer le test. Dans le code du site, j'utilise la fonction shell_exec de PHP pour essayer d'envoyer un simple "Hello Server!" au serveur python. La ligne exact dans le code est la suivante :

$test = shell_exec('python3 Python/client.py');

En ouvrant la page où se trouve ce code, on a bien une communication entre le serveur python et le client python. Cette solution semble alors fonctionner. Il faut maintenant trouver un "standard" de communication entre client/serveur afin de communiquer à la Raspberry les relais de la matrice que l'on veut utiliser, et que celle ci nous envoie les relais qui sont utilisés pour vérifier que les commandes de l'utilisateur de l'interface ont bien été pris en compte et ensuite afficher cela sur l'interface Web.

De plus, il faut trouver un moyen pour afficher les commandes de la matrice sur l'interface Web pour permettre aux utilisateurs de commander la matrice. Tout d'abord il faudra créer un type "Matrice" sur l'interface afin de réaliser l'interface comme pour les autres appareils déjà en place (Oscilloscope et Generateur).

Lors de la consultation des réservations pour les utilisateurs, ces derniers pouvaient toujours voir les réservations déjà passées et donc les supprimer. Je corrige ceci en cachant simplement les réservations qui sont déjà passées. Pour les réservations dans la journée présente, on peut cependant toujours les voir.

Lors de la consultation des réservations pour l'admin, ce dernier pouvait lui aussi modifier des créneaux passés. Maintenant, l'admin ne peut que consulter ces réservations.

Semaine 9

Je modifie une dernière fois la BDD pour y ajouter une table concernant les types d'équipements afin qu'il ne puisse pas y avoir de problème lorsque l'admin ajoute de nouveaux appareils sur l'interface.

Ensuite en continuant de travailler sur la matrice, je réalise une petite interface pour la commander. Elle n'est pas très intuitive, quelques modifications devraient être apportées mais je ne pense pas pouvoir les réaliser à temps. Une fois les entrées et sorties à relier choisies, on envoie à la matrice sur 25 caractères l'état voulu des relais. Chaque caractère étant 0 ou 1, on peut ensuite parcourir la trame reçue par la Raspberry pour envoyer en série les données nécessaires pour modifier les états de la matrice. Il faut encore travailler sur comment envoyer ces données.

Pour me connecter avec la RPi, je la branche en ethernet sur un ordinateur et je me ssh dessus avec ssh raspberrypi.local, le login est pi et le mot de passe raspberry.

Je vérifie d'abord si la connexion entre le serveur et la rapsberry fonctionne en modifiant le fichier /etc/network/interfaces :

$ sudo vim /etc/network/interfaces
auto eth0
iface eth0 inet static
	address 172.26.145.142/24
	gateway 172.26.145.254

Je donne une adresse IP dans le réseau du serveur (zabeth). En essayer de ping maintenant l'adresse de la RPi depuis une adresse, on peut voir que la RPi est bien connectée. En modifiant l'IP dans la BDD et le programme du serveur Python sur la RPi, la communication entre les deux fonctionne correctement.

Maintenant qu'on peut envoyer les données comme on le souhaite à la RPi, il faut pouvoir trouver un moyen de le faire vers une carte Nucléo.

J'ajoute également un multimètre sur l'interface Web. Ce dernier n'a pas de documentation concernant les commandes LXI, alors il faut tester des commandes pour voir leur fonctionnement. Tout d'abord je lui donne une adresse IP pour que le serveur puisse le trouver plus tard. Ensuite, je vérifie que l'on peut utiliser LXI sur l'appareil :

root@zabeth14:/home/pifou/Documents# lxi discover
Searching for LXI devices - please wait...
Broadcasting on interface lo
Broadcasting on interface bridge
  Found "Siglent Technologies,SDM3045X,SDM34FBX5R0946,5.01.01.06R1" on address 172.26.145.143
Found 1 device

Tout va bien. J'essaie d'abord un screenshot :

root@zabeth13:/home/pifou/Documents# lxi screenshot -a 172.26.145.143 test.bmp
Loaded siglent-sdm3000 screenshot plugin
Saved screenshot image to test.bmp

Donc ça fonctionne. Voici maintenant venu le temps des tests de commande sur l'appareil. En réalité, j'arrive à trouver un manuel de commande du multimètre. Mais en fait les commandes ne semblent pas très utiles. J'arrive à trouver les commandes pour changer les unitées observées sur le multimètre :

lxi scpi -a 172.26.145.143 "MEAS:VOLT:AC?"
lxi scpi -a 172.26.145.143 "MEAS:VOLT:DC?"
lxi scpi -a 172.26.145.143 "MEAS:CURR:AC?"
lxi scpi -a 172.26.145.143 "MEAS:CURR:DC?"
lxi scpi -a 172.26.145.143 "MEAS:CAP?"
lxi scpi -a 172.26.145.143 "UNIT:TEMP?"
lxi scpi -a 172.26.145.143 "MEAS:RES?"
lxi scpi -a 172.26.145.143 "MEAS:DIOD?"

Concernant la matrice maintenant : après avoir soudé tout ce qu'il faut pour essayer de faire fonctionner le relais tout en haut à droite car je n'aurai pas le temps de souder l'intégralité de la matrice. Ensuite, je connecte 3 broches de la carte nucléo (GND, 3.3V et 5V) à la matrice (respectivement avec la Masse du transistor, la grille du transistor et l'état haut de la carte). Lorsque tout est branché, on peut vérifier avec un multimètre le contact, et celui çi a bien lieu. Problème, en retirant le fil de la grille du transistor, le contact a toujours lieu. L'interrupteur entre l'entrée et la sortie du relais est alors toujours fermé (ce qui pose quand même un gros souci). Après plusieurs mesures de tensions, je ne comprends pas vraiment ce qu'il se passe. En plaçant la commande du transistor à la masse, je comprends encore moins car en mesurant la tension Vgs du transistor, celle ci n'est pas nulle, alors que les deux sont à la masse...

Cependant, en faisant le même test en débranchant la nucléo et la rebranchant, la tension est nulle cette fois ! L'interrupteur est alors ouvert, tout semble normal. En branchant les 5V sur la commande du transistor, l'interrupteur se ferme. Tout est normal ! La matrice semble donc pouvoir fonctionner.

Il reste alors une dernière partie pour terminer ce projet, que je ne pourrais malheureusement pas terminer. Il faut programmer la carte nucléo pour envoyer les signaux aux transistors des relais selon les données reçues en série par la Raspberry. Etant donné le test réalisé sur un relais, on peut imaginer que tous les relais fonctionnent (étant donné que le PCB est réalisé de la même manière pour tous les relais).

Documents rendus

Dépôt GIT

Fichier:Doc technique PI.pdf

Fichiers du PCB sous Altium Designer : Fichier:Matrice PI.zip

Rapport du projet : Fichier:Rapport PI Louis Wadbled.pdf

Présentation de la soutenance finale : Fichier:PI Soutenance Louis Wadbled.pdf

IMA5 2021/2022 P28 : Différence entre versions