La carte Micro ne lit pas le signal envoyé

Pourtant les bits transitent bien par RF et les fils !

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonsoir/bonjour, tout le monde.

Je suis face à un énigme. Voyez vous, moi et mon collègue de SI, on doit faire un prototype de télécommande, pour notre projet de terminale. Le but de cette télécommande, est d'envoyer un 1 ou un 0, qu'elle garde en mémoire, et de le changer d'état lorsqu'on appuie sur un bouton. C'est une carte Arduino Nano. Ensuite, à chaque tour de boucle, elle transmet ce nombre par ondes radio au récepteur (la fameuse carte Arduino Micro). Ce récepteur, en fonction de ce qu'il reçoit, va jouer soit un son 1 (si elle reçoit 0), ou un son 2 (si elle reçoit autre chose que 0). Voilà notre montage :

montage électrique

Le soucis, vous vous en doutez, c'est que coté récepteur, rien n'est reçu ! Alors, ni une ni deux, on a passé tout ça à l'oscilloscope. Et c'est là que ça devient bizarre. On s'est placé coté récepteur (sur le fil couleur cyan et la masse du récepteur RF), et on essayé de voir si le récepteur 433 MHz recevait un signal, et la réponse est… oui ! (désolé pour la qualité moyenne de la photo)

Tiens, on dirait que quelqu'un essaie d'envoyer un 1 codé sur 24 bits...

Vous conviendrez que c'est un signal plus qu'exploitable ! Alors pourquoi notre carte ne fait-elle comme si aucun signal n'était reçu ? Je vous explique plus en détail le soucis : En fait, on ne rentre jamais dans le bloc if qui permet de récupérer la valeur envoyée par RF. La fonction mySwitch.available() retourne toujours 0… Je vous met mes deux bouts de code, pour que vous puissiez voir :

Le code de l'émetteur:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#define bouton 2

#include<RCSwitch.h>
int etat = 0;
RCSwitch mySwitch = RCSwitch();

void setup() {
  // put your setup code here, to run once:
  mySwitch.enableTransmit(3);
  Serial.begin(9600);
  pinMode(bouton, INPUT);
  digitalWrite(bouton, HIGH);  
}

void loop() {
  // put your main code here, to run repeatedly:
  int value = digitalRead(bouton);
  if(value == LOW){
    //Serial.println("on change la variable etat");
    etat = !etat;
  }
  mySwitch.send(etat, 24);
  Serial.print("Valeur envoyée :");
  Serial.println(etat);
  delay(100);
}

Celui du récepteur

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();
int code = 0;
const int frequence[5]={3831,3861,4016,4132,4386};
const int temps[5]= {142,80,73,132,132};

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  mySwitch.enableReceive(2);

}

void bip1(){
  int i = 0;
  for (i=0 ; i<=4 ; i++){
    tone(4, frequence[i], temps[i]);
    delay(temps[i]);
  }
  for (i=0;i<=12;i++){
    tone(4, int(4545+i*49), 10);
    delay(10);
  }
  delay(391);
}

void bip2(){
  tone (4, 2717, 126);
  delay(126);
  tone (4, 3154, 623);
  delay(623);
  delay(488);
}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.println(mySwitch.available());
  if(mySwitch.available()){
    Serial.println("On a reçu quelque chose!");
    code = mySwitch.getReceivedValue();
  }
  
  if(code == 0){ 
    bip1();
  }else{ 
    bip2();
  }
  mySwitch.resetAvailable();
}

Selon vous, de quoi peut bien provenir le problème ? Je vous avoue que mis à part un coup de malchance des familles, du genre le câble coupé juste après l'endroit où on l'a dénudé pour faire les mesures avec l'oscillo', je vois pas trop… :D

D'autant plus qu'on a fait plusieurs test avec la librairie RCSwitch. On ne peut pas dire non plus que ce sont les modules RF qui ne fonctionnent pas…

Voilà, si vous pensez avoir une idée de ce qui cloche là dedans, je suis preneur. :)

Sur ce, bonne soirée/journée !

Édité par Popiette

C'est Sakamoto qui m'a dit de le faire !

+0 -0

Bonjour, un imprime écran de l'oscilloscope serais plus facile à lire bien que le signale ne devrais pas poser de problème à l'Arduino, pourrais tu nous donner un lien vers la doc de l’émetteur/récepteur ainsi que le signale de l’émetteur.

+0 -0
Auteur du sujet

J'ai pas de solution mais je note que c'est la première fois qu'un post sur le forum donne une photo d'oscilloscope pour le debug :D

Grimur

Achivement get ! :D

J'avais un peu peur que vous me preniez pour un fou, alors j'ai préféré montrer qu'on avait quand même procédé un peu méthodiquement… Et puis c'est classe les oscilloscopes, non ? ;)

le print du deuxieme programme renvois des valeurs ? le print "on a recu quelque chose" s'affiche bien sans arret à chaque tour de boucle ? (sans delay, ca doit bombarder le port série :D )

Eskimon

Non justement, il est là le problème. Le "mySwitch.available()" retourne toujours 0, du coup on rentre pas dans le if, et on change jamais la valeur code, le bip que la carte fait est toujours le même… Sinon, non ça ne bombarde pas trop la liaison série, car il y a pas mal de delays dans les fonction bip1 et bip2. ;) Par contre, j'avais fait une erreur en copiant collant mon code : J'avais laissé en commentaire le "if(mySwitch.available())" et ses accolades. Mon collègue voulait qu'on essaie de voir si l'arduino pouvait tout de même lire le signal, sans qu'on vérifie avant si le module était… disponible ? Bref, de toute façon ça ne fonctionnait pas.

Bonjour, un imprime écran de l'oscilloscope serais plus facile à lire bien que le signale ne devrais pas poser de problème à l'Arduino, pourrais tu nous donner un lien vers la doc de l’émetteur/récepteur ainsi que le signale de l’émetteur.

pigeorge

Désolé, notre oscilloscope n'avait pas de touche Imp' écran… :p Pour ce qui est de la librairie, nous utilisons RCSwitch, disponible ici : RCSwitch github Il y a très peu de documentation sur cette librairie, c'est un peu embêtant, car tout le monde fait un peu la même chose, avec les mêmes cartes, et les mêmes bouts de codes, sur Internet…

Notre émetteur 433MHz est un Cdt-88 et le récepteur est un xl-r03a. En terme de doc', pour le Cdt-88 j'ai trouvé ça : petite datasheet. Par contre, j'ai pas trouvé grand chose d'intéressant pour le récepteur…

Édité par Popiette

C'est Sakamoto qui m'a dit de le faire !

+0 -0

Il faut investiguer aussi au niveau du soft.

Effectivement le récepteur fonctionne vu qu'il y a un signal codé sur la pin. Mais as-tu testé l'envoie d'un "1" en dur dans le code, sans passer par l'UART ?

Pour le scope, il est capable de prendre des captures d'écrans, sur une clé USB. Normalement c'est la touche Save/recall ou alors passer par la touche Utility. ;)

+0 -0
Auteur du sujet

Effectivement le récepteur fonctionne vu qu'il y a un signal codé sur la pin. Mais as-tu testé l'envoie d'un "1" en dur dans le code, sans passer par l'UART ?

zeqL

Tu veux dire que la condition soit toujours vraie, de manière à ce que la carte essaie de lire sur le pin 2 le signal envoyé ?

C'est Sakamoto qui m'a dit de le faire !

+0 -0

Tu as mis un anti-rebond sur le bouton ?

Car si tu appuie dessus, tu change l'état envoyé, or sans anti-rebond ou timer pour ne prendre en compte qu'une fois l'appui, dans ta boucle de l'émetteur, la variable etat change de valeur, elle passe donc très rapidement à l'état inverse et à chaque boucle.

Donc en fait ce que tu observe, c'est du 01010101010101, qui correspond aux multiples changement de valeur de ta variable etat lorsque tu appuie sur le bouton.

Or si tu as l'impression d'appuyer "très rapidement" sur le bouton, le microcontroleur a fait plusieurs fois le tour de la boucle, et donc comme tu étais toujours le doigt appuyé, ta variable change de valeur.
Fait le test en mettant une chaine "000011110000111" par exemple à la place de la variable etat au niveau de l'émetteur.

Édité par zeqL

+0 -0
Auteur du sujet

Je ne suis pas sûr que ce soit de là que vienne le problème. Moi j'ai plus l'impression que c'est la carte qui ne lit pas ce qui est envoyé, plus qu'une variable qui change de valeur. Mais j'essaierai tout de même.

Par contre, j'y ai réfléchi, et je crois peut être avoir mis le doigt sur quelque chose : Se pourrait-il que comme la carte passe un certain temps à faire les bips, par tour de boucle, l'émetteur ne peut jamais lire quelque chose de correct, du fait qu'il va lire surement un bit du message, attendre peut-être trois seconde, et vérifier s'il y a la suite ?

C'est Sakamoto qui m'a dit de le faire !

+0 -0

C'est un peu ce que je raconte avec l'anti-rebond et je suis quasiment sûr que c'est ça le problème.

Le microntrôleur va effectuer la boucle en environ 100 ms (par exemple), cela veut dire qu'avec ton code, il va lire l'état du bouton (au niveau de l'émetteur) tous les 100 ms. Et tous les 100 ms il va inverser l'état de la variable etat.
Or, même en étant surhumain, tu n'arrivera pas à appuyer 100 ms (plus ou moins 50 ms) sur le bouton. On va dire que même en appuyant rapidement cela va durer 1 seconde (donc 1000 millisecondes).

Donc pendant 1 seconde, comme une boucle du programme du 100 ms, cela fera 10 fois, la variable etat va changer de valeur. Donc la chaine correspondante à 1 seconde d'appui sur le bouton sera : 0101010101. Or à l'oscilloscope on observe, tu le dis toi-même, une chaîne du style 010101010101… CQFD.

Pour confirmer cela tu peux désactiver l'utilisation du bouton en fixant la valeur envoyée par l'émetteur, justement en mettant une chaîne "00001111000011110000" qui ne peut pas être créée par un appui sur le bouton.
Le but est de mettre de côté tout ce qui peut avoir un caractère un peu aléatoire et non reproductible comme l'appui sur un bouton. Tu fixe la valeur qu'envoie l'émetteur, si tu reçois cette valeur, ça veut dire que ton code avec le bouton est la source.

+1 -0
Auteur du sujet

Donc pendant 1 seconde, comme une boucle du programme du 100 ms, cela fera 10 fois, la variable etat va changer de valeur. Donc la chaine correspondante à 1 seconde d'appui sur le bouton sera : 0101010101. Or à l'oscilloscope on observe, tu le dis toi-même, une chaîne du style 010101010101… CQFD.

zeqL

Oh wait, je crois qu'on ne s'est pas compris là ! Moi sur l'oscilloscope, je lis bien : 000000000000000000000001, soit un 1 codé sur 24 bits. C'est bien ça ? Je sais pas comment expliquer ça clairement, mais, les moments très courts ou on passe de 5V à 0, et on retourne à 5V ne comptent pas, si ?

C'est Sakamoto qui m'a dit de le faire !

+0 -0
Auteur du sujet

Bon, eh bien le problème c'est réglé, de manière plus ou moins hasardeuse.

Lorsque que j'ai mis l'appel des fonctions bip() dans la condition "mySwitch.available()", notre buzzer à commencer à faire un son de manière irrégulière. Cela se faisait alors qu'on envoyait en dur un 1 depuis l'arduino émetteur. On a ensuite essayé de gérer les appuis au bouton, c'est à dire d'envoyer un 0 pendant un temps, puis un 1, etc… Là on s'est rendu compte que la carte Arduino ne lisait rien lorsqu'on lui envoyait un 0 ! Cependant, elle lisait bien le 1. Résultat des courses : On envoie maintenant, soit un 1, soit un 2, et la carte détecte les deux messages, et change bien de bip. On a raccourci des delay coté émetteur (ça doit pas être tout à fait le même programme que celui que j'ai mis plus haut), et maintenant tout fonctionne comme sur des roulettes, notre buzzer refait bien nos bips insupportables, et toute la classe à envie de nous tuer. :p

Je trouve que certaines choses sont un peu bizarres, par exemple le fait qu'on ne puisse pas envoyer de 0, mais je ne vais pas me plaindre, tout fonctionne.

En tout cas, merci à vous d'avoir pris le temps de m'aider dans tout ça ! ;)

C'est Sakamoto qui m'a dit de le faire !

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte