rien n'est jamais fini
mais au 23 mai 2017 toutes les question techniques semblent avoir trouvé une réponse : le système fonctionne à 100%
c'est donc le moment d'envisager une pause (déjà largement entamée)
ce qui devrait encore être fait :
- équiper les véhicules nouvellement achetés
- faire faire les pcb des feux pour la z4 et la gt-r
- dessiner et réaliser les platines feux pour la A5 et la class C DTM
- au niveau du blog, faire un article sur le compte tour
Édit de sep 2017 : tout ce qui précède est réalisé (il ne fallait pas être pressé)
ce qui pourrait encore être fait :
- revendre les platines d'origine
- améliorations : idées spontanées ou suite à essais ou courses
mercredi 31 mai 2017
mardi 31 janvier 2017
Le protocole InfraRouge
J'aurais pu l'appeler le protocole aiguillage.
Il s'agit d'un signal infrarouge émis par le véhicule vers le sol, reçu par un capteur au niveau de la piste, et qui permet d'identifier le véhicule.
Cette identification à 2 utilités :
1) détection du passage sur la ligne d'arrivée pour renseigner le compte tours
2) identification du véhicule en amont de l'aiguillage : d'abord, les informations de bifurcation des véhicules sont transmises aux aiguillages depuis le module "blue", ainsi, les aiguillages savent quelle voiture doit bifurquer, ou pas. Un aiguillage donné doit encore savoir si un véhicule l'aborde, et quel est son numéro. Quand il a décodé le signal infrarouge et par là reconnu la voiture, il doit encore regarder dans sa mémoire si ce véhicule doit bifurquer ou pas, puis, le cas échéant,il manœuvre l'aiguille (le flipper).
Le code est simple, c'est un signal périodique composé d'une impulsion de lumière de 20µs et d'une obscurité de longueur variable afin de compléter la période
Les 36 valeurs :
la première ligne est le numéro du véhicule
la ligne en gras est la période en µs du signal infrarouge émis par la voiture correspondante
les 2 valeurs encadrantes, exemple 30 et 32µs pour la voiture 1, sont également admises par l'aiguillage ou le compte tour. Ainsi, si l'aiguillage mesure une période de 77µs, il considère qu'il s'agit de la voiture n°16, s'il mesure 78µs, il considère qu'il s'agit de la voiture n°17
il peut y avoir des erreurs. La première mesure, souvent erronée, n'est pas utilisée. La 2ème mesure fait l'objet d'une petite correction.
Pour détecter les erreurs j'utilise un principe simple : on regarde à quel véhicule correspondent les impulsions, dès qu'un véhicule à 4 impulsions qui lui correspondent, il est validé.
Lors les tests effectués il y a une erreur sur environ mille mesures, toujours immédiatement corrigée par 4 bonnes mesures. Le système est donc très fiable car le risque d'erreur est nul.
Notez que la méthode nécessite une bonne précision des oscillateurs des microcontrôleurs sur les décodeurs et les modules d'aiguillage. Cette précision est obtenue sans quartz grâce à la méthode décrite dans l'article "protocole circuit"
A pleine vitesse, le véhicule n°35 génère encore environ 8 périodes mesurables lors de son passage. Cela est suffisant pour pouvoir corriger l'une ou l'autre éventuelles erreurs
Techniquement, ce code est généré par un module pwm, dont le "on" (pulse) est fixe, et dont la période varie en fonction du numéro de la voiture
A la lecture, il faut un bon module capture pour déterminer les durées. Le calcul statistique doit également se faire rapidement, à fortiori dans le cas d'un aiguillage double ou d'un compte tours, car quand 2 véhicules se présentent simultanément, il faut faire les 2 calculs parallèlement.
Pas de souci pour le stm32f0, et dans ce cas également, la hiérarchisation des interruptions est appréciée.
Il s'agit d'un signal infrarouge émis par le véhicule vers le sol, reçu par un capteur au niveau de la piste, et qui permet d'identifier le véhicule.
Cette identification à 2 utilités :
1) détection du passage sur la ligne d'arrivée pour renseigner le compte tours
2) identification du véhicule en amont de l'aiguillage : d'abord, les informations de bifurcation des véhicules sont transmises aux aiguillages depuis le module "blue", ainsi, les aiguillages savent quelle voiture doit bifurquer, ou pas. Un aiguillage donné doit encore savoir si un véhicule l'aborde, et quel est son numéro. Quand il a décodé le signal infrarouge et par là reconnu la voiture, il doit encore regarder dans sa mémoire si ce véhicule doit bifurquer ou pas, puis, le cas échéant,il manœuvre l'aiguille (le flipper).
Le code est simple, c'est un signal périodique composé d'une impulsion de lumière de 20µs et d'une obscurité de longueur variable afin de compléter la période
la première ligne est le numéro du véhicule
la ligne en gras est la période en µs du signal infrarouge émis par la voiture correspondante
les 2 valeurs encadrantes, exemple 30 et 32µs pour la voiture 1, sont également admises par l'aiguillage ou le compte tour. Ainsi, si l'aiguillage mesure une période de 77µs, il considère qu'il s'agit de la voiture n°16, s'il mesure 78µs, il considère qu'il s'agit de la voiture n°17
il peut y avoir des erreurs. La première mesure, souvent erronée, n'est pas utilisée. La 2ème mesure fait l'objet d'une petite correction.
Pour détecter les erreurs j'utilise un principe simple : on regarde à quel véhicule correspondent les impulsions, dès qu'un véhicule à 4 impulsions qui lui correspondent, il est validé.
Lors les tests effectués il y a une erreur sur environ mille mesures, toujours immédiatement corrigée par 4 bonnes mesures. Le système est donc très fiable car le risque d'erreur est nul.
Notez que la méthode nécessite une bonne précision des oscillateurs des microcontrôleurs sur les décodeurs et les modules d'aiguillage. Cette précision est obtenue sans quartz grâce à la méthode décrite dans l'article "protocole circuit"
A pleine vitesse, le véhicule n°35 génère encore environ 8 périodes mesurables lors de son passage. Cela est suffisant pour pouvoir corriger l'une ou l'autre éventuelles erreurs
Techniquement, ce code est généré par un module pwm, dont le "on" (pulse) est fixe, et dont la période varie en fonction du numéro de la voiture
A la lecture, il faut un bon module capture pour déterminer les durées. Le calcul statistique doit également se faire rapidement, à fortiori dans le cas d'un aiguillage double ou d'un compte tours, car quand 2 véhicules se présentent simultanément, il faut faire les 2 calculs parallèlement.
Pas de souci pour le stm32f0, et dans ce cas également, la hiérarchisation des interruptions est appréciée.
lundi 9 janvier 2017
le module black
un accessoire modeste pour commencer l'année 2017
les manettes carrera sont chères et il est plus aisé de trouver des manette scalex (c7002) à bon prix
J'ai donc dans les cartons un projet de module pour raccorder 4 manettes scalex
des composants spéciaux sont nécessaires : self choke en boîtier 1206, jack pour fiche audio mono de 2.5mm. Les selfs sont nécessaires pour éviter les parasites les signaux de faible amplitude parcourant les cordons des manette
le dessin du pcb a été facilité par la reprise en grande partie de celui du module red. Le soft a été moins aisé, il a fallu faire des maths !
fonctionnement correct le 7 mars 2017, validés
le schéma :
le pcb : top et bottom
photo :
les manettes carrera sont chères et il est plus aisé de trouver des manette scalex (c7002) à bon prix
J'ai donc dans les cartons un projet de module pour raccorder 4 manettes scalex
des composants spéciaux sont nécessaires : self choke en boîtier 1206, jack pour fiche audio mono de 2.5mm. Les selfs sont nécessaires pour éviter les parasites les signaux de faible amplitude parcourant les cordons des manette
le dessin du pcb a été facilité par la reprise en grande partie de celui du module red. Le soft a été moins aisé, il a fallu faire des maths !
fonctionnement correct le 7 mars 2017, validés
le schéma :
le pcb : top et bottom
photo :
samedi 3 décembre 2016
la journée test
1er déc 2016 : le grand jour
on se rend compte que faire un système permettant de rouler avec 31 véhicules simultanément est plutôt ambitieux :
nous aurions pu être 7, mais nous ne nous retrouvâmes qu'à 4
j'ai été étonné par la persévérance de mes amis qui ont roulé 3 heures, alors que je me lasse au bout de 10 minutes ...
le système a bien fonctionné dans l'ensemble, je déplore les points suivants, qui donneront lieu à des investigations et corrections :
- le dispositif d'arrêt d'urgence n'a pas pu être utilisé, une des voitures continuant à rouler au ralenti ! (a)
- l'affichage du compte tours présentait un défaut de perte de couleur (la désignation de la voiture reprends la couleur de la voiture, pour une bonne lisibilité) : il y a un bug à trouver dans le programme vb net (b)
- par ailleurs cet affichage (vb net sous windows) rame à la réception des données bluetooth en provenance du module blue : il n'est ainsi pas possible d'avoir un chronométrage précis, ou un affichage dynamique des tensions et des courants (c)
- une des voitures est tombée en panne, heureusement lors d'une séance d'essai (d)
il y a d'autres enseignements :
- le local est trop petit vu le nombre de participants
- le circuit est trop en longueur, on n'a pas une bonne visibilité de la partie éloignée :
il faudra donc dans l'avenir faire un circuit en forme de C pour réduire les distances
- il faut plus de convivialité pour l'affectation des voitures aux différentes manettes : pouvoir pour chaque manette choisir dans la liste des voitures disponibles (e)
- mettre en service le dispositif de protection contre les court-circuit (f)
- les essais n'ont pas relevé de faiblesse de la fiabilité du compte tours, qui néanmoins n'est théoriquement pas à 100% (g)
à noter que le logiciel ultimate racer est désormais payant ...
je remercie les participants, les personnes ayant mis à disposition local et outils, et au vpciste du sud de la France qui propose du matériel à prix raisonnable
corrections :
(a) : fait : prise en compte de la variable "global_stop" dans le scheduler "switch (straight_repeat[throttle_num])" et "switch (thrown_repeat[throttle_num])"
(b) : défaut sans objet dans la nouvelle version du soft du 2 mai 2017
(c) : résolu 4 mai 2017 ! : maîtrise d'une (des?) méthode(s)
(d) : fait : contact tresse / guide suite à la surchauffe : nettoyage du guide et "recambrage" des tresses
(e) : fait : 2 mai 2017
(f) : fait 23 mai 2017 ; faire test en situation
(g) : changement de protocole : 100% au 2 mai 2017
on se rend compte que faire un système permettant de rouler avec 31 véhicules simultanément est plutôt ambitieux :
nous aurions pu être 7, mais nous ne nous retrouvâmes qu'à 4
j'ai été étonné par la persévérance de mes amis qui ont roulé 3 heures, alors que je me lasse au bout de 10 minutes ...
le système a bien fonctionné dans l'ensemble, je déplore les points suivants, qui donneront lieu à des investigations et corrections :
- le dispositif d'arrêt d'urgence n'a pas pu être utilisé, une des voitures continuant à rouler au ralenti ! (a)
- l'affichage du compte tours présentait un défaut de perte de couleur (la désignation de la voiture reprends la couleur de la voiture, pour une bonne lisibilité) : il y a un bug à trouver dans le programme vb net (b)
- par ailleurs cet affichage (vb net sous windows) rame à la réception des données bluetooth en provenance du module blue : il n'est ainsi pas possible d'avoir un chronométrage précis, ou un affichage dynamique des tensions et des courants (c)
- une des voitures est tombée en panne, heureusement lors d'une séance d'essai (d)
il y a d'autres enseignements :
- le local est trop petit vu le nombre de participants
- le circuit est trop en longueur, on n'a pas une bonne visibilité de la partie éloignée :
- il faut plus de convivialité pour l'affectation des voitures aux différentes manettes : pouvoir pour chaque manette choisir dans la liste des voitures disponibles (e)
- mettre en service le dispositif de protection contre les court-circuit (f)
- les essais n'ont pas relevé de faiblesse de la fiabilité du compte tours, qui néanmoins n'est théoriquement pas à 100% (g)
à noter que le logiciel ultimate racer est désormais payant ...
je remercie les participants, les personnes ayant mis à disposition local et outils, et au vpciste du sud de la France qui propose du matériel à prix raisonnable
corrections :
(a) : fait : prise en compte de la variable "global_stop" dans le scheduler "switch (straight_repeat[throttle_num])" et "switch (thrown_repeat[throttle_num])"
(b) : défaut sans objet dans la nouvelle version du soft du 2 mai 2017
(c) : résolu 4 mai 2017 ! : maîtrise d'une (des?) méthode(s)
(d) : fait : contact tresse / guide suite à la surchauffe : nettoyage du guide et "recambrage" des tresses
(e) : fait : 2 mai 2017
(f) : fait 23 mai 2017 ; faire test en situation
(g) : changement de protocole : 100% au 2 mai 2017
jeudi 6 octobre 2016
le protocole circuit
le courant délivré dans le circuit est créé par le module blue et amplifié par le module yellow
ce courant a 2 fonctions : alimenter les véhicules et transmettre les messages de vitesse
le messages de vitesse est composé du numéro du véhicule, suivi de la consigne de vitesse
le format utilisé est série, 9 bits, durée d'un bit de 13µs, pas de parité. Le choix du format série se justifie par la présence d'un périphérique uart dans le mcu des décodeurs à bord des véhicules, ce qui simplifie la programmation et apporte de la robustesse
le niveau 1 correspond à la tension d’alimentation, ici 15v, le niveau 0 correspond à 0v.
* voici la forme des octets transmis :
on voit qu'en plus du bit start, qui est obligatoirement à 0, un seul bit parmi le 9 bits normalement significatifs est aussi à 0 : en effet, si tous les bits étaient à 0, il n'y aurait plus de courant dans le circuit et les voitures ne pourraient pas rouler. J'ai donc fixé le principe suivant :
- il y a 1 et 1 seul bit significatif devant être à 0
- le bit 0, celui qui suit le start, n'est pas autorisé car je ne veux pas 2 bits consécutifs à 0v
on a donc un mot qui ne peut prendre que 8 valeurs différentes, au lieu des 512 normalement permises par les 9 bits
l'inconvénient de ce format (perso) c'est une baisse "dramatic" de la bande passante
les avantages sont :
- la simplicité électrique au niveau du module jaune (1/2 pont suffit) et des décodeurs (pas besoin de pont de graetz)
- une tension moyenne constante et peu diminuée
- un faible risque de perversion par les parasites, d'où une robustesse qui permet de se passer de mot de contrôle
la bande passante reste cependant très satisfaisante, la durée de transmission pour 1 véhicule étant de 1.04 ms. Pour un circuit comportant 6 voitures en courses, il faut 7.28 ms (une voie est réservée au système), ce qui fait un taux de rafraîchissement de 137Hz, qui dit mieux ?
** voici le format des messages :
les messages se suivent en boucle :
- numéro + vitesse voiture n°1
- numéro + vitesse voiture n°2
- etc.
- numéro + vitesse voiture n°31 (dernier)
- numéro + vitesse voiture n°1
- numéro + vitesse voiture n°2
- etc.
un message signifie le numéro et la vitesse d'une voiture
il est constitué d'un idle state suivi de 4 mots
les messages suivants ont le même format et se succèdent immédiatement. La durée de chaque message est invariablement de 1.04 ms, il n'y a pas de temps mort entre les messages successifs
l'idle state de 468 µs a 2 utilités :
- augmenter la tension moyenne pour être précisément et constamment la tension d'alim moins 10%. J'ai fixé cette valeur arbitrairement.
- désigner sans équivoque le début de chaque message
la durée rigide et précise de chaque message à 1040µs permet aux mcu réceptrices de régler précisément leur horloge rc internes et de se passer de quartz
la précision est nécessaire pour le rs232 (asynchrone), mais surtout pour l'identification des véhicules par infrarouge
*** à propos du protocole :
on aurait pu regrouper les 4 mots de chaque message de la manière suivante :
- les 2 premiers mots (rappel : un mot peut prendre 8 valeurs différentes) constituant 64 valeurs différentes et désignant le numéro du véhicule
- les 2 mots suivants et derniers constituant 64 valeurs différentes et désignant la vitesse à laquelle le véhicule (qui vient d'être désigné par son numéro) doit rouler
mais cela ne me convenait pas : 64 c'est trop grand pour le nombre de véhicules, et pas assez pour la précision de la vitesse (je ne peux pas faire moins bien que scalex !)
j'ai donc retenu le principe suivant :
- dans le premier groupe de 2 mots, 2 valeurs parmi 64 sont affectées à chaque véhicule, exemple :
2 et 3 pour la voiture 1
4 et 5 pour la voiture 2
...
62 et 63 pour la voiture 31
les valeurs 0 et 1 sont réservées au système
si le nombre est pair, exemple 4 pour la voiture 2, la vitesse sera basse
si le nombre est impair, exemple 5 pour la voiture 2, la vitesse sera haute
- le complément de vitesse est donné par le 2nd groupe de 2 mots, dont les valeurs sont comprises entre 0 et 63 :
si la vitesse est basse la vitesse finale sera de 0 à 63, selon la valeur de ce 2nd groupe
si la vitesse est haute la vitesse finale sera de 64 + la valeur du 2nd groupe, ie. les valeurs comprises entre 64 et 127
il y a 4 cas particuliers :
- la vitesse 0 c'est le freinage, il n'y a pas de roue libre, c'est de la course, pas de l'écologie !
- la "vitesse" 1 n'est pas destinée aux voitures mais aux aiguillages. Le message signifie que la voiture désignée par son numéro ne veut pas (plus) bifurquer aux aiguillages
- la "vitesse" 2 n'est pas destinée aux voitures mais aux aiguillages. Le message signifie que la voiture désignée par son numéro veut bifurquer aux aiguillages
- la vitesse 127, (en doutiez-vous ?) correspond à la vitesse maximale
il appartient à chaque véhicule de reconnaître son numéro et d'appliquer la vitesse correspondante en jouant sur la largeur du pwm commandant le moteur, en fonction de la vitesse reçue par le message
la vitesse 0 n'implique pas que la coupure du moteur, mais également l'activation du frein
il appartient aux aiguillages de décoder et de garder en mémoire : quelle voiture doit, ou ne doit pas, bifurquer
les messages système seront décrits ultérieurement, le protocole à ce stade est embryonnaire et sujet à modification
à suivre : le protocole IR
ce courant a 2 fonctions : alimenter les véhicules et transmettre les messages de vitesse
le messages de vitesse est composé du numéro du véhicule, suivi de la consigne de vitesse
le format utilisé est série, 9 bits, durée d'un bit de 13µs, pas de parité. Le choix du format série se justifie par la présence d'un périphérique uart dans le mcu des décodeurs à bord des véhicules, ce qui simplifie la programmation et apporte de la robustesse
le niveau 1 correspond à la tension d’alimentation, ici 15v, le niveau 0 correspond à 0v.
* voici la forme des octets transmis :
on voit qu'en plus du bit start, qui est obligatoirement à 0, un seul bit parmi le 9 bits normalement significatifs est aussi à 0 : en effet, si tous les bits étaient à 0, il n'y aurait plus de courant dans le circuit et les voitures ne pourraient pas rouler. J'ai donc fixé le principe suivant :
- il y a 1 et 1 seul bit significatif devant être à 0
- le bit 0, celui qui suit le start, n'est pas autorisé car je ne veux pas 2 bits consécutifs à 0v
on a donc un mot qui ne peut prendre que 8 valeurs différentes, au lieu des 512 normalement permises par les 9 bits
l'inconvénient de ce format (perso) c'est une baisse "dramatic" de la bande passante
les avantages sont :
- la simplicité électrique au niveau du module jaune (1/2 pont suffit) et des décodeurs (pas besoin de pont de graetz)
- une tension moyenne constante et peu diminuée
- un faible risque de perversion par les parasites, d'où une robustesse qui permet de se passer de mot de contrôle
la bande passante reste cependant très satisfaisante, la durée de transmission pour 1 véhicule étant de 1.04 ms. Pour un circuit comportant 6 voitures en courses, il faut 7.28 ms (une voie est réservée au système), ce qui fait un taux de rafraîchissement de 137Hz, qui dit mieux ?
** voici le format des messages :
les messages se suivent en boucle :
- numéro + vitesse voiture n°1
- numéro + vitesse voiture n°2
- etc.
- numéro + vitesse voiture n°31 (dernier)
- numéro + vitesse voiture n°1
- numéro + vitesse voiture n°2
- etc.
un message signifie le numéro et la vitesse d'une voiture
il est constitué d'un idle state suivi de 4 mots
les messages suivants ont le même format et se succèdent immédiatement. La durée de chaque message est invariablement de 1.04 ms, il n'y a pas de temps mort entre les messages successifs
l'idle state de 468 µs a 2 utilités :
- augmenter la tension moyenne pour être précisément et constamment la tension d'alim moins 10%. J'ai fixé cette valeur arbitrairement.
- désigner sans équivoque le début de chaque message
la durée rigide et précise de chaque message à 1040µs permet aux mcu réceptrices de régler précisément leur horloge rc internes et de se passer de quartz
la précision est nécessaire pour le rs232 (asynchrone), mais surtout pour l'identification des véhicules par infrarouge
*** à propos du protocole :
on aurait pu regrouper les 4 mots de chaque message de la manière suivante :
- les 2 premiers mots (rappel : un mot peut prendre 8 valeurs différentes) constituant 64 valeurs différentes et désignant le numéro du véhicule
- les 2 mots suivants et derniers constituant 64 valeurs différentes et désignant la vitesse à laquelle le véhicule (qui vient d'être désigné par son numéro) doit rouler
mais cela ne me convenait pas : 64 c'est trop grand pour le nombre de véhicules, et pas assez pour la précision de la vitesse (je ne peux pas faire moins bien que scalex !)
j'ai donc retenu le principe suivant :
- dans le premier groupe de 2 mots, 2 valeurs parmi 64 sont affectées à chaque véhicule, exemple :
2 et 3 pour la voiture 1
4 et 5 pour la voiture 2
...
62 et 63 pour la voiture 31
les valeurs 0 et 1 sont réservées au système
si le nombre est pair, exemple 4 pour la voiture 2, la vitesse sera basse
si le nombre est impair, exemple 5 pour la voiture 2, la vitesse sera haute
- le complément de vitesse est donné par le 2nd groupe de 2 mots, dont les valeurs sont comprises entre 0 et 63 :
si la vitesse est basse la vitesse finale sera de 0 à 63, selon la valeur de ce 2nd groupe
si la vitesse est haute la vitesse finale sera de 64 + la valeur du 2nd groupe, ie. les valeurs comprises entre 64 et 127
il y a 4 cas particuliers :
- la vitesse 0 c'est le freinage, il n'y a pas de roue libre, c'est de la course, pas de l'écologie !
- la "vitesse" 1 n'est pas destinée aux voitures mais aux aiguillages. Le message signifie que la voiture désignée par son numéro ne veut pas (plus) bifurquer aux aiguillages
- la "vitesse" 2 n'est pas destinée aux voitures mais aux aiguillages. Le message signifie que la voiture désignée par son numéro veut bifurquer aux aiguillages
- la vitesse 127, (en doutiez-vous ?) correspond à la vitesse maximale
il appartient à chaque véhicule de reconnaître son numéro et d'appliquer la vitesse correspondante en jouant sur la largeur du pwm commandant le moteur, en fonction de la vitesse reçue par le message
la vitesse 0 n'implique pas que la coupure du moteur, mais également l'activation du frein
il appartient aux aiguillages de décoder et de garder en mémoire : quelle voiture doit, ou ne doit pas, bifurquer
les messages système seront décrits ultérieurement, le protocole à ce stade est embryonnaire et sujet à modification
à suivre : le protocole IR
nouveau problème, nouvelle solution
Lors d'un test un véhicule a "désloté" et le guide s'est désolidarisé de son axe. Les tresses se sont donc retrouvées libres, et l'une d'elle s'est mise à cheval sur les 2 rails inox. Cela a provoqué un cour-circuit, drainant le courant maximal de l'alim, soit 20A. La tresse s'est mise à chauffer et a fait fondre le guide.
Avec l'alim d'origine, de 2 ou 3A, cet incident ne se serait probablement pas produit. Il y a donc un défaut dans mon système, mettant en péril notamment l'intégrité des véhicules. Le fusible dans le véhicule ne sert à rien dans ce cas.
Comment détecter les court-circuits ou les charges anormales ?
C'est faisable : le module blue a une idée du nombre de véhicules en service et de leurs consommation instantanées, donc il peut calculer la somme des ampères devant parcourir le circuit, du moins avec une précision satisfaisante. Reste à mesurer la consommation totale et à la comparer à la consommation calculée. En cas de différence patente, le courant sera coupé.
Cela m'a obligé à réaliser un nouveau module blue et un nouveau module yellow, et à rajouter les softs nécessaires
Avec l'alim d'origine, de 2 ou 3A, cet incident ne se serait probablement pas produit. Il y a donc un défaut dans mon système, mettant en péril notamment l'intégrité des véhicules. Le fusible dans le véhicule ne sert à rien dans ce cas.
Comment détecter les court-circuits ou les charges anormales ?
C'est faisable : le module blue a une idée du nombre de véhicules en service et de leurs consommation instantanées, donc il peut calculer la somme des ampères devant parcourir le circuit, du moins avec une précision satisfaisante. Reste à mesurer la consommation totale et à la comparer à la consommation calculée. En cas de différence patente, le courant sera coupé.
Cela m'a obligé à réaliser un nouveau module blue et un nouveau module yellow, et à rajouter les softs nécessaires
mercredi 31 août 2016
fonctionnement correct de l'ensemble
fonctionnement correct de l'ensemble le 22/8/2016 à 18h00
20 pcb décodeur carrera, 5 modules red et 10 modules switches ont été assemblés par elecrow en chine
expérience concluante malgré une petite erreur : sur les modules red les couleurs des leds 5 à 8 devaient être orange jaune orange jaune, interprétation chinoise : orange orange jaune jaune. Pas de souci pour ce qui me concerne, j'ai pu permuter les leds incriminées
20 pcb décodeur carrera, 5 modules red et 10 modules switches ont été assemblés par elecrow en chine
expérience concluante malgré une petite erreur : sur les modules red les couleurs des leds 5 à 8 devaient être orange jaune orange jaune, interprétation chinoise : orange orange jaune jaune. Pas de souci pour ce qui me concerne, j'ai pu permuter les leds incriminées
Inscription à :
Articles (Atom)