je ne cherche pas à réaliser un système sophistiqué : j'ai juste besoin d'une communication sans-fil. J'avais fait un petit test pour voir comment on pouvait utiliser les modules XBee, et apparemment, en n'utilisant à peu près que TX et RX, j'étais déjà satisfait
Pourtant j'ai été plutôt surpris qu'il n'y ait aucun appareillement à programmer...
J'aimerais savoir s'il existe une méthode particulière de répondre au problème suivant :
Dans un cercle de rayon 100 m sont présents quatre modules XBee A, B, C et D. A communique avec B et C avec D. On souhaite que A et B communiquent sans recevoir les messages de C et D, et vice versa.
Je voudrais donc savoir s'il existe quelque chose de plus sophistiqué que d'indiquer l'émetteur au début de chaque message envoyé et de vérifier l'émetteur de chaque message reçu...
On ne peut pas, physiquement, empêcher une antenne de recevoir un message même s'il ne lui est pas destiné.
Le seul moyen physique est d'avoir des antennes directionnelles, mais si tu as Emetteur - B - A dans le même axe, et que tu veux envoyer seulement à A, B recevra quand même le message.
Quand on s'intéresse à différents protocoles de communication permettant la mise en oeuvre de plusieurs éléments sur le même bus/réseau, il y a forcément un identifiant ou une adresse dans le message transmis, ou alors dans le cas du SPI l'adresse est spécifiée de manière "hardware".
Regarde l'I2C ou l'Ethernet et tu verra que l'adresse destination est indiquée dans le début du message, pourquoi ? Parce qu'un circuit, en général hardware, va vérifier que le message est bien destiné au composant en comparant les bits d'adresse du composant avec ceux du message, si un bit diffère, le message n'est pas pris en compte tout simplement.
Mais pour ce que je veux faire, j'en reviens à ce que j'ai proposé dans mon premier message ? Parce que s'il y avait vraiment des bits d'adresse sur plusieurs fils, avec un petit montage en combinatoire, cela aurait été facile je présume... Mais là... Si c'est inutilement compliqué, je le fais en logiciel. Si il y a vraiment des avantages en matériel et que c'est faisable, d'accord mais sinon... En plus, il faudrait le faire entre l'Arduino et le module XBee, au niveau du TX, puisque de toute façon, le message serait déjà reçu :p
En fait avec le XBee tu peux faire de la com' point à point, pour créer des sortes de réseaux entre différents modules XBee... Google regorge de liens à ce sujet... J'avais fait une recherche hier pour t'aider et en voyant le nombre de résultat je me suis dit que j'allais te faire mariner un peu (et j'avais pas le temps de toute facon d'expliquer quoi que ce soit dans un message)
Mais pour ce que je veux faire, j'en reviens à ce que j'ai proposé dans mon premier message ? Parce que s'il y avait vraiment des bits d'adresse sur plusieurs fils, avec un petit montage en combinatoire, cela aurait été facile je présume... Mais là... Si c'est inutilement compliqué, je le fais en logiciel. Si il y a vraiment des avantages en matériel et que c'est faisable, d'accord mais sinon... En plus, il faudrait le faire entre l'Arduino et le module XBee, au niveau du TX, puisque de toute façon, le message serait déjà reçu :p
Oui il faut indiquer un identifiant, après si tu n'as que 8 bits de dispo, tu peux faire un truc du genre 2-3 bits d'identifiant, 1 bit de numéro de trame et il te reste potentiellement 1 bit d'overhead (CRC), enfin tu as les 4 derniers bits pour les data. Pour envoyer 8 bits de data il te faudra envoyer 2 trames de 8 bits, avec 50% d'overhead.
Ensuite quand je parle de l'I2C ou de l'Ethernet et le fait que l'identification soit faite en hardware c'est parce le protocole est normé et donc les fabriquants ont une référence et peuvent donc faire quelque chose en hardware sans que dans les 6 mois ca change du tout au tout.
Néanmoins tu peux faire en soft ce qui est fait en hardware.
Eskimon a écrit:
En fait avec le XBee tu peux faire de la com' point à point, pour créer des sortes de réseaux entre différents modules XBee... Google regorge de liens à ce sujet... J'avais fait une recherche hier pour t'aider et en voyant le nombre de résultat je me suis dit que j'allais te faire mariner un peu (et j'avais pas le temps de toute facon d'expliquer quoi que ce soit dans un message)
Oui mais ca changera rien que les modules Xbee recevront, physiquement, des messages qui ne leur seront pas destinés
En fait avec le XBee tu peux faire de la com' point à point, pour créer des sortes de réseaux entre différents modules XBee... Google regorge de liens à ce sujet... J'avais fait une recherche hier pour t'aider et en voyant le nombre de résultat je me suis dit que j'allais te faire mariner un peu (et j'avais pas le temps de toute facon d'expliquer quoi que ce soit dans un message)
Oui mais ca changera rien que les modules Xbee recevront, physiquement, des messages qui ne leur seront pas destinés
Et alors ? J'ai ptet pas bien compris après tout mais le but de l'OP est de pouvoir faire communiquer ses modules entre eux, en en discriminant certains non (car comme tu le dis dans ton premier message "on ne peut pas empecher une antenne de recevoir...") ? Du coup c'est plutot une bonne solution ce que je propose ?
Je voudrais donc savoir s'il existe quelque chose de plus sophistiqué que d'indiquer l'émetteur au début de chaque message envoyé et de vérifier l'émetteur de chaque message reçu...
Et c'est tout ce dont j'ai besoin !
Eskimon a écrit:
zeqL a écrit:
Eskimon a écrit:
En fait avec le XBee tu peux faire de la com' point à point, pour créer des sortes de réseaux entre différents modules XBee... Google regorge de liens à ce sujet... J'avais fait une recherche hier pour t'aider et en voyant le nombre de résultat je me suis dit que j'allais te faire mariner un peu (et j'avais pas le temps de toute facon d'expliquer quoi que ce soit dans un message)
Oui mais ca changera rien que les modules Xbee recevront, physiquement, des messages qui ne leur seront pas destinés
Et alors ? J'ai ptet pas bien compris après tout mais le but de l'OP est de pouvoir faire communiquer ses modules entre eux, en en discriminant certains non (car comme tu le dis dans ton premier message "on ne peut pas empecher une antenne de recevoir...") ? Du coup c'est plutot une bonne solution ce que je propose ?
Oui mais le principe de base, reste toujours d'indiquer l'adresse du récepteur (Après il peut y avoir des multicast, unicast, broadcast, etc.)
Après si on utilise l'API fourni avec le Xbee, ca permet d'éviter de faire le traitement soit-même dans l'Arduino, puisque ce sera le microcontroleur du Xbee qui fera le boulot, mais le principe théorique restera toujours le même
Oui mais le principe de base, reste toujours d'indiquer l'adresse du récepteur (Après il peut y avoir des multicast, unicast, broadcast, etc.)
Après si on utilise l'API fourni avec le Xbee, ca permet d'éviter de faire le traitement soit-même dans l'Arduino, puisque ce sera le microcontroleur du Xbee qui fera le boulot, mais le principe théorique restera toujours le même
On est d'accord
(et personnellement, j'aurais tendance à conseiller de ne pas réinventer la roue, laisser la charge du traitement des adresses au µC de l'XBee, il a le mérite d'avoir été testé et éprouvé pour être fiable et efficace (et ca économise du travail ))
! Cela n'a pas vraiment l'air simple... Et je ne suis pas convaincu de pouvoir le faire avec le matériel que j'ai (d'ailleurs ils évoquent des S2 à cette adresse et j'ai vraisemblablement des S1 )... Et en plus, si j'ai compris, cela va faire que deux modules XBee communiqueront exclusivement ensemble... et si je veux annuler les modifications ou faire autre chose... Bon.. en fait je pense que je recherche quelque chose de souple (et simple si possible)...
Si par exemple je souhaites concevoir un système où un module XBee voit qu'il y a 4 modules XBee disponibles, démarre une communication avec un en excluant les autres... En effet, je le vois en l'écrivant, il faudrait faire ces traitements en logiciel. Donc en fait je serais d'accord pour qu'un code identifie chacun des appareils... Oui mais en fait il faudrait que ce code soit présent dans chaque "paquet" envoyé... et je n'ai pas la moindre idée de la façon dont cela se fait... :s
"tu mets les mains dans la doc et apprend a utiliser tes modules xbee de manière un peu plus poussé en les paramétrant a coup de commande AT."
=> J'ai une très forte contrainte de temps... donc je ne peux pas
"tu implémentés les système d'adresse toi même, et dans ce cas je te conseille de relirece qu'a eécris zeqL plus haut puisqu'il a déjà tout dit !"
=> Mais si j'ai bien compris on me disait d'envoyer un identifiant dans chaque "paquet"
"Oui il faut indiquer un identifiant, après si tu n'as que 8 bits de dispo, tu peux faire un truc du genre 2-3 bits d'identifiant, 1 bit de numéro de trame et il te reste potentiellement 1 bit d'overhead (CRC), enfin tu as les 4 derniers bits pour les data. Pour envoyer 8 bits de data il te faudra envoyer 2 trames de 8 bits, avec 50% d'overhead."
Mais je ne sais pas du tout comment modifier la nature d'un "paquet" ni comment les recevoir... Je sais seulement envoyer et recevoir du texte indépendamment de la manière dont il est transmis
Un texte c'est une suite d'octet.
Au lieu d'envoyer ton texte en une seule commande, tu peux l'envoyer octet par octet (ce qui est déjà fait en réalité cela dit en passant). Maintenant tu peux/doit bricoler tes octets pour les couper en deux d'un cote (a l'émission) et les envoyer dans deux octets remaniés a la suite puis les recomposer a la réception.
Perso j'aurais pris la solution des commandes AT qui est pas si compliqué, mais les deux choix sont réalisables... L'un te fera perdre du temps a lire et comprendre et appliquer une Doc, l'autre te fera perdre du temps a coder un système d'adresse pour l'émission et pour la reception
"Oui il faut indiquer un identifiant, après si tu n'as que 8 bits de dispo, tu peux faire un truc du genre 2-3 bits d'identifiant, 1 bit de numéro de trame et il te reste potentiellement 1 bit d'overhead (CRC), enfin tu as les 4 derniers bits pour les data. Pour envoyer 8 bits de data il te faudra envoyer 2 trames de 8 bits, avec 50% d'overhead."
Mais je ne sais pas du tout comment modifier la nature d'un "paquet" ni comment les recevoir... Je sais seulement envoyer et recevoir du texte indépendamment de la manière dont il est transmis
(oui, pas grand chose )
Bah si t'envoie du texte, c'est que t'envoie des données, donc des bits. Et à priori ton texte tu le formate sous forme d'octets (8 bits) qui seront transmis un à un via une liaison série probablement en 8N1 (8 bits de données, pas de parité et 1 bit de stop). Ton driver série prend les 8 bits de données et ajoute la parité si nécessaire et les bits de stop (c'est ce que tu configure dans l'arduino normalement, en plus de la vitesse)
Donc comme tu es capable d'écrire 8 bits de données, maintenant on passe à la couche supérieure, puisque là on était sur la couche PHY(sique) qui indique comment est le signal électrique (couche 1 du modèle OSI), ensuite on a une couche de formatage des trames (couche 2 du modèle OSI) et toi tu va te situer entre la couche 2 et la couche 3 (Liaison) selon l'avis des personnes.
En gros tu ajoute un niveau d'abstraction et de traitement des données : tu recois tes 8 bits de données, mais tu va faire un algorithme qui va analyser ces données. Soit tu décide de respecter un protocole style ethernet ou I2C et donc dans ce cas tu dois implémenter la norme, soit tu fais ton propre protocole, comme je t'ai mis en exemple, et tu implémente toi même l'algorithme de traitement :
- Je regarde les 2-3 premiers bits, ont-il la valeur du récepteur : si oui je continue l'algo, si non, j'attend un nouveau paquet
- Je regarde le bit 3-4, si c'est 0, dans ce cas je vais mettre les 4 bits de données aux emplacement [3-0] de mon buffer, si c'est 1 je met les 4 bits de données aux emplacements [7-4] du buffer.
- Enfin dernier bit, si CRC/parité, je check la parité : si c'est bon, le paquet est valide, sinon j'indique une erreur, soit je jette la trame en entier et je fais rien, soit je demande à ce qu'on renvoie le paquet fautif.
Bon un exemple, si avec ton arduino tu envoie via une liaison série 9600 8N1 le texte "Bonjour", celui va être découpé en une série d'octets, en effet le texte est sous forme ASCII, où chaque caractère est codé sur 1 octet.
- B = 0x42
- o = 0x6F
- n = 0x6E
- j = 0x6A
etc.
A priori tu envoie les données à la liaison série sous forme de texte (string) mais normalement tu dois pouvoir envoyer directement un octet en hexadecimal ( http://arduino.cc/en/Serial/Write )
Donc il te faut réfléchir un peu et ne plus envoyer des string mais 1 byte à la fois.
On va prendre pour exemple 3 bits d'identifiant, 1 bit de numero de trame et 4 bits de données.
On va envoyer le texte "Lu", en hexa / ASCII ca donne : L = 0x4C et u = 0x75 à la carte n°4 (0b100)
Comme le protocole a 50% d'overhead, et que l'on veut transmettre 2 octets de données utiles, il faudra 4 octets au total.
On va considérer que l'on transmet d'abord le LSB ( bits 3 à 0) et ensuite le MSB (bits 7 à 4).
Première trame : 0b 100 0 1100 ( carte n°4 / 1ere trame / 0xC) = 0x8C
2e trame : 0b 100 1 0100 (carte n°4 / 2e trame / 0x4) = 0x94
3e trame : 0x85
4e trame : 0x97
Voilà, je te laisse un peu réfléchir pour la réception, dont j'ai donné l'algorithme.
Mais je suppose que je peux écrire Serial.write(0xXX) pour envoyer un octet. Mais cet octet sera vraiment envoyé tel quel sur la liaison série en tant qu'un octet ? Il ne va pas subir un traitement quelconque pour être envoyé ? Par exemple, je pourrai envoyer un octet avec un nombre de '1' impair (par exemple 0xEF) et il sera reçu comme cela par l'émetteur ? Donc la parité (...) sont des paramètres par défaut qui ne concernent pas l'envoi de données par cette fonction ?
Est-ce sûr que l'octet envoyé sera reçu en entier d'un coup ?
Mais si tout cela est vrai, je vais pouvoir m'amuser ! :P
Mais si tout cela est vrai, je vais pouvoir m'amuser ! :P
Merci :)
oui.
xbee c'est un peu comme "l'internet des objets" (en fait ça a été conçu pour être en accord avec cette phrase). ça permet de faire plein de trucs sympa, sans trop se casser la tête pour faire des choses simples. ce qu'il faut se rappeler c'est que ça se controle de plusieurs façons, dont une très facile, une un peu plus difficile, mais qui offre plus de controle, et les autres je sais pas. avec ça, suivant ton modèle, tu peux faire des réseaux en étoile (sûr), ou peut-être maillés (avec des cycles dans le graphe, seulement les version pro' du module, il me semble, à vérifier).
le résultat quand c'est bien paramétré, c'est que tu peux envoyer une info d'un point à un autre, qui n'ont pas forcément un accès direct entre eux (mais il faut quand même avoir des modules pour répéter l'info au milieu), et le message se transmet via le réseau que tu as créé. (comme sur internet, les paquets TCP/IP, se déplacent, de proche en proche, routeur par routeur, jusqu'à ton PC).
Mais donc juste pour avoir la confirmation avant de me lancer dans je ne sait quoi : si j'écris Serial2.write(0xFF), le XBee qui reçoit recevra exactement cet octet sans qu'il n'ait subi aucune modification ?
Tu voudrais qu'il recoive quoi ? En fait ton Xbee va prendre ca, l'encapsuler dans son truc à lui (pour notamment que ca rentre dans le protocole zigbee) puis l'envoyer sur les ondes... Ensuite l'autre xbee va décapsuler et te redonneras ton octet d'origine.
Mais donc juste pour avoir la confirmation avant de me lancer dans je ne sait quoi : si j'écris Serial2.write(0xFF), le XBee qui reçoit recevra exactement cet octet sans qu'il n'ait subi aucune modification ?
Bah tu fais le test, ca va rien cramer...
Tu peux aussi essayer de trouver la définition de la fonction pour savoir comment elle fonctionne.
"Tu voudrais qu'il reçoive quoi ?" En fait je craignais que je ne reçoive pas l'octet tel quel, ou surtout en plusieurs morceaux. "Ensuite l'autre xbee va décapsuler et te redonneras ton octet d'origine" Mais si je lis sur la voie Série un byte, j'ai mon octet en entier d'un coup ?
=> Voilà les questions que je posais.
"Bah tu fais le test, ca va rien cramer" ... certes ^^
"Tu voudrais qu'il reçoive quoi ?" En fait je craignais que je ne reçoive pas l'octet tel quel, ou surtout en plusieurs morceaux. "Ensuite l'autre xbee va décapsuler et te redonneras ton octet d'origine" Mais si je lis sur la voie Série un byte, j'ai mon octet en entier d'un coup ?
=> Voilà les questions que je posais.
"Bah tu fais le test, ca va rien cramer" ... certes ^^
Certes... et donc tu as fait le test pour répondre à tes questions ? Tu n'as pas le temps de prendre 30 minutes pour faire un petit programme de test et vérifier si tu reçois bien tes données correctement ? (Sachant que tu envoie et reçois déjà des strings, si tu n'envoie qu'un seul octet, ca fonctionnera pareil qu'en envoyer plusieurs... Quand on peut le plus, on peut le moins).
J'ai passé 30 minutes à écrire ma réponse de l'autre jour, alors que je revenais du sport, que j'étais fatigué, que j'avais faim, etc. et pour être honnête avec toi, j'ai parié que tu allais encore poser des questions. Et je ne me suis pas trompé.
Ca fait quand même 3 réponses que tu post où tu demande si ton octet sera bien transmis. Tu as le temps de poster mais pas de faire les tests ?
Désolé d'être chiant, mais à un moment ou à un autre, il faut que tu comprenne, que ma patience (et probablement celles des autres) à une limite, pour moi elle est atteinte. Faut mettre les mains dans le cambouis, faire des tests, etc. Comme je l'ai dit tu ne va rien cramer, rien abîmer, à faire des tests de transmission, qui répondra a tes questions. Pour la parité, une petite recherche sur internet et tu auras ta réponse.
Il me semblait juste que vous demandiez ce que je voulais exactement... donc forcément, j'ai plus au moins écrit la même chose... :s
alors qu'avant eskimon t'a écrit:
Eskimon a écrit:
Tu voudrais qu'il recoive quoi ? En fait ton Xbee va prendre ca, l'encapsuler dans son truc à lui (pour notamment que ca rentre dans le protocole zigbee) puis l'envoyer sur les ondes... Ensuite l'autre xbee va décapsuler et te redonneras ton octet d'origine.
et zeql t'avait écrit la fois d'après:
zeqL a écrit:
Bah tu fais le test, ca va rien cramer...
Tu peux aussi essayer de trouver la définition de la fonction pour savoir comment elle fonctionne.
- Edité par zeqL il y a environ 19 heures
essaie de comprendre, quand ça fait 3 fois qu'on passe du temps à te répondre, que quand tu reviens poser exactement la même question alors qu'on te dit quoi faire et comment ça marche, on s'attend à ce que tu ne revienne pas une nouvelle fois, en n'ayant pas avancé (ni même vraisemblablement essayé), avec la même question.
dis toi que tant que c'est de l'électronique "de programmation" tu crains absolument rien, rien ne va bruler. tu n'as qu'à aller chercher la réponse dans la doc d'arduino, de XBee, ou de tout ce que tu veux qui a un lien avec ta question, ou même essayer, ça mange pas de pain, ça prend 30 min et ni toi ni nous ne perdons de temps "pour rien" (j'estime que poser 3 fois la même question sans chercher à avancer entre les réponses c'est perdre son temps... tu m'en voudra pas)
oui. non. enfin je regarde et je te dis.
Isoler la communications entre modules XBee
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
oui. non. enfin je regarde et je te dis.
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
oui. non. enfin je regarde et je te dis.