Répondre à la discussion
Affichage des résultats 1 à 23 sur 23

Probléme de collision entre un recepteur et plusieurs emetteur



  1. #1
    dje8269

    Probléme de collision entre un recepteur et plusieurs emetteur


    ------

    Bonjour à tous,

    J'avoue que mon problème est plutôt compliqué sans avoir les choses sous les yeux ! Mais je n'arrive pas à obtenir le comportement voulu et je ne comprends pas pourquoi !!

    Module AMBER8420
    AMB8420_2520_MA_V3_15.pdf

    Je vais essayer de généraliser mon problème pour essayé de vous aider, à m'aider ! . Sans parler de pure programmation mais plutôt de fonction ou chose à faire ou à essayer.

    La configuration:
    Deux transceivers "esclaves" (Identifiant:1 et identifiant :2) émettent des infos individuellement en permanence toutes les 100ms en direction d'un maitre(Identifiant:99) !
    Ces infos (payload) sont composées d'une lettre et d'un chiffre. elles font partie d'une trame sur laquelle le module rajoute l’identifiant de l'envoyeur et un cheksum. Les modules sont configurés de telle sorte que si ils ne reçoivent pas d'ACK de la part du maitre il ré-envoie la trame(10 tentatives) . Après ces 10 tentatives le module esclave poursuit son programme et repart pour un envoi avec 10 tentatives quelques milli-secondes plus tard. etc .....

    Le problème:
    LE HIC, c'est qu'il arrive, que ces 2 esclaves émettent au même moment, ou tellement proche que l'écart entre les deux trames à l'arrivé ne laisse pas le temps de traiter les informations reçues immédiatement.
    Surtout que le traitement de ces informations peut être long, à cause de l'affichage sur un LCD ( conversion Byte to string par exemple, calcul du RSSI etc...).

    Les résultats:
    Le résultat observé sur un terminal RS-232, sur ce qui arrive sur mon PIC maitre(18F46K22) .
    - Je n'ai aucun bug dans une trame complète . Elles arrivent toutes , entière avec les 2 bonnes valeurs de payload .
    - Le bug se situe dans l'ordre des ces trames. En effet il arrive au moment de la "pseudo collision" que je reçoive 8 fois de suite la trame N°1. puis 3 fois la N°2 ensuite pour repasser à la trame N°1 . Bref il y a chevauchement des trames . Après quelques chevauchement tout redevient normal ( on a passé la collision).

    Qu'il y ai des sautés dans les trames, ce n'est pas trop grave, le plus important c'est que les infos ne soit pas corrompus. Mais comment faire, pour me permettre de mettre à jour mon affichage sans AUCUN bug ! Je suppose qu'il faut bufférisé tout ça , mais j'y arrive pas ou pas assez bien, car j'ai toujours des ratés.

    J'ai simulé à 100ms pour deux esclaves, car au final il y en aura 8. Les temps de rafraichissement au final seront plus long pas besoin d'avoir un rafraichissement toutes les 100ms. Mais par contre à 8 , les collisions seront plus fréquentes. C'est pour simuler de nombreuses collision que j'ai mis 100ms !

    J'ai également mis en place un système de détection de perte de comm ou d'éloignement.
    VIA un timer, je met à jour un compteur propre à chaque esclave avec la valeur du timer. si je détecte que la mise à jour de l'esclave ne s'est pas produite pendant 3 secondes(exemple), c'est qu'il est hors de portée ou éteint ! cela reste secondaire ! J’essaye d'abord d'avoir des données FIABLES, même au moment de la collision.

    J'ai eu beau essayé de couper les INT après avoir reçu une trame, mais sa ne change pas le problème, voir ça l’aggrave car l’interruption se redeclenche au milieu d'une trame par exemple.
    J'ai aussi essayé de couper la réception radio après une trame, mais pareil que pour les INT .
    Je dispose que d"une broche RTS sur les modules radio ! Si j'ai compris son fonctionnement ( ça c'est pas sur du tout) , il ne me servirais à rien dans ce cas de figure ! car je n'envoie pas de donné au transceiver dans cette phase la !

    Si il vous manque des infos pour la compréhension dite le moi , je ferais le maximum pour vous les fournir.

    PS : FOSC du pic 8 Mhz ; UART à 38400bauds . une trame entière dure moins de 2ms .

    -----
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  2. Publicité
  3. #2
    DAUDET78

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    C'est un genre de RS485 ?
    On autorise un esclave à causer que si il a reçu une autorisation du maitre . Plus de collision !

    Si un esclave cause n'importe quand , tu risques la collision. Quelle est la durée de la trame et la fréquence de répétition ?
    J'aime pas le Grec

  4. #3
    lpt1com2

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Bonjour,
    J'ai un peu le même système que toi, mais un module qui veut émettre écoute d'abord si un autre émet avant de passer lui-même en émission, et je n'ai pas de problème de collision. Ceci dit à tout hasard car je ne suis pas sûr que ça réponde à ta problématique...
    Il vaut mieux être le deuxième mari d'une veuve, que le premier

  5. #4
    nornand

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    BJR/
    vOILA 2 solutions qui fonctionnes , mais dans les 2 cas il faut que l'esclave écoute , donc il te faut des tranceivers et non plus de simples émetteurs qui mitraillent en aveugles.
    Dernière modification par nornand ; 14/04/2017 à 15h50.

  6. A voir en vidéo sur Futura
  7. Comparatifs

    Gagnez du temps et de l'argent grâce à nos comparatifs de produits. Parmi nos sujets :
  8. #5
    Seb.26

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    change les delay entre 2 répétitions et le nombre de répétitions pour que ce ne soit pas les mêmes entre tes 2 émetteurs (pour que l'un puisse émettre pendant le 'trou' de l'autre et réciproquement).

    Et du coup y'a toujours des collisions, mais il y a aussi forcement une plage pour que chacun puisse émettre tout seul
    << L'histoire nous apprend que l'on apprend rien de l'histoire. >>

  9. #6
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Merci de vos réponses,

    donc il te faut des tranceivers et non plus de simples émetteurs qui mitraillent en aveugles.
    Se sont trois transceivers ! pas de probléme.

    mais un module qui veut émettre écoute d'abord si un autre émet avant de passer lui-même en émission
    C'est une bonne solution mais comment effectuer ceci ? comment un module peu savoir si un autre module émet ? Ou au moment de sa vérification un autre module émet juste après ?

    C'est un genre de RS485 ?
    je ne sais pas, j'ai étudié via la toile ,seulement le Rs-232 . mais je ne crois pas !
    On autorise un esclave à causer que si il a reçu une autorisation du maitre . Plus de collision !
    Humm..... je vois ... mais ça rallonge et complique énormément non ? Pour ce faire je dois donc :

    - Esclaves vers le Maitre : est ce que je peux t'envoyer quelques chose ?
    - Attente de l'ACK par l'esclave
    - Réponse de l'ACK qui arrive
    - Attente de la réponse du maitre
    - Réponse du maitre : OK tu peux envoyer .
    -Attente de l'ACK par le maitre
    - Envoi du message par l'esclave .

    Est ce que j'ai bon ?

    Si un esclave cause n'importe quand , tu risques la collision.
    Tu as tout as fait raison. Mais quel est le plus important:
    - Absolument éviter la collision pour n'avoir que des messages surs mais rare.
    - ou savoir qu'il peut y avoir collision et faire en sorte quelle n'ai pas d'impact sur le comportement quand elle se produit !

    Ça j'ai du mal à le savoir/ou comprendre !

    Quelle est la durée de la trame et la fréquence de répétition ?
    Reçus à 38400 bauds , une trame est inférieur à 2ms(pour 8bytes) . Elle est analysée par une machine d'état ( de ma sauce ).
    J'aurais aimé un rafraichissement des 8 esclaves de l'ordre de la seconde, si c'est psosible. si c'est plus ce n'est pas grave, le plus important est d'avoir les bonnes infos. qui sont le RSSI et son ID .

    En communication par voie radio:

    la trame d’émission des esclaves est constitué de 6 bytes comme ca :

    <START> <Commande> < Nbe de data> < Data1> <Data2><CHEKSUM>
    Valeur en hexa.

    Suite à l'envoi de cette trame, le maitre lui reçoit cela ( 8 bytes) :
    <START> <Commande> < Nbe de data + 2 > < ID envoyeur> <Data1><Data2><RSSI><CHEKSUM >

    Un ACK est composé comme ceci
    <START> <Commande> < 0x01> < STATUS><CHEKSUM>

    Si vous regardez la notice, mes modules sont configurés comme ceci :
    - je travaille en mode d'adressage 1
    - 10 essai de retransmissions sans ACK

    Merci de vos réponses
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  10. Publicité
  11. #7
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par Seb.26 Voir le message
    change les delay entre 2 répétitions et le nombre de répétitions pour que ce ne soit pas les mêmes entre tes 2 émetteurs (pour que l'un puisse émettre pendant le 'trou' de l'autre et réciproquement).

    Et du coup y'a toujours des collisions, mais il y a aussi forcement une plage pour que chacun puisse émettre tout seul
    Tu veux dire qu'en mettant des delays différents du genre tous les 100ms et 110 ms , je sortirais plus vite de la "zone de collision" ? c'est bien ca
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  12. #8
    Seb.26

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par dje8269 Voir le message
    Tu veux dire qu'en mettant des delays différents du genre tous les 100ms et 110 ms , je sortirais plus vite de la "zone de collision" ? c'est bien ca
    Exemple :

    Admetons que l'envoie de ta trame prenne 5ms.

    EM1 : 3 essais avec 20ms entre 2 essais = TX(5ms) ... WAIT(20ms) ... TX(5ms) ... WAIT(20ms) ... TX(5ms)
    EM2 : 3 essais avec 0ms entre 2 esais = TX(5ms) ... TX(5ms) ... TX(5ms)

    sauf erreur de ma part, chaque message sera envoyé au moins une fois seul quelque soit le timming.
    << L'histoire nous apprend que l'on apprend rien de l'histoire. >>

  13. #9
    annjy

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par Seb.26 Voir le message
    Exemple :

    Admetons que l'envoie de ta trame prenne 5ms.

    EM1 : 3 essais avec 20ms entre 2 essais = TX(5ms) ... WAIT(20ms) ... TX(5ms) ... WAIT(20ms) ... TX(5ms)
    EM2 : 3 essais avec 0ms entre 2 esais = TX(5ms) ... TX(5ms) ... TX(5ms)

    sauf erreur de ma part, chaque message sera envoyé au moins une fois seul quelque soit le timming.
    bjr,
    il a dit au final 8 émetteurs.....
    ça se complique...

    cdlt,
    JY

  14. #10
    Seb.26

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    8 émetteurs ?!! ...

    Dans ce cas essaye avec les probas : envoyer en permanence la dernière valeurs avec un délai aléatoire entre 2 envois (basé sur une table en dur de valeurs et de longueur différente pour chaque esclave).

    Pour éviter de mettre à jour à chaque trame reçue, tu peux te souvenir de la dernière valeur et ne mettre à jour l'affichage que si une valeur a changée.
    << L'histoire nous apprend que l'on apprend rien de l'histoire. >>

  15. #11
    Seb.26

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Si tu peux parler dans les 2 sens : c'est le maître qui interroge les esclaves ... encore plus simple ...
    << L'histoire nous apprend que l'on apprend rien de l'histoire. >>

  16. #12
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Avec huit modules au final je crains ne pas savoir faire l'expression mathématiques pour trouver les bonnes valeurs ?
    Surtout que cela n’empêchera pas le décalage dans le temps car chaque PIC n'a jamais les même tempo T° , nombre d'essai envoyé avec reception ACK etc ..., donc a force les tempos glisseront toujours .

    Je crains que cette solution ne soit pas adéquat ici . Merci en tout cas de ton intérêt c'était bien pensé.
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  17. Publicité
  18. #13
    lpt1com2

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par dje8269 Voir le message
    C'est une bonne solution mais comment effectuer ceci ? comment un module peu savoir si un autre module émet ? Ou au moment de sa vérification un autre module émet juste après ?
    Dans mon cas tous les transceivers sont sur la même fréquence. La trame émise commence par l’adresse du destinataire (une lettre et un chiffre), suivie par l’adresse du demandeur, suivi du message, et se termine par la checksum. Avant d’émettre, le demandeur « écoute » si un autre émet. Si oui, et si la trame reçue ne commence pas par sa propre adresse, il sait que ce n’est pas pour lui, et attend que la fréquence soit libre pour émettre.
    Il vaut mieux être le deuxième mari d'une veuve, que le premier

  19. #14
    annjy

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    re,
    il y a aussi des techniques de "désentrelacement" (en Anglais deinterleaving). voir sur le net.
    On en a récemment parlé sur un post lié à l'ADS-B

    mais ça se complique un peu....surtout pour un PIC....

    je n'ai pas compris la finalité, mais il me semble que l'approche "transpondeur" ( on interroge avec une adresse de récepteur, et seul celui qui est concerné répond) serait le plus simple.

    cdlt,
    JY

  20. #15
    DAUDET78

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par annjy Voir le message
    rje n'ai pas compris la finalité, mais il me semble que l'approche "transpondeur" ( on interroge avec une adresse de récepteur, et seul celui qui est concerné répond) serait le plus simple.
    C'est ce que j'ai proposé en #2
    Citation Envoyé par DAUDET78 Voir le message
    On autorise un esclave à causer que si il a reçu une autorisation du maitre . Plus de collision !
    Surtout que les trames ne font pas 100K octets !
    J'aime pas le Grec

  21. #16
    lpt1com2

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par annjy Voir le message
    ...on interroge avec une adresse de récepteur, et seul celui qui est concerné répond...
    Oui, c'est ce que je fais. J'ai 8 modules interconnectés, mais un seul dialogue n'est possible à un instant donné.
    Il vaut mieux être le deuxième mari d'une veuve, que le premier

  22. #17
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Avant d’émettre, le demandeur « écoute » si un autre émet.
    Oui mais ça mon module ne sait pas le faire.

    Je suis traine de reflechir a la méthode de demande par le maitre. Mais je tombe sur un HIC que je n'avais pas précisé car le pensant inutile ! c'est la consommation .

    en effet les modules transceiver ainsi que le maitre seront sur batterie ou pile !

    Dans ma réflexion papier j'étais partis sur un déroulé comme suit :

    Je configure le maitre pour envoyer un message seulement au module N°1 .
    J'attends l'ACK de cette configuration.
    J'envoie un message a l’esclave configuré précédemment lui demandant de m'envoyer son ID .
    J'attends l'ACK .
    Si après mes 10 tentatives je n'ai pas reçu d'ACK de la part de l'esclave c'est qu'il n'est pas connecté ou hors de portée.
    Si je reçois un ACK , j'attends la réponse de l'esclave .
    Une fois la réponse reçue je traite .
    et je recommence avec l'esclave numero 2 .....etc .....

    Je ne sais pas combien de temps cela prendre au final pour faire une boucle . Je crois que seul le test pourra me le dire ! Il faudrait que je descende sous les 100ms pour un boucle ; soit un rafraichissement toute les 0.8s .
    Mais ce qui me dérange c'est que le maitre va émettre presque en permanence ! sauf si ma boucle est trés courte !

    Qu'en pensez vous ?
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  23. #18
    DAUDET78

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par dje8269 Voir le message
    Je configure le maitre pour envoyer un message seulement au module N°1 .
    J'attends l'ACK de cette configuration.
    J'envoie un message a l’esclave configuré précédemment lui demandant de m'envoyer son ID .
    J'attends l'ACK .
    Si après mes 10 tentatives je n'ai pas reçu d'ACK de la part de l'esclave c'est qu'il n'est pas connecté ou hors de portée.
    Si je reçois un ACK , j'attends la réponse de l'esclave .
    Une fois la réponse reçue je traite .
    et je recommence avec l'esclave numero 2 .....etc .....
    Y a plus simple !
    Je configure le maitre pour envoyer une demande seulement au module N°1 .
    Si après mes 10 tentatives je n'ai pas reçu de trame de la part de l'esclave c'est qu'il n'est pas connecté ou hors de portée.
    Si je reçois une trame bonne, je lui envoie un ACK1
    Une fois la réponse reçue, Je configure le maitre pour envoyer une demande seulement au module N°2 et je traite la trame reçue de N°1
    etc etc
    Pour info, toute la gestion des demandes de trame, des ACK et des réception de trames doit être faites en interruption . Seul le traitement de la trame reçue est dans le "main"
    J'aime pas le Grec

  24. Publicité
  25. #19
    lpt1com2

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par dje8269 Voir le message
    Oui mais ça mon module ne sait pas le faire.
    Pourquoi ton module ne sait pas le faire ? Quel mode utilises-tu, UART, SPI ? Tu peux surement voir s’il y a une réception en cours pour savoir si tu peux émettre.
    Par contre, 10 tentatives en cas d’échec ça me paraît beaucoup (je n’en fais que 3).
    Il vaut mieux être le deuxième mari d'une veuve, que le premier

  26. #20
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Re,

    @DAUDET78: je vois à peu prêt ou tu veux en venir ! mais il y a quelques confusions , comme par exemple quand tu dis que tu lui envoie un ACK1 ? les ACK sont envoyés automatiquement . je ne gère pas cette partie.

    Quel mode utilises-tu
    Le module utilisé est en #1 . Je travaille en commande MODE 1 . Mon transceiver est relié en UART à mon PIC à 38400 bauds

    Par contre, 10 tentatives en cas d’échec ça me paraît beaucoup (je n’en fais que 3).
    Oui je pourrais baisser ce chiffre pour gagner du temps de réaction . Je l'avais mis à la louche .

    Tu peux surement voir s’il y a une réception en cours pour savoir si tu peux émettre.
    Oui mais ce n'est pas le problème à mon avis . La broche RTS m'indique un buffer plein, ou un transmission sans fil en cours.

    Désolé si je vous parait nul ! j'essaye de bien faire et de bien comprendre, car c'est passionnant , mais pas évident dans le détail.
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  27. #21
    DAUDET78

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Citation Envoyé par dje8269 Voir le message
    je vois à peu prêt ou tu veux en venir ! mais il y a quelques confusions , comme par exemple quand tu dis que tu lui envoie un ACK1 ? les ACK sont envoyés automatiquement . je ne gère pas cette partie.
    ben, tu modifies mon algorithme pour faire avec
    J'aime pas le Grec

  28. #22
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Bonjour ,

    Je suis toujours sur le coup mais j'ai du mal à arriver au comportement voulu.

    Je peux d’ors et déjà que c'est plutôt long ...... je suis à 25ms quand j'ai la communication et 60ms sans com . Et je n'ai pas encore fais le traitement de l'information . Juste le fait d'envoyer une requête et d'attendre la réponse !
    C'est en faisant des erreurs; que l'on apprend le mieux !!

  29. #23
    dje8269

    Re : Probléme de collision entre un recepteur et plusieurs emetteur

    Bonjour à tous,

    Après avoir galérer un faire mon programme, j'y suis enfin arrivé .

    Le résultat est plutôt mitigé, mais satisfaisant .

    Voici les temps de réponse entre deux demandes .
    26ms pour un module connecté.
    J'ai réduit à 15 ms pour un module non connecté.

    Ma méthode :
    - envoi d'un message à l'esclave
    - si dans les 15ms qui suivent l'envoi je n'ai pas d'ACK, j'en déduis que le module n'est pas connécté ou hors de portée. je sors de ma boucle.
    - Si je reçois un ACK dans les 15ms ( 11ms) , j'attends le message de réponse . qui vient 13ms plus tard. j'ai rajouter un garde-fou à 20ms si j'ai pas de message je sors .

    Je pense pas pouvoir optimiser bien plus mon programme. Je pense pas que je puisse gagner beaucoup plus de temps . en augmentant la vitesse je gagnerais un peu sur les communications , qui sont deja de 2ms seulement . ca ne vaut aps le coup de passer à 55kb/s . La ou j'aurais pus gagner du temps c'est à la réception de l'ACK , qui prends 10ms et la réception du message qui en prend 12ms.

    Franchement c'est déjà pas mal. Je suis dans les clous, même si je n'ai pas encore fait le traitement des données recues !

    Merci à tous pour votre aide . Si vous avez des suggestions d'amélioration je suis preneur

    reception ACK_OK.png

    reception NON_ACK.png
    C'est en faisant des erreurs; que l'on apprend le mieux !!

Discussions similaires

  1. Problème émetteur récepteur 433 !
    Par jejesg dans le forum Électronique
    Réponses: 3
    Dernier message: 17/08/2012, 07h58
  2. Émetteur récepteur IR à plusieurs canaux ?
    Par IHCAAMEL dans le forum Électronique
    Réponses: 15
    Dernier message: 26/07/2012, 15h33
  3. Émetteur Récepteur infrarouge à plusieurs canaux
    Par IHCAAMEL dans le forum Électronique
    Réponses: 4
    Dernier message: 15/06/2012, 21h47
  4. Réponses: 11
    Dernier message: 26/02/2012, 07h36
  5. emetteur gérant plusieurs recepteur
    Par NEOLAS.Sylvain dans le forum Électronique
    Réponses: 8
    Dernier message: 29/06/2011, 01h24
Découvrez nos comparatifs produits sur l'informatique et les technologies.