Tanca - Méthode d'appariement pour un tournoi de type Suisse

Tanca est le nom d’un logiciel de gestion d’adhérents, de tournoi et de championnat conçu pour le Club de Pétanque de ma commune. Durant l’année, nous organisons quelques tournois au format “Suisse” qui est assez bien adapté pour nous. Cet article explique comment, avec quelques techniques simples, il est possible de résoudre les problèmes d’appariement.

La problématique

Une fois les joueurs inscris à un tournoi, il va falloir générer les rencontres entre les équipes. Plusieurs styles de tournois existent, tout dépend de l’organisateur. Le format classique est le tournoi à élémination directe ou encore à double élémination. L’élémination directe peut être précédée d’une phase de poule pour faire jouer aux participants un nombre minimal de parties.

Car c’est bien là l’intérêt ; en tant que Club de Pétanque amateur, il nous est paru évident d’offrir à tout inscrit qui a payé son droit d’entrée un minimum de parties. Le tout devant se dérouler en une petite journée, sans terminer trop tard le soir (vers 18h étant l’idéal).

Organisation du tournoi

En partant de cette situation, nous avons décidé de faire jouer quatre parties à tous les participants, deux le matin, deux l’après-midi. Généralement, nous avons environ vingt équipes. Il y a alors deux méthodes pour la création des rencontres :

  • La méthode “toutes rondes” (round robin), toutes les rencontres sont tirées au hasard, 4 tours de jeu
  • La méthode dite “Système Suisse”: seule la première rencontre est tirée au hasard, les suivantes sont en fonction du classement intermédiaire

Bien entendu, pour complexifier l’affaire, il faut prendre en compte la règle suivante : deux équipes ne peuvent pas se rencontrer plus d’une fois.

Autre règle : en cas de nombre d’équipes impair, une équipe tirée aléatoirement est forfaitaire pour ce tour (elle ne joue pas). Une équipe ne peut être forfaitaire qu’une seule fois bien entendu ! Ceci est à prendre en compte lors de la création des rencontres.

Système Suisse

Le Système Suisse permet donc à tous les participants de jouer un nombre égal de parties mais tout en étant plus “juste” que le format “toutes rondes”. L’inconvénient avec la méthode “toutes rondes” est qu’on peut se retrouver avec des rencontres injustes pour tout le monde : l’équipe la plus forte peut ne tomber que sur des rencontres faciles et inversement. D’une part, ce n’est drôle pour personne, d’autre part cela ne donne pas une bonne image du concours.

Classement des équipes

Avant de parler de la méthode appariement, voyons comment réaliser un classement. On n’invente rien, le classement est réalisé selon le nombre de matches gagnés puis, en cas d’ex-aequos, on regarde le nombre de points marqués et encaissés. Cela donne, dans l’ordre :

  1. Nombre de matches gagnés
  2. Différence de la somme des points marqués avec la somme des points encaissés
  3. Buchholz : la somme des points des adversaires recontrés

Cette dernière méthode de départage permet de favoriser l’équipe ayant eu comme adversaire des équipes plus fortes.

Abréviations utilisées :

  • P: Games played (matches joués)
  • W: Games won (matches gagnés)
  • D: Games drawn (matches nuls)
  • L: Games lost (matches perdus)
  • PS: Points scored (points marqués)
  • PA: Points against (points encaissés)
  • +/-: goal difference (ie goals scored minus goals against) (points marqués moins les points encaissés)
  • Pts: Points
  • Bz: Buchholtz

Appariement naïf

Imaginons huit équipes, numérotées de 1 à 8. Pour la première manche, il n’y a pas le choix, toutes les rencontres seront tirées au hasard. Voici ce que cela donne, avec en parenthèses le résultat des matches.

3    contre    6   (13-1)
2    contre    8   (13-11)
4    contre    1   (8-13)
7    contre    5   (13-10)

Maintenant, réalisons un classement basé sur la méthode de départage décrite au chapître précédent.

Equipe W L PS PA +/-
3 1 0 13 1 12
1 1 0 13 8 5
7 1 0 13 10 3
2 1 0 13 11 2
8 0 1 11 13 -2
5 0 1 10 13 -3
4 0 1 8 13 -5
6 0 1 1 13 -12

Maintenant, créons les rencontres pour la deuxième manche. Pour cela, dans le cas d’un appariement naïf, nous allons créer les couples d’équipes deux à deux en commençant par le haut du tableau. On respecte donc notre but initial de faire jouer les équipes en fonction de leur niveau. Il faut également faire attention à ne pas faire jouer les équipes une deuxième fois entre elles.

Cela donne les matches suivants, avec le résultat entre parenthèses :

3    contre    1   (13-8)
7    contre    2   (12-13)
8    contre    5   (2-13)
4    contre    6   (13-7)

Le classement intermédiaire devient :

Equipe W L PS PA +/-
3 2 0 26 9 17
2 2 0 26 23 3
5 1 1 23 15 8
7 1 1 25 23 2
4 1 1 21 20 1
1 1 1 21 21 0
8 0 2 13 26 -13
6 0 2 8 26 -18

On continue pour la troisième manche, même algorithme :

3    contre    2
5    contre    7
4    contre    1
8    contre    6

Aïe, nous avons un problème, l’équipe 5 a déjà joué contre l’équipe 7, de même avec les équipes 4 et 1. Il se peut que la troisième manche tombe bien, mais cela ne fera que repousser le problème à la manche 4.

Une méthode semi intelligente consiste à “sauter” l’équipe qui a déjà été jouée ; par exemple ici pour trouver l’adversaire de l’équipe 5, on saute l’équipe 7 et on tombe sur l’équipe 4. 7 et 1 joueront donc ensemble, ce qui résoud le problème pour ce tour. Encore une fois, cela ne fait que repousser le problème et il y a for à parier que le tour 4 vous jouera des soucis d’appariement …

Il faut donc trouver un moyen qui nous assure un appariement le plus juste possible tout en respectant la règle de l’unicité des adversaires rencontrés.

Littérature sur le sujets

La littérature et les théories abondent sur le sujet, car il n’est pas simple. La théorie qui permet de trouver le couplage idéal se nomme la théorie des graphes. Je ne vais pas résumer ce sujet ici, je ferai plus mal que Wikipedia, je vous invite donc à consulter les différents articles à ce sujet.

Autres mots clés pour ceux que cela intéresse : méthode Hongroise, Dutch algorithm, Jack Edmonds, Leaguevine.

La solution adoptée ici s’inspire d’un peu tout cela et surtout du dernier laron : Leaguevine.

Méthode des matrices

La méthode que nous allons utiliser, très empirique et ne reposant sur aucune théorie, vise à trouver le couplage parfait entre deux équipes à l’aide de trois outils :

  • La séparation en deux du classement (les “forts” et les “faibles”)
  • L’affectation d’un poids (un nombre) très élevé aux coupages non désirés (typiquement les équipes qui ont déjà jouées ensemble)
  • Un poids en fonction de la force de chaque rencontre potentielle (basé sur la différence de points)

Etude d’un cas réel

Prenons un exemple tiré d’un vrai concours. Chaque jeu est enregistré dans une base SQL, les différents identifiants sont à mettre en relation avec d’autres tables de la base (table des joueurs et tables des équipes).

Voici l’extrait de la base, la liste des jeux et leur résultat pour 10 équipes (concours de doublettes, 20 joueurs).

tanca

Le classement après ce premier tour est le suivant :

Equipe W L D +/- Bz
166 1 0 0 13 0
168 1 0 0 6 7
161 1 0 0 5 8
164 1 0 0 3 10
160 1 0 0 1 12
165 0 1 0 -1 13
169 0 1 0 -3 13
167 0 1 0 -5 13
162 0 1 0 -6 13
163 0 1 0 -13 13

Passons donc le résultat de cette première manche à travers la moulinette de notre algorithme. Dans un premier temps, on coupe le classement en deux : les meilleurs d’un côté, les plus mauvais de l’autre.

Intéressons-nous à la liste des meilleurs (on procèdera de la même manière avec la deuxième liste). Pour cela, nous allons créer une matrice et, pour chaque combinaison de rencontre on assigne notre fameux poids.

Voici ce que donne notre matrice:

---------------  WINNERS COST MATRIX -------------------
	166	168	161	164	160	165
166 [ 	10000	7	8	10	12	14 ]
168 [ 	7	10000	1	3	5	7 ]
161 [ 	8	1	10000	2	4	6 ]
164 [ 	10	3	2	10000	2	4 ]
160 [ 	12	5	4	2	10000	10000 ]
165 [ 	14	7	6	4	10000	10000 ]

Nous pouvons remarquer deux choses :

  1. La matrice est symétrique, inutile donc de s’occuper de toutes les cases
  2. Le poids élevé (>=10000) pour les équipes s’étant déjà rencontrées (c’est le cas ici pour les équipes 165 et 160) ou les paires impossibles (deux équipes identiques)

Les autres points sont l’écart des différences entre les deux équipes. Plus cette valeur est faible, plus les équipes sont sensées être de force équivalente. La prochaine étape est de créer les rencontres avec cette matrice. Nous allons donc créer un arbre: l’arbre des rencontres possibles.

Détermination des rencontres possibles

Notre algorithme va chercher, dans la moitié de la matrice uniquement cu qu’elle est symétrique, toutes les rencontres possibles. Pour chaque rencontre, on calcule la somme des poids (voir le chapitre précédent). On rejette systématiquement les solutions ayant un total supérieur à 10000, notre limite.

Nous obtenons 12 combinaisons possibles :

----------- Solution 1 cost is :15
168 <--> 166
160 <--> 161
165 <--> 164

 ----------- Solution 2 cost is :15
168 <--> 166
165 <--> 161
160 <--> 164

 ----------- Solution 3 cost is :17
161 <--> 166
160 <--> 168
165 <--> 164

 ----------- Solution 4 cost is :17
161 <--> 166
165 <--> 168
160 <--> 164

 ----------- Solution 5 cost is :21
164 <--> 166
160 <--> 168
165 <--> 161

 ----------- Solution 6 cost is :21
164 <--> 166
165 <--> 168
160 <--> 161

 ----------- Solution 7 cost is :17
160 <--> 166
161 <--> 168
165 <--> 164

 ----------- Solution 8 cost is :21
160 <--> 166
164 <--> 168
165 <--> 161

 ----------- Solution 9 cost is :21
160 <--> 166
165 <--> 168
164 <--> 161

 ----------- Solution 10 cost is :17
165 <--> 166
161 <--> 168
160 <--> 164

 ----------- Solution 11 cost is :21
165 <--> 166
164 <--> 168
160 <--> 161

 ----------- Solution 12 cost is :21
165 <--> 166
160 <--> 168
164 <--> 161

Nous vons donc au final deux solutions possibles ayant les plus faibles totaux (15). Nous prenons n’importe laquelle, nous avons réussis à déterminer notre configuration la plus optimale pour des rencontres plus intéressantes.

Implémentation

Vous trouverez un exemple d’implémentation dans le logciel “Tanca” dont le code source est disponible sur GitHub. La classe intéressante se nomme “Tournament.cpp”, c’est elle qui implémente les calculs d’appariement et de classement. Peut-être que nous y reviendrons plus en détails sur les algorithmes, si j’ai le temps d’approfondir la chose.

Nombre idéal de parties

Avec quatre parties jouées, il est possible de tomber sur deux équipes ayant gagnées tous leurs matchs, avec 20 équipes. Bien entendu, nous pouvons les départager à l’aide des autres statistiques (différence des points et le Buchholtz). Idéalement, il faudrait jouer une cinquième partie mais pour un tournoi amateur cela commence à faire beaucoup de matchs.

Je n’ai pas cherché la méthode pour déterminer le nombre idéal de matchs en fonction du nombre d’équipe. Encore quelque chose à creuser, j’éditerai cet article si je parviens à mettre la main sur quelque chose.

Evidemment, au delà de cinq parties pour 20 participants, l’algorithme ne va pas pouvoir trouver de solutions en respectant la règle visant à ne pas rencontrer deux fois le même adversaire.

Conclusion

Nous voici armé d’un algorithme efficace pour gérer nos tournois de Pétanque, sans stress.

Version mobile de TarotClub - partie 1

Je développe depuis quelques années un jeu de tarot libre appelé TarotClub, créé à l’origine pour combler le manque de jeux de cartes sur Linux. Il est pour le moment disponible uniquement sur les trois grands systèmes d’exploitation du monde PC. Cette série d’articles expliquera le cheminement, j’espère logique, du portage du jeu sur mobile mais également jouable sur une page Web.

Sous le capot

Attardons nous dans un premier temps sur l’aspect technique du logiciel existant. Ce bilan va nous aider dans les choix technologiques pour les plateformes web et mobiles.

Etat actuel

Il est développé en C++ en utilisant Qt. Les premières versions utilisaient la librairie dans toutes les classes du jeu. Depuis plusieurs versions majeures, je m’attarde à découpler les différents modules pour ne plus avoir de dépendances entre le moteur du jeu (la partie appelée “logique”) et la librairie graphique.

La dernière version de TarotClub dispose ainsi:

  • D’un client graphique
  • Un serveur dédié (en pur C++ sans aucune librairie)
  • D’un client console (utilisant des caractères graphiques)
  • D’un client “robot” dont les scripts d’IA sont développés en JavaScript

Voici donc la preuve de la parfaite réussite du découplage entre le moteur de jeu et son affichage graphique.

tarotclub

La version desktop du jeu utilisant Qt

L’interface utilisateur graphique

Le GUI est développé en utilisant complètement Qt car il excelle en la matière. Le moteur graphique choisi à l’époque est le QGraphicsScene qui est spécialisé dans l’affichage 2D de primitives. Il est puissant, facile à développer mais c’est le parent pauvre du framework. Autrefois au centre de la communication de l’éditeur, il est délaissé par la stratégie du tout QML/QtQuick. Il est vrai que ce dernier a tout pour plaire : accélération graphique, interpréteur Javascript, moteur d’animation et d’effets graphique et écriture très simple de l’interface utilisateur dans un style JSON.

Le framework Qt possède donc deux grandes façons de programmer une interface (ou un jeu !), l’ancêtre QWidgets et le nouveau QtQuick/QML. Il est temps de réfléchir à remplacer le grand ancien car il risque tôt ou tard de terminer dans la corbeille de l’éditeur.

tarotclub

Il est vrai que QtQuick/QML semble séduisant

Interpréteur Javascript

Pour l’information technique, l’interpréteur Javascript utilisé se nomme Duktape. Il est particulièrement “petit” en terme d’empreinte mémoire (il peut tourner sur des systèmes enfouis type microcontrôleurs) et son développement est super dynamique. Son auteur travaille comme un titan pour sans cesse apporter des améliorations et est particulièrement à l’écoute d’une communauté très active. Les discussions techniques sur Github sont d’un très haut niveau technique.

Attention, si vous cherchez la performance, passez votre chemin même si pour la plupart des usages Duktape s’avère largement suffisant. Restez sur les moteurs de Chrome et Firefox si la performance est nécessaire pour votre application. Avec Duktape, l’auteur vise surtout la portabilité maximale et le respect de la norme.

Pourquoi avoir choisi de développer une IA en langage scripté ? Le but premier était de fournir une interface plus simple que le C++ pour motivier les contributions externes. Puis, l’idée d’une version web cheminant, ce langage devenait naturel car c’est le langage natif des navigateurs.

Le réseau

L’architecture interne utilise nativement les sockets BSD. C’est-à-dire que derrière une partie locale contre l’IA se cache un serveur de jeu qui dialogue en TCP/IP avec trois clients IP de type “bot” (les adversaires) et un client IP graphhique humain : vous.

Dès lors, il est très facile de créer mon serveur dédié : je supprime toute la partie graphique et le tour est joué. De plus, étant seul développeur, cela me permet d’éviter de dupliquer du code et de tester l’ensemble par une seule suite de tests automatisés.

Le découplage va encore plus loin car la partie TCP/IP proprement dite est elle aussi bien séparée du code se chargeant d’encoder et de décoder les données transférées sur le réseau (la sérialisation). Vivent les interfaces bien pensées, oui je me félicite mais il faut bien se motiver un peu!

Enfin, le code réseau (classes utilitaires serveur/client) contient le support du protocole WebSocket. Toujours en avance de phase, j’ai choisi de l’intégrer rapidement lors d’un refactoring du net code afin de l’intégrer nativement dès le départ de façon transparente pour éviter de tout casser par la suite.

tarotclub

L’architecture actuelle de TarotClub, le code GUI est décorellé du moteur de jeu.

Architecture statique

Un dernier mot enfin sur le découplage des fichiers. Toutes les classes “génériques” (réseau, JSON, utilitaires) sont situées dans un répertoire bien séparé au sein d’une librairie que j’ai appelée “ICL” signifiant Independant C++ Library. Eh oui là encore, j’essaie de ne pas lier les fichiers entre eux pour ne pas tomber dans le plus grand défaut des framework de type Qt où la modularité n’est pas très fine. Avec ce dernier par exemple, il faut redistribuer un paquet de grosses DLL si on ne compile pas statiquement le projet.

Perspectives

Nous voici donc avec sur les bras un logiciel en C++ et une interface graphique en Qt. A priori, les deux sont portables assez facilement sur les plateformes mobiles (iOS, Android, Windows Phone). Reste que rien n’a été pensé “mobile first” donc même s’il est possible de générer un exécutable sur une plateforme donnée, toute l’interface graphique est à revoir.

Pour le web, n’en parlons pas, à part quelques choix technologiques rien n’a été pensé pour l’exécution à partir d’une page HTML.

Inspirations

J’ai quelques idées en tête sur mon but final. Au niveau du portail communautaire, je souhaiterais dans l’idéal quelque chose comme Lichess.

tarotclub

Le site Lichess est vraiment impressionnant en terme de fluidité

Au niveau de l’interface de l’application, certains jeux existants possèdent une interface très simple et bien pensées, comme “French Tarot” de Eryod Soft.

tarotclub

Le tiroir de statistiques sur la droite est bien pensé

Au final, ce genre d’apparence pour un jeu de carte est assez commun. Si on veut vraiment s’amuser et proposer quelque chose de neuf, pourquoi pas aller dans quelque chose de plus rare. Par exemple, j’adore l’aspect du jeu Splendor (Asmodee) qui est fait en 3D.

tarotclub

Une interface 3D façon Splendor ?

Cahier des charges

Ok maintenant attaquons nous à lister ce que nous désirons, ce que j’appelle ma “lettre au Père Noël”. N’ayons pas peur d’intégrer même l’impossible, rêvons un peu puis lors du choix technologique nous pourrons revenir un peu sur terre.

Cibles

Alors là c’est facile, il faudra viser en prioriter les plateformes suivantes :

  • Android
  • Le Web (via une page HTML)
  • iPhone
  • Windows Phone

Idéalement, j’utiliserai le même code pour la version “desktop”, mais étant donnée qu’elle existe déjà on peut imaginer partir sur quelque chose de radicalement différent puis unifier le tout plus tard.

Réutilisation du code

Pour un soucis évident de maintenance et de rapidité, il est nécessaire de pouvoir réutiliser le code de l’interface graphique, c’est-à-dire la table de jeu avec les cartes. Ou du moins une bonne partie, sous la forme de fonctions/classes réutilisables. Voici donc notre critère numéro 1.

Il faudra également utiliser le code existant, et donc la technologie choisie devra pouvoir s’empaqueter avec du code C++ sous forme native ou une librairie.

Divers

Dans les diverses propriétés moins importantes, on peut essayer d’avoir un résultat le plus faible possible en terme d’empreinte mémoire, dans la dizaine de méga octets. Ce n’est qu’un jeu de Tarot tout de même !

Ensuite, il faudrait de préférence un langage standard, pas trop exotique, pour ne pas se lier à un seul fournisseur. Je déteste également les transpileur de code qui nécessitent de maîtriser deux langages au lieu d’un.

Il faudra s’adapter à pas mal de tailles d’écrans en ne cherchant pas à être compatible avec de trop vielles configurations.

On va viser l’avenir et pourquoi pas utiliser des technologies assez récentes, je ne suis pas nostalgique et à la limite, je dispose déjà d’une versions “console” utilisable sur des vieux tromblons et une version Qt pour les configurations intermédiaires.

Outils

A priori un PC sous Linux et un téléphone Android devraient suffirent pour commencer la première cible à pas trop cher. Le développement pour iOS nécessite d’acheter deux machines : l’hôte pour le développement et un téléphone cible ; gasp ! Le téléphone ne semble pas obligatoire au début, je piquerai donc les iPhone de mes proches pour essayer l’application. Concernant la machine hôte, un Mac Mini fera l’affaire (500 € tout de même), en n’oubliant pas les frais de dépôt d’une application (100 €) ?

Même chose pour Windows, il va falloir passer à la caisse pour obtenir une licence Windows 10 et un mobile. Sachant que l’avenir de la plateforme est vraiment floue et la popularité du téléphone, cette cible sera clairement développée en dernier.

Se faire plaisir

Eh oui ça compte, j’ai envie d’apprendre aussi quelque chose de neuf.

Conclusion

On se retrouve pour un prochain article dans lequel nous essaierons de lister et comparer différentes technologies par rapport à ce cahier des charges.

Liens

  • Duktape : http://duktape.org/
  • Lichess : http://lichess.org/

Domotique1/2 : les capteurs

Introduction

Cet article est paru dans le magazine PC Team numéro 68, mai 2001, au sein de la rubrique “Team pratik” sous rubrique “Électronique”.

pcteam_65

Article

Cette première partie consacrée à la domotique va nous initier plus particulièrement aux capteurs météorologiques. Pour cela, l’ordinateur va nous être d’une grande aide afin de centraliser toutes les informations.

À l’évidence, la maison du futur n’est pas encore pour demain. Les constructeurs ayant du mal à s’entendre sur des normes communes, le la maison toute-automatique rêvée par nos parents doit encore attendre. Qu’à cela ne tienne, nous allons automatiser nous même notre chère demeure à l’aide de moyens relativement simples.

Le but est d’effectuer certaines taches automatiquement, comme réaliser un délestage, fermer des volets, contrôler l’éclairage d’une pièce ou tout autre chose. Nous allons commencer ce mois-ci par apprendre à interfacer quelques capteurs qui existent sur le marché. Une fois ces informations centralisées vers notre ordinateur, il nous sera facile d’agir en conséquence sur les actionneurs.

Capteur de luminosité

Ce capteur est d’une simplicité enfantine : il s’agit d’une résistance dont la valeur varie en fonction de la luminosité reçue. Par exemple, la version présentée ici donne 300 Ohms pour 1000 lux, et 30K Ohms pour la luminosité ambiante. Il existe énormément de versions, qui varient selon la résistance maximale, la sensibilité, la puissance etc. Plusieurs solutions s’offrent à nous pour interfacer ce genre de capteur.

La façon la plus souple est d’utiliser un convertisseur analogique-numérique : on a ainsi accès à toute la plage de variation. Il y a encore d’autres méthodes comme de créer un petit oscillateur à l’aide d’un 74HCT14 ou d’un NE555, mais nous avons choisi une solution encore plus simple. Le montage ci-contre, un très classique comparateur à amplificateur opérationnel, va nous donner deux états : présence de lumière ou non. Cela pourra nous être utile pour allumer une lampe à partir d’une certaine obscurité par exemple.

pcteam

Le plus simple des montages peut se révéler très pratique

On peut même faire un montage plus efficace en fabriquant un comparateur à hystérésis, qui permet de fixer les deux seuils haut et bas avec effet mémoire. Il n’y a pas de meilleur montage, tout dépend de votre système et ce que vous voulez faire. Enfin, vous pouvez inverser les entrées de l’amplificateur opérationnel selon la logique que vous souhaitez obtenir en sortie.

Capteur de température

Parmi la très grande variété de capteurs dans ce domaine, nous avons choisi un composant original et tout à fait remarquable. Le plus souvent, nous avons affaire à des capteurs à trois broches qui nous fournissent une tension analogique proportionnelle à la température. L’ennui est qu’il faut alors faire appel à un convertisseur analogique numérique afin de pouvoir traiter le signal par un automatisme quelconque.

Le DS1620 de Dallas Semiconductor est un capteur numérique empaqueté dans un petit boîtier DIL à 8 broches ne nécessitant aucun composant supplémentaire (hormis l’alimentation) pour pouvoir fonctionner. Le dialogue avec le capteur se réalise par l’intermédiaire de 3 fils, les données étant transmises en série. La plage de température est très étendue, allant de –55°C à +125°C, en espérant que vous n’aurez jamais besoin d’une telle résolution pour mesurer la température ambiante de votre salon ! Bien entendu, vous retrouverez le datasheet sur le CD.

pcteam

Le DS1620 seul suffit pour mesurer une température

Passons au branchement ; nous allons utiliser la seule broche du port parallèle non inversée et bidirectionnelle, la broche 16 /Init. Le deuxième fil est l’horloge et le troisième le signal Reset ; n’importe qu‘elles autres broches en sortie feront l’affaire. Comme d’habitude, nous allons utiliser Visual Basic qui se prête parfaitement à ce genre d’applications. Il est également possible d’utiliser Visual Basic pour Applications, qui a l’immense intérêt d’être fourni en standard avec Microsoft Office : vous pourrez ainsi créer de beaux graphiques, présentant la variation de température en une journée par exemple. Notre application se montre assez simple, a vous de l’adapter à vos besoins et de la compléter à l’aide de la documentation fournie.

pcteam

Un sèche cheveux est pratique pour tester ce genre de montage :-)

Il peut être intéressant d’utiliser les sorties thermostats à programmer dans la mémoire EEPROM non volatile du DS1620. Par exemple, vous définissez deux valeurs, haute et basse, limites pour votre système (des températures critiques comme la température d’un processeur si vous vous adonnez à l’overclocking) : dès que la température mesurée atteint une de ces valeurs, la broche correspondante passe au niveau haut, vous donnant les moyens d’actionner n’importe quel automatisme. Enfin, le dernier (grand) avantage de ce capteur est qu’il peut fonctionner en mode autonome : plus besoin de votre ordinateur, pour peu que vous ayez bien programmé tous les paramètres.

Capteur d’humidité

Là encore, il s’agit de fabriquer un petit montage adaptateur. Le capteur d’humidité utilisé est appelé “humidistance” ; c’est un petit boîtier à souder sur circuit imprimé qui, bien qu’un peu cher - 80 F environ -, permet la mesure de l’humidité relative au degré d’hygrométrie ambiant.

pcteam

Voici un capteur d’humidité

C’est en fait un simple condensateur dont la valeur varie en fonction de cette humidité relative. N’allons pas chercher compliqué, encore une fois les montages les plus simples s’avèrent les plus performants. C’est pour cela qu’un petit montage oscillateur à base de 74HCT14 ou de 4011 fera parfaitement l’affaire.

pcteam

Le montage classique d’un oscillateur

Au niveau de la programmation, il faut réaliser un fréquencemètre ou période mètre, la différence entre les deux est que le premier procède à une mesure d’impulsions pendant un certain temps tandis que le second calcule le temps entre deux fronts d’horloge. Nous rappelons que la fréquence est inversement proportionnelle à la période. Dès lors, il s’agit de bien choisir la méthode de mesure en fonction de la plage de fréquence mesurée ; par exemple, un fréquencemètre sera d’autant plus performant que la fréquence est grande. Le problème est qu’il faut au préalable faire des tests à l’aide d’un vrai capteur d’humidité afin d’avoir la correspondance entre le fréquence mesurée et la valeur réelle d’humidité relative (relation qui n’est pas linéaire).

Le plus simple étant de faire des essais et d’en déterminer les valeurs à ne pas dépasser, sans avoir à connaître précisément la valeur d’humidité ambiante. Le circuit présenté ci-contre est à base d’un circuit CMOS 4011 classique, alimenté entre 3 et 15V, et fourni une fréquence sur la broche 4 égale à 1/(R1*C1). Remplacez le condensateur C1 par le capteur d’humidité capacitif et calculez alors la résistance à placer en fonction de la fréquence désirée en sortie. A titre indicatif, sachez que le capteur utilisé ici (de Philips) possède une capacité de 120pF à 40% d’humidité relative. Enfin, il peut être intéressant de connecter la broche 1 du 4011 à une broche du port parallèle pour pouvoir commander l’oscillateur.

Conclusion

Cette petite mise en bouche sur le (vaste) thème des capteurs est loin d’être exhaustive tant les produits sont abondants dans les catalogues. Il est possible d’aller beaucoup plus loin, en créant un véritable réseau de capteurs, pourquoi pas avec un dialogue par infrarouge entre le PC et les capteurs. De même, si vous possédez une connexion illimitée à Internet, pourquoi ne pas créer une page Web supervisant toute votre installation pour vérifier l’état de vos capteurs où que vous soyez.

Comme d’habitude, nous attendons vos réalisations pour les placer sur le CD. Il y a vraiment une quantité impressionnante d’applications qui peuvent émerger, en attendant le mois prochain où nous attaquerons les actionneurs !

Encadré

Plus de place ?

Les ports d’entrées/sorties sont malheureusement limités. Si votre installation devient conséquente, il vous manquera sûrement des broches. Pour remédier à ce problème, sachez qu’il existe quelques astuces et possibilités fortes intéressantes.

Tout d’abord, à condition de disposer d’un peu plus de matériel, le port ISA peut fournir une solution parfaite. L’accès au port se fait à l’aide des fonctions classiques que l’on utilise depuis déjà quelques mois (inportb, outportb etc.). Oubliez le port PCI qui est beaucoup trop complexe à mettre en oeuvre.

Les capacités des ports parallèle et série peuvent être étendus grâce à des “sérialiseurs” et des registres à décalage à accès série. Les 74HC165 et 74HC595, dont les datasheets sont sur le CD Pro, sont deux composants idéaux pour ce genre de problème. En outre, ils peuvent se câbler en cascade ce qui est d’autant plus intéressant. Bref, toutes les diverses techniques de multiplexage et de conversion série/parallèle pourront vous rendre de fiers services.