Jean-François FOURCADIER
F4DAY

Montpellier  (France)

projets radioamateurs

écrivez moi !  
© 2000-2016- J.F. Fourcadier
page d'accueil
haut débit télévision antennes hyperfréquences relais divers

 


Exemple de logique de relais VHF/UHF

application de la technologie polling/I2C

 

Dans un article précédent nous exposions les principes de la technologie polling/I2C. Rappelons que cette technologie permet d'assembler des modules matériels au gré des besoins et autorise donc une grande évolutivité des réalisations. On peut débuter simplement avec le module unité centrale et un module de commutation pour obtenir des temporisations précises, même très longues, puis ajouter un décodeur DTMF, des commutations audio ou vidéo, des modules de transmission, de visualisation, d'annonce vocale, etc... Le fonctionnement est de type temps réel. Les temporisations souhaitées, les différents évènements extérieurs même nombreux, n'interrompent pas le cycle d'analyse, de prises de décision et de mise en oeuvre des actions nécessaires. Le fonctionnement est dès lors très souple, sans temps morts ni bugs nécessitant quelquefois une reprise de numérotation. Plusieurs processus peuvent être gérés simultanément et indépendamment.

Les modules matériels utilisés dans cet exemple

Ce sont, pour plusieurs d'entre eux, des modules mis au point et utilisés dans une réalisation précédente:


module unité centrale - horloge

cliquer pour agrandir


module réception DTMF

cliquer pour agrandir


module interface radio

cliquer pour agrandir


module commutations audio

cliquer pour agrandir


générateur 1000 Hz

cliquer pour agrandir


ampli audio haut-parleur

 

Les interconnexions entre modules

Le schéma général d'interconnexions est le suivant:

cliquer pour agrandir

La liaison I2C entre les modules s'effectue de manière naturelle au moyen d'un câble blindé à deux conducteurs véhiculant les signaux SDA et SCL. Chaque fil est blindé séparément.

Pour le reste, rien de plus simple, il suffit de câbler les alimentations + 5V et + 12V.

On obsevera que le niveau audio est standardisé à 2 V crête à crête dans l'ensemble de l'équipement.

 

Le logiciel

Il est fourni à titre d'exemple et le lecteur pourra bien sûr l'adapter en fonction de ses besoins. Il est écrit en assembleur pour PIC 16F876:

télécharger le programme source transp.asm (20 ko zippé)

Il est nécessaire de compiler le programme source fourni, au moyen de MPLAB, puis d'introduire le fichier .hex obtenu dans le microcontrôleur PIC 16F876 grâce au logiciel ICprog paramétré avec l'option "AN589". Le module microcontrôleur-horloge autorise la programmation in-situ au moyen d'un simple câble raccordé au port parallèle d'un ordinateur portable. Il s'agit là d'une facilité et rien n'empêche bien sûr de procéder au changement de version logicielle d'une manière plus traditionnelle par débrochage puis rebrochage du PIC.

Les fonctionnalités disponibles:

L'émetteur est commandé par la réception d'une porteuse sur le récepteur. L'information est un niveau logique provenant du squelch du récepteur.

Nous avons à notre disposition quatre modes dits "modes administrateur" et trois commandes utilisateurs. Les modes administrateur sont activés par l'envoi d'un code secret suivi d'un caractère définissant le mode choisi. Les commandes utilisateurs sont publiques.

- le mode administrateur A
Le relais fonctionne pendant une durée de 120 minutes après l'envoi d'une commande utilisateur d'activation. L'utilisateur peut également décider d'arrêter prématurément le relais.

- le mode administrateur B
Le relais fonctionne dès l'envoi d'une commande utilisateur d'activation. L'utilisateur peut ensuite décider d'arrêter le relais. Il n'y a pas de temporisation.

- le mode administrateur C
Le relais fonctionne en service permanent. Les commandes utilisateurs sont inhibées, hormis la commande de beep long (signal 1000 Hz pendant 10 secondes) utilisée à des fins de test.

- le mode administrateur Z
Le relais est arrêté. Les commandes utilisateurs sont sans effet. Le récepteur et le décodeur DTMF restent cependant à l'écoute des codes transmis, dans l'attente d'une éventuelle demande de retour en fonctionnement.

- la commande utilisateur 0
Allume le relais

- la commande utilisateur 1
Eteint le relais

- la commande utilisateur 9
Le relais transmet à des fins de test un signal audio 1000 Hz pendant 10 secondes. Ceci est utile pour permettre des réglages d'antennes ou de récepteurs.

Le système n'est pas fermé. Lorsqu'on a bien compris la structure du logiciel, explicitée plus bas, il devient facile de modifier des paramètres, d'ajouter de nouveaux modes administrateur ou de nouvelles commandes utilisateurs !

Un accusé réception, sous la forme d'un beep de fréquence 1000 Hz et de durée 800 ms, est par ailleurs émis après chaque commande active.

Description succincte du logiciel

Le logiciel est écrit en assembleur 16F876 et conçu de manière modulaire. Pour les commentaires, on se rapportera au fichier transp.lst qui comporte des numéros de lignes.

télécharger le programme source transp.asm (20 ko zippé)

La ligne 033 indique la configuration retenue pour le PIC (état des "fusibles"). Dans cette version nous n'activons pas le watchdog.

De la ligne 036 à 093, nous trouvons la déclaration des différentes variables utilisées dans le programme.

De la ligne 112 à la ligne 221, se trouvent les routines I2C. Il y a là plusieurs heures de travail personnel avant d'obtenir un fonctionnement correct. Aussi, sauf si l'on est un expert du domaine, il est déconseillé de toucher à ces routines. La procédure pour envoyer un octet à un périphérique est très simple: on entre l'adresse I2C du périphérique dans la variable "SlaveAddr", puis l'octet à transmettre dans la variable "ByteToSend". Il suffit ensuite d'appeler le sous programme d'émission par la ligne "call Send_Byte" pour déclencher l'envoi du message I2C.

exemple de code:

movlw 0x24 ; address of radio module
movwf SlaveAddr
movlw b'01111111' ; TX ON, Audio from RX ON
movwf ByteToSend
call Send_Byte

La procédure de lecture des octets sur un périphérique est similaire avec un appel par l'instruction "call Receive_Byte", l'octet lu étant récupéré dans la variable "Received_Byte".

De la ligne 222 à la ligne 343 nous trouvons la routine d'initialisation du circuit horloge PCF8583, puis la routine de lecture de l'heure système : centièmes de secondes, secondes, minutes et heures, soit quatre octets. Les variables Hundredths, Seconds, Minutes et Hours sont mises à jour. Les jours et mois seraient disponibles, mais ne sont pas chargés.

De la ligne 344 à la ligne 422, nous trouvons les routines de gestion de l'octet "administrateur". Celui-ci est essentiel au fonctionnement du relais car il conditionne son comportement. Il ne doit bien sûr pas être altéré par une coupure de secteur. Aussi, est-il sauvegardé en EEPROM dès son acquisition ou sa modification. Après un arrêt du système, une procédure d'initialisation restaure le contenu de l'octet "administrateur" à partir de son image sauvegardée en EEPROM.

De la ligne 423 à la ligne 443 nous trouvons deux fonctions d'initialisation et de lecture des codes DTMF sur le module de réception DTMF. Les lignes 444 à 470 réalisent les mêmes opérations pour le module interface radio.

A la ligne 471 débute le programme principal, par une séquence d'initialisation de tous les modules périphériques, puis la grande boucle à la ligne 493.

A noter que la communication entre les différentes sections du logiciel s'effectuent au moyen de drapeaux ou "flags". Leur signification précise est détaillée dans une page spécifique.

Les lignes 497 et 498 servent à génerer une impulsion test de 1 µs, d'amplitude 5 V sur la patte RB1 du 16F876. On peut ainsi mesurer facilement, au moyen d'un oscilloscope, le temps mis pour boucler la boucle: utile dans un système "temps réel" !

cliquer pour agrandir
cliquer pour agrandir
le test de la durée de boucle: ici T = 1700 µs

A la ligne 503 nous débutons la réception et l'analyse des codes DTMF reçus. Les caractères reçus sont stockés dans un buffer circulaire de 16 chiffres "Digit_Counter", grâce à un adressage indirect. Une mise en phase est assurée lors de la réception d'un caractère particulier: ici le caractère " * ".

Nous trouvons ensuite les échelles de décodage des séquences utilisateurs et administrateur. Le 6ème et 10ème caractère, respectivement, sont sauvegardés comme étant l'octet utilisateur et l'octet administrateur.

Bien que purement logiciels, les timers sont très précis. Leur nombre est ici de trois, mais n'est en fait pas limité. Nous faisons appel à un algorithme simple mais très efficace:
Nous avons vu que nous chargions l'heure système, heures, minutes, secondes et centièmes de secondes, dans des variables spécifiques en début de chaque boucle. Pour réaliser par exemple une temporisation de 120 secondes, il suffit d'observer la valeur du chiffre des secondes et d'incrémenter un compteur chaque fois que le chiffre des secondes de l'heure système est modifié entre deux cycles successifs. Lorsque le compteur atteint la valeur 120, la temporisation est écoulée.

A partir de la ligne 765, nous trouvons les arbres de décision qui déterminent les actions à mettre en oeuvre en fonction de l'environnement (squelch, CTCSS, temporisations,...), et des valeurs des octets utilisateurs et administrateur.

Les messages I2C d'allumage ou d'extinction de l'émetteur et de sélection de la source audio sont situés à partir de la ligne 801.

Enfin, la ligne 829 marque la fin d'un cycle et le renvoi vers le début de la boucle.

La réalisation

Ci-après les photographies, de la face avant de la réalisation et de l'intérieur du coffret:

cliquer pour agrandir
cliquer pour agrandir

Sur la face avant on observera à droite la prise Sub-D permettant la programmation in-situ ainsi que le voyant signalant que l'on est en mode programmation.

 

Conclusion

Nous venons de décrire un exemple d'utilisation de la technologie "polling/I2C" qui permet une grande diversité et une évolutivité des réalisations.

L'utilisateur pourra modifier à son gré le logiciel: modifications de paramètres, introduction de nouveaux modes administrateur ou de commandes utilisateurs, ou bien ajouts de nouveaux modules matériels qui sont particulièrement simples à construire. Les composants utilisés sont répandus et peu coûteux.

Le système décrit fonctionne aujourd'hui parfaitement sur table. Il sera prochainement validé en situation opérationnelle.

Allumons nos fers à souder, et bonnes réalisations !

 

 

73 de Jean-François FOURCADIER, F4DAY

 

 

retour à la page d'accueil du site

 

 

 

© 2000-2016  J.F. Fourcadier F4DAY