Calculer la période d'une horloge

**barthelv** · 27/02/2004, 11h10

Bonjour, voici mon problème, et c'est à mon avis pas simple:

J'ai une horloge dont je souhaite connaître la période et un signal qui sert à envoyer des octets d'un dispositif électronique à un autre. Ce signal est codé ainsi:

Au repos, le signal est à l'état haut.
lorsque je veux envoyer un octet, j'ai:
- 1 StartBit (front descendant)
- 8 états qui sont soit haut soit bas, pour coder l'octet
- 1 bit de parité

ainsi, un octet est donc codé en 10 coups d'horloge. Je veux donc deviner la période de mon horloge en analysant mes octets.

MAIS la grosse difficulté vient du fait que au cours du temps l'horloge peut changer de période entre deux octets.

En conslusion: comment faire pour connaître la période de l'horloge pour chacun de mes octets

:

Si vous avez une idée, ou si au moins vous pouviez me donner une condition supplémentaire dont j'aurais besoin pour pouvoir calculer ces périodes, faites moi signe

[EDIT]
- Je peux connaître avant de commencer l'analyse la période max, min et de départ de mon horloge.
- De plus je connais la totalité de mon signal avant de commencer à l'analyser.

**khayyam90** · 27/02/2004, 15h11

bien le bonjour,

Envoyé par barthelv

au cours du temps l'horloge peut changer de période entre deux octets.

as-tu une idée de la manière dont la période change entre 2 octets ?

si j'ai bien compris, tu envoies 1 o avec une certaine période, changement de période, 2ème o avec cette nouvelle période, changement.......envoi du dernier o avec la dernière période . c bien ça?

connais-tu l'intervalle de temps entre chaque envoi d'o ?

as-tu accès à ton horloge à chaque instant, (par exemple pour lui demandez le nombre de cycles écoulés depuis un certain moment) ?

si tu réitères plusieurs fois tes envois d'o, se passe-til toujours la même durée, autrement dit est-ce que c'est toujours la même chose ?

**barthelv** · 27/02/2004, 16h04

En fait ce qu'il se passe, c'est que sur la ligne d'I/O, les octets sont codés au moyen de l'horloge. Ainsi, on commence par voir transiter sur l'I/O des octets qui sont codés en 10 coups d'horloge quoi qu'il arrive (start bit, 8 bits, bit de parité). Cependant, pour une raison externe, il peut arriver que entre deux octets, la fréquence de l'horloge change (du style divisée ou multipliée par 2). Du coup, comme les octets qui transitent restent codés sur 10 coups d'horloge, ces derniers sont "plus courts" ou "plus longs".

Or moi j'ai un algo externe à tout cela qui analyse ce qu'il voit sur la ligne d'I/O mais qui ne connait pas la période des coups d'horloge. Du coup si je ne connais pas cette période, je ne peux pas deviner la valeur des octets... Et c'est bien là le problème.

Concernant l'intervalle entre chaque envoi d'octet, je ne le connais pas mais il est plus grand qu'un octet, au moins 3 fois plus grand, voir plus de temps en temps.

Malheureusement je n'ai aucun accès à l'horloge. En fait elle sert à envoyer les octets et moi je récupère ce signal, mais je ne connais pas l'horloge. Au mieux je connais sa valeur de départ utilisée pour l'envoi des premiers octets. Je peux connaitre aussi sa valeur min et sa valeur max. Mais c'est tout.

**khayyam90** · 01/03/2004, 09h47

tu cherches à filtrer un signal de période aléatoire changeant à chaque o.

cette simple description me laisse penser que dans la situation actuelle, point de salut

le seul moyen que je vois pour l'instant est d'envoyer chaque o séparément autant de fois qu'il le faudra pour que la période d'envoi coïncide avec celle que tu as choisis arbitrairement (avec la min et la max). suis d'accord que ça risque d'être long et que c'est pas bo mais tu cherches à casser un message aléatoire quand même !

**victorracine** · 01/03/2004, 15h51

salut,

Je me souviens (de mes lointain cours d'elec) qu'il y a un systeme de codage binaire qui permet de ne jamais avoir un etat constant durant plusieur cycle pour le ne pas desynchroniser l'horloge, mais je ne me souviens plus du nom. Par contre ce qui serait assez simple à mon avis c'est de transformater ton premier bits StartBit en 3 bits 010 pour connaitre automatiquement la frequence de l'horloge. De meme, on pourrait ajouter un à nouveau 1 bit 0 à la fin apres le bit de parité pour mesurer la duré entre le debut de la transmition et la fin (le front montant suivide X etat indique la fin di mot) afin de verifier que l'horloge n'a pas changé de tempo durant la transmition de l'octet.
A+
VIc

**Masterglob** · 01/03/2004, 18h53

A priori, ca va etre difficile, en imaginant que tous tes bits valles 1, tu sera incapable de determiner la frequence

De plus, si tu as 2 bits identiques plusieurs fois de suite (mettons 10 fois de suite), il est sans plus d'informations impossible de juger si la frequence n'est pas deux fois plus faible...

**victorracine** · 02/03/2004, 10h02

je pense qu'on peut s'y retrouver si on encadre l'octet avec des bits bien choisis qui mettent en evidance la frequence. De plus il faut utiliser le fait qu'entre 2 transmitions d'octets il 3 fois ou plus le temps de transmition d'un octet.
Ainsi avec:
N bits à 1 (rien ne se passe)
3 bits de debut 010
8 bits d'octet
1 bit de fin à 0
M bits à 1 (rien ne se passe)

On commence à lire la transmistion à la detection du premier font bas.
On calcul la periode grace au 010.
On enregistre ce qu'il se passe apres le 010 sur le temps maximum de transmistion de l'octet et du bit de fin. Dans l'enregistement, en le lisant à partir de la fin, on cherche le premier front desendant qui indique la position du bit de fin. Maintenant qu'on a la fin et le debut on peut verifier que le systeme n'a pas changé de periode au cours de la transmisiton (i.e. si la periode calculé pour le 010 du debut correspond à la periode des 9bits suivant).
Donc par cette methode ca permet de calculer la frequence de transmistion et de verifier qu'elle n'a pas changé durant la transmision de l'octet. Par contre ca ne permet pas de comprendre l'octet si la frequence du system change durant sa transmision.

A+
VIc

**barthelv** · 04/03/2004, 15h06

Je me doutais qu'il n'y avait pas de solution, car en fait je ne peux pas changer le signal d'I/O, moi tout ce que je peux faire, c'est l'analyser.

Toutefois je tiens à préciser que la fréquence ne change pas entre chaque octet, mais seulement elle peut changer entre deux octets. Donc à mon avis , je peux me servir de cela pour faire une moyenne sur un période de temps pour trouver la période de l'horloge à condition de ne pas avoir que des "FF"... Mais bon suivant ce qui passe sur le signal, je ne peux pas être sûr que cela fonctionne...

Il va donc falloir que je trouve autre chose

**victorracine** · 04/03/2004, 16h22

SAlut,
en effet je pense que ton probleme est insolvable en absolu. Par contre je pense qu'il y a statistiquement beaucoup plus cas où tu peux resoudre ton signal que de cas ou tu ne peux pas.
Par exemple pour un signal:

11111111111111100111001111111111111
si tu comptes le temps des differents paquets de meme bits, et le temps pour entre les 2 0 les plus eloigné:
T(00)=1s,
T(111)=1,5s
T(00)=1s
tu peux donc affirment que si la periode du signal est t alors
1s=t*p et 1,5=t*q avec p et q 2 nombres entiers. Tu as donc q/p=3/2. Comme le plus petit denominateur commun de 3 et 2 est 1 tu peux affirment que la frequence du systeme est une fraction entiere de 0,5s (car 0,5s=1s/2 ou 0,5s=1,5s/3).
les configuration possibles sont ainsi:
t1=0,5s; t2=0,25s; t3=0,1666s.... Une fois que tu as fait ce calcul tu peux retirer les ti qui n'appartiennent pas à ton intervale de periode de ton signal. Pour chaque ti restant tu peux tester si la valeur du bit de parité est bonne sans quoi il faut retier le ti.

J'ai fait quelques calculs et j'ai l'impression que seul si il n'y a qu'un paquet de bits identique, la methode proposé et fonctionne pas toujours.

par exemple si on a:
11111111100001111111111111111111
T(0000)=1s
comme il n'y a qu'un paquet on ne peut pas utiliser le denominateur commun. On juste dire que t_i=1s/i (i=1..n). Or si i est impaire, on ne respecte plus le bit de parité donc l'ensemble des solutions est t_i=1s/i (i=2..2n). En plus on peut voir que le plus grand paquet de bit identique est 10 (dix zeros) i<=10 et i paire donc i={2,4,6,8,10}.

Enfin on peut se demander si un transmition avec un unique bloc de bits similaire est courrant:
on ne peut denombrer de 5 combinaisons differents:
111100111111111
111100001111111
111100000011111
111100000000111
111100000000001
or on peut passer 2^8=256 combinaison d'octet differents
on peut donc affirmer qu'on peut decripter le signal avec une probablilité de p=0,980. Dans le cas ou le signal est inresolvable, il y a au plus 5 valeurs possible.
Ce qui est quand meme pas mal!!!! 8)
A+
VIc

**barthelv** · 04/03/2004, 17h04

Ta solution me semble pas mal du tout, je vais essayer cela. Etant donné le type de signaux que j'analyse, je pense qu'en effet ta méthode devrait très bien fonctionner (il est rare pour moi d'avoir que des octets de type 00 ou FF, de plus je connais les endroits où il y a une possiblité que la période de l'horloge change). Je vais donc essayer de coder cela, et je vous tiendrai au courant des résultats obtenus.

Merci.