LOCODUINO
Discussions Générales => Bus DCC => Discussion démarrée par: Thierry le janvier 27, 2015, 03:56:51 pm
-
Il y a un aspect du DCC qui me laisse perplexe. Lorsqu'une loco est sur sa voie de programmation, une centrale DCC peut l'interroger pour lui demander les valeurs courantes de ses CVs. Comment l'information de la valeur remonte t-elle ? D'ailleurs, est-ce qu'elle remonte ? Je voudrais ajouter la configuration de UAD par des CVs, mais je ne vois pas comment faire cela...
-
Ce n'est pas ça que tu cherches ? http://www.nmra.org/sites/default/files/s-9.2.3_2012_07.pdf
-
C'est effectivement ça. Le décodeur consomme du courant en pointillé pendant un temps mort entre deux paquets DCC pour envoyer des bits, façon morse...
Du coup, je comprend mieux pourquoi mes locos sursautent quand je modifie les CVs de leur décodeur...
Pour arriver à communiquer, il va falloir un petit circuit électronique dit 'Railcom' ...
-
Oui, il faut mesurer la consommation du décodeur. On fait ça en mettant une résistance dans le circuit, par exemple 1Ω. Quand le décodeur ne surconsomme pas de 60mA, disons qu'il consomme 100mA, la chute de tension dans la résistance va être de 100mV. Quand il surconsomme, 160mA, elle va être de 160mV. Le problème est que ce différentiel de tension n'a pas de référence de masse. En mettant un ampli op aux bornes de la résistance, on transforme ce différentiel en une tension par rapport à la masse que tu peux ensuite entrer sur une entrée analogique. Je suis pas un expert là dessus mais j'ai un collègue qui peut m'aiguiller.
Il y a un montage sur mes cartes alimentation qui permet de mesurer un courant via un ampli op, il faut sans doute adapter mais il s'agit du même type de montage.
-
Thierry,
Voici le montage de mesure de chute de tension. Il est extrait des cartes faites par Pierre Molinaro (un collègue) que j'utilise sur mon réseau.
Voir la pièce jointe ci-dessous.
À gauche, on a la tension de base du DCC avant le booster que j'ai arbitrairement fixée à 15V. L'alimentation du booster traverse R3 et entre sur le booster. Quasiment tout le courant passe par R3, R1 et R2 faisant 1MΩ, le courant qui les traverse est négligeable. Le courant io qui traverse R8 est donné par l'équation suivante :
io = (1+u)(V+-V-) / (u R0)
u est le rapport de R5 sur R4. On a forcément R1 = R2 = R6 = R4 et R5 = R7
Donc ici, le courant qui traverse R8 est égal à (1+1x10-3)(V+-V-)/(1x10-3 x 1x106)
donc (1+1x10-3)(V+-V-)/1000
Donc par exemple si 100mA traverse R3, V+-V- = 1 x 0,1 = 0,1
io = 1,001 x 0,1 / 1000 ~ 1mA. Et donc la tension en entrée de l'Arduino est de 2000 x 0,001 = 2V
Si ça monte à 160mA, ça fait 3,2V
D1 empêche que la tension ne monte au dessus de 5V et casse l'entrée analogique de l'Arduino.
Ensuite, il faut changer les valeurs de R5 et R7 selon ce qui est consommé au repos sur la voie de programmation. Une petite campagne de mesure s'impose.
-
Super, au moins la solution technique existe, il faudra un jour tenter de l'adapter. Mais je me sens bien incapable de le faire tout seul, étant une -presque- bille en électronique...
C'est un projet à garder sous le coude, pour de futurs développement...
-
Bonjour Thierry
J'ai trouvé un schéma de surconsommation (coté décodeur donc) simple : http://www.franksworkshop.com.au/ModelRail/DCCServoDecoder/DCCServoSchematic.pdf
C'est en bas à gauche. Via un optocoupleur 4N25, le micro pilote un transistor qui consomme sur la connexion DCC. Il faut également un pont de diodes et une résistance. Je vais voir si j'arrive à greffer tout ça sur la carte servo quitte à virer les diodes TX et RX qu'on puisse expérimenter la programmation des CV.
-
Deux-trois remarques :
io = (1+u)(V+-V-) / (u R0)
u est le rapport de R5 sur R4
Tu es vraiment sûr que u c'est R5/R4 ???
Dans le pont dont tu parles, il va passer un fort courant (1A) puisque c'est celui qui est dans les rails.
Mais le circuit n'a besoin que d'un tout petit courant et donc de tout petits fils.
Je mettrais bien le pont "en volant" côté bus DCC et de petits fils vers ta carte.
En plus un pont (ou 4 x 1N400x) ça prend de la place et ça chauffe. 8)
C'est aussi bien loin d'une carte.
-
De mon côté, j'ai trouvé un schéma (http://usuaris.tinet.cat/fmco/dccgen_en.html (http://usuaris.tinet.cat/fmco/dccgen_en.html)) qui pourrait faire le même boulot, même si je trouve le tien plus simple et compréhensible...
-
Le célèbre site de Paco !
Pas mal de bonne idées pour le DCC, basées sur des PIC. D'autres choses sont à adapter, d'ailleurs.
Concernant ce schéma, c'est un détecteur de présence.
Au passage, de plus en plus souvent, les nouvelles centrales permettent de programmer la loco en roulant, sans voie de programmation spécifique.
Le schéma s'explique facilement :
On mesure la tension aux bornes de la 12 Ω.
En parallèle de cette 12 ohms, 4,7 kΩ + un potar de 10 kΩ pour régler la sensibilité.
Ces résistances sont nettement >> 12 Ω, donc la résistance réelle approche les 12 Ω, un tout petit peu moins, d'ailleurs.
Le transistor BC547 déclenche quand cette tension dépasse 0,6 V.
Une 1N4004 de protection, une LED pour voir l'occupation et 2 condos pour lisser les tensions.
Et voilà la grosse différence : il déclenche : on ne peut pas mesurer une tension.
Le schéma de Pierre Molinaro, lui, te fournit une valeur de l'intensité qui passe dans la résistance de 1 Ω.
C'est nettement mieux. ;)
-
Deux-trois remarques :
io = (1+u)(V+-V-) / (u R0)
u est le rapport de R5 sur R4
Tu es vraiment sûr que u c'est R5/R4 ???
Je vais vérifier mais me semble bien que oui
Dans le pont dont tu parles, il va passer un fort courant (1A) puisque c'est celui qui est dans les rails.
Mais le circuit n'a besoin que d'un tout petit courant et donc de tout petits fils.
Je mettrais bien le pont "en volant" côté bus DCC et de petits fils vers ta carte.
En plus un pont (ou 4 x 1N400x) ça prend de la place et ça chauffe. 8)
C'est aussi bien loin d'une carte.
Il n'y a pas de pont de diode. Le courant est mesuré sur l'alimentation du LM18200 pas sur les rails. C'est donc du continu, pas un signal périodique.
Le courant de traction traverse effectivement la résistance, et seulement la résistance. Comme c'est destiné à la voie de programmation, je ne pense pas que l'on atteigne 1A. Avec 1A la chute de tension est de 1V et la résistance doit donc dissiper 1W : http://www.tme.eu/fr/details/smd2512-1r-1%25/resistances-cms-2512/royal-ohm/25121wf010jt4e/
Relier les bornes de la résistance à l'ampli op par deux fils risque de donner de moins bons résultats. Le courant qui circule est de l'ordre du μA et donc facilement perturbable par l'environnement. Il faut que l'ampli op soit le plus près possible de la résistance de 1Ω.
-
Dans le schéma de surconsommation que j'ai pointé au dessus le gars a mis une résistance de 47Ω ce qui donne environ 250 mA sous 12V. Ça fait beaucoup non ? Si mon calcul est bon ça fait également 3W de dissipation. Certes ça ne dure pas longtemps mais si le logiciel plante, la résistance part en fumées.
-
On est OK.
47Ω -> 250mA et 3W. Il faut une grosse résistance !
Question de béotien : pourquoi voulez-vous mesurer une surconsommation ?
-
C'est la manière dont un décodeur envoie des infos à la centrale. Au mini il fait un ack.
-
J'ai contacté le gars qui admet que la surconsommation est inutilement importante.
Entre l'optocoupleur et Q1 on a un montage darlington. J'ai trouvé des optocoupleurs à sortie darlington qui permettent de tirer 100 mA (il faut tirer 60mA mini pour être dans la norme). Ça économise Q1.
Si on veux intégrer ce montage sur la carte servos, il va falloir que je mette le régulateur vertical plutôt que couché. Ça libérera de la place.
-
et avec ce Max471 dans l'alimentation continue du LMD18200, on pourrait récupérer les informations RailCom ?
-
Oui, ça remplacerait le montage de Pierre.
Deux inconvénients toutefois, le circuit n'est plus produit par Maxim. Mais bon nous ne sommes pas des professionnels :)
La résistance soudée sur le module est une 2kΩ comme dans la datasheet Max471 qui donne 1V/A. Donc 100mA représente 0,1V. Est-ce suffisant ?
-
D'après la norme NMRA S-9.3.2,
To transmit a “0”, the decoder must supply a current 1 of 30+4/-6 mA with a voltage drop at the track of up to 2.2V. To transmit a “1”, the current 1 must be at the most +/- 0.1mA. The power source of the decoder must be protected from unexpected external voltage at the track during the cutout.
A detector must interpret a current of greater than 10mA during the middle 50% of the bit time as “0”, a current smaller than 6 mA during the middle 50% of the bit time as “1”. The voltage drop over the detector may not exceed 200mV at a maximum current of 34 mA during the cutout.
Donc ce n'est certain que la mesure avec le Max471 soit assez précise.
De plus j'ai compris que c'est un courant fourni par le décodeur qu'il faut mesurer, donc le Max471 dans l'alimentation du LMD18200 ne conviendra pas. Le circuit de Pierre semble plus approprié
-
C'est un courant consommé par le décodeur. Ce qui me semble acquis est que 250mA c'est carrément hors norme. Mais où ai-je donc lu 60mA ???
C'est pas hyper clair leur truc. Il va falloir expérimenter.
-
Ah je vois que j'introduis une déviation par rapport à la question de Thierry au début de ce fil : la surconsommation correspond à un ACK simple, par exemple suite à la programmation d'un CV.
Basic Acknowledgment
Basic acknowledgment is defined by the Digital Decoder providing an increased load (positive-delta) on the programming track of at least 60 mA for 6 ms +/-1 ms. It is permissible to provide this increased load by applying power to the motor or other similar device controlled by the Digital Decoder.
Ça explique pourquoi la machine bouge !
Par contre j'étais parti sur les messages Railcom où c'est le décodeur qui fournit du courant:
Advanced Acknowledgment See-S-9.3.1 and S-9.3.2.
L'idéal serait donc de mesurer le faible courant dans les 2 cas et je pense que l'ampli différentiel de Pierre est le mieux adapté.
-
Ok vu
C'est super compliqué leur truc parce que visiblement cette communication est conçue pour avoir lieu également pendant que la machine roule. De temps en temps ça doit tomber en marche ;D
Bon détecter ça n'est pas très compliqué.
-
Apparemment pour un ACK simple c'est 60 mA au moins consommé par le décodeur, et pour une réponse Railcom, c'est 34 mA générés par le décodeur donc dans l'autre sens et pendant un arrêt complet d'alimentation du générateur DCC.
Ils sont compliqués ces allemands ;(
-
Personnellement j'avais l'intention d'utiliser le ACK simple seulement dans un premier temps.
Si je comprend bien il faut que j'attende la centrale DC/DCC de Thierry et le circuit de mesure de Pierre !
Merci les amis !
-
Bonjour à tous,
Je me permets de rejoindre cette discussion car ça m'intéresse, j'attends mon module LMD18200 pour expérimenter le contenu de vos articles sur la génération de signal DCC et voir bouger mon autorail, mais je m'intéresse déjà à la programmation des CVs et même à la lecture des valeurs.
En effet je ne possède pas de centrale DCC, c'est une récente acquisition de matériel roulant équipé qui me pousse à expérimenter, du coup j'ai envie d'aller jusqu'au bout !
Avez-vous avancé dans vos expérimentations ? Puis-je filer un coup de main ? :)
-
Bonjour sierramike,
Je n'ai pas encore trouvé le temps de tester le schéma de Pierre. Ce qui marche en tout cas c'est la mesure de courant avec un détecteur en série avec l'alimentation continue du LMD18200. Je m'en sers actuellement pour la détection de court-circuit, donc un courant assez élevé, mais ça détecte aussi des courants plus faibles (60mA, c'est le moteur d'une machine en N).
Je vais construire une centrale DCC rien que pour la voie de programmation, avec un Nano, un LMD18200 et un Max471:
http://www.ebay.fr/itm/3A-Range-Current-Sensor-Module-Professional-MAX471-Module-For-arduino-/311523659684?hash=item488841cfa4 (http://www.ebay.fr/itm/3A-Range-Current-Sensor-Module-Professional-MAX471-Module-For-arduino-/311523659684?hash=item488841cfa4)
-
Bonjour à tous,
Si vous me permettez, il me semble que ce fil c’est rapidement écarté du sujet de départ posé par Thierry qui est la lecture des CV’s sur une loco. Il avait même lâché le mot magique « Railcom ».
Il me semble que c’est bien là le vrai plus. L’une des principales problématiques sur un réseau est en effet de pouvoir disposer d’informations « fiables » sur la position des locos ou, en sens inverse, quelle loco occupe telle section (ce qui ne correspond pas forcement au canton). Connaître le sens de marche est aussi intéressant. Accessoirement, il est aussi intéressant de pouvoir lire la valeur de différents CV’s. Mais tout système de pilotage un peu évolué dispose de ses informations puisque c’est lui qui a transmis ces données. Par contre, la lecture complète des infos dans toutes les locos est très appréciable en cas de plantage du système pour le mettre à jour ou quand on revient sur notre réseau qu’on a laissé « en plan » sans être obligé de tout réinitialiser.
C’est cela que permet le Railcom ou plus exactement le RailcomPlus qui est la version la plus évoluée pour le retour d’information. C’est une technologie à part entière et un concept évolué capable d’apporter des réponses aux besoins de connaître les positions des trains.
Le Railcom nécessite une compatibilité des décodeurs sur les locomotives, mais c’est je crois le cas pour la plus part depuis maintenant quelques années. Il nécessite également l’envoi d’un signal DCC modifié ou plus exactement completé par un « cutout », signal à partir duquel le décodeur (compatible dont je parle ci dessus) sait qu’il doit envoyer en retour par la voie DCC les fameuses informations, dont son adresse. Enfin, la centrale doit être capable de lire et déchiffrer les informations renvoyées.
Pour quelques infos sur le sujet : http://usuaris.tinet.cat/fmco/railcom_en.html (http://usuaris.tinet.cat/fmco/railcom_en.html) et http://www.opendcc.de/info/railcom/railcom_f.shtml (http://www.opendcc.de/info/railcom/railcom_f.shtml)
Railcom une technologie qui n’entre pas dans la norme NMRA ce qui n’est pas sans agiter la petite communauté, mais c’est une technologie et une programmation qui à mon avis devraient être à la portée de nos Aruino’s et apporteraient beaucoup à la sécurité de nos réseaux et permettrait d’accroitre considérablement l’expérience et le plaisir d’utilisation.
Personnellement, je suis à l’heure actuelle sur des problématiques de détection et de rétro-signalisation que je pousse très loin car je cherche derrière à construire des scénarios informatisés de réponses en temps réel.
Je serai très heureux de partager avec d’autres sur ces sujets de la détection, de la rétro signalisation et bien sûr du Railcom+.
Bien à vous et merci à Locoduino qui à m’apporte beaucoup.
-
Je suis de mon côté en train de refondre UAD, et de tester la nouvelle version via un Arduino Emulator fait maison.... Mais j'ai quand même commandé quelques Max471 pour procéder à des tests aussi et améliorer ma centrale Dc/Dcc.
-
Bonjour à tous,
Si vous me permettez, il me semble que ce fil c’est rapidement écarté du sujet de départ posé par Thierry qui est la lecture des CV’s sur une loco. Il avait même lâché le mot magique « Railcom ».
Il me semble que c’est bien là le vrai plus. L’une des principales problématiques sur un réseau est en effet de pouvoir disposer d’informations « fiables » sur la position des locos ou, en sens inverse, quelle loco occupe telle section (ce qui ne correspond pas forcement au canton). Connaître le sens de marche est aussi intéressant. Accessoirement, il est aussi intéressant de pouvoir lire la valeur de différents CV’s.
Merci à toi de rappeler le sujet principal de ce fil. C'est une de mes préoccupations aussi de pouvoir repérer les locos (au moins) car le pilotage en DCC nécessite la connaissance de l'adresse de la machine.
J'ai eu l'occasion de développer sur ce site plusieurs solutions possibles, avec divers capteurs (RFID par exemple) ou en utilisant simplement les capteurs de consommation et en manœuvrant les locos une à une pour établir la correspondance entre leur adresse et leur position. Cette dernière méthode marche assez bien mais j'ai besoin de la fiabiliser.
La découverte du projet DCC++ par Denis (voir le sujet ici : http://forum.locoduino.org/index.php?topic=203 (http://forum.locoduino.org/index.php?topic=203)) nous apporte une autre solution que je suis en train de tester avec succès (j'en parle plus loin ci-dessous et il faudra voir les détails sur ce fil).
Railcom est certainement bien adapté à cette problématique de reconnaissance, mais comme tu le dis bien :
- il faut des décodeurs spéciaux non normalisés dans les locos (on voit bien sur Locoduino que certains d'entre nous préfère n'installer aucun décodeur dans leur machines; moi-même j'ai quelques machines impossibles à digitaliser sans charcutage douloureux)
- il faut des capteurs spéciaux dans les zones (pas toutes j'espère)
- il faut intégrer ce protocole non normalisé dans la rétrosignalisation
Pour le moment, et j'espère me tromper pour l'avenir, je trouve que cela fait beaucoup de complications pour un tel but à atteindre. Personnellement je vais explorer la solution qui est présente dans DCC++ : il contient pas mal de fonctions de programmation, de lecture et d'écriture de CVs, tant sur la voie de programmation que sur la voie principale.
Par exemple, j'ai ajouté dans DCC++ une fonction qui permet de lire le CV 01, sur la voie principale, donc de récupérer l'adresse DCC de la loco qui s'y trouve : et ça marche nickel ;D
D'où l'application immédiate pour une voie unique avec seul train (un va et vient avec un autorail par exemple) : je pose une loco sur les rails et je lance la centrale (celle du fil invoqué plus haut avec un simple Nano, un LMD18200 et un Max471). Elle récupère alors l'adresse DCC de la loco. Ensuite elle fait partir cette loco en marche avant (on ne sait pas encore à ce moment dans quel sens la loco va rouler, sens pair ou impair). Mais les capteurs d'occupation vont se charger de lui donner la solution : à la prochaine détection, elle sait donc dans quel sens, pair ou impair, correspond la marche avant DCC.
Ensuite c'est l'affaire de mon automate de faire fonctionner le va et vient à ma convenance. Je n'ai pas encore écrit tout le sketch, juste fait des tests sur un cercle que j'ai emporté avec moi en vacances et j'écris et teste seulement les jours de pluie (il n'y en pas pas beaucoup en ce moment :-\)
Pour singer Railcom, avec cette solution, je pense qu'il suffirait d'isoler des zones avec des relais (par exemple les voies dans les gares où on est censé ranger les trains) et d'y connecter temporairement (grâce aux relais) ce type de centrale pour détecter les adresses DCC, voire bricoler certains CVs, comme sur une voie de programmation. Cela pourrait faire l'objet d'un sous-système à part entière, relié au gestionnaire par un bus CAN, avec des messages assez simples.
Comme promis, je vais donner plus de détails sur le fil http://forum.locoduino.org/index.php?topic=203 (http://forum.locoduino.org/index.php?topic=203)... dans quelques heures car il fait beau !!!!
Amicalement
-
Bonjour Dominique,
Tout d’abord, je te remercie pour ton inlassable contribution à faire évoluer « la chose ». Je n’avais pas vu dans DCC++ qu’il y avait possibilité de lire les CV’s et pour cause, puisque tu dis que c’est une fonction que tu as développé toi même ;-). Je suis très intéressé que tu nous mettes à disposition le code.
Je tiens à préciser que je ne suis pas particulièrement défenseur de Railcom plus que de tout autres technologies. Bien au contraire, je crois qu’il faut chercher à s’approprier le meilleur de tout ce qui est à notre disposition et marier tout cela. Et donc pourquoi pas Railcom et DCC++. Mais Railcom est commercial et il difficile de se procurer les sources.
A suivre je pense ! Et que certains d’entre nous travaillent dans différentes directions pour ensuite croiser les résultats et le rendre disponible aux autres me paraît une bonne chose. Au final, le sujet principal qui nous préoccupe est bien celui de la détection et de la rétro signalisation des locos.
Au passage, je voudrais signaler que j’ai fait le choix sur mon réseau de communiquer entièrement en TCP/IP. Il y a à cela plusieurs raisons dont celle qui était de pouvoir développer un controller en HTML 5 pour disposer d’une gigantesque bibliothèque graphique de potentiomètres, boutons etc…. Associé à un langage de programmation objet puissant, AngularJS (Framework javascript), ça marche vraiment bien et c’est quand même beaucoup plus ouvert (possibilité de plusieurs controllers pour un même réseau dont smartphones et tablettes, WIFI inclus, possibilité de communiquer en PHP avec des bases de données type SQL…)
Voici le lien sur mon controller en version démo : http://89.225.199.180/train_HO/locomotives/controller_demo.html (http://89.225.199.180/train_HO/locomotives/controller_demo.html)
(J’ai testé avec Chrome, rien n’est garanti pour les autres navigateurs)
C’était juste un clin d’œil par rapport au controller proposer avec DCC++. Avouez que ça a un peu plus de « tête » non ? Mais je ne voudrais pas créer une confusion et préciser que DCC++ et son controller sont indépendants ce qui n’interdit pas d’utiliser le premier avec autre chose que le second. C’est d’ailleurs ce que tu fais avec tes manettes.
Je ne manquerai pas de tester DCC++ avec ton code de lecture de CV et je vous ferai un retour. Et pour ceux que ça intéresse, je veux bien développer sur la communication par Ethernet en TCP/IP.
Bien amicalement
Christophe
-
Merci beaucoup Christophe,
Je suis en train de préparer une présentation du code de DCC++ pour montrer comment on peut l'adapter à chaque cas personnel.
En attendant je vais mettre le code pour la lecture du CV1 des que possible, peut-être ce soir ou demain.
À suivre ...
Amicalement
Dominique
-
Hello les gars,
Voici une version 0.0.1 (en attendant mieux) de DCC++ considérablement amaigri et augmenté d'une fonction de récupération du CV de la loco placée SEULE sur la voie principale (il n'y a plus de voie de programmation dans ce code adapté d'aileurs au Nano).
Ces modifications comprennent :
- l'ajout d'une méthode discover() dans la structure SerialCommand (SerialCommand.h)
- le code de discover() dans SerialCommand.cpp : il simule l'envoi des commandes "<1><r 1 123 123><0>"
- l'ajout d'une variable addressDccToDiscover dans la structure RegisterList de PacketRegister.h
- l'ajout d'une fonction readCV_Main() dans PacketRegister.h et .ccp
- l'appel de cette mécanique en fin de setup
mainRegs.addressDccToDiscover = 3;
SerialCommand::discover(); // dcc adress found is stored in readCV_Main()
Serial.println();
Serial.print("adresse DCC : ");Serial.println(mainRegs.addressDccToDiscover);
Le principe est simple : en fin de Setup, on établi le courant sur la voie principale (<1>) puis on demande une lecture du CV 1 (<r1...>) où r est un caractère ajouté à la liste des commandes, puis on coupe le courant (<0>).
Le CV de la machine s'affiche dans la fenêtre du moniteur.
Il n'y a rien à faire, c'est automatique.
L'exploitation du numéro de CV découvert n'est pas écrite dans cette version, mais on l'a et c'est le principal.
J'espère que ça pourra vous servir :D
Amicalement
Dominique
-
Comme ça me démangeait, voici une nouvelle version de :
- DCC++ version Nano seul sans piste de programmation et avec détection automatique de l'adresse DCC au démarrage sur la voie principale
- ManetteDCC, en processing qui récupère cette adresse DCC correctement
Il suffit de poser une loco sur la voie et de lancer la manette. L'écran va passer en vert le temps de la recherche de l'adresse DCC puis redeviendra rouge.
L'adresse par défaut est 3 donc elle doit changer sur l'écran Processing si votre loco a une adresse différente.
Ensuite la manette s'utilise comme avant.
Cette version de DCCpp_VV a été modifiée (un peu) pour compiler sur l'IDE 1.6.9 car la version précédente avait été adaptée pour compiler sur la version 1.6.0 de l'IDE (à cause du vieux MacBook que j'emporte an vacances) et, malheureusement, il y a pas mal de petites choses qui ont changé.
La manette affiche les messages reçus dans la console et j'ai ajouté une mesure de courant qui s'affiche aussi dans la console. Mais elle ne semble pas très significative. Il y a encore des choses à creuser de ce coté là.