Décodeur de capteur RF Arduino : 5 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:07

Ma maison précédente était équipée d'un système de sécurité préinstallé doté de capteurs de porte, d'un capteur de mouvement et d'un panneau de commande. Tout était câblé à un gros boîtier électronique dans un placard et il y avait des instructions pour câbler un téléphone fixe pour composer automatiquement en cas d'alarme. Lorsque j'ai essayé de jouer avec, j'ai découvert que l'un des capteurs de porte était incomplètement installé et qu'un autre était intermittent en raison d'un alignement incorrect. Voilà pour l'installation professionnelle vantée sur la carte de visite de l'entreprise de sécurité. Ma solution à l'époque était d'acheter quelques caméras de sécurité Internet et une alarme de sécurité sans fil bon marché.

Avance rapide jusqu'à aujourd'hui et cette alarme sans fil se trouve dans une boîte dans mon sous-sol. Après mon acquisition d'un récepteur RF bon marché, j'ai décidé de voir si je pouvais décoder les messages transmis par la variété de capteurs d'alarme et de télécommandes dont je dispose. J'ai pensé que, puisqu'ils travaillaient tous avec le boîtier d'alarme bon marché, ils devaient tous utiliser le même format de message avec juste un identifiant différent. J'ai vite découvert qu'ils ne sont similaires que dans la structure générale des messages. Le projet est donc rapidement passé de trivial à très intéressant.

Étape 1: Modules de capteurs

Comme vous pouvez le voir sur les images ci-dessus, les émetteurs comprennent des capteurs d'ouverture de porte, des détecteurs de mouvement, des télécommandes d'armement et un clavier sans fil utilisé pour programmer le boîtier d'alarme. Il s'avère que deux de ces appareils n'utilisent pas la même longueur de synchronisation ou la même durée de bits. Le seul point commun, autre que la longueur du message, est le format de base des bits. Chaque bit occupe une période de temps fixe, la différence entre un zéro et un un étant le cycle de service des parties haute/basse.

La jolie forme d'onde montrée ci-dessus n'est PAS celle que j'ai reçue pour la première fois. Parce qu'il y a tellement de trafic dans la bande de fréquences 433 MHz, je devais m'assurer d'activer le capteur juste avant de régler l'oscilloscope pour qu'il effectue un seul déclenchement. Heureusement, les capteurs émettent plusieurs copies du message de données lorsqu'ils sont activés et les télécommandes et le clavier continuent d'émettre des messages tant qu'une touche est enfoncée. En utilisant la portée, j'ai pu déterminer la longueur de synchronisation et les durées de bits de données pour chaque élément. Comme mentionné précédemment, les temps de synchronisation sont différents et les temps de bit sont différents, mais les formats de message ont tous une synchronisation de bas niveau suivie de 24 bits de données et d'un bit d'arrêt. C'était suffisant pour que je puisse construire un décodeur générique dans un logiciel sans avoir à coder en dur tous les différents détails pour chaque appareil.

Étape 2: Matériel

J'ai à l'origine construit un décodeur de capteur à l'aide d'un microcontrôleur PIC et d'un langage d'assemblage. J'ai récemment joué avec des variantes d'Arduino, alors j'ai pensé voir si je pouvais le reproduire. Le schéma simple est montré ci-dessus et il y a aussi une photo de mon prototype. Tout ce que j'ai fait, c'est d'utiliser trois cavaliers communs pour aller de l'Arduino Nano à la carte de réception RF. L'alimentation et une seule ligne de données suffisent.

Si vous lisez mon Instructable sur « l'affichage de l'heure et de la météo 3-en-1 », vous verrez que j'utilise un récepteur commun RXB6, 433 MHz. Vous pourrez peut-être faire fonctionner les récepteurs vraiment bon marché à la courte portée nécessaire pour ce projet, mais je recommande toujours d'utiliser un récepteur super-hétérodyne.

Étape 3: Logiciel

Le logiciel convertit les bits reçus en caractères ASCII affichables. Il sort la valeur de la longueur de synchronisation et les longueurs des bits 1 et 0. Parce que je connaissais déjà les longueurs de synchronisation et les formats de bits, j'aurais pu écrire le logiciel spécialement pour eux. Au lieu de cela, j'ai décidé de voir si je pouvais l'écrire pour trier les longueurs de synchronisation et pour déterminer automatiquement les bits de données. Cela devrait faciliter la modification au cas où je voudrais essayer de détecter d'autres formats à un moment donné. Il est important de noter que le logiciel ne sait pas si le premier bit d'un message est un 1 ou un 0. Il suppose que c'est un 1 mais, s'il découvre qu'il aurait dû être un zéro, il inversera le bits dans le message terminé avant de l'envoyer sur le port série.

Les temps de l'impulsion de synchronisation et les bits de données sont déterminés en utilisant l'entrée d'interruption externe INT0 pour déclencher un gestionnaire d'interruption. INT0 peut se déclencher sur les fronts montant, descendant ou les deux, ou sur un niveau bas constant. Le logiciel est interrompu sur les deux fronts et mesure la durée pendant laquelle l'impulsion reste faible. Cela simplifie les choses car le démarrage/la synchronisation du message est une impulsion de bas niveau et les bits peuvent être déterminés en fonction de leur temps de bas niveau.

Le gestionnaire d'interruption détermine d'abord si le compte capturé est suffisamment long pour être une impulsion de démarrage/synchronisation. Les différents appareils que j'ai utilisent des impulsions de synchronisation de 4, 9, 10 et 14 millisecondes. Les instructions de définition pour les valeurs de synchronisation min/max autorisées sont en amont dans le logiciel et sont actuellement définies pour 3 et 16 millisecondes. Les temps de bits varient également entre les capteurs, de sorte que l'algorithme de décodage des bits doit en tenir compte. L'heure du bit du premier bit est enregistrée ainsi que l'heure d'un bit suivant qui présente une différence significative par rapport au premier bit. Une comparaison directe des temps de bits suivants n'est pas possible, c'est pourquoi une définition de « fudge factor » (« Variation ») est utilisée. Le décodage des bits commence en supposant que le premier bit de données est toujours enregistré comme un 1. Cette valeur est enregistrée puis utilisée pour tester les bits suivants. Si un nombre de bits de données ultérieur se trouve dans la fenêtre de variance de la valeur enregistrée, il est également enregistré comme un 1. S'il se trouve en dehors de la fenêtre de variance de la valeur enregistrée, il est enregistré comme un 0 logique. Si le 0 logique le temps de bit est plus court que le premier temps de bit, alors un indicateur est défini pour indiquer au logiciel que les octets doivent être inversés avant de s'afficher. Le seul cas où cet algorithme échoue est lorsque les bits d'un message sont tous des 0. Nous pouvons accepter cette limitation parce que ce genre de message n'a pas de sens.

Les capteurs qui m'intéressent ont tous une longueur de message de 24 bits de données mais le logiciel n'est pas limité à cette longueur. Il existe une mémoire tampon pouvant contenir jusqu'à sept octets (d'autres pourraient être ajoutés) et définit la longueur minimale et maximale du message en octets. Le logiciel est configuré pour collecter les bits, les convertir en octets, les stocker temporairement, puis les sortir au format ASCII via le port série. L'événement qui déclenche la sortie du message est la réception d'une nouvelle impulsion de démarrage/synchronisation.

Étape 4: Enregistrement des données

Le logiciel est configuré pour sortir les données converties en caractères ASCII via la sortie série (TX) de l'Arduino. Lorsque j'ai créé la version PIC, j'avais besoin de m'interfacer avec un programme de terminal sur le PC afin d'afficher les données. L'un des avantages de l'IDE Arduino est qu'il intègre une fonction Serial Monitor. J'ai défini le débit du port série sur 115,2k, puis défini la fenêtre Serial Monitor sur le même débit. La capture d'écran ici montre un affichage typique avec les sorties d'une variété de capteurs que j'ai. Comme vous pouvez le voir, les données ne sont parfois pas parfaites mais vous pouvez facilement déterminer quelle devrait être la valeur réelle de chaque capteur.

Étape 5: Exemple de logiciel de récepteur

J'ai inclus un exemple de liste de logiciels qui montre comment vous pouvez utiliser les informations collectées pour recevoir un ensemble spécifique de codes pour votre application. Cet exemple est configuré pour émuler l'une de mes prises distantes Etekcity. Une commande allume la LED intégrée au Nano (D13) et l'autre commande éteint la LED. Si vous n'avez pas de LED intégrée à votre Arduino, ajoutez la résistance et la LED comme indiqué sur le schéma. Dans une application réelle, cette fonction mettrait sous/hors tension une prise électrique (à l'aide d'un relais ou d'un triac). Les temps de synchronisation, les temps de bit et les octets de données attendus sont tous définis à l'avance pour faciliter la modification. Vous pouvez utiliser n'importe laquelle des lignes de données restantes pour activer/désactiver des éléments, etc. pour votre application spécifique. Il suffit d'ajouter le code de commande applicable définit et de remplacer la logique d'allumage/extinction de la LED en « boucle » pour répondre à vos besoins.