LOCODUINO
Discussions Générales => Bus CAN => Discussion démarrée par: Tony04 le mai 23, 2018, 05:01:37 pm
-
Bonjour,
je me suis permis d'ouvrir un nouveau sujet car je n'ai rien trouvé sur le forum pour en discuter.
Comme je vous en ai parlé dans le sujet "Réduire câblage", je travaille actuellement avec mes 3 cartes (boucle, aiguille et signalisation) reliées par le merveilleux bus CAN en utilisant les routine de: http://www.locoduino.org/spip.php?article130.
Pour la création du signal DCC j'utilise un UNO avec le logiciel DCC++ de Gregg E. Berman si bien exliqué ici: http://www.locoduino.org/spip.php?article182
Ce logiciel reçoit ses commandes par la voie série alors que ce serait plus logique chez moi d'utiliser là aussi le bus CAN.
Mon but serait de parvenir à la structure de la "Figure 2 : Architecture de l’électronique en mode DCC" de l'article http://www.locoduino.org/spip.php?article132.
J'ai beau me plonger dans les méandres de "PacketRegister.cpp" et de "SerialCommand.cpp", je n'arrive pas à trouver le moyen d'interfacer ces fonctions avec la réception CAN.
Je vous joins le fichier de base que j'utilise pour la communication CAN.
On a tellement parlé du bus CAN sur Locoduino, ai-je loupé le sujet ou quelqu'un a-t-il déjà réalisé cette liaison ?
Merci par avance pour vos réponses.
Antoine
PS: Je vous avais également parlé de mes test de reconnaissance de loco par effet HALL; projet définitivement abandonné car trop de difficultés à positionner les aimants. Du coup je me suis moi aussi rabattu sur le RFID avec le module suivant qui fonctionne bien même avec plusieurs modules sur le circuit:
https://fr.aliexpress.com/item/RFID-Reader-Wireless-Module-UART-3Pin-125KHz-Card-Reading-EM4100-8CM-DC-5V-for-IC-Card/32831988522.html?spm=a2g0s.9042311.0.0.40696c37W3dFzp
-
le module RFID suivant ... fonctionne bien ...
bonsoir,
des questions : à quelle distance et à quelle vitesse le tag est détecté ? Le tag est le rond, genre porte-clé ? Le module est placé sous la voie ?
merci d'avance.
-
Bonsoir msport,
j'utilise les tags suivants: https://fr.aliexpress.com/item/EM4100-125khz-rfid-keyfob-Proximity-ID-Token-Tag-Key-for-access-control-Arduino/32441862393.html?spm=a2g0s.9042311.0.0.56e46c37eyeXl3
mais je les ouvre et découpe autour de la bobine pour réduire l'encombrement puis je les met au plus bas de la loco (à la place du décodeur dans mon cas); le lecteur est quand à lui sous un panneau de MDF de 10mm pour les essais
Le tag est détecté à 40mm sans problème et à vitesse max de la loco.
Bonne soirée
Antoine
-
Bonsoir,
J'ai monté ce type de détection RFID
J'ai testé avec des tags en verre (puces pour les animaux "problème d'approvisionnement via Aliexpress") et détecteurs comme mentionné par Tony, cela fonctionne mais il faut affiner
J'ai fait un petit programme sous Excel qui reconnais le numéro de wagons.
Je me suis inspiré de ce post:
https://www.youtube.com/watch?v=CM88k0HpyGc
Cordialement
Marcel
-
Hello,
j'avance petit à petit avec ma commande de la carte UNO qui produit le DCC et qui doit être commandée par le bus CAN.
Exemple: Dans la version ci-jointe, j'ai récupéré les 7 octets de la commande "<t 1 3 30 1>" (je ne compte pas les espaces) dans Rbuf aux lignes 285 à 308.
Mes connaissances s'arrêtent là, je n'ai aucune idée comment je peux transmettre ces données à l'une des fonctions "SerialCommand::process()" ou "SerialCommand::parse(char *com)" ou directement à l'une des 4 fonctions suivantes: "setThrottle()", "setFunction()", "writeCVByte()", "readCV()" ce qui me semblerait plus judicieux. Je n'utilise rien d'autre.
La seule commande que j'ai pu passer c'est <0> ou <1> (c'était facile :P).
Pour les quelques "CRACS" qui animent ce forum ce doit être un jeu d'enfant.
Un grand merci à qui me donne la solution.
Bonne soirée à tous
Antoine
-
Faute de temps, je n'ai pas pu regarder tes différents codes, mais si tu as réussi à envoyer <0> ou <1> à DCCpp le plus dur est fait. Dans la version originale de DCCpp ligne 205 du fichier DCCpp_uno.ino, tu as l'appel de la fonction : SerialCommand::process(); au tout début du loop.
C'est cette fonction (dans le fichier SerialCommand) qui va faire le travail :
void SerialCommand::process(){
char c;
#if COMM_TYPE == 0
while(INTERFACE.available()>0){ // while there is data on the serial line
c=INTERFACE.read();
if(c=='<') // start of new command
sprintf(commandString,"");
else if(c=='>') // end of new command
parse(commandString);
else if(strlen(commandString)<MAX_COMMAND_LENGTH) // if comandString still has space, append character just read from serial line
sprintf(commandString,"%s%c",commandString,c); // otherwise, character is ignored (but continue to look for '<' or '>')
} // while
#elif COMM_TYPE == 1
EthernetClient client=INTERFACE.available();
if(client){
while(client.connected() && client.available()){ // while there is data on the network
c=client.read();
if(c=='<') // start of new command
sprintf(commandString,"");
else if(c=='>') // end of new command
parse(commandString);
else if(strlen(commandString)<MAX_COMMAND_LENGTH) // if comandString still has space, append character just read from network
sprintf(commandString,"%s%c",commandString,c); // otherwise, character is ignored (but continue to look for '<' or '>')
} // while
}
#endif
} // SerialCommand:process
Ici, tu as les cas pour le port serie et pour une liaison en ethernet TCP. Il faut ajouter le cas de la réception en CAN et la fonction parse(commandString); va faire tout le reste du travail.
Comme tu fais la réception des messages CAN dans ton loop, tu peux essayer d'envoyer l'ensemble du message reçu comme paramètre à SerialCommand::process(tonMessageCan) du loop. Et modifier en consèquence SeriaCommand.cpp et SerialCommand.h
Bien sûr, dans le loop, tu n'auras plus à appeler SerialCommand::process() à chaque tour mais simplement quand tu as un nouveau message CAN
-
Merci boby pour tes précisions qui malheureusement n'ont pas répondu immédiatement à mon problème.
J'avais bien compris comment et où étaient traités les commandes séries, mais je n'arrivais pas à passer mon message récupéré par CAN dans le loop vers les fonctions qui vont utiliser ces valeurs.
Mais il semblerait que ta réponse m'a boosté car je viens de trouver la solution.
En suivant tes conseils j'ai essayé toutes les possibilités imaginables et suis arrivé à l'instruction suivante "SerialCommand::parse(cmdChar);" ligne 327 dans le loop du pgm joint, où cmdChar est la chaine de char (remaniée à ma sauce, voir le String(char(Rbuf[1]))) qui contient les caractères reconnus par SerialCommand::parse. C'était tout bête au fond mais je maîtrise très mal "le monde des objets" pourtant si bien expliqué par Thierry dans http://www.locoduino.org/spip.php?article85.
En tous cas ça y est, toutes mes cartes sont reliées par le bus CAN et se parlent comme une belle petite famille :D
Merci au forum et à ses acteurs pour les coups de pouce qu'ils nous donnent.
Très bonne journée à tous avec un peu de soleil de Sisteron 8)
Antoine
-
Aie, aie, aie,
en ce qui concerne les essais de détection RFID, je commence à me ranger du coté de Marcel et suis désolé de ma réponse trop rapide à msport.
En effet une fois sur le circuit ce n'est plus les mêmes résultats que sur mon rail d'essai, il a fallu que je déplace le tag qui était sous le moteur, que je rapproche le lecteur et en fin de compte je vais certainement placer les tags sur les cotés des locos au plus loin du moteur et mon lecteur dans un abri ou tunnel ou autre.
Comme a dit Marcel, "il faut affiner"...
à suivre donc
-
Merci pour ces réponses somme toute encourageantes.
Peut-être qu'une antenne indépendante serait plus efficace ?
https://www.ebay.fr/itm/125K-EM4100-RFID-Card-Reader-Module-RDM6300-ID-RF-Module-UART-Output-For-Arduino/263106416572
-
Il se trouve que j'ai aussi testé ce modèle qui est nettement moins sensible, achat inutile.
Je continue mes recherches et essais.
On se tient au courant
Antoine
-
Bien que le sujet soit sur le CAN, je signale que j'ai acheté ces 2 produits RFID :
https://www.ebay.fr/itm/5148-MFRC-522-RC522-RFID-Kits-S50-13-56-Mhz-6cm-for-arduino/142493271686 (https://www.ebay.fr/itm/5148-MFRC-522-RC522-RFID-Kits-S50-13-56-Mhz-6cm-for-arduino/142493271686)
et
https://www.ebay.fr/itm/10-Clear-Midas-Tiny-NFC-Tags-Stickers-12mmx19mm-wafer-thin-NXP-NTAG213/271421280851 (https://www.ebay.fr/itm/10-Clear-Midas-Tiny-NFC-Tags-Stickers-12mmx19mm-wafer-thin-NXP-NTAG213/271421280851)
Et des test ont été faits dans mon club sur les réseaux N et HO : la carte électronique se glisse facilement sous les rails, même en N et les tags sont des étiquettes autocollantes assez petites pour se loger sous une loco N ou un wagon. Des essais en vitesse des trains ont montré que les détections sont fiables. Mais ça reste à confirmer quand même.
Il faut seulement éviter de coller l'étiquette sur une partie métallique.
Je publierai des résultats de tests un de ces jours ...
-
Bonjour Dominique (et tous les autres bien sûr ;)),
j'avais déjà utilisé ce lecteur pour une autre application mais ne connaissais pas les stickers (que je viens de commander), je vous tiendrai au courant de mes expériences.
Mais revenons au bus CAN qui était le sujet premier de ce fil.
Ma question était: Est-ce que quelqu'un a déjà réalisé la structure de la "Figure 2 : Architecture de l’électronique en mode DCC" de l'article http://www.locoduino.org/spip.php?article132 ?
Comme je n'ai pas de réponse :'(, je repose la question (mais qu'une seule fois ;D).
Bon début de WE à tous
Antoine
-
Est-ce que quelqu'un a déjà réalisé la structure de la "Figure 2 : Architecture de l’électronique en mode DCC" de l'article http://www.locoduino.org/spip.php?article132 ?
Comme je n'ai pas de réponse :'(, je repose la question (mais qu'une seule fois ;D).
Bon début de WE à tous
Antoine
Bonsoir Antoine,
Ayant discuté récemment avec Denis (DD), je peux te dire qu’il n’ à pas encore réalisé lui-même cette architecture qui est inspirée par les différentes discussions entre nous : c’est son « best of » de cette époque :D
(http://www.locoduino.org/IMG/jpg/schema_global_dcc.jpg)
Personnellement l’architecture de mon réseau perso est un peu différente (http://forum.locoduino.org/index.php?topic=290.msg3101#msg3101 (http://forum.locoduino.org/index.php?topic=290.msg3101#msg3101)) autour du bus Can mais elle existe et fonctionne à merveille.
(http://www.locoduino.org/IMG/jpg/archi.018.jpg)
Là aussi c’était mon « best of » du moment et ça correspondait à la taille de mon réseau et au nombre d’équipements qui permettait de regrouper par fonctions et les réaliser par etape, plutôt que de distribuer comme sur le schéma de Denis.
J’ai préféré voir mes trains rouler rapidement et ajouter l’intelligence progressivement sans refaire ce qui était fait. L’architecture à Denis demande beaucoup plus d’efforts avant de voir rouler un train.
Aujourd’hui je verrai l’architecture un peu différemment et je ferai plutôt un mix des deux architectures en distribuant des petites cartes capables de gérer plusieurs équipements de voie proches les uns des autres (aiguilles, capteurs de présence, signaux notamment) le long d’un bus Can sur lequel se trouve aussi la centrale, le gestionnaire, le TCO, etc..
Comme je l’ai déjà un peu dévoilé dans ce forum, il se trouve qu’avec mes amis de Locoduino nous développons une telle carte que nous décrirons quand elle sera au point et que nous montrerons à Orléans les 10 et 11 Novembre.
Ce n’est pas moi qui en a eu l’idée et qui l’a conçue, mais je participe à sa mise au point et je la trouve géniale.
Encore un peu de patience car je n’avance pas très vite :P
Amicalement
Dominique
-
Bonsoir Dominique,
si j'ai bien compris ta nouvelle vision de la structure est absolument identique ou du moins très très proche de celle qui m'a faite ouvrir le fil http://forum.locoduino.org/index.php?topic=501.msg5184#msg5184 et que j'ai réalisé avec mes 3 cartes présentées dans le fil. Comme tu peux le voir, chaque carte a plusieurs fonctions afin d'optimiser les sorties et de réduire le câblage.
Si oui, cela va me donner le courage de démarrer de façon plus concrète mon projet car pour l'instant je travaille avec quelques voies au sol mais surtout sur l'ordi pour le hardware et les logiciels qui vont avec.
Demain après-midi je prends contact avec le Rail Model Club de Manosque dans les Alpes de Haute Provence (à 35 km de chez moi) pour trouver peut-être des personnes qui ont comme moi cette envie de DIY.
Merci en tous cas pour ces sympathiques échanges.
Cordialement
Antoine
-
Comme je l’ai déjà un peu dévoilé dans ce forum, il se trouve qu’avec mes amis de Locoduino nous développons une telle carte que nous décrirons quand elle sera au point et que nous montrerons à Orléans les 10 et 11 Novembre.
Ce n’est pas moi qui en a eu l’idée et qui l’a conçue, mais je participe à sa mise au point et je la trouve géniale.
Encore un peu de patience car je n’avance pas très vite :P
Amicalement
Dominique
Bonjour Dominique,
après avoir consulté le forum presque toute la journée hier pour tout lire (hé oui, je suis nouveau), j'ai passé une nuit quelque peut agitée et pleins de choses ce sont bousculées dans ma tête
j'ai passé 20 ans de ma vie professionnelle à développer des moutons à 5 pattes en électronique avec bien sûr aussi la conception du circuit imprimé qui va avec.
Ne pourrais-je pas vous faire profiter de mon expérience pour le développement de la carte citée ?
Voici la technologie que j'ai appliqué pour les miennes:
- 1 led CMS de contrôle pour chaque entrée toujours opto-isolée et la led directement à l'entrée côté diode de l’optocoupleur (très utile en cas de défaillance d'un switch ou effet Hall, ainsi que dans la phase de développement).
- 1 led CMS sur chaque sortie ainsi que sur les bobines des relais.
- 1 entrée alimentation 5V pour le µP (sur bornier si possible débrochable).
- 1 entrée alimentation 5V ou autre pour les optos coté diode ou les relais (sur le même bornier).
- tous les circuits intégrés non CMS sur support.
- bien sûr le µP (NANO ou MICRO) sur support.
- 1 carte CAN sur support (2 sorties CAN sur bornier, mais à voir)
- toutes les entrées/sorties sur connecteurs du style https://fr.rs-online.com/web/p/embases-de-circuit-imprime/2305060/ avec outil de sertissage fabriqué maison.
- utilisation d'un plan de masse généralisé (non réalisé sur les protos du fil http://forum.locoduino.org/index.php?topic=501.15).
Tous ces choix dans 1 seul but la maintenance et la mise au point facile
Autre sujet pour ton TCO, as-tu pensé au MAX7219 en mode "sans décodage" qui permet d'adresser 64 leds en matrice donc très facile à câbler et qui remplace 8 de tes 74HC595.
Si non, regarde ici: http://tronixstuff.com/2013/10/11/tutorial-arduino-max7219-led-display-driver-ic/
ou ici: https://www.idreammicro.com/post/Controleurs-d-affichage-Maxim-MAX7219-MAX7221
C'est un composant hyper fiable que j'ai utilisé dans l'industrie du lavage auto pendant des années.
Je vais d'ailleurs le mettre dans le sujet "COMPOSANTS", tout le monde ne connait pas forcément ce circuit.
Je vais aussi chercher dans mes archives tous les composants qui pourraient être utiles dans LOCODUINO.
Dernière chose qui m'a turlupiné, la réalisation et le prix des circuits imprimés. J'ai fait réaliser les miens ici: https://jlcpcb.com/ pour un prix défiant toute concurrence, j'ai pourtant essayé les liens indiqués dans ce forum mais la différence est énorme.
La qualité est irréprochable, il suffit de voir la présentation de la société.
Mais attention! Ne pas opter pour une livraison par DHL à cause des frais facturés par ces derniers (on en a déjà parlé ailleurs sur ce forum), il faut choisir "Air mail".
Un exemple à tester pour trouver moins cher si quelqu'un veut essayer: le circuit double face (2 fichiers gerber ci-joint qu'il faut à nouveau réunir, ils était trop volumineux) qui fait quand même 195 x 277mm, prix pour 5 pièces..... 39,09€ les 5 (28$ le circuit et 16.29$ de port).
La aussi je vais le mettre dans le sujet "Bonnes affaires".
Voila ce qui me travaille la nuit en ce moment; d'ailleurs il ne faudra pas que cela dure trop longtemps si je ne veux pas me faire rappeler à l'ordre par ma charmante épouse ::)
J'ai démarré ce message vers 5h30 ce matin, il est 6h40 :P, alors très bon WE à tous
Antoine
-
Bonjour Antoine,
Moi aussi il m’arrive d’être plus créatif au lever du jour, surtout quand une question me turlupine la veille où les jours précédents. Par contre je n’ai pas autant de savoir-faire en électronique que toi donc je cherche plutôt des solutions simples. Tu pourras te rapprocher de Jean-Luc, « le père créateur de Locoduino », heureusement pour lui, beaucoup plus jeune que nous ;D
Cela dit, en s’y mettant à plusieurs, on peut bien au delà des limites de ses propres compétences, et c’est là tout l’intérêt de Locoduino ;D
En tout cas tu as bien lu ce qu’on écrit dans ce site et tu sembles prêt à contribuer à l’effort rédactionnel du site, avec une énergie et une expérience très intéressante pour tes futurs lecteurs.
Maintenant je comprends pourquoi tu t’intéresses autant à l’architecture avant d’engager des développements matériels sur circuits imprimes. C’est pour cela que nous avons créé les sujets sur la modélisation et l’architecture, chose plus rare sur les autres forums. Ici nous essayons de « voir » le plus loin possible, avec, en tête des idées de normalisation pour simplifier la conception des différents projets que nous avons et trouver d’autres voies que les solutions du commerce, plus chères et généralement « pas françaises ».
Il se trouve que nous avons réuni sur Locoduino la plupart des technologies qui permettent de construire un réseau intelligent très complet sans passer par l'achat d'une centrale du commerce et d'un logiciel de contrôle et de commande, le tout dépassant largement les 1000€.
La majorité d'entre nous est en DCC surtout depuis l'arrivée de DCC++ et maintenant de sa version en bibliothèque DCCpp faite par Thierry (un gros progrès !), mais il y a aussi de la place pour l'analogique dont la plus belle réalisation est celle de Jean-Luc (http://modelleisenbahn.triskell.org (http://modelleisenbahn.triskell.org)).
Le DCC sert à commander le matériel roulant mais nous ne tombons pas dans l'exagération : pas de commande d'accessoires en DCC, les rails constituent un réseau de transmission trop pollué pour cela. D'où le bus Can pour tous les autres échanges.
Ce principe étant posé, on arrive vite à se demander comment concevoir et faire communiquer tout un monde de "périphériques" intelligents (il y a forcément un Arduino dans chacun des objets connectés). On l'a fait d'abord chacun de son coté en réinventant un protocole de communication personnel. Maintenant il est temps de chercher et trouver un protocole aussi universel que possible pour raccorder et faire vivre les différents modules dont nous avons besoin et qui viendront s'ajouter progressivement aux premiers arrivés, si possible sans se casser la tête à adapter les logiciels à chaque nouvel entrant.
En ce sens, il me semble évident que les cartes que tu as conçues peuvent parfaitement s'intégrer dans cette architecture : il ne reste plus que le logiciel à réaliser.
Cette dernière étape que j'aimerai appeler "de normalisation logicielle" sans vouloir être prétentieux car le sujet n'est pas simple, est déjà en train de germer au sein de Locoduino mais, comme le bon pain, il faut que ça lève lentement et la retraite n'est plus la galère donc ça avance lentement.
La prochaine étape dans cette réflexion sera l'exposition d'Orléans le 10 et 11 Novembre (http://forum.locoduino.org/index.php?topic=515.0 (http://forum.locoduino.org/index.php?topic=515.0))
Si tu peux nous y rejoindre, nous t'invitons à y présenter tes cartes et, pourquoi pas, à les décrire au préalable sur le site éditorial de Locoduino.
Bon courage
Dominique
-
Ouahou, quelle réactivité, message à 5h30 du matin, réponse à 8h03 !!!
Tu me surprend en me répondant que tu cherches des solutions simples, le MAX7219 ne te simplifierait-il pas énormément ton TCO ?
Par contre tu ne réponds pas à ma proposition de participer au développement de votre ou plutôt vos cartes (car je ne crois pas qu'un seul modèle de carte puisse répondre au besoin).
Que votre équipe se rassure, c'est juste une proposition, si vous ne voulez personne d'autre dans ce groupe je comprendrai très bien et ne vous en voudrai pas du tout.
De plus mon but avec mes cartes n'est pas de les imposer, loin de là, d'ailleurs j'ai déjà des améliorations à y apporter, mais il fallait que je les réalise pour avoir une expérience réelle et pas seulement théorique. En électronique la théorie ne suffit pas comme vous avez tous pu vous en rendre compte :-[.
Bonne journée à toi et à très vite
Antoine
-
Tu me surprends en me répondant que tu cherches des solutions simples, le MAX7219 ne te simplifierait-il pas énormément ton TCO ?
Tout simplement parce que mon TCO est fait et marche nickel, je ne vais pas le démonter pour en faire un autre, d’autant que le plus pénible est la câblage 8)
-
Bonjour à tous,
comme je l'ai précisé dans ce fil, j'utilise chez moi le bus CAN entre toutes les cartes y compris la carte qui reçoit les infos de la souris (pour l'instant mon smartphone).
Je viens de m'inscrire au Rail Model Club de Manosque (http://railmc04.chez.com/) qui commence très péniblement le DCC et qui semble très très intéressé par le système LOCODUINO.
Ils ont 400m de voie avec 92 aiguilles mais pour l'instant pas de rétro-signalisation ni d'accessoires.
Pour la commande du réseau ils ont fabriqué 4 TCO assez minimalistes(mais qu'on va garder) et voudraient utiliser plusieurs souris sans fil avec le nouveau système envisagé.
Voila ce que je leur propose (en PJ). En rose le minimum pour commencer à "jouer", le reste au fur et à mesure de la transformation analogique en DCC.
Pour les souris multiples voyez-vous une autre solution que celle que j'ai envisagé (1 carte nano+CAN+HC12 par souris) ?
Merci par avance pour vos propositions et bonne journée à tous (surtout pas trop de grelons pour les Nord-Ouest'istes)
Antoine
-
Comme tout bon jésuite que je ne suis pas, il est difficile de te répondre autrement que par des questions car ce seul schéma n’est pas assez détaillé :
- que font les souris, côté Can et côté sans fil ? Pilotent-elles des trains manuellement ? Sans restriction ?
- que fait le Mega Maitre ? Pourquoi un Mega ?
- les détections de présence sont disséminées sur plusieurs cartes, dont des cartes futures, alors comment fonctionne la retrosignalisation ? Partielle ?
- pourquoi un Can a 125kHz ? (Schéma de DDEF)
- si les R= et T= sont les identifiant Can, alors comment sont-ils choisis pour tenir compte des priorités ? Les valeurs les plus faibles sont plus prioritaires !
- quel gestionnaire sera intégré ?
Bon j’arrête la ...
Bon courage
-
Coucou,
- que font les souris, côté Can et côté sans fil ? Pilotent-elles des trains manuellement ? Sans restriction ?
On envisage de fabriquer des souris dans la philosophie de la Multimaus (une imprimante 3D est dispo à la MJC) pour le pilotage manuel (sans restriction pour le début).
Mon schéma n'est en effet pas très clair, ( je vous avais prévenu ;)). Ce n'est pas "Souris" que j'aurais du l'appeler, mais Récepteur souris.
Côté CAN elles envoient les commandes DCC vers la carte DCC en passant par le gestionnaire (Maître sur mon schéma). Côté sans fil (HC12 et non NRF24L01 qui est trop sensible d'après mon expérience) elle reçoit les infos de la souris elle-même.
- que fait le Mega Maitre ? Pourquoi un Mega ?
C'est en fait le gestionnaire (qui fera ce qu'on lui demandera de faire >:( avec la grande aide de Locoduino, pas trop clair encore dans ma tête) et un MEGA parce qu'au départ j'étais parti la dessus mais un DUE sera plus adapté d'après ce que j'ai appris depuis que je fréquente assidument votre forum.
- les détections de présence sont disséminées sur plusieurs cartes, dont des cartes futures, alors comment fonctionne la retrosignalisation ? Partielle ?
La aussi c'était mon idée première (avant Locoduino) pour éviter trop de câblage et profiter des pins dispos et je ne comprend toujours pas pourquoi cela pose un problème pour la retrosignalisation. Peux-tu m'expliquer ton "Partielle" ?
- pourquoi un Can a 125kHz ? (Schéma de DDEF)
Parce qu'à mon âge et en Provence on se prends le temps de vivre Monsieur... 8) . En fait je ne me suis jamais posé la question car pour l'instant mes cartes passent 99% de leur temps à attendre, que j'ai copié la bulle du schéma de DDEF (sans payer les droits d'auteur) et que ce sera très facile de modifier en cas de besoin.
- si les R= et T= sont les identifiant Can, alors comment sont-ils choisis pour tenir compte des priorités ? Les valeurs les plus faibles sont plus prioritaires !
Ce ne sont que des valeurs prises au hasard pour l'instant mais tu fais bien de me rappeler le principe de la priorité (que j'ai bien appris ici: http://www.locoduino.org/spip.php?article130).
- quel gestionnaire sera intégré ?
Ce sera le MEGA euh le DUE.
De toute façon j'ai toutes les vacances pour bien cogiter le sujet car le Club s'arrête dans 15 jours, mais je compte bien sur vous tous, même pendant vos vacances ::), pour me guider vers la bonne solution.
Merci à vous
Antoine
-
- les détections de présence sont disséminées sur plusieurs cartes, dont des cartes futures, alors comment fonctionne la retrosignalisation ? Partielle ?
La aussi c'était mon idée première (avant Locoduino) pour éviter trop de câblage et profiter des pins dispos et je ne comprend toujours pas pourquoi cela pose un problème pour la retrosignalisation. Peux-tu m'expliquer ton "Partielle" ?
Tout simplement, si une carte qui supporte des détections n’est pas présentes (quand seule la partie en rose est implémentée), alors ces détections ne sont pas prises en compte dans la retrosignalisation. J’ai du mal à imaginer que le système puisse fonctionner sans toutes les détections nécessaires.