Convertisseur radio RS232 sur 433.92 MHz
Convertisseur radio RS232 sur 433.92 MHz
1 Le pourquoi de la radio
2 La technique
2.1 Quelques historiques et les normes
2.2 Les schémas du convertisseur radio-RS232
2.2.1 L'appareil lui-même
2.2.2 Schéma de principe
2.2.3 Schéma du convertisseur radio RS232
2.3 Les différents problèmes
2.3.1 Le banc de tests
2.3.2 Marques de modules hybrides et spécifications
2.3.3 L'attaque normale ou barre
2.3.4 Les bandes passantes
2.3.5 Le baud rate
2.3.6 La compatibilité RS232
2.3.7 La propagation HF et les fréquences
3 Conclusions
Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil. L'accès se fait par l'un des deux liens en tête de colonne de droite ----->
ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé !
Avant-propos
Voilà un article consacré aux transmissions micro-informatiques par radio, car je viens de m'y "frotter" avec quelques problèmes…. Je pense que cela sera utile à ceux qui s'y intéressent. Aussi j'ai débordé un peu sur quelques aspects pratiques généraux, mais qui permettent de mieux comprendre ce qui peut se passer.
Loin de moi l'idée de faire du professorat en ce domaine, car les OM sont plus compétents que moi.
Je m'aperçois aussi que ces articles assez techniques ne remportent pas nécessairement les suffrages d'un grand nombre, mais ils sont cependant utiles, surtout lorsqu'en cours de mise au point on bute sur un problème. Alors peu importe l'audience le sujet aura été débroussaillé !
Voyez également un article plus récent qui donne une version améliorée ainsi qu'en alimentation 5V seulement (Attention la description est au milieu de cet article sur les "radio 3 pour compteur...")
1 Le pourquoi de la radio
Une partie de la réponse se trouve dans mon article sur le datalogger. L'autre raison est que je vais réaliser une nouvelle régulation solaire avec un PIC, et que je me vois mal faire des contorsions près du cumulus et tirer des fils partout pour récupérer mes données d'analyse et de vérification (Une dizaine de mesures).
D'autre part, le PIC de la régulation solaire (16F886 prévu) ne pourra jamais stocker les différentes mesures, ni VÉRIFIER le bon fonctionnement (Non inversion des échanges) lors d'une période d'observation. Il sera donc nécessaire d'avoir toutes les mesures à distance pour tout vérifier, et de préférence par des courbes qui témoigneront réellement d'un fonctionnement correct. L'obtention des données sera donc réalisée par transmission radio. Ces informations permettront de corriger éventuellement le programme du PIC en conséquence.
Cette solution radio est très attractive tant pour la régulation solaire, le datalogger ainsi que pour tout le reste des applications de mesures dont la récupération des données est toujours une petite acrobatie.
C'est avant tout pour ne plus avoir des fils partout, ni avoir des systèmes qui fonctionnent d'une certaine façon puis d'une autre, et peut-être essayer d'homogénéiser la surveillance et la récupération de données de bon nombre d'appareils.
A ce sujet, sur le datalogger, j'avais mis un clavier PC pour la configuration ET un PC connecté par RS232. C'était un peu anachronique et gênant, alors que la RS232 du PC Netbook pouvait très bien configurer en même temps le datalogger et servir ainsi de clavier !
C'était mes débuts sur PIC, et j'avais misé en premier sur la simplicité et l'autonomie, car il devrait y avoir le deuxième maillon radio avec la Base De Stockage…mais pour plus tard !
Cette fois ci avant de me lancer sur la régulation solaire dont les différentes "briques" matérielles sont déjà bien avancées, je me dois de réaliser ce dispositif avant toutes choses, tant pour la saisie des paramètres que pour le suivi énergétique, mais aussi et surtout pour l'expérience radio réelle en 433.92 MHz. Ainsi plus besoin (Peut-être ?) d'être à côté du cumulus en RS232, la radio et le PC de bureau seront là en standard et à distance...
C'est aussi très important que la faisabilité radio soit testée dès maintenant, car la partie matérielle de la régulation solaire pourrait évoluer en cas de problèmes "insurmontables"...Ça ne sera pas le cas fort heureusement !
2 La technique
2.1 Quelques historiques et les normes
L'interface RS232 / V24 est une "norme" très ancienne (1980) qui définit
les transferts de données séries filaires entre les équipements informatiques. L'organisme à l'origine de cette norme était le CCITT dont le siège est à Genève (Comité Consultatif International pour le Téléphone et le Télégraphe), avec son livre jaune et ses différents Avis (Recommandations portant le nom" d'Avis"). Cela a dû évoluer aujourd'hui je pense avec l'ISO.
Cette norme s'appliquait à l'origine sur les vieux télétypes et télex à 50, 75 voire 110 bps, pour lesquels il fallait mettre en marche automatiquement les différents moteurs, temporiser, et toute une "ribambelle" de codes spécifiques pour gérer des transmissions dignes du "fil qui chante".
On a gardé quelques codes très connus comme les "CR et LF" etc…mais il reste le grand principe de la sérialisation des données avec des vitesses qui ont franchi aujourd'hui la barre des 100 ou 250 Kbits. Le principe de base n'a pas changé mais s'est largement simplifié, car on ne"traîne" plus maintenant plus que 3 fils en général :
Fil Commun (souvent la masse),
Rx (Receive data)
TX (Transmit Data).
J'en ai fini avec ce qui ne représente plus grand'chose aujourd'hui dans son étendue complète (avec tous les signaux), mais qui reste un procédé extrêmement répandu et il faut le dire assez simple dans le principe.
Ce procédé a un regain d'intérêt avec les PIC et microcontrôleurs de toutes marques, qui ont tous des possibilités de sérialisation des données suivant ce principe, et auquel il manque seulement les niveaux de ligne RS232, mais les circuits annexes existent et se chargent très facilement de la transformation suivant l'interface RS232. (Ces transmissions se réalisent alors en ASYNCHRONE et en FULL DUPLEX au niveau RS232).
C'est aussi une façon beaucoup plus simple d'acquérir des données externes, que de chercher dans la "jungle" des dispositifs sophistiqués ayant des structures en couches (parfois vides) je pense à l'USB pour lequel des drivers spécifiques sont indispensables,.
En ce sens je trouve ces transmissions séries asynchrones RS232 très utiles, tout autant que le port // des vieux PC…
Si les concepteurs pouvaient parfois rester simples nous y gagnerions beaucoup.
Dans l'esprit seulement, je critique volontiers les choses compliquées pour lesquelles même les spécialistes sont obligés de déposer les armes faute de temps.
Il n'est pas normal que lorsqu'un professionnel se présente chez vous, il soit amené à vous dire "c'est foutu" et que tout est à changer…Il y a un malaise sur le fond à cela, ou alors je ne comprends pas tout ! C'est le siècle, mais cette façon de faire et de penser sera nécessairement condamnée à terme.
Bref,…Ce qui nous intéresse ici est la partie électronique pure et notamment les signaux avec leurs valeurs et leur logique.
Ainsi les caractéristiques RS232 que l'on retrouve à l'interface d'un connecteur DB9 piloté le plus souvent par un MAX232 ou équivalent Low Power, sont définis ainsi par la recommandation Rec V.28 (Fascicle VII.2 Rec S.16 page 30 du livre jaune du CCITT)
Start ON >= +3 Volts
Stop OFF =< -3 Volts
Voir également les signaux et valeurs logiques très bien représentés sur le petit graphique du site de WIKIPEDIA.
Ces éléments sous-entendent que le niveau de repos EN LIGNE est =entrée LOGIQUE à 1 (Au niveau MAX232). Or ce niveau logique est celui qui est donné par les PIC.
On remarquera la très grande ambiguïté entre les "conditions de circuit", les "niveaux logiques", les "tensions" et le "type de signaux" dont le livre jaune fait référence.
On retrouve également le niveau de repos de -12V en sortie de port COM1 sur PC pour le signal TX.
Au niveau des normes, on ne pouvait pas faire quelque chose de plus confus, mais c'est souvent toutes les normes qui sont ainsi, et c'est bien dommage, car je me pose toujours la question de la vérité à un inverseur près, et de plus les textes eux-mêmes sont réellement indigestes de part la terminologie et des références A,B, etc... que l'on arrive parfois à retrouver au prix d'une lecture complète du bouquin, ou jamais !
(Si ça se trouve, je me suis peut-être même trompé !)
Il est donc important de confirmer qu'un PIC (Sortie TX d'un PIC) qui attaque directement un MAX232 serait donc conforme concernant les signaux RS232 (Signaux présents au connecteur DB9).
(On verra par la suite que si l'on passe directement par radio depuis le PIC cela pose un problème).
Tout cet ensemble concerne les transmissions Asynchrones, c'est-à-dire, celles qui n'ont pas d'horloge d'accompagnement pour échantillonner les données.
(Sur ce point, aujourd'hui, les transmissions Synchrones BSC2780, VIP, (sauf HDLC)…suivant RS232/V24 n'existent pratiquement plus et nécessitent obligatoirement des connecteurs DB24 pour faire transiter les signaux d'horloge émission et réception. Internet et FTP ont supplanté ces procédures un peu anciennes).
Le seul procédé de "synchronisation bit" en Asynchrone est un bit START, une vitesse prédéterminée, et un (Ou plusieurs) bits de STOP qui termine chaque caractère.
Ce principe oblige à avoir une période d'horloge assez stable et précise entre chaque bit transmis (ou reçu). On verra que cela n'est pas toujours le cas et qu'avec tous les aléas de transmission et de décodification/détection/mise en forme, il faut rester très prudent.
Enfin le dernier point concerne le nombre de bits par caractère et les codes. Cela peut aller de 5 à 9 bits (y compris la parité). Concernant les codes utilisés, cela n'est pas définit par le CCITT et tout est possible, mais le plus habituel est de traiter en ASCII ou en binaire pur. Le code EBCDIC est de moins en moins utilisé (code d'origine IBM).
(On remarquera d'une façon générale, qu'un nombre restreint de bits peut être une façon détournée d'augmenter la vitesse de transmission (pas avec les PIC), surtout lorsque l'on a que des données numériques à transférer). Ainsi pour une transfert à 1200 bps et caractères de 8 bits cela donne environ 120 caractère secondes, mais à seulement 5 bits cela donnerait environ 171 caractères par secondes…)
Malheureusement le nombre de bits par caractère n'est toujours paramétrable (Cas des PIC 16F628 16F886 par exemple, car ce sera 8 ou 9 bits sans autres possibilités)
2.2 Les schémas du convertisseur radio-RS232
2.2.1 Le montage lui-même
Ce montage est capable d'émettre et de recevoir des données par radio sur la fréquence de 433.92 MHz. Ce montage utilise des petits circuits hybrides pour les parties émission et réception.
Il reçoit les données issues de la radio et les transmet vers une interface RS232 (En liaison avec un PC le plus habituellement).
A l'inverse, les données issues du PC à destination d'équipements éloignés sont transmises par RS232 depuis le PC, puis envoyées par radio à l'équipement distant.
On notera que dans un sens comme dans l'autre il n'y a pas de reprise de synchronisation ou de mise en forme quelconque, car c'est une interface totalement transparente pour les données.
Pour éviter toute confusion ultérieure sur la terminologie entre émetteur, récepteur et le montage lui-même, nous appellerons ce MONTAGE, un CONVERTISSEUR radio –RS232.
L'application de l'instant est de recevoir sur PC par le logiciel "terminal BRAY++", les données en provenance du datalogger.
En complément et bien que cela ne soit pas implémenté encore, le montage doit aussi permettre de paramétrer par radio et RS232 d'autres appareils distants. On utilise dans ce cas la fonction émission du convertisseur.
A terme, il serait possible de traiter plusieurs réceptions et de les différentier par le code adresse en tête de chacune des trames. A cette fin un programme en PASCAL sur port COM pourrait se charger de ces opérations. Cela posera aussi le problème de l'émission de porteuses multiples et du tri des données.
Le convertisseur est nécessairement Half duplex, car il ne peut pas recevoir et émettre en même temps sur une même fréquence. C'est un petit handicap connu dès la conception du montage, que je qualifierai de non gênant dans mon contexte. Ce serait peut-être plus discutable en industriel, et pour palier ce problème il faudrait doubler émetteurs et récepteurs avec des fréquences différentes, ce que je ne ferai pas !
La détection automatique de baud rate qui existe sur certains PIC 16F sera possible, car ce convertisseur est "transparent" au niveau des données. De même, les transmissions en binaire pur seront également possibles par l'utilisation de RTS/CTS.
2.2.2 Schéma de principe
L
e schéma de principe ne pose pas de difficultés mais doit être bien appréhendé pour savoir ce que l'on reçoit (d'où) et la destination des éventuelles émissions.
Dans ce genre d'application on arrive très vite à ne plus très bien se rappeler qui émet ou reçoit (Tant au niveau RS232 ou qu'en radio) !
On remarquera simplement que les signaux RTS (et CTS) sont nécessaires pour éviter de polluer par porteuse émission, la réception.
En effet le signal RTS assure la mise sous tension immédiate de l'émetteur. A l'issue d'un petit délai, le montage renvoie le signal CTS pour indiquer au PC que tout est prêt !
(Ce signal ne sera recherché que dans les drivers qui ont besoin de signaux de handshake pour fonctionner. Bray++ n'en a pas besoin)
J'ai fait quelques essais de réception avec la porteuse émission permanente, et je dois dire que ce n'est pas si mauvais que cela…Est-ce normal ? Ou le fait d'une caractéristique de la modulation ? Je ne saurais le dire, mais ce que je peux dire avec certitude, est qu'il est hautement préférable de couper l'alimentation de l'émetteur lors d'une réception !
2.2.3 Schéma du convertisseur radio RS232
Le schéma est lui aussi est très s
imple, mais nécessite une petite explication concernant la partie émission. Il est important de "ne pas se marcher dessus". Ce terme cher aux OM (radio amateurs) indique simplement que l'on ne peut pas émettre de plusieurs endroits sur une même fréquence sans interférences en réception et qui plus est dans ce cas, on ne peut pas à la fois recevoir et maintenir une porteuse identique en émission.
Il faut donc couper la partie émission lorsqu'elle n'est pas utilisée.
Il n'y a pas d'entrée logique sur les émetteurs pour assurer cette fonction, aussi il faut donc couper l'alimentation. C'est ce qui est fait par les deux transistors qui alimentent le circuit RT2 (ou RT4).
Le signal de commande de l'alim est donné par un signal RTS (Request To Send ou DPE) émis par le PC qui veut envoyer des données.
Le convertisseur renvoie alors le signal CTS (Clear To Send ou PAE) avec un petit retard qui est nécessaire pour que les tensions aient le temps de s'établir au niveau de l'émetteur, et de le rendre "opérationnel".
(A réception du CTS le PC peut alors envoyer les datas. (Ce signal peut ne pas être nécessaire, mais ayant les portes inutilisées sur le MAX232, autant se rendre utile !!!)
J'ai fait quelques essais de réception avec la porteuse permanente, et je dois dire que ce n'est pas si mauvais que cela…Est-ce normal ? Ou le fait d'une caractéristique de la modulation ? Je ne saurais le dire, mais ce que je peux dire avec certitude, est qu'il est préférable de couper l'alimentation de l'émetteur lors d'une réception !
Si vous n'avez pas la possibilité de gérer les signaux RTS/CTS, vous pourrez modifier le schéma en lançant un monostable sur les premier datas reçus depuis le PC. A cette fin ce pourrait être des caractères NUL (0 binaire) ou le caractère "U" de recherche de baud rate. Vous pourriez aussi utiliser les codes XON et XOFF mais je ne suis pas spécialiste de ces procédures.
(Pour ma part et avant d'avoir lu les docs des PIC les plus récents, j'avais choisi une séquence SYN,STX,ADR sur le datalogger, qui peut remplir la mission de lancement de l'alim de l'émetteur. (Pas la détection du baud rate automatique) Le remplacement de SYN ou STX par "U" pourrait très bien palier (à) ce problème.
Un strap a été mis pour invalider ou non la réception lors des transmissions du PC vers l'émetteur. Dans le mode standard il y a réception de la totalité des données transitant tant en émission qu'en réception par le biais de la radio (Pas par la logique). Toute chaîne de caractère envoyée par le PC est alors affichée à l'écran (Si il y a réception en même temps, alors c'est "le plus fort qui gagne" !)
Le convertisseur présenté ici a des possibilités de réception à 4800 bps mais seulement de 2400 bps en émission à cause de l'utilisation d'un émetteur "minature" RT2. Si vous voulez absolument émettre à 4800 bps, il faut alors choisir un autre émetteur tel que le RT6 (comme sur le datalogger)
(Ce point n'est pas gênant à mon avis dans l'optique de la philosophie retenue, car le paramétrage d'un appareil se réalise habituellement au clavier ou par switchs… !)
Dans le cas contraire et avec une automatisation des échanges, il faudra se rabattre sur la vitesse inférieure commune.
2.3 Les différents problèmes
Tout ne s'est pas très bien passé lors de ces essais et il m'a fallut de nombreuses tentatives avec plusieurs retours à la situation d'origine pour seulement essayer de comprendre ce qui se passait vraiment (Et je n'en suis pas encore absolument certain).
Il faut aussi confirmer que ma source de données était issue du datalogger, et que j'ai réussi à force de le démonter à le mettre en panne intermittente ! Bref tout est rentré dans l'ordre maintenant, car il y avait de nombreux problèmes conjugués pour faire en sorte que cela devienne assez incompréhensible. (Une panne intermittente de chargeur de batterie entre autres !...)
2.3.1 Le banc de tests
- Le synoptiq
ue est nécessaire pour comprendre comment les essais ont été réalisés.
(ATTENTION Le circuit a été réalisé pour un câble "droit" et non croisé. Ces câbles sont beaucoup plus répandus et cela simplifie la connectique dans ce cas).
Ce schéma reste simple. Initialement, le PIC délivrait donc son signal logique TX en logique négative directement sur le MAX232 mais AUSSI sur le RT6 Telecontrolli. Cette partie émission n'est donc pas attachée à une interface RS232, (Sauf pour vérification du bon fonctionnement en direct du datalogger avec le PC par RS232)
- La configuration du PIC
J'ai du reprendre le programme du PIC qui fonctionnait pourtant parfaitement en RS232 à 115200 bps, pour une question de niveaux.
En effet les trames ASCII de sortie sont multiples pour un seul groupe de mesures, par le fait que la taille du buffer de transmission ne peut pas être étendue.
J'avais alors fermé le port de transmissions avec SPEN entre chaque appel. Cela avait pour conséquence de faire redescendre à 0 le signal de sortie (normalement à 1) en l'absence de datas.
Cette situation n'était pas normale et je l'ai corrigée, car je crois qu'elle me posait des problèmes notamment avec des mauvaises synchronisations sur bit start.
(Je ne suis pas cependant catégorique sur ce point)
Enfin, après bien des hésitations, le signal d'attaque de l'émetteur radio du datalogger a dû être inversé, et une toute petite modif a permis de ne rien casser dans le datalogger (Voir § 2.3.3).
2.3.2 Marques de modules hybrides et spécifications
Il y a un an, j'avais commandé des modules Télécontrolli RR3 à Clermont Ferrand mais j'ai été livré en Velleman RX433N. Je n'étais pas très content car cela me posait des problèmes pour un circuit déjà réalisé et des problèmes d'homogénéité de matériel.
Je n'ai pas voulu faire d'histoires, mais je regrette, car ce qui suit en témoignera.
En effet ces modules ayant de plus un réglage avec noyau ne fonctionnent pas bien et de plus ne sont pas du tout pins compatibles. J'ai donc été obligé de "bidouiller" le circuit imprimé pour adapter mon module hybride RR3 de secours.
Sur le modèle Velleman, j'ai eu beau "titiller" la self pour trouver une plage fonctionnelle à seulement 1200 bps, mais je n'ai pas pu y arriver.
A décharge que la partie émission du datalogger avait peut-être des problèmes à cet instant et que l'inversion du signal de l'émetteur RT6 n'était pas faite….
Mais cela n'empêche pas qu'entre un circuit époxy CMS avec deux selfs bobinées et un circuit céramique "trimé" au laser, sans self (apparente), le choix de qualité est vite décidé !
Dans les spécifications Velleman, je lis "data rate" 4800 bps mais je vois aussi "Base board data rate" 3 KB/S. je ne sais pas si j'ai manqué "un épisode" ? Mais pour "noyer le poisson" c'est pas mal. (S'agit-il de bande de base ? pas très clair !)
Je vais aussi "rhabiller" Télécontrolli car ses notices indiquent des valeurs différentes. C'est tout de même très gênant de trouver des rapports 2 dans les specs de "data rate" ou KHz..
Aucun des fabricants ne spécifie clairement qu'il s'agit de super-réaction, mais même si on le suppose, il faut tout de même le dire, c'est une question d'honnêteté.
Seul Velleman précise le mode de modulation ASK. Télécontrolli ne dit rien du tout ! Ce point important d'une transmission nécessite d'être précisé surtout si plusieurs matériels de marques différentes sont appelés à dialoguer entre eux.
On doit donc rester très prudent sur le mixage de marques différentes sur des couples émission et réception. On ne peut que raisonnablement supposer que la modulation la plus simple ASK sera utilisée pour les petits matériels, mais rien n'est dit sur le sujet, alors Prudence !. Sur cette modulation, les spécifications de pourcentage de modulation des 1 et 0 doit être très important pour assurer la compatibilité….
Sur les émetteurs RT6 Télécontrolli, j'ai préféré utiliser des tensions plus élevées que le 5 Volts habituel pour gagner un peu en portée/puissance, mais vous pouvez rester à 5 V si une alim complémentaire pose problème.
Toujours sur RT6 Télécontrolli, Les entrées IN1 et IN2 ne sont pas très bien expliquées dans leur nécessité, car dans certaines configurations d'alimentations, on ne sait pas quoi choisir, notamment à une tension de 8 Volts où il semble que l'on puisse utiliser l'une ou l'autre !
Ce sera exactement la même chose pour une tension d'alimentation de 5 Volts où on pourra choisir aussi bien IN1 ou IN2 !
J'ai donc mesuré à l'ohmmètre la résistance sur chaque entrée et voici les résultats.
IN1 ---> 21.4 K
IN2 ---> 26.4 K
Ceci étant fait je ne trouve pas de relation directe de causalité entre la tension Vcc et les valeurs de résistances, car ce serait pratiquement l'inverse ! Tant pis je supposais seulement que les résistances les plus élevées seraient pour les tensions les plus élevées. On ne peut pas rivaliser avec le concepteur !
On notera seulement qu'il n'est pas question d'alimenter les entrées IN1 ou IN2 avec des tensions supérieures à 5Volts.
Un gros reproche aux constructeurs de petits modules qui est de prendre les utilisateurs pour des imbéciles.
En effet, quand on voit les NOTICES techniques des constructeurs de ces petits modules (Pas toutes identiques de plus), c'est réellement se moquer des utilisateurs. Ces notices (Quand elles existent : RT2 par exemple aucune notice) ne méritent pas de s'appeler des datasheet.
Pas de type de modulation ni de schéma d'application pour Télécontrolli. Pas d'indication, ou plus exactement un réglage de noyau pour Velleman, alors qu'il est dit dans la notice qu'il n'y a aucun réglage !
2.3.3 L'attaque normale ou barre
Ainsi qu'il a déjà été évoqué, la partie émiss
ion du datalogger prenait les signaux directement depuis la sortieTX du PIC (Ou l'entrée MAX232).
Malheureusement ce procédé qui est parfait en liaison directe RS232, ne fonctionne pas bien du tout en radio.
J'ai donc du assurer une inversion complémentaire pour retrouver le signal série en logique positive. N'ayant pas d'inverseur disponible, j'ai converti la tension RS232 +12-12V (Qui est inversée) en signal 0/5V
On le voit dans le schéma électrique du Convertisseur, il y a un seul NAND utilisé, mais le circuit d'origine comportait un 74HC04 en plus qui n'a plus lieu d'être. Le schéma a donc été simplifié, et vous devrez reprendre le design en conséquence.
Cette configuration fonctionne correctement jusqu'à 4800 bps (Avec RT6) et 2400 bps (Avec RT2). Ceci implique pourtant que l'émission RT6 du datalogger soit réalisée avec le niveau logique en sortie de MAX232 (Converti en logique TTL/CMOS)
Il semble que l'inversion logique en entrée de RT6 ait une importance capitale dans la transmission. Je ne suis plus certain à cet instant de ne pas m'être fait piègé par les autres pannes. J'ai donc refait des essais arrières, mais la situation semblait confirmée, ceci voulant dire que les émetteurs doivent être configurés en logique positive ! (A vous de me dire si ce que j'avance est bien réel ou non).
Je propose tout de même une hypothèse au mauvais fonctionnement lorsque l'on attaque le petit émetteur RT6 par le signal barre en sortie directe du PIC (côté de la logique TTL/CMOS).
En modulation d'amplitude, il semble "logique" que le 1 logique soit "matérialisé" par une modulation de niveau élevé. Le 0 logique étant à un niveau de modulation faible (voire nul suivant les valeurs de pourcentage de modulation ?).
En cas de réception faible ou perturbée, la modulation nulle ou l'absence de signal seraient équivalents à un 0 logique. Ceci étant, il me semblerait normal que l'on trouve de très nombreux 0 BINAIRES qui font le lien avec les datas "à peu près intelligibles" dans le cas de modulation barre.
Rappelez vous que j'ai du aussi remettre le signal SPEN à 1 même en l'absence d'émission. C'est une hypothèse qui me parait plausible. Est-ce la réalité ?
(Pour ma part j'arrête là les investigations car cette fois tout fonctionne suivant ce que j'ai fait et dit).
J'ai donc réalisé la petite modification d'inversion de la modulation avec une résistance et une diode zener sur le datalogger. J'y ai ajouté en // une diode germanium par sécurité pour éviter de descendre trop bas en tension négative sur le petit module émetteur (0.3V au lieu de 0.7V). Le signal modulé est donc en logique positive.
La modification logique a aussi été faite sur le Convertisseur en supprimant une porte d'inversion.
2.3.4 Les bandes passantes
L'augmentation de la rapidité de transmission radio augmente également la largeur des bandes latérales engendrées par la modulation. Disons pour simplifier que la porteuse se décale d'autant plus de chaque côté de sa valeur initiale et que ce déport latéral est limité (Règles légales d'émission de façon à ne pas perturber les canaux adjacents et contenir ainsi une émission entre deux valeurs maximum de fréquences. C'est la largeur d'un canal).
Mais il faut aussi prendre conscience que plus on monte en rapidité plus cela devient difficile à gérer sans dépasser les bandes latérales autorisées, aussi en "petites transmissions radio" on ne dépassera que rarement les 9600 bps.
La pente des signaux de modulation détermine également les "bavures" parfois importantes sur les bandes latérales, aussi il ne faut pas se formaliser si on voit des largeurs de canaux à 500 KHz et une "maigre transmission" à 2400 bps.
Pour aller plus loin, on est amené à trouver des procédés qui permettent de codifier plusieurs bits pour un état de modulation. C'est là que le Baud intervient !
La vitesse de transmission en bauds est toujours égale ou inférieure à la vitesse en bps … ! voir http://www.infoclick.fr/dico/B/baud.html
Dans le cas de très grandes vitesses il est possible de coder sur la fréquence, l'amplitude et la phase de la porteuse.
(Inutile de dire que c'est compliqué et que ce n'est pas gratuit).
Les constructeurs de modules hybrides Télécontrolli ou Velleman donnent souvent des valeurs assez fantaisistes et quelque peu exotiques, mais ils ne parlent que de bps ou de KHz (Voir ci-avant les dénominations). Je pense qu'ils pourraient faire un effort pour se rapprocher des valeurs standardisées (De "baud rate"). Il n'y a dans ces équipements qu'une modulation simple dans laquelle les bps et les bauds sont identiques (Je le suppose).
Voici les performances vérifiées entre :
RT6 et RR3 : 4800 bps.
RT2 et RR3 : 2400 bps.
Les notices d'un même constructeur donnent des valeurs du simple au double. Allez je préfère me taire car je me répèterais !
Ces performances ont été vérifiées entre deux équipements situés chacun à un étage et séparés par une dalle en béton armé. La distance en ligne directe était d'environ une dizaine de mètres.
"L'avantage" de bandes passantes larges vous permettra aussi de recevoir des parasites insoupçonnés.
(Démarrage d'un brûleur fuel par exemple, lors de la présence de l'arc d'amorçage !)
2.3.5 Le baud rate
Ce sujet des bauds et des bps a déjà été largement défloré, aussi nous oublierons les bauds au profit des bps.
C'est simplement la vitesse d'échantillonnage des bits d'un caractère. Dans les grandes lignes on peut dire que l'on transfère 120 caractères secondes pour une transmission de 8 bits à 1200 bps.
Revenons donc au "baud rate"… Sur PIC le baud rate est en liaison directe et très étroite avec la fréquence d'horloge de cadencement du processeur. Si l'on veut être très précis, il faut donc choisir une fréquence du PIC qui par divisions permet d'atteindre la vitesse précise à laquelle on veut travailler en transmission RS232, et suivant la formule déterminée pour le PIC
Ceci n'est pas anodin et je vous donnerai ci après quelques mesures réalisées grâce au générateur variable du programme terminal de BRAY++.
Il faut donc choisir le quartz horloge du processeur en conséquence… Mais alors pour l'horloge temps réel ? Eh bien je crois qu'à ce niveau il faut savoir choisir entre la pomme ou le fromage !!!
Pour ma part, je pense que l'horloge temps réel doit être entrée à part du fonctionnement du PIC, sur une entrée dédiée (T0CKI comme pour le datalogger par exemple)). Ainsi le PIC peut tourner à une vitesse relativement proche de son maximum. Mais par le biais des divisions, et en modifiant légèrement la fréquence du processeur, on peut avoir des vitesses de transmission parfaites. Ceci est la raison des valeurs "extravagantes" des quartz utilisés, telles que 3.6864 ou 6.912 MHz ou 6.144 MHz etc…
Ces valeurs doivent répondre à la formule de calcul des "baud rate" des PIC.
baud rate= Fosc/((DIV(X+1)) avec DIV représentant 64 ou 16 suivant la valeur du bit BRGH
On a toujours intérêt à travailler au plus près des valeurs standard (300, 600, 1200, 2400, 4800, 9600, 19200…115200), sous peine de ne plus pouvoir dialoguer avec "Pierre" ou "Paul". Noter qu'à cause de la formule des PIC, ce qui est correct à une vitesse peut ne pas l'être au multiple ou sous multiple suivant. Peu de valeurs de la fréquence de base du PIC permettent de traiter toute la lignée de vitesses (Avec des valeurs exactes), y compris avec BRGH high ou low.
(Vous pourrez utiliser la fonction SOLVEUR d'OPEN OFFICE ou EXCEL pour trouver le quartz qui sera à la fois le plus proche de la vitesse maxi du PIC et qui donnera une fréquence de baud rate exacte ou très proche)
On remarquera qu'avec la version V1.9B du programme "terminal de BRAY++", il est possible de faire des essais aux marges du baud rate (custom) et d'obtenir ainsi une certaine sécurité relativement à la fréquence centrale utilisée.
Ce programme gratuit et très bien conçu, permet de faire varier le baud rate avec la précision d'une unité Il est ainsi possible de tester précisément à 1271 bps pour 1200 bps (Par exemple).
Je suis particulièrement satisfait de pouvoir utiliser ce programme freeware extrêmement utile pour debugger les transmissions.
2.3.6 La compatibilité RS232
La transmission radio reste une facilité et il ne faut pas masquer la réalité d'une transmission RS232 qui devra toujours pouvoir fonctionner indépendamment de la radio. La radio n'est qu'un maillon complémentaire dépendant étroitement des données séries qui alimentent la RS232.
Le datalogger fonctionne donc aussi bien en radio qu'en RS232.
Il est vrai que les performances sont très différentes puisque les petits émetteurs récepteurs ne dépassent pas 4800 bps voire 9600 bps pour les plus véloces, alors qu'en liaison directe on peut sans problèmes atteindre 128 kbps voire 256 kbps.
Les niveaux de tensions doivent être supérieurs à +3 V ou inférieurs à -3 V. De façon habituelle ce sera ± 8ou 9V (MAX232).
On notera aussi que les "pseudo RS232" en 0 à 5 V ne sont que des arrangements spécifiques et il faut donc traiter au cas par cas ces liaisons séries spécifiques et qui sont de toutes façons incapables de dialoguer avec les équipements standards.
2.3.7 La propagation HF et les fréquences
La garantie d'une transmission parfaite par radio n'est pas toujours acquise, car il y a des perturbations électromagnétiques de toute nature. A ces fréquences il y a toujours de l'activité et de plus cette fréquence précise de 433.92 MHz est un véritable fourre-tout, aussi dès que "le voisin" ouvrira son portail vous pourrez parfaitement le recevoir !
Vous recevrez aussi la commande de vos volets roulants et ceux des voisins, la télécommande de votre superbe auto et peut être même aussi les trames de votre compteur d'eau s'il est équipé d'une tête radio d'une marque donnée !
(Les volets roulants d'une marque connue sont pourtant calés sur 433.42 MHz, mais ça passe tout de même dans les petits récepteurs. Je n'ai noté par contre aucune commande intempestive sur les volets suite aux émissions du datalogger ! Je n'ai pas vu non plus ma voiture "se sauver" toute seule Ouf !)
Je ne peux que vous engager à prévoir de vous "synchroniser" sur vos données en utilisant des codes d'entête de trame (Déjà évoqués plus avant).
Comme dans toute émission, les antennes ont un rôle essentiel dans la portée d'un émetteur. Pourtant dans l'utilisation telle que prévue, la distance n'est pas un véritable critère, mais pourrait l'être seulement dans quelques cas. La distance maxi (portée) dépend de tout un ensemble de paramètres dont la hauteur de l'antenne d'émission est un point majeur.
Les éléments traversés (Murs en béton, terre, eau, feuilles…etc) sont également des éléments déterminants qui affaiblissent le niveau de réception par absorption partielle du rayonnement électromagnétique.
La proximité des personnes peut largement contribuer à modifier cette transmission, de même que tout objet qui peut assurer une réflexion des ondes ou leur absorption (Voiture, avion, éolienne, feuilles des arbres…etc)
Certaines antennes favorisent la directivité, avec une très forte sensibilité, d'autres au contraire permettent de recevoir ou émettre dans toutes les directions (omnidirectionnelles)… Ce sont des choix pour lesquels je ne me suis pas appesantit, car un simple brin de fil de wrapping de 17 cm a fait l'affaire et donne de bons résultats qui me suffisent.
Je n'ai pas fait de mesures par manque de matériel et de temps, mais je pense qu'un plan de masse assurant l'image inverse de l'élément rayonnant pourrait être bénéfique.
Il est possible d'utiliser tout type d'antenne tel que l'antenne "YAGI" comme en télévision traditionnelle et dans ce cas la portée d'un émetteur sera largement augmentée sans que la puissance n'ait été accrue. Dans de tels cas où l'antenne doit être déportée en hauteur, il est évident qu'il sera souhaitable de placer le convertisseur à proximité immédiate de l'antenne avec un câble coaxial 50 ohms du minimum de longueur. Attention alors aux conditions climatiques de cette électronique qui va souffrir !
Cette portée a aussi un important paramètre qui est la SENSIBILITÉ du récepteur. En ce sens, les récepteurs type super hétérodyne sont de bien meilleurs outils que les récepteurs à super réaction pour la sélectivité.
Pratiquement tous les récepteurs on une très bonne sensibilité de quelques µVolts. (A ajouter qu'une sensibilité extrêmement faible ne sert à rien si les données ne sont plus intelligibles, car noyées dans le bruit)
Il faut dire aussi que ces petits modules hybrides bon marché, sont destinés au "grand public". Les équipements industriels sont effectivement bien mieux conçus et permettent une bien plus grande fiabilité des transmissions.
A nous de compenser ce manque de fiabilité par un contrôle parfait de l'intelligibilité des trames !
Au niveau réception, ainsi que cela a déjà été évoqué (?) il peut être utile, suivant la distance entre émetteur et récepteur de réduire le niveau du signal reçu. Pour cela, j'ai utilisé soit un brin y/4 soit y/8 (Lire lambda !).
Dans certains cas de proximité, il n'est même pas nécessaire de mettre une antenne, tant ces fréquences arrivent à s'infiltrer partout. J'ai tout de même remarqué des erreurs de transmission plus fréquentes.
Ces petites facilités permettent d'ajuster au mieux le niveau d'entrée du récepteur.
Pour l'anecdote, les récepteurs sont normalement équipés d'une CAG (Commande Automatique de Gain (HF)), mais à ce niveau de prix, j'ai bien peur que la CAG (Ou AGC) soit en proportion du prix et reste très peu efficace, si elle existe….?
On notera qu'il peut être délicat de modifier l'impédance de sortie d'un émetteur, aussi celui-ci sera toujours laissé avec une antenne à sa longueur nominale de y/4 de 17 cm.
(Vous pourrez vous amuser à faire un relevé de portée en terrain découvert en réglant finement le brin d'émission par raccourcissements successifs…)
2.3.8 Les parités
Ce point n'a pas été développé, mais je n'y attache pas un énorme intérêt. En effet, toutes les trames issues de la radio doivent être vérifiées en vraisemblance. Faut-il utiliser la parité ? Peut-être ! Mais la parité reste un contrôle fragile qui ne vaut pas un CRC et elle ne remplacerait pas non plus la vraisemblance.
(En liaison directe RS232, il n'y a pas de réel problème d'erreurs à ma connaissance si on respecte les distances maximum fonction de la vitesse).
D'autre part, ce contrôle doit être géré partiellement par logiciel sur le PIC et ne peut donc être totalement transparent. Ce contrôle ralentit aussi le débit réel puisqu'il y a un bit de plus à transmettre.
Alors le fait de compliquer un peu plus le travail du PIC, ralentir le débit et ne pas en obtenir un avantage déterminant, ne m'enchante pas. Je n'utiliserai donc pas la parité !
3 Conclusions
Je pense non pas avoir proposé un montage révolutionnaire, mais au contraire montré combien ce dispositif à priori ultra simple se révèle un peu imparfait, mais si utile cependant, car rien d'autre n'est en mesure de remplacer l'absence de liaison physique entre équipements.
Les communications par le "son" sont fortement limitées en débit. Les communications par la voie optique sont : ou très directionnelles ou nécessitent un support optique (fibre).
Si l'on peut se passer de la radio c'est encore mieux, mais ce n'est pas toujours possible, et c'est pour cela que j'ai rédigé cet article.
Cela vous permettra d'utiliser quelque chose qui donne satisfaction, tout en ayant en ligne de mire, toutes les cartes pour conjurer les inévitables erreurs dues au principe dont le parasitage est garanti.
A chacun de s'en affranchir.
Je n'ai rien dit sur les puissances d'émission, mais je crois que celles-ci ne peuvent dépasser légalement 10 MW suivant la réglementation Française. Cela reste à vérifier, et cela conduit le plus souvent à des portées "normales" ne dépassant pas 200 mètres.
Pour des portées supérieures, rien n'interdit d'utiliser des antennes en conséquence, tant à l'émission qu'à la réception. Heureusement, ces antennes sont de très petites dimensions.
La radio est très intéressante comme procédé, mais elle nécessite des contrôles complémentaires, pour garantir l'intégrité des données.
" Allez "Roger", sort le vapotron qu'on en finisse avec la portée rikiki"
____ (retour début d'article) ____
____ (retour accueil bricolsec) ____
____ ( retour accueil lokistagnepas) ____
/http%3A%2F%2Fstorage.canalblog.com%2F78%2F10%2F338014%2F116239131_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F55%2F24%2F338014%2F105236621_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F29%2F22%2F338014%2F74002382_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F36%2F08%2F338014%2F63028714_o.jpg)
/https%3A%2F%2Fprofilepics.canalblog.com%2Fprofilepics%2F2%2F8%2F289215.jpg)