Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - bobyAndCo

Pages: [1] 2 3 ... 11
1
Comme je te le disais, commence par les détecteurs de consommation, c'est le basic et ceux qui ont été conçus et réalisés par Jean-Luc et Dominique fonctionnent vraiment bien et sont très économiques.

Si tu le souhaites, je peux t'en adresser un pour tests ! Tu me contactes alors par MP.



2
Sergio,

C'est vrai que le seul chapitre de la détection est déjà complexe, et la signalisation tout autant. Il faut bien sûr y ajouter le bus de communication, alors... Raisons sans doute pour lesquelles ces sujets n'ont jamais été traités dans leur globalité.

Par ailleurs, la discussion est souvent vive entre tenants de telle ou telle technologie qui ont tendance à camper sur leur positions et s'y tiennent, quitte à mordre quelques fois. Certains rejetant les ILS, trop fragiles et môches, d'autres les capteurs à effet Hall, refusant les aimants sous leurs locos.

D'autres encore ne veulent surtout pas entendre parler de technologies couteuses comme RailCom, qui plus est réservé au digital.

D'autres encore explorent des terrains prometteurs mais sans avoir encore obtenu les résultats escomptés comme avec le RFID par exemple.

Seule la détection de consommation de courant semble semble faire l'unanimité et apporter des résultats satisfaisants. C'est un sujet encore récent :

http://forum.locoduino.org/index.php?topic=558.0

Les cartes proposées fonctionnent bien, à condition semble t'il de changer les diodes dont il est question. C'est ce que j'ai fait et mes détecteurs single fonctionnent très bien.

La détection de courant est nécessaire et importante mais ne peut suffire car elle agit sur des zones et non pas sur de points particuliers du réseau. Par ailleurs, elle ne permet pas l'identification de la loco et encore moins du convoi.

C'est là que ILS, capteurs à effet Hall, IR (mais qui pose aussi problème dans certaines conditions particulières), c'est là donc que ces capteurs peuvent entrer en jeu.

En soi, détecteurs de consommation et capteurs ponctuels suffisent en théorie si l'on possède un puissant outil de gestion et de suivi de ses trains et convois. Un programme informatique est capable de déduire quel train est dans une zone ou franchit un capteur. Un capteur étant toujours dans une zone et dans une zone, il ne peut y avoir qu'un seul train ! CQFD. Mais comme dit précédemment, ce doit être une base de données qui fait le travail.

C'est pour cela que des capteurs qui permettent en plus d'identifier la loco (et pourquoi pas les wagon) sont bien pratiques : RFID en particulier. J'ai personnellement fait des tests assez concluants avec des lecteurs de codes barres placés sous la planche et des codes barres collés sous les locos et les wagons.

Enfin, comme tu le vois, un (très) vaste chantier. Tout ou presque a déjà été dit sur Locoduino mais c'est éparpillé un peu partout. Tu peux déjà commencer à prendre ta lampe frontale et t'enfoncer dans les méandres du site, ce ne sera pas inutile.

Moi je pense que l'on pourrait ouvrir une rubrique générale sur le thème de la détection et des sous rubriques pour chacunes des principales technologies. Chacun pouvant alors apporter son savoir et son expérience dans chacun des thèmes. Mais il va falloir une très grande discipline pour que ça ne dérape pas et sans doute de la modération, mais je ne crois pas qu'aucun modérateur soit très disponible en ce moment.

Et je n'ai pas parlé de la rétro signalisation que tu évoques à juste titre sinon, quel intérêt de faire de la détection. A mon avis, sur ce thème, les choses au moins sont claires sur Locoduino, difficile de te faire entendre si tu parles d'autre choses que du bus CAN. Et je pense que c'est bien. WiFi et Ethernet au besoin car ils peuvent apporter des solutions complémentaires au CAN.

Comme je te le disais dans un précédent post, les cartes satellite sur lesquelles ont travaillés Jean-Luc et Dominique en particulier, sans oublier Thierry pour la programmation, ces cartes satellites donc seront une réponse à pas mal de problèmes.

Voilà moi ce que j'en pense de ces vastes sujets et de la manière de faire.

Bien amicalement.

Christophe

3
Les rédacteurs ils sont bien occupés. Il ne s'agit pas seulement d'écrire car à Locoduino, on teste et on réalise en vrai grandeur aussi. Alors forcement, c'est plus long. Patience patience tu vas découvrir bientôt des cartes qui gèrent la détection par consommation de courant mais aussi par capteurs (Effet Hall, IR...) et qui font encore plein d'autres choses comme la signalisation lumineuse. Le bus de communication est en CAN bien sûr, avec des passerelles en Ethernet et en Wifi.

Tout cela sera présenté à Orléans en novembre.

Sans trahir de secret, voici la "tête des bêtes".



4
Le logiciel DCC++ / Re : Controller DCC++ Ethernet On-Line
« le: septembre 06, 2018, 05:23:46 pm »
J'ai aussi testé la configuration avec une carte moteur POLOLU MC33926. Et ça marche nickel. En prime dans cette configuration, la voie de programmation et la voie principale sont pilotables conjointement.

C'est propre !


5
Le logiciel DCC++ / Re : Controller DCC++ Base Station en WiFi
« le: septembre 03, 2018, 09:56:31 pm »



Voici une solution simple pour commander DCC++ Base Station en Wifi. J'ai tout simplement placé un shield Wifi à la place du shield Ethernet. J'ai conservé un MEGA pour des questions pratiques mais aussi de performances.

Pour ceux qui s'étaient intéressés à mon contrôleur réalisé en HTML/JavaScript/NodeJs, je m'affranchis maintenant du serveur Node qui devait être hébergé sur un ordinateur. Ici, les fichiers de l'application sont stockés directement sur l'ESP8266 dans la zone SPIFFS qui peut contenir 1Mo de données. L'ESP8266 fait office de serveur web et les échanges se font par l'intermédiaire de websockets particulièrement rapides.



Bien sûr la version tablette et smartphone qui existaient avec l'Ethernet seront également compatibles avec cette nouvelle configuration.

En prime, j'ai installé l'OAT qui permet de téléverser le sketch à partir de l'IDE Arduino en WiFi sur la carte, plus besoin donc de câble USB.

Pour ceux qui le souhaitent, j'ai mis le sketch Arduino en téléchargement.

Je présenterai ce contrôleur au Salon du Train Miniature d'Orléans les 10 et 11 novembre 2018 où, comme vous le savez déjà, Locoduino présentera plusieurs réalisation inédites et innovantes.

A bloquer dans vos agendas.

Bien amicalement.

Christophe

PS : Ici la présentation du contrôleur en version Ethernet, mais pour ce qui est des fonctionnalités, il n'y a pas de changement en WiFi : http://176.154.165.92/locoduino/controller_dccpp/dccppController/index.php

A voir également la petite vidéo que j'avais posté sur YouTube : https://www.youtube.com/watch?v=kRdBmnA_-HE&feature=youtu.be

6
Débuter / Re : Tableau d'objet
« le: juillet 10, 2018, 03:48:53 pm »
Pas bien cherché, il y a tout sur locoduino.org,

Ces tableaux qui peuvent nous simplifier le développement Arduino : http://www.locoduino.org/spip.php?article227

7
... En utilisant la programmation modulaire à plusieurs fichiers ce qui simplifie la lisibilité, facilite la maintenance et autorise plus facilement la réutilisation de code. L'IDE d'Arduino gère cela assez simplement. Il suffit que tous les fichier soient dans le même dossier que le .ino.

8
Bonjour Pierre,

Merci pour cette info. Mais pour les billes en electronique dont je fais partie, te serait-il possible de donner plus d'informations sur les composants, valeur de la resistance, type des diodes...

Merci

9
Bravo j'applaudis des deux mains, très bonne idée d'utiliser des tableaux  :) :) :)

Par contre, il faut utiliser les balises de code pour que ton code dans les messages soit plus lisible. Le bouton avec # à l'intérieur.


const byte pin[] = {4, 5, 6, 7}; // création du tbl pour les 4 Pin des clignotants - Attention Index du 4 = 0
// à ajuster au total des 12 sorties / leds utilisées > TODO : sélectionner les 12 Pin
void setup () {
  for (int i = 0 ; i < 5 ; i++) {      // 5 car 4 leds utilisées dans cet ex
    pinMode (pin[i] , OUTPUT) ;        // les 4 leds sont déclarées en même temps en sortie
    digitalWrite (pin[i] , LOW) ;      // on éteint ttes les leds avant de commencer une sélection au clavier
  }                                    // fin de la boucle FOR
}

10
Discussions ouvertes / Re : Méga carte (pas carte Méga)
« le: juin 01, 2018, 08:08:50 am »
Bonjour Antoine,

C'est assez séduisant de prime abord. Nous sommes dans l'esprit de ce sur quoi nous travaillons comme en a déjà parlé Dominique (carte universelle tournée modélisme ferroviaire). Pas mal de choses intéressantes me semble t'il, dont les E/S opto isolées. Je ne suis pas spécialiste mais si effectivement comme tu le dis cela peut limiter ou supprimer les effets indésirables.

30 sorties 500mA. Je suppose que c'est 500mA sur chaque sortie. Auquel cas, c'est vraiment un plus car il est vrai que +-20mA, c'est tout de même un peu juste. Et les LEDs de contrôle, simple mais effectivement très utile.

Comment comptes-tu faire avec avec les si peu E/S du Nano pour gérer autant d'E/S sur ta carte ?

Bien amicalement.

Christophe

11
Vos projets / Re : Un mini module sonore
« le: mai 27, 2018, 08:42:04 pm »
Oui mais dans cas que je cite, il s'agit d'une situation particulière où plusieurs Arduino ont des programmes différents à executer et selon les étapes du programme, ils sont amenés à demander la lecture d'un morceau. Donc intérêt du CAN ici, tous les Arduino peuvent envoyer sur le même bus et grâce aux filtres, seul l'Arduino qui joue les sons peut intercepter les messages le concernant.

12
Eh bien mon cher Jean-Luc !!! Et tu n'oubliras pas de facturer ton temps aussi. Merci vraiment pour tout ce que tu fais.

Christophe

13
Vos projets / Re : Un mini module sonore
« le: mai 27, 2018, 06:58:17 pm »
C'est très bien tes musiciens   :) :) :)

Tu as totalement raison, il est très simple de faire jouer par différents Arduinos en CAN. Je viens moi même de le réaliser à partir de plusieurs cartes sur un UNO dédié avec son mini player MP3.

Et je compte bien aller plus loin car je viens d'acheter 6 modules mini player MP3 sur Ebay à 1,20€ pièce port gratuit ! Alors pourquoi se priver.

https://www.ebay.fr/itm/TF-Card-U-Disk-Mini-MP3-Player-Audio-Voice-Module-For-Arduino-DFPlay-Mini-Board/173243875082?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2648



14
Trouvé au hasard du net pour ceux qui s'intéressent au très bon JMRI. Une solution complète JMRI/DCC++ à base de Raspberry et Arduino Uno avec en prime le WiFi donc pilotage à partir d'un smartphone. Le tout probablement pour moins de 100 €.



Bon WE à tous, Christophe

15
Bus CAN / Re : Bus CAN avec DCC++
« le: mai 24, 2018, 08:12:53 am »
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

Pages: [1] 2 3 ... 11