J'ai posté derniérement un topic pour savoir comment utilisé 2 hc-05 qui communique entre eux via bluetooth et s'envoirait des inforation contenu dans des variables (voir ici pour le topic : http://openclassrooms.com/forum/sujet/faire-communiquer-2-arduino-sans-fil) mon problème n'est actuellemnt pas résolu donc si vous vous y connaissez en bluetooth etc cliquer sur le lien. Mais en attendant que quelqu'un trouve une solution a mon prblème on m'a parlé de ce fabuleux monde qu'est le monde du 434 mHz .J'ai donc trouver des exemple de code mais voila que je rencontre un autre problème (et oui j'en ai plein) je ne sais pas ou mettre dans le code de l'metteur que je souhaite que les donné de ma variable soit envoyé au recpteur. Help quelqu'un s'y connait en 434mHz et pourrait me dire comment on envoie des information de l'émétteur au recepteur. J'ajouterai mon code de base , le code de l'emtteur trouvé sur internet , le code du recepteur egallement trouvé sur internet en commentaire.
Tu parles des modules hf à 1€ ? Justement j'en ai reçu deux paires hier, j'ai testé avec ce tuto très simple et bien expliqué pour transmettre un bit, ça marchait parfaitement
a oui 2 cm pas top je vais regardé tout ca et j'aurai besoin d'un conseil enfaite j'ai un capteur HC-SR04 qui mesure a quelle distance sont les obstacles je stock donc la valeur comprise entre 2 et 200 dans une variable de type long apelle cm. J'aimerais que la valeur stocké dans cm soit envoyé au recpteur lorsque c'est a moin de 50 cm , coment tu ferai ca ?
bon on va faire simple, parce que tu semble pas réussir à comprendre ce qu'on te dit, et vers quel tuto on t'envoie depuis le début.
tu prends ton code tel quel pour l'émetteur, et tu rajoute dans le setup une fonction
vw_setup(2000); //2000 c'est le débit maxi: 2000 bauds. sur le site de skyduino tu as plus de précisions
ensuite dans ton code actuel, tu remplace ton code qui fait vibrer le buzzer par vw_send("BEEP").
pour la partie récepteur, maintenant, tu fais ce code:
#include "virtualWire"
setup{
vw_setup(2000); // initialisation de la librairie VirtualWire à 2000 bauds (note: je n'utilise pas la broche PTT)
vw_rx_start();
}
loop{
uint8_t buf[VW_MAX_MESSAGE_LEN]; // Tableau qui va contenir le message reçu (de taille maximum VW_MAX_MESSAGE_LEN)
uint8_t buflen = VW_MAX_MESSAGE_LEN; // Taille maximum de notre tableau
// REMARQUE ULTRA IMPORTANTE :
// Par le passé ces deux lignes se trouvaient en "haut de programme", c'était donc des variables globales.
// Elles ne doivent PAS être globales, c'est très important !
//
// Pourquoi ?
// C'est très simple. Posez vous la question suivante : que vaut "buflen" si la réception d'un message échoue,
// où qu'on reçoit un message de moins de VW_MAX_MESSAGE_LEN octets ?
// Au début "buflen" vaut VW_MAX_MESSAGE_LEN, mais après "buflen" vaudra une valeur < VW_MAX_MESSAGE_LEN.
// Et paf, la taille de votre buffer vient de diminuer pour la réception suivante, et ainsi de suite.
if (vw_wait_rx_max(200)) // Si un message est reçu dans les 200ms qui viennent
{
if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
{
if(buf="BEEP"){
//ton code qui fait beeper ton bip
delay(1000); //pour que ça beep 1s et après on arrête
}
}
}
}
}
et me dis pas que c'est pas exactement ce que je t'ai déjà dit au moins 3 fois dans l'autre post.
ces codes sont bien entendu faux, mais l'idée est là. t'as plus qu'à corriger les erreurs de langage, et ça marchera.
Je pense pas que ça change quoi que ce soit d'après ce que j'ai trouvé sur le web : la bibliothèque tu l'as choisi selon tes gouts de programmeur plutot, spa une question de compatibilité a mon avis
Sur aliexpress les acheteurs du XY-MK-5V (mon mien) reportaient que la library nomée "RadioHead Packet Radio library for embedded microprocessors" était utilisable avec ce module là :
et c'est confirmé sur le site (cf les drivers en bas). Du coup je la testerais également des que j'aurais résolu ce pb d'antenne. Mais j'estime mieux de commencer à tester avec la librairie Virtualwire, ya pas de raison que ça soit incompatible après tout puisque c'est la plus connu, et puis la preuve par l'image (le XY-MK-5V en bas):
c'est pour les 433 Mhz, il faut bien entendu inclure virtualwire dans les deux programmes, dans le programme fait à la va vite que j'ai à moitié pompé sur skyduino, il utilise les pin "par défaut", qui en fait sont déclarées dans serialwire.h. tu peux les redéfinir toi en haut de programme, il l'explique dans son tuto, dont on t'a posté déjà au moins 5 fois le lien.
je l'ai lu mais j'avais ppas compris ou fallait metre mon code de base et plein d'autre truc, d'aillleur c'est pas en mettant le tuto 5 fois que j'allais mieux le comprendre en plus le lien que tu m a donne je le connaissai en faisant des reccherches avant de demander sur le forum
ha. bah il faut essayer de comprendre le code alors (en général il commente beaucoup, lui, et ce qui est pas dans les commentaires est en dehors du bloc de code).
et coup de bol, le code, ça tombe bien, il est plutôt simple à comprendre.
du coup comme je l'ai compris, je te pose la question, qu'est-ce que tu comprends pas?
EDIT: une nouvelle méthode pour tes prochains projets, qui t'évitera de trop galérer sur un projet qui t'en demande trop du premier coup:
déjà, c'est bien de vouloir travailler par milestones, ou en suivant un processus itératif: ce que tu fais déjà, puisque tu as commencé par un projet qui fait ce que tu veux, sur une seule arduino, je suppose que c'est pour comprendre comment fonctionne le buzzer et le module sonar.
ensuite, pour un projet à deux têtes intelligentes, il faut décider qui fait quoi, et de manière très claire: qui mesure, qui traduit la mesure en valeur qui correspond à quelque chose si besoin est, qui réfléchit à savoir s'il faut biper, qui bipe, etc...
comme je te l'ai déjà dit pour ça t'as deux choix: l'arduino du sonar réfléchit, ou l'arduino du buzzer réfléchit.
mais ce qu'il faut pas faire, c'est aller direct dans ton projet, avec une liaison que tu ne maitrise pas. donc à ta place, je chercherais à faire un pont entre deux terminaux serial, mais qui passerait par tes modules sans fil (que ce soit bluetooth, ou 433Mhz)
et une fois le protocole sans fil maîtrisé (qu'il fasse exactement ce que tu veux, comme tu veux), tu peux te lancer dans ton projet final, parce que tu as tout maitrisé ce dont tu as besoin pour le réaliser.
de là, tu fais (pour chaque board arduino): dans le setup, tu recopie tout ce que contient tes anciennes milestones (donc tes initialisations de voie série, de modules sans fil, de module sonar, etc... toutes tes initialisation). dans le loop, tu rentre une procédure logique qui fait tes mesures, et agit en conséquences.
bien sûr, ça marchera pas du premier coup, d'où la voie serie qui reste, et tu décris ce que ton arduino fait. à chaque fois. si le comportement que tu lis sur les deux terminaux te convient, tu vire toutes les lignes série, et ton applciation est finie. sinon, bah 'faut corriger
le premier emmeteur est avec un HC-SR04 si cm < 50 alors il envoie un message au recepteur et donc un bip via un buzzer retenti
le second emmetteur est avec un HC-SR04 si <50 alors il envoie un messgae au meme recpeteur et donc un bip via un second buzzer qui sonne differement du premier retenti.
Deplus comment le recepteur pourrait faire pour differencier les 2 emmeteur si il n y a pas d adressage ? Comment pourra t il se dire :" Ah le second emetteur qui m envoie la donne ! ou c'est le premier emmeteur ?" ?
bah ça tu peux le transmettre dans le code. tu peux transmettre "e1\tbeep" ou "e2\tnobeep"... et même tu pourrais mettre des modules qui font à la fois émetteur et récepteur sur tes 3 points, et faire que l'émetteur demande aux deux capteurs chacun à leur tour et leur transmette que la mesure est comprise.
c'est d'ailleurs un peu ce qu'il se passe dans les protocoles "réseau" style xbee, ou quoi, l'info est empaquetée dans un paquet plus gros contenant des infos sur l'émetteur, sur le récepteur, et sur les données elles-mêmes (checksum, parité, taille du message, etc...), et des fois même un horodatage.
j'ai dit ça comme j'aurais pu dire autre chose hein...
dans ce genre de communications, imagine que tes 3 modules 433 MHz sont des téléphones dans une grande entreprise, style une centrale nucléaire. quand à la commande un des agents doit décider s'il doit lancer une alerte. et pour lancer l'alerte, il attend un coup de fil de la part d'un des deux agents qui sont postés chacun devant un réacteur. d'un coup son téléphone sonne. il décroche. le premier truc qui va intervenir dans la communication va etre de savoir qui est qui. ensuite, on téléphone pas pour rien, donc on finit par délivrer le contenu du message.
bah dans ton procédé, tu dois avoir quelque chose d'analogue. e1 c'est pour "émetteur 1" e2 pour "émetteur 2", \t c'est un séparateur que j'aime bien utiliser, parce qu'il est très visuel (ça fait une tabulation), et "beep" ou "nobeep" c'était le contenu du message, à savoir s'il faut sonner ou pas.
d'ailleurs, l'analogie téléphone aide bien quand on veut créer ce genre de communications.
Oui mais n oublie pas qu'il a 2 buzzer , le buzzer est "relié" a l emmteur 1 et pareil pour le buzzer , avec quel fonction je pourrai faire comprendre au recpteur cette info vien du e1 ou cette info vien du e2 , je ne vois pas comment on peut faire vu que dans le lien que tu ma passé c'etait ecrit qu'il n'y avais pas d adressage
Je crois avoir trouvé une solution ,si dans le code de l emmteur je met qu on envoie un message qui dit BEEP si cm < 50 et dans celui du second pareil sauf que le message di BEP ensuite dans le code du recepteur je dis si buf = "BEEP" alors on allume le premier buzzer si buf = "BEP" alors on allume le second buzzer . Est-ce possible de faire un truc du genre ?
ça marcherait, même bien, par contre, si t'as un e qui passe mal, tu te retrouveras avec une alarme"de gauche" pour le capteur "de droite". (cas un peu rare, mais si t'es dans la limite de portée, enfin dans des cas un peu limites, ça peut faire des choses imprévues, voire déconner completement. avoir un modèle bien défini, c'est bien pratique dans ce cas.)
ce que je te disais, c'était plutôt de faire un protocole maison ou l'arduino qui émet se présente, et donne un ordre. c'est comme ça que j'avais construit le message que je t'ai proposé: un identifiant, "\t" puis un ordre: "E1\tBEEP" pour "émetteur \t ordre". Du coup, l'arduino des buzzers sait en décodant le message l'expéditeur de l'ordre, et ensuite il peut exécuter l'ordre indiqué dans la fin du message.
du coup, tu peux donner plusieurs ordres différents via ce moyen. par exemple, dire de biper, d'arrêter de biper, enregistrer une valeur (admettons que tu la transmette aussi dans le protocole), envoyer un timestamp avec l'arduino qui bipe à une page web, ou que sais-je...
avoir une structure de message bien définie, ça facilite beaucoup le travail de code après.
et surtout, si tu conçois bien ton code, après, c'est presque facile de rajouter un nouveau capteur et un nouveau buzzer, parce que t'as qu'à #define un 3e buzzer, et rajouter un cas de lecture sur le début du message.
juste avant de le mettre en resolu y a un probleme :
#include <VirtualWire.h>
int led = 4;
int led1 = 5;
void setup()
{
vw_setup(2000); // initialisation de la librairie VirtualWire à 2000 bauds (note: je n'utilise pas la broche PTT)
vw_rx_start();
}
void loop()
{
uint8_t buf[VW_MAX_MESSAGE_LEN]; // Tableau qui va contenir le message reçu (de taille maximum VW_MAX_MESSAGE_LEN)
uint8_t buflen = VW_MAX_MESSAGE_LEN; // Taille maximum de notre tableau
if (vw_wait_rx_max(200)) // Si un message est reçu dans les 200ms qui viennent
{
if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
{
if(buf="BEEP")
{
tone(led, 6500, 1000);
}
else(buf="BEP")
{
tone(led1, 2500, 1000);
//pour que ça beep 1s et après on arrête
}
}
}
}
ca me dit ERREUR DE COMPILATION
HC_SR04_CODE_RX1.ino: In function ‘void loop()’:
HC_SR04_CODE_RX1.ino:23:19: error: incompatible types in assignment of ‘const char [5]’ to ‘uint8_t [30] {aka unsigned char [30]}’
HC_SR04_CODE_RX1.ino:29:21: error: incompatible types in assignment of ‘const char [4]’ to ‘uint8_t [30] {aka unsigned char [30]}’
HC_SR04_CODE_RX1.ino:30:13: error: expected ‘;’ before ‘{’ token
#include <VirtualWire.h>
int led = 4;
int led1 = 5;
void setup()
{
vw_setup(2000); // initialisation de la librairie VirtualWire à 2000 bauds (note: je n'utilise pas la broche PTT)
vw_rx_start();
}
void loop()
{
uint8_t buf[VW_MAX_MESSAGE_LEN]; // Tableau qui va contenir le message reçu (de taille maximum VW_MAX_MESSAGE_LEN)
uint8_t buflen = VW_MAX_MESSAGE_LEN; // Taille maximum de notre tableau
if (vw_wait_rx_max(200)) // Si un message est reçu dans les 200ms qui viennent
{
if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
{
if(buf=="BEEP")
{
tone(led, 6500, 1000);
}
}
}
if (vw_wait_rx_max(200)) // Si un message est reçu dans les 200ms qui viennent
{
if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
{
if(buf=="BEP")
{
tone(led1, 2500, 1000);
//pour que ça beep 1s et après on arrête
}
}
}
}
tu fais une erreur de conception, ça marchera pas comme ça. rappelle toi que tout ce que tu écris est exécuté dans l'ordre dans lequel c'est écrit.
donc ton code devrait plutôt être:
#include <VirtualWire.h>
int led = 4;
int led1 = 5;
void setup()
{
vw_setup(2000); // initialisation de la librairie VirtualWire à 2000 bauds (note: je n'utilise pas la broche PTT)
vw_rx_start();
}
void loop()
{
uint8_t buf[VW_MAX_MESSAGE_LEN]; // Tableau qui va contenir le message reçu (de taille maximum VW_MAX_MESSAGE_LEN)
uint8_t buflen = VW_MAX_MESSAGE_LEN; // Taille maximum de notre tableau
if (vw_wait_rx_max(200)) // Si un message est reçu dans les 200ms qui viennent
{
if (vw_get_message(buf, &buflen)) // On copie le message, qu'il soit corrompu ou non
{
if(buf=="BEEP")
{
tone(led, 6500, 1000);
}
else if(buf=="BEP")
{
tone(led1, 2500, 1000);
//pour que ça beep 1s et après on arrête
}
}
}
}
bien entendu je t'ai laissé les erreurs de pointeurs, parce que c'est important que tu comprenne bien ce qu'il se passe. donc essaie de chercher dans google pourquoi ça marche pas, essaie aussi de comprendre ce qui est écrit dans tes rapports de compilation.
Merci de ton aide et ouai au moins maintenant je sais utiliser le pointeurs
Prépa PCSI
Arduino 434mHz
× 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.
Prépa PCSI
Prépa PCSI
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
Prépa PCSI
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI
Prépa PCSI
Prépa PCSI
oui. non. enfin je regarde et je te dis.
Prépa PCSI