[TUTO] RFXCom du pauvre sur RPI pour prises radio

La section dédiée aux Raspberry Pi (tous modÚles); Comment on l'installe; Comment on ajoute des capteurs; Ce qu'on peut en faire ...

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede cha » 17 FĂ©v 2015, 20:07

Pour recompiler, c'est la commande g++ -o Recepteur Recepteur.cpp -lwiringPi
Remplacer Recepteur par Emetteur pour l'autre binaire. Tiens nous au courant !
cha
Membre Actif
 
Messages: 13
Inscription: 12 Juil 2014, 19:03

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede françois ROLAND » 17 FĂ©v 2015, 22:25

Super
Merci
Je tente ça des que possible
françois ROLAND
Membre Actif
 
Messages: 22
Inscription: 26 AoĂ» 2014, 15:03

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede françois ROLAND » 20 FĂ©v 2015, 08:51

Super

Cela fonctionne maintenant pour la telecommande de ma hote aspirante

En revanche, je crais que le probleme pour les stores RTS de Somfy ne persiste

Le fichier CSV ne contient que des 0

Je ne comprend pas comme ils ont fait leur protocole

Merci pour ces infos
françois ROLAND
Membre Actif
 
Messages: 22
Inscription: 26 AoĂ» 2014, 15:03

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede cha » 20 FĂ©v 2015, 09:23

Nickel ! C'est bon Ă  savoir, donc t'as mis 10ms de sleep ?
Somfy ça semble assez particulier. Je ne connais pas les dĂ©tails, mais RFXCom a dĂ» sortir une seconde rĂ©vision du boitier (celle suffixĂ©e E) pour la compatibilitĂ© Somfy. Peut ĂȘtre que la modulation radio est diffĂ©rence
cha
Membre Actif
 
Messages: 13
Inscription: 12 Juil 2014, 19:03

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede chites » 31 Mar 2015, 19:49

Bonjour,

J'ai achetĂ© le mĂȘme module rĂ©cepteur radio 433Mhz que Zescientist (chez Snootlab) dont la qualitĂ© est apparemment bien meilleure que les modules chinois.

Seulement, je n'ai pas réussi à le faire fonctionner sur mon raspberry pour capter les informations de mes sondes Oregon.

J'y arrive avec un module chinois mais je ne suis pas satisfait de la portée (moins de 10m en intérieur).

Quelqu'un aurait-il une idée du schéma pour connecter correctement ce récepteur au raspberry pour que cela fonctionne ?

Merci par avance.

Arthur
chites
Membre un peu timide !
 
Messages: 1
Inscription: 08 Mar 2012, 21:42

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede rimram31 » 31 AoĂ» 2015, 16:09

Bonjour,

Un nouveau sur le sujet, je ne sais pas si le post est actif ... nous verrons bien.

Je rejoins le club des bidouilleurs du 433, pas hyper calé en électronique, l'info c'est par contre un peu plus mon truc. Mon souci c'est le schéma d'idleman, si mes lectures sont correctes, les gpio du raspberry c'est du 3,3V alors que le schéma lui envoie du 5V (a priori l'alim injectée donc le 5V ici).

Pas convaincu donc ... soit il faut alimenter en 3,3 (peut suffire pour bricoler si on recoit quelque chose) soit il faut rabaisser la sortie data du récepteur non ?
rimram31
Membre un peu timide !
 
Messages: 9
Inscription: 18 Nov 2010, 14:49

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede cha » 31 AoĂ» 2015, 17:25

Je n'ai pas saisi ton problÚme ni de quel schéma tu parles.
Le module 433 veut 5V d'alimentation sur la broche VIN. Les GPIO du Pi sont de 3.3V et il a une PIN d'alim de 5V. Je ne connais pas la tension des broches de données du module 433 (3.3 ou 5 ?) mais ça fonctionne avec les 3.3V des GPIO du Pi
cha
Membre Actif
 
Messages: 13
Inscription: 12 Juil 2014, 19:03

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede rimram31 » 04 Oct 2015, 19:15

Oops, je lis bien tard ta réponse désolé, il faudra que je regarde mon profil pour avoir les notifications mail.

Ma question Ă©tait, si tu alimentes ton circuit rĂ©cepteur en 5V, la sortie data sera en logique 0-5V donc trop Ă©levĂ©e pour ĂȘtre lue par une gpio de pi. Ok, ça marche en 3,3V mais ces circuits sont alors bien moins performants et tu ne portes qu'a quelques dizaines de centimĂštres.

J'ai depuis pas mal avancé et je me suis tourné vers un autre composant, un tranceiver linx technologies assez cher (15 euros je crois HT et j'ai pris chez mouser, fdp trÚs élevés) mais impressionnant en performance et fonctionnant en 3,3V. Tranceiver donc gérant du coup l'antenne pour l'émission/réception sans électronique en plus (il permet en sus de régler la puissance en émission du signal et c'est nécessaire!!!).

Pas trop de soucis en l'etat de temps réel sur le pi (code basé sur le code ninja, RFCSwitch ... -> codé sur interruption) en ignorant les paliers < 100us mais je ne travaille qu'avec des périph qui ont des intervalles supérieurs a 3/400us: oregon, dio ... Je reçois maintenant sans souci tout mes équipements partout dans la maison au travers de tous les murs, y compris étage, mur "extérieur" (j'ai réhabilité un garage en bureau)

Je vais rĂ©flĂ©chir a revoir le code en utilisant la librairie pigpio (http://abyz.co.uk/rpi/pigpio/index.html) qui parait trĂšs performant. Autre Ă©tape sur laquelle je cale actuellement, une intĂ©gration directe domoticz, directe au sens de mĂȘme niveau que les hardware existants.
rimram31
Membre un peu timide !
 
Messages: 9
Inscription: 18 Nov 2010, 14:49

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede Yannoo » 08 Jan 2017, 23:49

[quote = "cha"] J'ai tentĂ© avec de l'infrarouge et ça ne fonctionne pas, mĂȘme en raccourcissant les timings.
L'idĂ©e que j'ai en tĂȘte serait qu'il manque la modulation. C'est cette page qui me fait dire ça : http://www.sbprojects.com/knowledge/ir/sirc.php
Sur du 433 c'est le module qui la fait, mais ici, on est directement sur l'Ă©metteur sans aucune Ă©lectronique faisant la modulation.
Pensez vous que j'ai juste ?"
[/quote]

D'aprÚs ce que je vois sur la page HTML, ce n'est pas vraiment de la modulation mais seulement une succession de pics qui se produisent à 40 KHz, celà durant une durée différente selon qu'il s'agisse d'un 0 ou d'un 1

La fréquence des pics y étant de 40 KHz, le nombre de pics consécutifs est donc de :

40 000 Hz * 0.0006 secondes = 24 pics consécutifs quand c'est un 0

40 000 Hz * 0.0012 secondes = 48 pics consécutifs quand c'est un 1

On pourrait effectuer l'intégration de ces pics par tranches de 600 millisecondes, via qqchose comme un condensateur par exemple

=> La tension aux bornes du condensateur indiquerait alors s'il y a eut des pics ou pas durant les 600 derniĂšres milli-secondes
(si elle est supĂ©rieur Ă  un certain seuil X, c'est qu'il y a eĂ»t pleins de pics durant cette pĂ©riode, sinon elle devrait ĂȘtre trĂšs proche de 0 [si on prend soin de bien vider le condensateur avant de commencer chaque bloc de 600 nanosecondes bien sĂ»r)

En mémorisant l'état haut ou bas pour plusieurs blocs consécutifs de 600 nanosecondes, on devrait pouvoir en déterminer si c'est potentiellement un 0 ou un 1 qui a été émis
(en passant, j'ai [re]découvert le code de Manchester et à réellement comprendre comment il permettait de réduire drastiquement le nombre possible d'erreur de transmission sur un média :) )

* si deux blocs consécutifs ont dépassés le seuil d'intégration X, c'est donc obligatoirement un 1

* si sur des blocs consĂ©cutifs il y en a un qui a dĂ©passĂ© le seuil et l'autre pas, c'est potentiellement un 0 (mais ca peut aussi ĂȘtre la fin d'un 0 ou d'un 1 prĂ©cĂ©dent combinĂ© avec le dĂ©but d'un 0 ou d'un 1 ...)


On peut extrapoler cette idée pour générer des tables de correspondances sur bien plus de 2 blocs consécutifs et qui utilisent un rang d'index à 1 quand la valeur de l'intégration a dépassée un certain seuil X sur ce bloc et à 0 sinon

Avec seulement 2 bits d'indexation :

00 impossible (on ne peut pas avoir 2 blocs vides consécutifs)
01 ??? (ca peut ĂȘtre la fin d'un 0 comme d'un un suivi d'un 0 ou d'un 1)
10 ??? (ça peut ĂȘtre la fin d'un 1 ou le dĂ©but d'un 0)
11 deux blos de pics consécutifs => c'est donc un 1 qui été emis

=> pas terrible comme table, dans la moitĂ© des cas, on ne sait pas trop si c'est de 0 ou de 1 qui ont Ă©tĂ© Ă©mis + il y peut ĂȘtre dĂ©jĂ  la fin du prĂ©cĂ©dent bit Ă©mis ou le dĂ©but du prochain Ă  Ă©mettre :(

Avec 3 bits d'indexation :

000 impossible (on ne peut pas avoir 2 blocs vides consécutifs)
001 impossible (on ne peut pas avoir 2 blocs vides consécutifs)
010 un bloc de pics entouré de blocs vides des 2 cÎtés => c'est donc un 0
011 deux blocs de pics qui se suivent => c'est donc un 1
100 impossible (on ne peut pas avoir 2 blocs vides consécutifs)
101 ???
110 deux blocs de pics qui se suivent => c'est donc un 1
111 impossible (il ne peut y avoir 3 blocs de bits consécutifs car ca finit toujours pas un bloc vide)

=> le cas 101 est problématique car on ne sait pas trop si c'est la fin d'un 0 ou d'un 1 suivie dy début d'un 0 ou d'un 1 :(


Avec 4 bits d'indexation :

0000 : impossible (on ne peut pas avoir au moins 2 blocs vides qui se suivent)
0001 : impossible (2 blocs vides qui se suivent)
0010 : impossible (2 blocs vides qui se suivent)
0011 : impossible (2 blocs vides qui se suivent)
0100 : impossible (2 blocs vides qui se suivent)

0101 : 0 + on décale la clé d'index de 3 bits (+ il y a dû y avoir un pb avant car commence par un 0)
0110 : 1 + on décale la clé d'index de 4 bits (+ il y a dû y avoir un pb avant car commence par un 1)

0111 : impossible (on ne peut avoir 3 blocs de pics qui se suivent)
1000 : impossible (on ne peut pas avoir au moins 2 blocs vides qui se suivent)
1001 : impossible (on ne peut pas avoir 2 blocs vides qui se suivent)

1010 : 0 + on décale la clé d'index de 2 bits
1011 : 1 + on décale la clé d'index de 2 bits (+ le prochain bit émis sera à 1)

1100 : 1 + on décale la clé d'index de 2 bits (+ il y aura un pb au décodage du prochain bit émis car il commencera pas un 0)

1101 : 1 + on décale la clé d'index de 4 bits (+ il y a dû y avoir un pb car le prochain index commencera par un 1)

1110 : impossible (on ne peut avoir plus de 2 blocs de pics qui se suivent)
1111 : impossible (on ne peut avoir plus de 2 blocs de pics qui se suivent)

=> lĂ , on est certain si c'est un 0 ou un 1 qui a Ă©tĂ© emis + on sait dĂ©tecter quand il y eut des problĂȘmes et mĂȘme prĂ©dire de temps en temps la valeur du prochain bit Ă©mis et s'il y aura une erreur lors de son traitement :)

Je pense néammoins que l'on pourrait raisonnablement se contenter d'un table indexée sur 2x3=6 bits qui prendrait en compte toutes les agencements possibles de 2 à 3 salves consécutives, une salve représentant un groupe de 24 pics
=> ça ne devrait pas prendre plus 64 entrées de 4 octets = 256 octets au grand maximum :)
(combien de bits à générer en sortie + 1 octet pour dire si chaque bit qui sera à générer ensortie sera un 0 ou un 1)

On pourrait ensuite encore réduire drastiquement la taille de cette table qui utilise 1 octet entier pour indiquer s'il y aura 2 ou 3 bits qui seront générés + un octet de plus pour chaque bit potentiellement généré afin d'indiquer si le bit associé sera à 0 ou un 1
=> avec un peu de chance, il serait donc peut-ĂȘtre possible de faire tenir cette table dans qqchose comme seulement 64x(1+3) = 256 bits = 32 malheureux octets :)
(de l'autre cĂŽtĂ©, la dĂ©compression de cette table Ă  la volĂ©e prendra obligatoirement du temps de calcul Ă  chaque fois qu'une entrĂ©e devra ĂȘtre utilisĂ©e donc je ne sais pas trop s'il y aura besoin de le faire ou pas ...)
[la taille de la table dĂ©compressĂ©e ne devrait faire que 256 octets => ce n'est donc peut ĂȘtre pas la peine de perdre un prĂ©cieux temps Ă  "dĂ©compresser" systĂ©matiquement chacune de ces entrĂ©es en temps rĂ©el pour ne finalement pouvoir n'y gagner en sortie que 256 malheureux octets au grand maximum ...]


Je fais encore un peu mumuse avec le rf433, que je n'ai réellement découvert que la semaine derniÚre et à ne bien faire fonctionner qh'hier sur mon Pi3 avec un récepteur XY-MK-5V et un émetteur FS1000A, et pense ne commencer à réellement m'occuper de la gestion de l'infrarouge que d'ici une à deux semaines, soit vers le millieu ou la fin de ce mois de janvier si tout se passe pas trop mal

PS : ça marche nickel quand le XY-MK-5V et le FS1000A sont tout deux alimentĂ©s en 3.3V par un petit module d'alimention 3.3V indĂ©pendant sur la bredboard mais pas quand ce mĂȘme module sort du 5V ou que c'est le Pi qui fournit l'alimentation 3.3V et/ou 5V
(je pense avoir essayĂ© toutes les combinaisons possibles en 3.3V et/ou 5V et c'est la seule combinaison qui semble rĂ©ellement fonctionnelle => une alimentation 3.3V indĂ©pendante de celle du Pi3 pour alimenter les Ă©mĂ©tteurs /rĂ©cepteur RF433 [j'ai mĂȘme sĂ©parĂ© l'emetteur du recepteur en les mettant chacun sur une bredboard spĂ©cifique pour chacun d'eux => ça me permet d'avoir des blocs totalement indĂ©pendants que je peux facilement ajouter/supprimer/modifier/tester indĂ©pendement les uns des autres => c'est peut-ĂȘtre un peu/beaucoup du luxe mais c'est vraiment hyper pratique :) )
Yannoo
Membre un peu timide !
 
Messages: 2
Inscription: 08 Jan 2017, 13:25

Re: [TUTO] RFXCom du pauvre sur RPI pour prises radio

Messagede Yannoo » 13 Jan 2017, 04:45

Je viens de faire un petit programme permettant de rechercher automatiquement les bonnes valeurs pour la resistance et le condensateur qui permettent d'obtenir un circuit RC ayant une constante de temps la plus proche de celle recherchĂ© (x5 pour ĂȘtre certain que le condensateur est bien totalement chargĂ© ou dĂ©chargĂ©) avec un nombre limitĂ© de valeurs de rĂ©sistances et de condensateurs.

Code: Tout sélectionner
#include <stdlib.h>
#include <stdio.h>
#include <math.h>


double resistances[10];
double condensateurs[4];


void Init()
{
   resistances[0] = 10;
   resistances[1] = 100;
   resistances[2] = 220;
   resistances[3] = 330;
   resistances[4] = 1000;
   resistances[5] = 2000;
   resistances[6] = 10000;
   resistances[7] = 100000;
   resistances[8] = 512000;
   resistances[9] = 1000000;

   condensateurs[0] = 10  * pow(10, -6);
   condensateurs[1] = 100 * pow(104, -6);
   condensateurs[2] = 22  * pow(10, -12);
   condensateurs[3] = 104 * pow(10, -12);
}

int main( int argc, char **argv )
{
   int    r, c;
   double    search, rc, best, diff, dist = 1000000;
   int   nr, nc, ir, ic;

   search = atof( argv[1] ) ;   

   Init();

   nr = sizeof(resistances) / sizeof(double);
   nc = sizeof(condensateurs) / sizeof(double);

   printf("\t\t");
   for( r = 0 ; r < nr ; r++ )
   {
      printf("%.0f\t\t", resistances[r]);
   }
   printf("\n");

   // printf("\t\t");
   for ( c = 0 ; c < nc ; c++ )
   {
      printf("%2.2g\t\t", condensateurs[c]);
      for ( r = 0 ; r < nr ; r++)
      {
         rc = resistances[r] * condensateurs[c] * 5.0f;
         diff = (double)(rc) - (double)(search);
         
         printf("%2.2g\t\t", rc );      
         // printf("%2.2g\t\t", diff );
         // printf("%3.3f%%\t\t", (100.0f * dist) / search);

         if ( fabs( diff ) < fabs( dist) )
         {   
            ic = c;
            ir = r;
            best = rc;
            dist = diff;
         }   
      }
      printf("\n");
   }
   
   printf("\na resistance of %.0f Ohms with a condensator of %2.2g Farads (best=%2.2g search=%2.2g diff=%2.2g) [%3.3f%%] \n",
      resistances[ir], condensateurs[ic], best, search, dist, (100.0f * dist) / search  );      
   
   return 0;
}


Avec un cycle de chargement de 24 pics à 40 000 Hz, soit 0.006 secondes, ça me donne ça :
Code: Tout sélectionner
yannoo@Aerocool ~/Dev/Resistance $ ./rc 0.0006
      10      100      220      330      1000      2000      10000      100000      512000      1000000      
1e-05      0.0005      0.005      0.011      0.016      0.05      0.1      0.5       5      26      50      
7.9e-11      4e-09      4e-08      8.7e-08      1.3e-07      4e-07      7.9e-07      4e-06      4e-05      0.0002      0.0004      
2.2e-11      1.1e-09      1.1e-08      2.4e-08      3.6e-08      1.1e-07      2.2e-07      1.1e-06      1.1e-05      5.6e-05      0.00011      
1e-10      5.2e-09      5.2e-08      1.1e-07      1.7e-07      5.2e-07      1e-06      5.2e-06      5.2e-05      0.00027      0.00052      

a resistance of 1000000 Ohms with a condensator of 1e-10 Farads (best=0.00052 search=0.0006 diff=-8e-05) [-13.333%]


=> une resistance de 1 méga-ohm et un condensateur de 10 micro-farads correspondent-ils bien à des valeurs réalistes pour effectuer un "filtrage/seuillage" des pics générés en générant une tension maximale lorsque la trame analysée durant une période de 0.0006 secondes contient environ 24 pics et environ 0V lorsqu'aucun pics n'y a été généré ?
(le condensateur est bien sûr déchargé entre chaque cycle de 0.0006 secondes)
[en fait, je pense qu'il faudra 2 cicuits RC pour que l'un puisse se décharger pendant que l'autre se charge durant une période 0.0006 secondes, chacun s'occupant à tour de rÎle de l'intégration des pics sur 0.0006 secondes pendant que l'autre se "repose"/décharge pour pouvoir à son tour le faire au cycle suivant et vice-versa pour le cycle suivant]

PS : j'ai pris un peu d'avance sur mon "chrono" concernant la gestion hardware de l'infrarouge :)

PS2 : mais je reviens trÚs bientÎt sur le RF433 car je voudrais pouvoir y passer différents type de messages "à ma guise" afin de pouvoir décoder différents types d'infos que m'enverront des Arduino munis de capteurs de présence/lumiÚre/température/pression qui je situerait à divers endroits afin de pouvoir couvrir plusieurs salles en //

PS3 : je ne pense pas avoir rĂ©ellement perdu du temps avec l'infrarouge (la libraire LIRC doit par exemple dĂ©jĂ  le gĂ©rer trĂšs bien), mais si ça pourrait aussi servir afin de dĂ©coder le signal rf433 en un signal binaire "propre" en amont du Pi, ce qui permettrait au Pi de n'avoir Ă  faire l'Ă©chantillonnage qu'Ă  des frĂ©quences bien plus faibles et de ne plus ĂȘtre obligĂ© de passer le noyau en mode temps-rĂ©el pour y effectuer un Ă©chantillonnage toutes les 100 micro-secondes comme c'est actuellement le cas)
Yannoo
Membre un peu timide !
 
Messages: 2
Inscription: 08 Jan 2017, 13:25

Précédente

Retourner vers Raspberry Pi

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité

Copyright © 2011 - Touteladomotique.com - Tous droits rĂ©servĂ©s
Les blogs partenaires : Abavala, Domo-Blog, Domotique34, Maison et Domotique