Discussion :

[Bistru]

Bonjour,

J'ai réalisé un récepteur DCF 77 (une petite antenne radio qui capte l'heure de francfort) qui envoie sur mon port RS-232 un signal carré de période 300ms sur 1min.

Je souhaite maintenant récupérer ce signal à l'aide d'un programme C pour pouvoir ensuite le traiter et le convertir. (et in fine, obtenir l'heure )

Cependant, je n'arrive pas à déterminer les éléments de bases pour récupérer ce signal: Quelle(s) bibliothèque(s) dois-je importer et quels peuvent-être les fonctions associées. La solution optimale serait alors de pouvoir récupérer ce signal sous forme de tableau d'entier de 0 ou 1.

J'ai régulièrement codé des algorihtmes et des petites applications en C (3000~4000 lignes), aussi, je suis coutumier de la syntaxe, mais c'est la première fois que je m'attaque au hardware.

Aussi,

J'avoue que toute aide ou conseil serait la bienvenue. Merci beeaucoup!!!

[pfeuh]

Salut,

D'après les souvenirs que j'ai du DCF77, vu la lenteur du signal (1 bit/seconde, quelque chose comme ça?), il n'est pas directement récupérable sur une liaison série dont les vitesses commencent à 300 bauds. La broche RxD n'est de toute façon pas lisible. Le moyen généralement utilisé est un hardware extérieur à base de micro contrôleur qui reçoit les bits, fabrique l'heure en format texte et l'envoit sur le port série de façon classique.

A+

Pfeuh

[ram-0000]

D'après les souvenirs que j'ai du DCF77, vu la lenteur du signal (1 bit/seconde, quelque chose comme ça?)

C'est cela , bonne mémoire. Plus d'info ici

[Bistru]

Salut,

D'après les souvenirs que j'ai du DCF77, vu la lenteur du signal (1 bit/seconde, quelque chose comme ça?), il n'est pas directement récupérable sur une liaison série dont les vitesses commencent à 300 bauds. La broche RxD n'est de toute façon pas lisible. Le moyen généralement utilisé est un hardware extérieur à base de micro contrôleur qui reçoit les bits, fabrique l'heure en format texte et l'envoit sur le port série de façon classique.

A+

Pfeuh

Le "problème" est que je voulais justement éviter d'utiliser un pic. Du coup, je suis parti du montage suivant qui permet de traiter proprement le signal et de l'analyser directement sur le port série (du moins si j'ai correctement compris le circuit).

Le montage envoie alors un signal carré au port RS 232. Ce dernier devrait logiquement le convertir en binaire. Puis, j'espérais effectuer un traitement du signal numérique obtenu pour le diviser en 60 variables booléenne me permettant enfin d'obtenir l'heure... Je n'ai aucun problème sur ces niveaux de l'algorithme mais, il me faut encore récupérer mon signal électrique initial...

Sur internet, j'ai surtout trouvé des infos sur comment envoyer ou recevoir des chaines de caractères. J'aimerai pouvoir aller à un niveau encore plus bas.
De surcroit, a chaque fois, les exemples que j'ai obtenus étaient codé à partir de bibliothèque windows et j'aurai préférer bosser sur linux (mais, bon, je suis prêt à faire un écart)

[pfeuh]

Le "problème" est que je voulais justement éviter d'utiliser un pic. Du coup, je suis parti du montage suivant qui permet de traiter proprement le signal et de l'analyser directement sur le port série (du moins si j'ai correctement compris le circuit).

Oui, tu l'as compris, pas de souci. Mais ça m'a l'air d'être un montage assez vieux, plus de 10 ans, et les OS ont évolué entre temps. Sous DOS (je ne connais pas trop Unix mais l'évolution devrait être identique), on pouvait accéder au matériel et lire la broche Rxd comme un simple bit d'entrée. Actuellement l'OS verrouille tout mais te fournit en compensation des fonctions prêtes à l'emploi de gestion du port série... Qui ne fonctionnent malheureusement pas à des vitesses aussi lentes que celle du DCF77. Ce qui est peut-être un inconvénient pour toi, mais qui permet entre autre d'émuler le port série par des periphériques usb de façon totalement transparente pour l'utilisateur.

Il te reste une solution de bricoleur pour accéder à ce bit sauvagement, tape "UserPort " sur google. Je n'encourage pas, mais je sais que tu iras de toute façon. Sache cependant que ton appli ne tournera que sur des PC qui ont un vrai port physique et non pas une émulation usb, et encore, à la même adresse que le tien. De plus, autour de moi je vois de plus en plus de PC, à commencer par les portables, qui n'ont plus ce port. Sans parler des gens qui refuseront d'installer userport

[Obsidian]

Comme on l'a dit, 1 Hz, c'est extrêmement lent pour un ordinateur, surtout s'il est récent. Et quand je dis récent, ça va jusqu'à une dizaine d'années !

L'approche la plus censée à mon goût est d'utiliser l'un des signaux de contrôle de RS-232 (apparemment, le schéma que tu nous montres utilise DTR) autant pour relever la valeur instantanée du signal lu que pour déclencher une interruption (IRQ).

Sur réception de cette interruption, tu relèves la valeur de l'horloge de ton système (le tick count). Ensuite, soit la broche en question peut déclencher une interruption sur les deux fronts, et dans ce cas, tu compares le relevé d'horloge avec le précédent, soit tu programmes un timer fait pour se déclencher 130 ms plus tard et tu examines l'état de la broche. Sa valeur te donnera directement celle du bit en cours de transmission.

Cette technique peut être transposée au port parallèle si besoin (utiliser ACK).

[pfeuh]

Oui, très bonne technique, je ne savais pas qu'on pouvait le faire sur un PC. Ce que je conseillerais pour avoir réalisé en embarqué des uarts logicielles:

1- On récupère le bit de start par une it sur front. On dévalide l'it et on lance un timer d'une durée d'un bit et demi de façon à lire le port pile au milieu du premier bit.

2- Une fois le premier bit récupéré, On relance le timer à chaque réception d'un nouveau bit pour une durée de pile la largeur du bit.

3- le dernier bit (de stop) ne relance pas le timer mais revalide l'interruption sur front pour la prochaine donnée.

Une machine d'état (fsm, finite state machine) me parait bien pour gérer tout ça.

[Bistru]

Oui. Sous DOS (je ne connais pas trop Unix mais l'évolution devrait être identique), on pouvait accéder au matériel et lire la broche Rxd comme un simple bit d'entrée. Actuellement l'OS verrouille tout mais te fournit en compensation des fonctions prêtes à l'emploi de gestion du port série...

A part en usant UserPort (), c'est vrai que je ne vois pas de solution sous windows.
Cependant, il semble possible de repasser en mode natif (juste les bits I/O) sous Unix pour les ports. Pour cela, il faut utiliser la fonction cfmakeraw de la bibliothèque <termios.h> et d'utiliser la fonction getattr() sur le bon port ttys[0~3]. Je vais essayer de faire ca dans un premier temps.

Un problème reste tout de même présent: la vitesse de transmission comme vous l'avez dit. Le RS 232 a une vitesse de réception pouvant descendre jusqu'à 110 Bauds. J'ai réétudié le fonctionnement du DCF77, sa fréquence est effectivement de 1hz mais, il envoie un signal carré de 100ms pour un 0 et un signal carré de 200ms pour un 1 suivi d'un signal plat le reste du temps. cela simplifie un peu les choses.
Si je me met en 110 Bauds, je recevrai en 1 seconde
11 bits 1 et 109 bits 0 pour un signal de 100ms codant pour un 0
22 bits 1 et 88 bits 0 pour un signal de 200ms codant pour un 1
Néanmoins, cela fait beaucoup de bits inutiles utilisés. J'avais aussi à faire une demande "manuelle" au niveau du port RS 232 toutes les 50ms ou une demande en continue en travaillant directement sur le flux des données. Néanmoins, je trouve que calculer le temps entre deux fronts est assez élégante et de surcroit plus facile à programmer.

Après, je vais voir si je ne peux pas coupler les deux solutions. (Font montant/descendant et bit à 50 et 150ms).

Concernant le finite state machine, je vais faire des recherches à ce sujet car je ne connaissais pas.

En tous cas merci! Je vais essayer de coder tout ca d'ici vendredi soir. Si le code marche (ou pas...), je le mettrai surement en ligne.

[pfeuh]

il envoie un signal carré de 100ms pour un 0 et un signal carré de 200ms pour un 1 suivi d'un signal plat le reste du temps. cela simplifie un peu les choses.

Alors tu n'as pas de regrets à avoir, même en faisant abstraction de la vitesse, un PC est incapable de lire ça nativement. La solution de Obsidian est la meilleure. Il reste quelque chose que tu ne nous as pas dit, c'est comment identifier le premier bit des autres.

Si je me met en 110 Bauds, je recevrai en 1 seconde
11 bits 1 et 109 bits 0 pour un signal de 100ms codant pour un 0
22 bits 1 et 88 bits 0 pour un signal de 200ms codant pour un 1

Ca ne marche pas comme ça. Si tu configures ton port pour une donnée de 8 bits par exemple, tu reçois 10 bits, un start, les huit bits de donnée et un stop. Le bits de start est le front qui sert à initialiser le cadencement de la réception des autres bits. le bits de stop est un temps mort garanti après la réception des autres bits. Pour recevoir une deuxième donnée, il faut obligatoirement un front sur la ligne, donc le bit start de la prochaine donnée. C'est d'ailleurs ce qui permet d'envoyer des données de façon asynchrone. Ton idée de compter les bits ne peut pas marcher.