Questions autour de l'émetteur/récepteur TB387

Bonsoir à toutes et à tous, j'utilise un couple émetteur/récepteur TB387.

Ça fonctionne bien, mais je me pose des questions au sujet du protocole d'échange.

Dans la FAQ, vers la fin de l'article cité en lien, il est dit :

Can I transmit to more than one receiver?
Yes, so long as the receivers are on the same channel and have the same ID then it is theoretically possible to transmit to up to 65534 receivers.

Comment fait un émetteur pour savoir qu'il a un certain nombres de récepteurs à l'écoute ; jusqu'à 65534 :fearful: , et comment fait-il pour les reconnaître, les distinguer ? Il y a un hand-shake ?

Il est dit aussi, au début de l'article :

To try and reduce errors caused by poor reception an automatic retry system is enabled (defaults to 100 retries) which will repeatedly resend a data packet a fixed number of times.

Comment va-t-il deviner que le récepteur N° i (sur 65534) est celui qui n'a pas bien reçu le message et le lui retransmettre "a data packet". Et à quoi correspond ce data packet par rapport au message que moi, je veux envoyer ?

Je ne suis pas arrivé à trouver de doc complémentaire à ce sujet. Peut-être en avez-vous trouvé ou bien alors êtes-vous bien plus au fait de ce protocole que moi.

Merci pour renseignements.

Cordialement.

Pierre

Bonjour,

D’après le lien donné et cela me parait logique, il faut que les 2 modules aient le même ID et soient sur la même fréquence…

Je pense qu’il faut changer l’ID du module “maître” en le passant en mode commande AT ( en mettant au niveau bas la broche cmd du module) chaque fois que tu veux t’adresser à un module"esclave" different .

Change the modules ID:

AT+ID=

Where ID is a two byte identifier giving a theoretical 65536 different identifiers. Modules must have the same ID value to communicate with one another.

Pour le message Packet : ( je ne suis pas informaticien …mais à ce que j’ai compris) tes données sont mises en forme de manière transparente pour toi dans des Packets. En plus du ou des octets envoyés, il y a l’ID du correspondant ainsi que des bits ou octets de verification. Tout cela est transmis avec un débit nettement supérieur au débit parametré sur la liaison série. Si le “récepteur” estime que le Packet n’est pas correct, il demande à l’émetteur de lui renvoyé (dans la limite du nombre paramétré dans : automatic resend).

La seule question que je me pose : que se passe t’il si tu changes l’ ID de l’émetteur alors que le dernier packet n’est pas arrivé correctement au récepteur précédent?

Je ne sais pas si j’ai été très clair dans mon explication

Pierre

+1 avec Pierre - si vous changez l'ID du maître avant d'avoir reçu l'ACK, faudra juste espérer que le message ne s'est pas perdu

Le 65534 est bizarre - codant sur 2 octets l'ID vous avez des IDs entre 0 et 65535 soit 65536 valeurs... il y a peut être les valeurs 0x0000 et 0xFFFF qui sont interdites?

Merci pour vos réponses.

Ne comprenant pas trop pourquoi changer d'ID, j'ai essayé d'expliquer ce que je croyais comprendre du fonctionnement et, je viens de prendre conscience que j'avais mal interprété cette phrase (j'ai donc mis à la poubelle toute mes explications vaseuses) :

Can I transmit to more than one receiver?
Yes, so long as the receivers are on the same channel and have the same ID then it is theoretically possible to transmit to up to 65534 receivers.

Je pensais que l'émetteur pouvait communiquer simultanément aux 65534 récepteurs possibles pour autant qu'ils étaient sur le même canal et avaient le même ID.

Grosse erreur : l'émetteur ne peut "dialoguer" qu'avec un seul récepteur à la fois : celui qui a l'ID de l'émetteur. Ce dernier pouvant en reconnaître jusqu'à 65534 en changeant son ID.

Maintenant, pour ce qui est du "Retry", est-ce que vous pensez que ce que je décris ci-après a du sens :

Si, après analyse (code de Gray ou autre ...), le récepteur constate que le paquet qu'il reçoit n'est pas correct, il retourne l'info à l’émetteur qui à son tour va renvoyer (dans la limite d'un nombre de fois préprogrammé) le paquet considéré.

Cordialement.

Pierre

J-M-L:
+1 avec Pierre - si vous changez l'ID du maître avant d'avoir reçu l'ACK, faudra juste espérer que le message ne s'est pas perdu ...

Le problème, est qu'il n'y a pas d'ACK disponible, ou alors, il faut aller le chercher sur une broche d'un de composants de module ?

Cordialement.

Pierre

Non l'ACK est dans le protocole que vous ne voyez pas directement puisque vous configurez le module et ensuite c'est vu depuis vos arduinos juste comme un port série qui lit les 2 modules sans fils, comme 2 modules BlueTooth appairés et avec un profil SPP.

Regardez s'il y a une commande AT pour savoir l'état du module (auquel cas il faut mettre la pin CMD à LOW, envoyer la bonne commande AT, lire lire résulat sur le port série et remettre ensuite la PIN commande à HIGH pour pouvoir transmettre) ou si d'aventure une demande d'envoi par un print ou println (transmission sur le port série) retrourne un OK ou un ACK ou quelque chose sur le port série (regadez après un print s'il y a quelque chose avec Serial.available() - dans l'absolu vous n'avez que la réponse de l'autre module et pas de bavardage de l'intermédiaire, mais à vérifier)

la puce utilisée dans ces modules est assez peu documentée, vous aurez plus de succès si vous avez besoin de contrôler un peu plus ce qu'il se passe avec du Nrf24L01+ et ses librairie associées (regardez TMRh20). certains modules offrent une distance respectable (plus d'un km) car ils embarquent des "Transmitter power amplifiers" et "Receiver preamplifiers", et c'est aussi du 2.4GHz. Vous pouvez avoir plusieurs canaux de communication etc.. (et ils sont produits massivement donc les prix sont raisonnables)

Merci pour ces précisions. Je n’ai pas vu dans la doc de commande At permettant de voir l’état du module. Je n’ai pas vu non plus de suite avec un Serial.available().

Je vais voir ce fameux NrF24L01+

Cordialement.

Pierre

Bonjour à tous,

Je possède quatre de ces modules.
J'avais prévu de les utiliser avec le même ID et sur la même fréquence.
Celui qui émet, arrose tout les autres, le filtrage des messages étant fait par chaque récepteurs.
Mais, maintenant, à la lumière (encore un peu faible) de ce que je viens de lire, un GROS doute s'installe.
Ca risque de mettre en cause toute la philosophie de mon système.
Je n'ai pas réussi à trouver une autre doc.
J'ai seulement testé une paire afin de voir si la portée était suffisante, sachant que j'ai besoin d'un peu plus de 100m. C'était ok.

Je n'ai pas choisi les fameux NrF24L01+, parce-que certains utilisateurs, n'obtiennent pas cette portée.

Je suis également preneur de toute info concernant ces modules.
Et bien sûr, j'en donnerais si j'en trouve.

bilbo83:
… Mais, maintenant, à la lumière (encore un peu faible) de ce que je viens de lire, un GROS doute s’installe. …

J’ai réalisé une transmission : un émetteur et un récepteur distants d’une trentaine de mètres et cela fonctionne bien.

Content de ces petits modules, j’en ai acheté d’autres et un jour, pour m’amuser, j’en ai branché un en écoute de mon système de transmission sur mon PC. Quelle n’a pas été ma surprise de voir que cet “écouteur” me fichait la pagaille dans mon autre couple émetteur/récepteur.

C’est un peu à la lumière de cela que je suis venu poser des questions ici. Les réponses m’ont aidé à y voir plus clair. Compte-tenu du système de “Reply”, mes deux récepteurs étant sur le même canal avec le même ID, l’un des deux l’emportait sur l’autre pour les échanges.

La conclusion est nette et claire : un émetteur ne peut dialoguer qu’avec un seul récepteur ; ces deux là ayant le même ID.

J’avais aussi dans l’idée de pouvoir communiquer avec plusieurs émetteurs, mais apparemment, cela ne va pas être aussi simple que cela. A voir.

NOTA, Si la transmission d’info n’est pas critique, on peut essayer (je vais le faire) de mettre le nombre de “retry” à zéro. Peut-être que les différents modules ne vont pas s’auto-polluer

Cordialement.

Pierre

La première idée qui me vient c'est:

1-Chaque E/R à son propre ID.
2-Quand IDx veut émettre vers IDy, commande AT pour changer IDx en IDy.
3-Emission vers IDy.
4-Commande AT pour remettre IDx.

Le problème qui peut se poser, c'est qu'à la mise sous tension du TB387, la pin CMD doit être à "1", sinon, pas de commandes AT.

Roger.

bilbo83:
... Le problème qui peut se poser, c'est qu'à la mise sous tension du TB387, la pin CMD doit être à "1", sinon, pas de commandes AT.

Ça, ce n'est pas un problème, où que soit positionnée cette broche, vous pouvez toujours la ramener à "1" avant toutes choses.

Par contre, suite à une coupure de courant, vous pouvez ne plus savoir où vous en êtres dans vos paramétrages. Je vous suggère donc, à la remise sous tension de faite un "AT+RESET" afin de savoir d'où vous partez.

Cordialement.

Pierre

Je me suis mal exprimé.

Un "AT+RESET" remet le paramétrage d'usine, ce n'est pas ce que je veux faire.

Ce que je veux dire c'est qu'à la mise sous tension du TB387 la pin CMD doit être au niveau "1", si elle est à "0", les commandes AT ne passent pas et ne passeront plus, même par des changements d'états.
En d'autres termes, il faut être sur que la pin de sortie de l'Arduino connectée à CMD ne soit pas à "0" durant cette mise sous tension.

bilbo83:
... Un "AT+RESET" remet le paramétrage d'usine, ce n'est pas ce que je veux faire. ...

Ca, ce n'est pas obligatoire, c'est juste pour repertir du bon pied.

bilbo83:
... Ce que je veux dire c'est qu'à la mise sous tension du TB387 la pin CMD doit être au niveau "1", si elle est à "0", les commandes AT ne passent pas et ne passeront plus, même par des changements d'états.
En d'autres termes, il faut être sur que la pin de sortie de l'Arduino connectée à CMD ne soit pas à "0" durant cette mise sous tension.

Je n'ai jamais rencontré ce problème. Une fois sous-tension, je fais ce que je veux avec cette entrée selon que je souhaite configurer le TB387 ou m'en servir en émetteur/récepteur. Je n'ai jamais lu une telle recommandation ??

Cordialement.

Pierre

ChPr:
La conclusion est nette et claire : un émetteur ne peut dialoguer qu’avec un seul récepteur ; ces deux là ayant le même ID.
J’avais aussi dans l’idée de pouvoir communiquer avec plusieurs émetteurs, mais apparemment, cela ne va pas être aussi simple que cela. A voir.

il y a un article intéressant dans Hackable Magazine n°16 janv-fev 2017
de ce que j’ai compris : le NRF24L01 possède 6 pipes, le pipe 0 peut être en écriture ou lecture les pipes 1 à 5 seulement en lecture
dans le cas d’une liaison 1 émetteur vers 1 récepteur l’@ du pipe 0 de l’un correspond a l’@ du pipe 1 de l’autre et vice versa
NRF1e1r.jpg
dans le cas de multiples émetteurs vers un récepteur on peut donc configurer jusqu’a 6 émetteurs l’@ du pipe 0 de chaque emetteur correspond a l’@ d’un des pipes du récepteur
NRF6e1r.jpg
dans le cas d’un emetteur vers plusieurs récepteur il faut déclarer la même @ pour tous les pipes mais il faut dévalider l’auto Ack et l’auto RETRANS

Je viens de faire l'essai : mise à zéro de la broche CMD pendant la mise sous tension : tu as raison, on ne peut plus commander le T387 après.

Pour autant, cela ne m'est jamais arrivé en connectant cette broche à une sortie de l'Arduino.

Cordialement.

Pierre

Pour autant, cela ne m'est jamais arrivé en connectant cette broche à une sortie de l'Arduino.

C'est une bonne nouvelle.