réception 433 MHz par module RXB6

hello bonjour,

j'ai acheté ce récepteur 433 MHz
Je le teste avec une UnoR3.
Rien de compliqué dans les branchements (GND, VCC et DATA).

Je constate que le récepteur envoie en permanence des trucs sur sa broche DATA, même lorsque je n'active aucun émetteur. J'ai essayé avec ou sans antenne, c'est pareil. J'ai ajouté une LED entre DATA et GND, elle vacille.
J'ai testé les exemples de la biblio rc-switch : rien n'est détecté.

J'ai testé le code suivant:

void setup()
{
  Serial.begin(115200);
  pinMode ( 3, INPUT );
}
// -----------------------------------------------------
void loop()
{
  unsigned long dthi = pulseIn ( 3 , HIGH );
  Serial.println ( dthi );
}

Je vois défiler des valeurs apparement aléatoires, de qques dizaines de microsecs.
Malheureusement, je ne dispose pas d'un oscilloscope.

Je ne comprends pas pourquoi le récepteur envoie tout ce binz. Je ne pense pas baigner dans un champ d'ondes 433 MHz permanentes !

Une idée ?

Y a pas une bibliothèque à utiliser, une initialisation à faire, ...

Cordialement.

Pierre

biggil:
hello bonjour,

j'ai acheté ce récepteur 433 MHz
Je le teste avec une UnoR3.
Rien de compliqué dans les branchements (GND, VCC et DATA).

Je constate que le récepteur envoie en permanence des trucs sur sa broche DATA, même lorsque je n'active aucun émetteur. J'ai essayé avec ou sans antenne, c'est pareil. J'ai ajouté une LED entre DATA et GND, elle vacille.
J'ai testé les exemples de la biblio rc-switch : rien n'est détecté.

J'ai testé le code suivant:

void setup()

{
 Serial.begin(115200);
 pinMode ( 3, INPUT );
}
// -----------------------------------------------------
void loop()
{
 unsigned long dthi = pulseIn ( 3 , HIGH );
 Serial.println ( dthi );
}



Je vois défiler des valeurs apparement aléatoires, de qques dizaines de microsecs.
Malheureusement, je ne dispose pas d'un oscilloscope.

Je ne comprends pas pourquoi le récepteur envoie tout ce binz. Je ne pense pas baigner dans un champ d'ondes 433 MHz permanentes !

Une idée ?

bonjour
Le RXB6 est plutôt un bon recepteur 433.920 , ça n'a rien à voir avec les modules recepteurs à superreaction.

la frequence 433.920 est superbruitée (surtout en milieu urbain), rien d'etonnant donc à detecter de l'activité en permanence sur le pin data.

ChPr:
Y a pas une bibliothèque à utiliser, une initialisation à faire, ...

Comme je disais, j'ai testé les exemples de la la biblio rc-switch : rien n'est détecté.

Artouste:
la frequence 433.920 est superbruitée (surtout en milieu urbain)

Je suis en pleine campagne. Et si la chip recevait des trames cohérentes, les exemple de la biblio rc-switch devraient afficher qque chose ? Mais rien.

J'ai lu 200 000 tutos sur le Web, ce chip a l'air de donner satisfaction en général.

biggil:
Comme je disais, j'ai testé les exemples de la la biblio rc-switch : rien n'est détecté.
Je suis en pleine campagne. Et si la chip recevait des trames cohérentes, les exemple de la biblio rc-switch devraient afficher qque chose ? Mais rien.

J'ai lu 200 000 tutos sur le Web, ce chip a l'air de donner satisfaction en général.

tu utilise quoi comme emetteur ?

biggil:
Comme je disais, j'ai testé les exemples de la la biblio rc-switch : rien n'est détecté. ...

Certes, mais dans le sketch figuratif de vos essais, aucune bibliothèque n'est incluse. On peut supposer alors que le récepteur n'est pas dans une bonne configuration.

Par ailleurs, si vous êtes loin de sources à 433 MHz, le CAG du récepteur va mettre le gain au maximum et il est alors logique que vous récoltiez du bruit (comme les vieux postes de radio en recherche entre deux stations). Pour autant, ce bruit n'étant pas en cohérence avec l'horloge baudrate, l'information n'est pas valide.

Autre source potentielle de problème, la trop grande proximité entre le récepteur et l'émetteur. Dans ces conditions, le récepteur est saturé et il n'arrive pas à extraire l'information. Ça m'est arrivé.

Cordialement.
Pierre.

Artouste:
tu utilise quoi comme emetteur ?

Pour l'instant rien du tout. Le récepteur parle sans arrêt tout seul.

Bonjour

tu utilise quoi comme emetteur ?

Pour l’instant rien du tout. Le récepteur parle sans arrêt tout seul.

Comme indiqué par ChPr en l’absence de signal reçu le gain automatique du RXB6 est maximum, le bruit de fond est envoyé au comparateur qui est en sortie du module, d’où le signal aléatoire qui est susceptible d’apparaitre en sortie. (prix à payer pour la haute sensibilité)

Avec ces modules récepteurs 433 MHz économiques (superréaction ou même superhétérodynes) il y a des “1” non désirés qui apparaissent en sortie… plus ou moins selon l’environnement RF, le bruit de l’alimentation, les tolérances de fabrication du module…

A tester :
-as-tu bien câblé toutes les masses du module ?
-peux-tu mettre un condensateur d’environ 100nF entre VCC et GND, broches 5 et 8, sur le récepteur ?

OK, j'ai un peu avancé, j'ai pu enregistrer le signal DATA (avec Audacity !). En plus de le voir, je l'entends en temps réel.
J'ai testé avec :

  • la télécommande de mon portail,
  • le détecteur IR de mouvement qui est l'objet de ce projet.

Effectivement, comme certains l'ont dit, je capte en permanence du bruit, voici 140ms de signal :

Lorsque j'active le détecteur de mouvement, il envoie un train de messages :

Zoom sur un message :

On voit que le signal est nettement plus exploitable dans ce cas.

Il semble donc que j'aie uniquement un problème de soft ? La bibliothèque rc-switch semble incapable d'identifier ça (j'ai regardé le code de cette lib, c'est un peu chaud, il y a 5 types de protocoles reconnus, je ne trouve pas de doc détaillée).
Le détecteur de mouvement est de marque Chacon, il utilise le protocole DIO.
J'ai la doc du contenu de la trame, mais pas de l'encodage-bit.

les copies d'écran ne sont pas passées sur le forum ....

Il ya peut être des variantes de codage chez Chacon
sur ce blog il est question de codage Manchester pour transmettre une trame utile de 32 bits (résultat du codage sur 64 bits car deux bits sont émis pour chaque bit 'utile')

La première traduction, est liée a ce qu’on appelle le “codage de manchester” derrière ce nom étrange se cache un principe tout simple : on vas convertir les 0 en 01 et les 1 en 10.

Image de l'article Wikipedia :

biggil:
OK, j'ai un peu avancé, j'ai pu enregistrer le signal DATA (avec Audacity !). En plus de le voir, je l'entends en temps réel.
J'ai testé avec :

  • la télécommande de mon portail,
  • le détecteur IR de mouvement qui est l'objet de ce projet.

Effectivement, comme certains l'ont dit, je capte en permanence du bruit, voici 140ms de signal :

Lorsque j'active le détecteur de mouvement, il envoie un train de messages :

Zoom sur un message :

On voit que le signal est nettement plus exploitable dans ce cas.

Il semble donc que j'aie uniquement un problème de soft ? La bibliothèque rc-switch semble incapable d'identifier ça (j'ai regardé le code de cette lib, c'est un peu chaud, il y a 5 types de protocoles reconnus, je ne trouve pas de doc détaillée).
Le détecteur de mouvement est de marque Chacon, il utilise le protocole DIO.
J'ai la doc du contenu de la trame, mais pas de l'encodage-bit.

bonjour
je te conseille de regarder du coté de RFLINK
Compte tenu du grand nombre de protocoles supportés c'est prevu d'origine pour tourner sur une mega
mais dans la mesure ou tu connais déjà le protocole , c'est assez simple de la faire "tourner" sur un uno juste avec un ou 2 protocoles , je l'ai fait sans trop de problemes.

Je n'ai pas le portage sous la main avant demain

Bonjour. j'ai réalisé un récepteur avec ce module RXB6. Ses performances sont correctes mais il faut un petit programme pour décoder les trames valides du brouhaha. Comme l'ont dit les précédents intervenants le récepteur ajuste son gain en permanence (temps de réaction environ 2 milisecondes) pour avoir un signal en sortie qui oscille entre niveau haut et niveau bas en permanence. C'est au programme de trier le signal utile.
Le problème est que cela mobilise le cpu en permanence, sinon on risque de ne pas décoder une trame si le processeur fait autre chose pendant la réception de trame. Il existe plusieurs solutions de décodage, en utilisant les interruptions, mais je me garderai bien de donner un quelconque conseil, car je ne suis ni programmeur ni électronicien, simple bidouilleur curieux. :confused:
Montage à base de RXB6

Effectivement, il faut un programme qui mobilise 100% du CPU pour attraper toutes les trames.
Dans mon montage, j'ai une carte Uno qui fait ça - et ne fait que ça. Quand une trame de détection de mouvement est reconnue, la Uno la transmet par USB à un RPI qui réalise le reste du boulot (enregistrer une video d'un caméra de surveillance).

Je n'ai jamais trouvé la documentation de l'encodage-bit utilisé. J'ai étudié les enregistrement que j'ai faits, comparé à ce que font d'autres protocoles, et finalement j'ai pu écrire le programme de reconnaissance des trames.

Une question que je me pose : que se passerait-il si j'avais 2 détecteurs de mouvements ? En supposant qu'il envoient leurs trames en même temps. Que verrait le récepteur ? de la bouillie ?

Bonjour

Oui, de la bouillie = le détecteur ,normalement, considère que la trame reçue est invalide (somme de controle invalide)
Les certains émetteurs envoyant souvent la trame avec redondance , il y a une bonne probabilité de réception ultérieure sans collision