enregistrement et comparaison d'une (longuuuuue) variable

International Français
1

Bonjour à tous !

En cours de développement d'un système d'alarme, j'aimerai récupérer le signal 433 MHz provenant de détecteur d'ouverture de porte et de fenêtre.

J'ai essayé différentes libraries comme RCSwitch, mais le codage de mes détecteurs n'est pas supporté (fournisseur : meian/atlantic security).

Le seul code capable de me donner une réponse unique pour chaque signal reçu provient de l'exemple de la library RFControl.h.

La partie du code qui m'intéresse est la suivante :

Serial.print("\nt: ");
    for(int i=0; i < timings_size; i++) {
      Serial.write('0' + timings[i]);
    }

et cela me renvoit une info :

t: 01001101001011001010101100110100110101001011001100110010101011001010110102

Voilà ma question :

comment stocker et puis comparer ce signal avec une table des signaux connus, pour, par exemple me dire : t: 01001101001011001010101100110100110101001011001100110010101011001010110102 = signal du détecteur de la porte d'entrée.

J'ai essayé de stocker cette info, mais sans grand succès pour l'instant... si qq'un a qqpistes pour m'orienter, je suis preneur.

Merci d'avance.

2

Vous avez la possibilité (ce n'est pas beau, mais si ça tient... soit en RAM, soit dans la flash) de stocker pas mal de chaînes de caractères dans la flesh. Il ne serait pas absurde que vous indiquiez quelle est la longueur maximale des codes / séquences de bits que vous souhaitez stocker.... ainsi que leur nombre. (ce qui peut permettre d'éviter des pistes loufoques ou compliquées)

3

En même temps, une chaîne composée quasi exclusivement de 0 et de 1 on sent confusément qu'on doit pouvoir la compacter très facilement sous forme de nombres. Et obtenir par exemple 10 octets et un 2
En regroupant les 0 et les 1 (je mets de coté le 2)

0 10011010 01011001 01010110 01101001 10101001 01100110 01100101 01011001 01011010
0    9A       59       56       69       A9       66       65       59       5A

Il faudrait aussi récupérer le code de tous les capteurs pour voir s'ils sont tous de la même forme et aussi s'assurer qu'il n'y a pas une partie fixe suivi d'une partie variable ce qui est souvent le cas. Cela permettrait aussi de réduire le stockage.

4

Je suis d'accord sur le fait qu'une chaîne de taille fixe (ou ayant un nombre limité de possibilités de tailles) composée de "0" et "1" prend plus de place que sa représentation binaire... mais "si ça tient" sans trop d'efforts , pourquoi ne pas s'en contenter et exploiter les possibilités de la libc -str(n)cmp est populaire- (et si "ça ne tient pas", au vu des évolutions futures, il ne faut pas hésiter à remettre en cause ce choix, ou, mieux, décrire assez précisément quel sera le nombre maximum et la taille des chaînes / séquences de bits à gérer)

et aussi s'assurer qu'il n'y a pas une partie fixe suivi d'une partie variable ce qui est souvent le cas.

vous pensez que les capteurs émettent une séquence de la forme:
{ préambule commun } { partie spécifique } {fin de séquence commune, éventuellement vide} ?

5

Oui pourquoi pas.

Et inversement, faire plusieurs acquisition d'un même capteur au cas où il y aurait des codes tournants.

6

Bonsoir à tous !

merci pour tous vos conseils, c'est très sympa de votre part !

j'ai vérifié en activant d'autres détecteurs, et plusieurs fois, le code est toujours le même, ce qui simplifie les choses, par contre, la "racine" est différente, on n'a pas de partie fixe suivie d'une partie variable.

l'idée de fdufnews est très séduisante :

fdufnews:
En même temps, une chaîne composée quasi exclusivement de 0 et de 1 on sent confusément qu'on doit pouvoir la compacter très facilement sous forme de nombres. Et obtenir par exemple 10 octets et un 2
En regroupant les 0 et les 1 (je mets de coté le 2)

0 10011010 01011001 01010110 01101001 10101001 01100110 01100101 01011001 01011010

0    9A      59      56      69      A9      66      65      59      5A




Il faudrait aussi récupérer le code de tous les capteurs pour voir s'ils sont tous de la même forme et aussi s'assurer qu'il n'y a pas une partie fixe suivi d'une partie variable ce qui est souvent le cas. Cela permettrait aussi de réduire le stockage.

cela permet de limiter la taille de l'information stockée.

Par contre, auriez-vous des idées sur le traitement "on-line" pour produire ce type de réponse ?

7

Un 0 en ASCII vaut 48. Donc si tu as un char qui contient un 0,tu fais
byte x = leChar - 48;oubyte x = leChar - '0';
Et x contiendra 0 ou 1 selon le contenu du char.

8

Si vous voulez remplir des séquences de bits dans un uint8_t, (uint8_t mot il vous faut garder en memoire la place où on veut les mettre (uint8_t place) , et
disposer d'une table de puissances de deux (uint8_t tabP2[] ={1,2,4,8,16,32,64,128}; )
Lors de l'arrivée d'un nouveau bit, il faut:
si le bit est à 1, rajouter tabP2[place] à mot;
dans tous les cas : incrementer place; si place atteint 8, le remettre à zero et passer au mot suivant.... si on peut.

C'est pour ça que (c'est la même chose pour les chaînes de caractères, légèrement plus simples à gérer) je pense qu'il est fort utile de connaitre la longueur maximale de vos séquences de bits.

9

On a pas besoin d'une table de puissance. On peut faire par décalage, addition successive.

variable = 0
début de boucle
   variable << 1
   si valeur entrante = '1'
     variable +1
reboucler

On répète cette boucle autant de fois que nécessaire pour remplir la variable (8, 16, 32 suivant le type de la variable utilisée)

10

"On a pas besoin d'une table de puissance"
Effectivement; mais le prix à payer pour une table de puissances (8 elements + indice) est faible, sur un arduino (8/2000 ) et est compensé par la simplicité de compréhension. Il en est de même pour l'emploi de décalages, qui remplacent avantageusement les multiplications (et divisions, lors de la restitution/affichage) par 2: ce n'est pas intuitif à comprendre -même et surtout si ça devrait l'être-